Probably a 200 GB download too.
xubu
You are implying that any data gathered will be delivered to the government upon request (unsure if you are implying with or without a warrant). If you can show me from this article, or even this case, regarding this privacy case that that happened, then yes I agree with you and the fourth amendment applies.
But this issue is between private entities which generally precludes amendments from being applicable. Specifically, the plaintiffs alleged that the infotainment systems collected and stored personal data without consent and violated Washington's Privacy Act.
The "unlawful search and seizure" amendment? Why would that apply here?
What is agreeable for social safety net(s) from the perspective of conservatives?
Single payer healthcare? Universal Basic Income? More expansive food subsidies? More expansive housing subsidies?
What is not considered "government hand out" that we can all agree on?
Next up, mute detection...
I'm in IT security and I'm fighting this battle. I want to lessen the burden of passwords and arbitrary rotation is terrible.
I've ran into a number of issues at my company that would give me the approval to reduce the frequency of expired passwords
-
the company gets asked this question by other customers "do you have a password policy for your staff?" (that somehow includes an expiration frequency).
-
on-prem AD password complexity has some nice parts built in vs some terrible parts with no granularity. It's a single check box in gpo that does way too much stuff. I'm also not going to write a custom password policy because I don't have the skill set to do it correctly when we're talking about AD, that's nightmare inducing. (Looking at specops to help and already using Azure AD password protection in passive mode)
-
I think management is worried that a phishing event happens on a person with a static password and then unfairly conflating that to my argument of "can we just do two things: increase password length by 2 and decrease expiration frequency by 30 days"
At the end of the day, some of us in IT security want to do the right things based in common sense but we get stymied by management decisions and precedence. Hell, I've brought NIST 800-63B documentation with me to check every reason why they wouldn't budge. It's just ingrained in them - meanwhile you look at the number of tickets for password help and password sharing violations that get reported ... /Sigh
RDC could be a good option to uninstall for businesses where the machine acts as a terminal and you don't want those devices launching RDC to begin with Not sure why it hasn't been allowed already.
Paginated login
Microsoft enabled it in ADFS on WS 2019. I know there are plenty other places it's used, but It's the example I'm most familiar with.
There can be a security element to it depending on how the server handles paginated auth as it separates the password field away from the user ID. You can also interject the second factor first before the password to protect brute forcing.
But the larger reason I've read is that it's easier for end users to use. Here's MS talking about it with ADFS.
"Instead of a long form to fill out, a new flow takes you through the sign-in experience step-by-step. Our research shows that with this approach, our customers have more successful sign-ins."
https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/operations/ad-fs-paginated-sign-in
Whether this is true or not is debatable. I'd love to see passwords die out. I doubt I'll see that in my lifetime though.
Currently in hybrid situation. 65k+ users, two main forests.
A lot of things. -What is your auth strategy? How do you want users to log in? You said you want to use local dc auth but you have three different ways of doing it: password hash sync, pass thru auth, or federation (typically adfs). (Don't do federation though, I really don't recommend it).
-make sure your users user principal names match their email addresses. In most cases when MS asks a user for email for their username, they are asking for their upn. It'll be easier on everyone when their upn and email match.
-what is your two factor strategy? If you don't have one, maybe look at Microsoft's offering. This may sway your auth strategy slightly.
-look at Azure Cloud Sync first before Azure AD Connect. They both perform the same function -synchronizing on prem objects in AD to AAD. Cloud sync is where MS wants to go but it's not feature parity with AAD Connect. Likely would guess you'd end up with AADConnect
-We are currently doing Exchange migrations to Azure now. And it's going I guess. It's not easy, particularly with the sync side of things. I don't have a lot to say here except I know it's a massive process for us. I only see parts of it. GPOs, conditional access, adjusting in our MDM solutions to work with migrated mailboxes, etc.
-Use dynamic licensing groups where you can. Makes app on boarding easier.
I could go on for days. Looking back I really wish I had banged the drum to do password hash sync. Federation domains into Azure feels pretty bad in a lot of ways and only helpful in a small subset of others. I expect you'd do seamless sso too, to make using m365 apps easy.
Yes and no. The people that truly keep the lights on to critical systems I think are more insulated. I deal with active directory (and azure to an extent). I'm one of two engineers that are attuned to what is going on in AD in a 65k+ staffed company. I do other things than AD, but it needs care and feeding.
AD is going to stick around for a lot longer and may end up being in that cobol state where companies have it for critical things but there are few who truly understand how to work it.
Everyone else may end up in a DevOps-esque role. Then you have the scope of the industry too. I think this article overblows the premise it puts forth.
Duo. After Cisco bought out Duo, however, they did not like our original contract. Now our CISO is saying for us to explore Microsoft. 65k+ staffed company.
The problem I've had with duo is that a user counts towards a license just by existing within your duo tenant (correct term?). Meaning that even if the user has no devices associated and cannot perform 2fa, they still have a cost.
I found it eye opening when they talked about Duo SSO (their own identity provider, think adfs). I may be wrong but my thoughts was "okay, but duo is cost restrictive to us, are you saying we need to onboard everyone just so they can get to internally federated applications?". Didn't feel great.
You look at their directory synchronization tool, it's the same thing, it will onboard users no problem, but you pay for those users the moment the account exists.
I have no problem saying everyone should have to perform mfa, but if you mfa all your ingress points and highly sensitive data, paying for everyone whom may not require or use it is a waste of money.
What we did was an opt in approach. You register on your own time via onpremise portal that uses their API to register the user and their device. If you don't do that and end up needing it externally, well too bad. In extreme scenarios we can admin register a user .
Really cool photo! Well done ๐
Just curious, why is the light for the partial eclipse that specific color vs the full eclipse? Stylistic?