Table of Contents
For quite some time (Beginning of 2017) it is now possible to solve SSO scenarios with Azure even without ADFS infrastructure. However, it is only recently that companies has started to not insist on ADFS. Now one may finally also point out the alternative solutions of Microsoft.
The possible scenarios for Seamless SSO are:
- Pass-through authentication (PTA)
- Password Hash Sync (PHS)
Pass-through authentication (PTA)
Disadvantages
- No automatic detection of leaked login data
- Azure AD DS requires enabled Password Hash Synchronization feature in tenant to work
- Is not part of Azure AD Connect Health
Password Hash Sync (PHS)
“Disadvantage“
- Password is synchronized to the cloud (as hash value)
Seamless Single Sign-On
Seamless Single Sign-On automatically logs users on to certain websites (e.g. myapps.microsoft.com) and native applications (e.g. Office365 Outlook) when they are in the corporate network (local, VPN or Direct Access) with their corporate device.
Users do not need to enter their password to log in to Azure AD and usually do not even need to enter their username (for domain hint addresses).
It is important that it provides easy access without the need for additional local components such as ADFS.
Advantage
- Users don’t have to enter their password all the time
- No additional local components required
- Can be introduced for some or all users using a Group Policy
- No further license costs
- Can be easily activated via AD Connect
- Username can be the local default username (UPN) or another LDAP attribute configured in Azure AD Connect
- If an error occurs for any reason, the regular user logon is performed, e.g. users must enter their password on the logon page
- If an application forwards the domain_hint parameter or the login_hint parameter in the Azure AD logon request, users are automatically logged on without entering a user name or password.
Sequence of authentication with a web application
- The user tries to access a web application (e.g. https://myapps.microsoft.com/) via a domain computer in the corporate network (Local, VPN or Direct Access)
- If the user is not already logged in, the user will be redirected to the Azure AD logon page
- The user enters his user name on the Azure AD login page
- When JavaScript is used in the background, Azure AD prompts the browser to provide a Kerberos ticket via a 401 – Unauthorized response
- The browser again requests a ticket from Active Directory for the AZUREADSSOACC computer account (which Azure AD creates when Seamless SSO is enabled in the local AD).
- Active Directory searches for the computer account and returns a Kerberos ticket to the browser encrypted with the computer account’s Azure AD Decryption Key.
- The browser forwards the Kerberos ticket retrieved from Active Directory to Azure AD.
- Azure AD decrypts the Kerberos ticket, which contains the identity of the logged-on user, using the exchanged decryption key of the AZUREADSSOACC computer account
- After evaluation, Azure AD either returns a token to the application or prompts the user to provide additional evidence, such as multi-factor authentication.
- If the login is successful, the user can access the application
Note: If under point 1 an address is used which contains a domain_hint or login_hint parameter function. If points 2 & 3 are skipped.
EXAMPLE ADDRESSES FOR DOMAIN_HINT & LOGIN_HINT
Microsoft Access Panel
https://myapps.microsoft.com/<Azure AD Domain> | https://myapps.microsoft.com/deyda.net |
Web Outlook
https://outlook.office365.com/<Azure AD Domain> | https://outlook.office365.com/deyda.net |
Office365 Portal
https://portal.office.com?domain_hint=<Azure AD Domain> | https://www.office.com?domain_hint=deyda.net |
https://www.office.com?domain_hint=<Azure AD Domain> | https://portal.office.com?domain_hint=deyda.net |
Azure Portal
https://portal.azure.com/<Azure AD Domain> | https://portal.azure.com/deyda.net |
Sequence of authentication with a native app
- The user starts a native application (e.g. Office365 Word Client) via a domain computer in the company network (Local, VPN or Direct Access)
- If the user is not already logged in, Word retrieves the user name from the Windows session of the device
- The app sends the username to Azure AD and gets back the WS-Trust-MEX endpoint of the tenant
- Word queries the WS Trust MEX endpoint to determine if the Integrated Authentication Endpoint (IWA) is available
- If step 4 is successful, a Kerberos request is executed to the local Active Directory
- The received Kerberos ticket will be forwarded to the IWA of Azure AD
- Azure AD decrypts and verifies the Kerberos ticket
- Azure AD sign on the user and outputs a SAML token for the app
- Word then transmit the SAML token to the OAuth2 token endpoint of Azure AD
- Azure AD checks the SAML token and issues an access token to the app, as well as an update token & an ID token for the specified resource
- The user gets access to the resource of the app
Activation Seamless SSO – AD Connect
I will now show you how to enable Pass-through authentication and Password Hash Synchronization. Only one feature is needed to use Seamless SSO.
Requirement
- AD Connect version installed and configured > 1.1.644.0
- Firewall release for *.msappproxy.net on port 443
- Domain administrator credentials for the domains that connected to Azure AD via AD Connect
- Office Version > 16.0.8730
- Users need to work on a computer that is a domain member
- Computer must have a connection to the domain (Local, VPN or Direct Access)
- Internet Explorer may not in Enhanced Protected Mode
Activating Pass-through authentication
To enable Pass-through authentication, connect to the AD member on which AD Connect is installed.
- Start Azure AD Connect
- Click on Configure in the Welcome Screen
- Now click on Change user sign-in and confirm this with Next
- Enter the credentials of the Global Administrator and confirm the entry with Next
- Possibly another login mask is requested because of an MFA
- Select Pass-through authentication and then Enable single sign-on. Confirm with Next
- Under Single single-on click on Enter credentials
- In the following windows, enter the credentials of a local domain administrator and click OK
- Click on Configure to perform the described actions
- Confirm the successful execution in the Configuration complete window with Exit
Activating Password Hash Synchronization
To activate Password Hash Synchronization connect to the AD member on which AD Connect is installed.
- Start Azure AD Connect
- Click on Configure in the Welcome Screen
- Now click on Change user sign-in and confirm this with Next
- Enter the credentials of the Global Administrator and confirm the entry with Next
- Possibly another login mask is requested because of an MFA
- Select Password Hash Synchronization and then Enable single sign-on. Confirm with Next
- Under Single single-on click on Enter credentials
- In the following windows, enter the credentials of a local domain administrator and click OK
- Click on Configure to perform the described actions
- Confirm the successful execution in the Configuration complete window with Exit
Local Active Directory
In the local Active Directory you can now find a new computer object called AZUREADSSOACC. This object should be protected from deletion.
Azure Portal
In the Azure Portal you can also see the activated Seamless SSO methods.
- In the Azure Portal, click on Azure Active Directory > Azure AD Connect
- Now click on the method set up via Azure AD Connect
Under Seamless single sign-on you can see the domains created with Password Hash Synchronization.
With Pass-through authentication, a Warning Symbol is displayed because the agent is only stored on one server.
According to Microsoft this should be distributed on 3 internal servers.
Group Policy Object
In order for Seamless SSO to work on the end devices, some settings still have to be distributed via GPOs.
- Connect to a computer that has the Group Policy Management Console installed.
- Now adds the following settings to an existing or a new GPO
- In the GPO, go to User / Computer Configuration > Adminstrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page and edit the Site to Zone Assignment List with the following values
Value Name | Value |
---|---|
login.microsoftonline.com | 3 |
aadg.windows.net.nsatc.net | 1 |
autologon.microsoftazuread-sso.com | 1 |
secure.aadcdn.microsoftonline-p.com | 1 |
device.login.microsoftonline.com | 1 |
Note: If Seamless SSO is to be disabled for individual groups or users, the GPO must be turned to the Value 4 for these people.
- Then go to the path User / Computer Configuration > Adminstrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Intranet Zone and set the Allow updates to status bar via script entry to Enabled
Renew the Kerberos Decryption Key
Microsoft recommends rolling out the Kerberos Decyption Key at least every 30 days.
This reduces the risk of spying on the Kerberos Decryption Key.
Microsoft is working on the introduction of an automated function to perform this task.
To renew the Kerberos Decryption Key of the AZUREADSSOACC computer account, you must first download the Azure AD PowerShell module from the PowerShell Gallery.
Start PowerShell as the administrator on the computer on which AD Connect is installed and run the following command:
1 |
Install-Module MSOnline |
Navigate to the path C:\Program Files\Microsoft Azure Active Directory Connect and import the module AzureADSSO.psd1
Execute the New-AzureADSSOAuthenticationContext command
Enter the credentials of an Azure administrator in the following window.
Then run Get-AzureADSSOStatus. This checks which domains are stored and activated in the Seamless SSO tenant.
Then run the command $passwd = Get-Credential and enter the credentials of a local domain administrator in the following window.
Finally, executes the following command to complete the update of the Decryption Key of the AZUREADSSOACC computer account.
1 |
Update-AzureADSSOForest -OnPremCredentials $passwd |
This must be done for all domains configured for Seamless SSO.
Result
After a gpupdate /force has been performed on the end devices, we can start testing.
Scenario 1 – Company network with company address
Scenario is a computer (Domain Member) in the corporate network that opens the following page via Internet Explorer:
https://myapps.microsoft.com/deyda.net
You are logged in directly, without entering your username or password, via Seamless SSO and can use your resources (e.g. Citrix FAS) directly.
Scenario 2 – Company network with general address
Scenario is a computer (Domain Member) in the corporate network that opens the following page via Internet Explorer:
https://myapps.microsoft.com/
You will be asked to enter a user name.
Then you are logged in via Seamless SSO without entering your password and can use your resources (e.g. Citrix FAS) directly.
Scenario 3 – Outside company network with company address
Scenario is a computer (Domain Member) outside the corporate network that opens the following page via Internet Explorer:
https://myapps.microsoft.com/deyda.net
You will be asked to enter a user name.
You will then be prompted to enter a password.
You will then be redirected to the stored resources.
Great post! Was able to also get it working for Firefox / Chrome by importing admx files, someone described it here:
https://www.reddit.com/r/sysadmin/comments/as4mri/google_chrome_seamless_sso_with_azure_ad_device/egsnw63/
I was able to use the ‘cached mfa token’ for Chrome by downloading the w10 Chrome extension https://chrome.google.com/webstore/detail/windows-10-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji?hl=en