Microsoft recommends rotating the Encryption Key for this sensitive account every 30 days. This blog, which is Part 1 of a series, will review how to do it manually and in Part 2 we will demonstrate how to automate it and run it on a schedule.
A little about Azure AD Seamless Single Sign On
Azure AD Seamless SSO allows you to enable Single Sign on into Azure AD / Office 365. This is a great feature that your end users will really enjoy and the best part about this is that it doesn’t even require an Azure AD Premium license!
This feature allows end users to experience Single Sign On (SSO) in a similar fashion to ADFS but without all the infrastructure required to maintain ADFS!
Put simply, when a user attempts to sign into a Microsoft login page e.g. https://portal.office.com their computer will be able to leverage Kerberos authentication to pass credentials directly via the web browser and they will not have to enter their password.
There are a few requirements you will need in order for this to work and they are:
- You must have the Single Sign On feature enabled in AD Connect
- You must be using a supported browser, see HERE for more details
- The AD UserPrincipalName (UPN) of the logged in user must match the Office 365 UPN / Sign on
- The user must be using a domain joined computer and be able to communicate with a Domain Controller
- You must add the following URL to the Local Intranet Zone of Internet Explorer Security settings
- https://autologon.microsoftazuread-sso.com
How it works
This functionality is achieved by using a special computer account in AD called AZUREADSSOACC, which represents Azure AD. The password of this account is securely shared with Azure AD. When a user is at the Azure AD sign-in page and has entered their username (or a domain hint is being used in the URL), a Java script runs in the background to require the user to access AZUREADSSOACC. The domain controller provides a Kerberos ticket back to the user which is then passed on to Azure AD via the secure browser session. Azure AD decrypts the Kerberos ticket, which includes the identity of the user signed into the domain-joined device, by using the previously shared key.
After evaluation, Azure AD either returns a token back to the application or asks the user to perform additional proofs, such as Multi-Factor Authentication
So far so good?
Due to the sensitive nature of this password, Microsoft highly recommends rotating the AZUREADSSOACC account password every 30 days. It’s been rumored that there is supposed to be functionality built into Azure AD Connect that will do it automatically however that has yet to be announced.
How to reset the key manually
You must reset the AZUREADSSOACC Kerberos Key in each AD Domain within the Forest where AD Connect Seamless SSO is enabled. To determine which domains are configured in your environment, do the following on your AD Connect Server from PowerShell:
Import-Module “C:Program FilesMicrosoft Azure Active Directory ConnectAzureADSSO.psd1”
New-AzureADSSOAuthenticationContext #Sign in with a Global Admin account
Get-AzureADSSOStatus | ConvertFrom-Json
Note the Domains field. If you have multiple domains, you will need to reset the AZUREADSSOACC password by issuing the following command in each AD domain:
Update-AzureADSSOForest
You will be prompted for credentials- use a Domain Admin for the AD domain you are running it. Use the SamAccountName format e.g. DOMAINUsername.
Do this in each AD domain as required. If you will run this for several domains from the same PowerShell session, you can capture the credentials to a variable:
$Cred = Get-Credential
Update-AzureADSSOForest -OnPremCredentials $Cred
Note: this is the quick and dirty method. In Part 2 when we automate this, we will not be using a Domain Admin account, we will use a least privileged model account
Testing
To confirm that it worked, open PowerShell from a Domain Controller in each domain where you ran the command and run:
Get-ADComputer AZUREADSSOACC -Properties * | FL Name,PasswordLastSet
The PasswordLastSet time stamp should coincide with when you ran the command
At this point verify that Seamless SSO still works.
The steps above will get the job done but this would need to be done manually every 30 days and let’s face it, manually doing tasks on a schedule is, well, lame! I hope you enjoyed this blog and please reach out to us if you have any questions. Stay tuned for Part 2 of this blog in which we will show how to automate this using Azure Automation with Hybrid Runbook Workers!
