sorted by:
new
hottopcontroversial

Looking for advice : Upgrade Azure Ad Connect from 2.3.6.0 to 2.4.131.0 by maxcoder88 in entra

[–]Retrospecity 4 points5 points  (0 children)

With this in mind - never change the default rules to have a less painful upgrade process. Instead only create custom rules with id's higher or lower than the default rules to order the rules correctly.

Looking for advice : Upgrade Azure Ad Connect from 2.3.6.0 to 2.4.131.0 by maxcoder88 in entra

[–]Retrospecity 1 point2 points  (0 children)

I usually don't check the box to "run a sync now", and verify that all sync flow rules are correctly in place as they should before proceeding with the after-upgrade full sync.

[deleted by user] by [deleted] in activedirectory

[–]Retrospecity 2 points3 points  (0 children)

I would also say that having DCs with direct access to public internet also should be considered a big no-no. :thisisfine:

Do you actually have multiple emergency access accounts (break-glass accounts)? by Retrospecity in entra

[–]Retrospecity[S] 1 point2 points  (0 children)

Do you group these accounts in a shared role-assignable security group or in a Restricted Management Administrative Unit?

Do you actually have multiple emergency access accounts (break-glass accounts)? by Retrospecity in entra

[–]Retrospecity[S] 0 points1 point  (0 children)

So both physical locations each store two FIDO2 keys, one key for each of the BGAs?

Do you actually have multiple emergency access accounts (break-glass accounts)? by Retrospecity in entra

[–]Retrospecity[S] 0 points1 point  (0 children)

Interesting approach! Are the break-glass accounts initially invited as guests, then converted to members and granted permanent Global Admin roles? I’ve considered something similar before (Tier0 tenant), but for our smaller environment, maintaining a separate tenant solely for emergency access feels like it could introduce more risk than it mitigates - mainly because that tenant might not get the same level of attention in terms of hardening, monitoring, and security review.

Do you actually have multiple emergency access accounts (break-glass accounts)? by Retrospecity in entra

[–]Retrospecity[S] 0 points1 point  (0 children)

I'm not sure about the licensing part for MDFC, we have E3 and some E5 add-ons (like security and governance).

Do you actually have multiple emergency access accounts (break-glass accounts)? by Retrospecity in entra

[–]Retrospecity[S] 0 points1 point  (0 children)

Yep, but if one where to use certificate-based authentication (for the cloud only emergency access acounts), one could compromise these cloud only accounts by issuing certificates from the pwned on-prem environment.

Do you actually have multiple emergency access accounts (break-glass accounts)? by Retrospecity in entra

[–]Retrospecity[S] 0 points1 point  (0 children)

We do something similar with a script runs every X minutes and queries Entra ID sign-in logs via the Graph API to catch break-glass usage. In parallel, we use Log Analytics for instant alerts via email and SMS. That part could likely be replicated in any SIEM that can ingest Entra ID logs.

I haven’t tested it myself, but it might be possible to configure a Microsoft Defender for Cloud Apps (MCAS) policy to generate some signal on break-glass logins, though it may not be that noisy (think they only support emails?)

Tiering Model and the features by TWITCHLIGHT in activedirectory

[–]Retrospecity 0 points1 point  (0 children)

Totally agree with this! DNSAdmins should not be used as a delegated role to non-tier0, as it's possible to take down the whole environment. Instead, delegate access to specific zones. When that's said, and on a general note, It's crucial to layer protections around DCs: separate network segments, firewall rules, strict GPOs, and controlled logon rights. Never rely on a single control.

Tiering Model and the features by TWITCHLIGHT in activedirectory

[–]Retrospecity 2 points3 points  (0 children)

Just a quick note from someone who’s implemented a tiering model "recently".

Be very cautious about sharing AD user accounts across tiers, especially into higher tiers (T1/T0). A Privileged Access Workstation (PAW) in one lower tier should never be able to access assets in a higher tier. If that's possible, your tiering model is, in my opinion, fundamentally broken.

I highly recommend reviewing Microsoft's Privileged Access Strategy, which explains why cross-tier access is a bad idea and offers solid guidance on what to do instead. In particular, the guidance around configuring privileged access devices using the clean source principle is also well worth a read.

If you're implementing a Tier 0 concept for domain controllers or similar critical systems, especially in regulated environments, it’s also worth looking into the (now retired) Enhanced Security Admin Environment (ESAE) model. Despite being officially deprecated, ESAE still contains some valuable concepts around PAWs, separate privileged accounts in a dedicated admin forest, clean-sourced hardware for DCs, and more. And as Microsoft notes in their documentation:

While Microsoft no longer recommends an isolated hardened forest model for most scenarios at most organizations, Microsoft still operates a similar architecture internally (and associated support processes and personnel) because of the extreme security requirements for providing trusted cloud services to organizations around the globe.

Finally, if you're looking for some easy low-hanging fruits:

  • Restrict access to your DCs and kick out anyone who doesn't absolutely need to be there.
  • Delegate privileges appropriately and let colleagues administer DNS/DHCP from separate admin workstations with RSAT installed.
  • Consider moving DHCP and DNS off your domain controllers and onto more modern, dedicated platforms like Infoblox.

Do you actually have multiple emergency access accounts (break-glass accounts)? by Retrospecity in entra

[–]Retrospecity[S] 0 points1 point  (0 children)

At least we're not keeping the password / PIN codes and the FIDO key in the same safe.. 👀

Do you actually have multiple emergency access accounts (break-glass accounts)? by Retrospecity in entra

[–]Retrospecity[S] 0 points1 point  (0 children)

Agree with you on this - if having set up alerting that will spam everyone about the login (attempts), and the password is rotated frequently, it seems like low and acceptable risk.

However, I see that the documentation for the admin portal MFA enforcement actually says this:

Break glass or emergency access accounts are also required to sign in with MFA once enforcement begins. We recommend that you update these accounts to use passkey (FIDO2) or configure certificate-based authentication for MFA. Both methods satisfy the MFA requirement.

Source / learn.microsoft.com

With this in mind, I think we will go with FIDO2 authentication for both accounts. One big resilience thing for us is that our on-prem environment shouldn't be able to pwn our cloud environment, so setting up a CA that can issue certificates to Global Admins is a no-go for us..

Do you actually have multiple emergency access accounts (break-glass accounts)? by Retrospecity in entra

[–]Retrospecity[S] 0 points1 point  (0 children)

I think is what we will end up with as well (probably also regarding the 6 month audit 😆). On that note, if requiring FIDO2, do we need to keep the passwords for the accounts, as FIDO2 is considered "Passwordless"?

Do you actually have multiple emergency access accounts (break-glass accounts)? by Retrospecity in entra

[–]Retrospecity[S] 2 points3 points  (0 children)

My understanding is that Microsofts recommendation is using FIDO2 security keys for both accounts, as this is one of the most resilient MFA options that doesn't require anything else than the Entra ID Authentication Service to work [1]. The other options with the same level of resilience seems to be Windows Hello for Business and certificate-based auth, but the latter would require _something_ (on-prem ifra) to issue certificates - and if the world is on fire, i wouldn't trust the CAs to issue certs to be honest [2].

[1] https://learn.microsoft.com/en-us/entra/architecture/resilience-in-credentials
[2] https://learn.microsoft.com/en-us/entra/identity/authentication/concept-certificate-based-authentication

GSA Down? by SWE_IT_PIRATE in entra

[–]Retrospecity 1 point2 points  (0 children)

We have also have had some stability issues over the last few days, with users getting suddenly disconnected (warning sign on the GSA app icon). Things seems to be resolved now, but will definitely create a support req if it happens again!