Seamless SSO: protecting the AZUREADSSOACC account and rolling over its key
In almost every hybrid environment we audit, a computer account called AZUREADSSOACC sits in Active Directory with a password that has not changed since Entra Connect was installed. This account is anything but harmless: its key can be used to sign in to Entra ID as any synchronised user.
How Seamless SSO works
Seamless single sign-on lets a user signed in to a domain-joined computer access Microsoft 365 services without typing their password again, when the computer is on the corporate network or can reach a domain controller. When the feature is enabled, Entra Connect creates a computer account, AZUREADSSOACC, in each forest; it holds the service principal names used by Entra ID. The Kerberos decryption key of that account is securely shared with Entra ID.
At sign-in, the browser obtains a Kerberos ticket for this service from the domain controller and presents it to Entra ID, which decrypts it with the shared key and identifies the user.
Why this account is so sensitive
Anyone who knows this account's key can forge a Kerberos ticket for any synchronised user and present it to Entra ID. They then get an authentication as that user without knowing their password. Conditional Access still applies, and MFA will be required if policies say so, but the attacker has cleared the first hurdle. The account must therefore be treated as a Tier 0 asset: its secret is as valuable as that of a federation service account.
Rolling over the key regularly
Unlike ordinary computer accounts, AZUREADSSOACC does not change its password automatically. Microsoft recommends rolling over the decryption key at least every 30 days. This is done from the Entra Connect server, with the PowerShell module provided, and requires domain administration rights as well as an appropriate Entra ID administrative role.
- Run the rollover only once per forest per cycle: two rollovers in quick succession break the feature until users' Kerberos tickets expire.
- If you automate the operation, protect the credentials it uses to the same standard as the account itself.
- Check the password last set attribute to confirm that the rollover actually happened.
Protecting the account in Active Directory
- Place it in an organisational unit whose permissions are limited to Tier 0 administrators, and make sure no inherited delegation lets anyone else modify it.
- Do not delete or disable it: the feature would stop working.
- Check its supported encryption types and make sure AES is used rather than RC4, in line with current Microsoft documentation.
- Monitor any change to its attributes and service principal names.
A computer account, not a computer. Scripts that clean up inactive computers sometimes delete AZUREADSSOACC, since it never logs on to the domain. Exclude it explicitly from such jobs.
Do you still need it?
On recent Windows devices that are Entra joined or hybrid joined, single sign-on relies on the Primary Refresh Token (PRT) and does not need Seamless SSO. The feature remains useful for computers that are only domain joined, or for older systems. If your whole fleet is hybrid joined or Entra joined, turning it off reduces the attack surface. This is done from the Entra Connect wizard, then by removing the account from each forest involved, following the procedure in the Microsoft documentation.
What an audit checks
- Whether Seamless SSO is enabled and whether that is justified by the device fleet.
- The date of the last password change of the AZUREADSSOACC account in each forest.
- Permissions on the account and on its organisational unit.
- The configured Kerberos encryption types.
- Monitoring of changes made to the account.