Parks contractors must sign in through a separate identity provider and must not be able to reset city Active Directory passwords. How should the administrator design that identity provider?
Select an answer to reveal the explanation.
Short Explanation
A contractor IdP is a visitor badge printer, not a master key to city AD. Keep it isolated—no write-back, no domain-admin LDAP. Adding an IdP in Access does not mean that IdP may reset civic passwords.
Full Explanation
Parks contractors must sign in through a separate identity provider and must not be able to reset city Active Directory passwords. Keep the contractor identity provider isolated with no write-back to civic Active Directory—a visitor badge printer, not a master key to city AD. Enabling directory write-back from the contractor identity provider into civic Active Directory so passwords stay in sync fails by concept because write-back creates a path for contractor IdP influence over civic credentials. Granting the contractor identity provider domain-admin LDAP rights so it can unlock staff accounts fails because domain-admin rights for a contractor IdP violate isolation and least privilege. Replacing civic Active Directory with the contractor identity provider for every city application fails because contractors should not become the city’s sole directory for staff apps. Exam caveat: contractor IdPs in Access stay isolated—no write-back, no domain-admin LDAP, no replacing civic AD citywide. Operational check: configure the contractor IdP without write-back, verify contractor SSO to allowed contractor apps, attempt any password-reset path into civic AD and confirm it does not exist, and review LDAP rights for connector accounts. Document the isolation boundary in the parks contractor onboarding guide for auditors and seasonal vendor managers.