Free Identity and Access Management practice questions

Inheritance flows the parent folder's Read for Domain Users down to every subfolder, and allow entries add together, so the executives' new entry widens access without replacing what was inherited. Nothing about the folder looks wrong until someone checks effective access, which is how sensitive folders inside broad shares end up readable by everyone.

Windows stores permissions against the account's security identifier, not its name, and recreating a deleted account produces a new SID, so entries granted to the old account no longer apply and show as an unresolved SID. Re-adding her groups restores only group-based access. That is one reason accounts are disabled first and deleted after a retention period: a disabled account keeps its SID and everything tied to it.

A sound mover process treats a role change like a leave followed by a join: the old role's groups come off on the effective date, the new role's groups go on, and any old access still needed is requested and approved explicitly. Keeping old access until a review, through a handover or as read-only is how employees end up holding access from several jobs, which is privilege creep.

Identity proofing confirms the person before a credential exists, and for a remote hire that means checking a document and matching it to the live person, for example with a selfie match or a supervised video session. A FIDO2 key is the tempting choice, but strong authentication can't help if the credential goes to the wrong person, and a birth date or an emailed password proves nothing about who is on the other end.

With the signing key, attackers can mint assertions for any user that every service provider will accept, without touching a password or an MFA prompt; this is Golden SAML, and keeping the key in an HSM or managed key service protects it. MFA is the tempting answer, but forged assertions skip the IdP's sign-in entirely, and a shorter validity window only means the attacker mints fresh ones.

Consent phishing gives the attacker's app its own OAuth tokens, so no password was stolen and resetting it doesn't cut the app off; the fix is to revoke the app's consent grant and restrict which apps users can approve without an administrator. Another password reset, number matching and a new MFA device all protect the sign-in, which the attacker never needed.

OpenID Connect adds an ID token on top of OAuth: a signed JSON Web Token with claims such as the issuer, the user's identifier and the intended app. An OAuth access token is the tempting choice, but it says what an app may do, not who the user is; SAML assertions are XML designed for browsers, and an LDAP bind makes the app collect the user's password itself.

When every application checks the same directory password, users have one password but still type it into each app, and each app handles it; that is same sign-on. With true SSO the applications never see the password, federation means one organization's IdP vouches for users at another's service, and delegated authorization is what OAuth provides.

An assertion's conditions limit it to one audience, here the CRM, and a short time window, so it is useless to a different service and worthless a few minutes later. A copied assertion still carries a valid signature, which is exactly why the conditions matter, and the attribute statement and issuer don't restrict where or when it can be used.

Kerberoasting cracks the part of the ticket encrypted with a key derived from the service account's password, so a long random password, or a group managed service account whose password the domain rotates, makes the offline cracking impractical. Denying interactive logon is the tempting choice, but it limits what a known password can do rather than how hard it is to crack, and lockout never triggers because the guessing happens offline.