opkmessenger.blogg.se

Using JavaScript in the background, Azure AD challenges the browser, via a 401 Unauthorized response, to provide a Kerberos ticket. The user types in their user name into the Azure AD sign-in page.įor certain applications, steps 2 & 3 are skipped. If the user is not already signed in, the user is redirected to the Azure AD sign-in page. The user tries to access a web application (for example, the Outlook Web App - ) from a domain-joined corporate device inside your corporate network. The sign-in flow on a web browser is as follows:

How does sign-in on a web browser with Seamless SSO work? Once the set-up is complete, Seamless SSO works the same way as any other sign-in that uses integrated Windows authentication (IWA). If the AzureADSSOAcc$ account encryption type is set to RC4_HMAC_MD5, and you want to change it to one of the AES encryption types, please make sure that you first roll over the Kerberos decryption key of the AzureADSSOAcc$ account as explained in the FAQ document under the relevant question, otherwise Seamless SSO will not happen. The encryption type is stored on the msDS-SupportedEncryptionTypes attribute of the account in your Active Directory. It is recommended that the encryption type for the AzureADSSOAcc$ account is set to AES256_HMAC_SHA1, or one of the AES types vs.

Seamless SSO supports the AES256_HMAC_SHA1, AES128_HMAC_SHA1 and RC4_HMAC_MD5 encryption types for Kerberos. If there are multiple AD forests, each computer account will have its own unique Kerberos decryption key. The computer account's Kerberos decryption key is shared securely with Azure AD.In addition, a number of Kerberos service principal names (SPNs) are created to be used during the Azure AD sign-in process.A computer account ( AZUREADSSOACC) is created in your on-premises Active Directory (AD) in each AD forest that you synchronize to Azure AD (using Azure AD Connect).While enabling the feature, the following steps occur:

Seamless SSO is enabled using Azure AD Connect as shown here.