Seamless SSO Kerberos Key Rollover: Safe Steps

Originally published 16 August 2021. Reviewed 4 November 2026 against current Microsoft Learn guidance.

The safety rule to remember

Microsoft recommends rolling over the Kerberos decryption key for Microsoft Entra Seamless Single Sign-On (Seamless SSO) at least every 30 days. The important operational warning is just as short: run the update no more than once per forest. Microsoft says a repeated rollover can interrupt Seamless SSO until existing Kerberos tickets expire and are issued again. Plan one controlled update for each forest where the feature is enabled, then stop and verify.

If your goal is to change the account from RC4 to an AES encryption type, Microsoft says to roll over the key before changing the encryption type. Do not combine this guide with an unreviewed domain-controller, service-account, or encryption-policy change.

What the key belongs to

When Seamless SSO is enabled with Microsoft Entra Connect, a computer account named AZUREADSSOACC is created in each enabled on-premises Active Directory forest. Kerberos service principal names are configured on that account. Its decryption key is securely shared with Microsoft Entra so the cloud service can decrypt tickets presented during sign-in. Each forest has its own account and key.

Treat the computer account and its key as sensitive authentication material. Microsoft recommends that only Domain Admins manage the account, that Kerberos delegation on it be disabled, and that no other account receive delegation rights on it. Place it in an OU protected from accidental deletion. Never paste credentials, key material, or unredacted administrative output into tickets, chat, or a public troubleshooting page.

Check prerequisites before changing anything

Use the server running Microsoft Entra Connect and the AzureADSSO PowerShell module documented for that installation. Confirm your change authority and the two credential contexts: Microsoft documents a Hybrid Identity Administrator account for the authentication context, plus Domain Administrator credentials for the on-premises forest. If your Domain Admin role was delegated, Microsoft documents a -PreserveCustomPermissionsOnDesktopSsoAccount option. Follow Microsoft's current role and command guidance for your Connect version.

Make an inventory of every forest where Seamless SSO is enabled. Choose an approved change window, notify the service owner, and confirm a rollback or support plan. Do not start by changing encryption types. First check the feature status and determine the one update action required for each forest. A staging server does not need a rollover under Microsoft's documented procedure.

PowerShell outline

Run the supported procedure in an elevated PowerShell session on the Microsoft Entra Connect server. The credential prompt is interactive; do not put passwords in this script, source control, command arguments, or a shared transcript.

Set-Location "$env:ProgramFiles\Microsoft Azure Active Directory Connect"
Import-Module .\AzureADSSO.psd1
New-AzureADSSOAuthenticationContext
Get-AzureADSSOStatus | ConvertFrom-Json
$creds = Get-Credential
Update-AzureADSSOForest -OnPremCredentials $creds
Get-AzureADSSOStatus | ConvertFrom-Json

Treat this as an outline, not a command to paste blindly. The status query is read-only, but Update-AzureADSSOForest changes the Kerberos key for the target forest and updates the shared key in Microsoft Entra. Use the exact current Microsoft instructions for selecting a forest and supplying credentials in your environment. Do not run the update twice for the same forest. If several forests are enabled, follow Microsoft's per-forest sequence, recording completion without recording passwords or key values.

Verify after the single update

Allow the documented synchronization and directory replication to complete. Check the Seamless SSO status again and confirm the intended forest is represented as expected. Then perform an approved sign-in test from a domain-joined device and check the organization’s normal identity sign-in diagnostics if the experience changes. Seamless SSO is opportunistic: failure may fall back to another sign-in experience, so a successful password prompt alone does not prove that Seamless SSO worked.

If the command reports an error, do not retry the rollover reflexively. Preserve a sanitized error category, verify the selected forest and roles, and consult Microsoft's troubleshooting guidance. Avoid sharing full command transcripts if they could contain tenant names, usernames, or other operational details.

RC4 and AES planning

Microsoft documents support for AES256, AES128, and RC4 Kerberos encryption types for Seamless SSO and recommends an AES-based type instead of RC4. The selected type is stored in msDS-SupportedEncryptionTypes on the AZUREADSSOACC account. If you are moving from RC4 to AES, perform the key rollover first, as Microsoft's troubleshooting guidance requires.

Microsoft's technical deep dive notes a July 2026 Windows Server update that changes the default Kerberos encryption type to AES-256 and warns organizations still using RC4 may see authentication or Seamless SSO issues. Check official guidance and domain compatibility before changing encryption. This article does not prescribe a universal setting or assess a specific tenant.

Sources and scope

Checked on 4 November 2026 against Microsoft's Seamless SSO FAQ, technical deep dive, and troubleshooting guide. Reread current Microsoft guidance before the operation. General guidance, not a tenant check or change approval.