Tag Archives: AAD

Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO)

I am sure most of you aware what is single sign-on (SSO) in Active Directory infrastructure and how it works. When we extend identity infrastructures to Azure by using Azure AD, it also allows to extend Single Sign-On capabilities to authenticate in to cloud workloads. it can be done using on-premises ADFS farm. Password Hash Synchronization or Pass-through Authentication allow users to use same user name and password to log in to cloud applications but this is not a “Seamless” access. Even they are using same user name and password, when log in to Azure workloads it will prompt for password. 

In my below example, I have an Azure AD instance integrated with on-premises AD using Pass-through Authentication. In there I have a user R272845. I logged in to a domain joined computer with this user and try to access application published using Azure. when I type the URL and press enter, it redirects me to Azure AD login page.

sso1

sso2

Azure Active Directory Seamless Single Sign-On is a feature which allow users to authenticate in to Azure AD without providing password again when login from domain join/ corporate device. This can be integrated with Password Hash Synchronization or Pass-through Authentication. This is still on preview which means cannot use in production environment yet. However, if it doesn’t work in environment, it will always issue the typical Azure AD authentication page, so it will not prevent you from accessing any application. This feature is not supported if you using ADFS option already.

According to Microsoft, following can list as key features of Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO)

Users are automatically signed into both on-premises and cloud-based applications.

Users don't have to enter their passwords repeatedly.

No additional components needed on-premises to make this work.

Works with any method of cloud authentication – Password Hash Synchronization or Pass-through Authentication.

Can be rolled out to some or all your users using Group Policy.

Register non-Windows 10 devices with Azure AD without the need for any AD FS infrastructure. This capability needs you to use version 2.1 or later of the workplace-join client.

Seamless SSO is an opportunistic feature. If it fails for any reason, the user sign-in experience goes back to its regular behavior – i.e, the user needs to enter their password on the sign-in page.

It can be enabled via Azure AD Connect.

It is a free feature, and you don't need any paid editions of Azure AD to use it.

It is supported on web browser-based clients and Office clients that support modern authentication on platforms and browsers capable of Kerberos authentication

According to Microsoft, following environments are supported. 

OS\Browser

Internet Explorer

Edge

Google Chrome

Mozilla Firefox

Safari

Windows 10

Yes

No

Yes

Yes, additional config required

N/A

Windows 8.1

Yes

N/A

Yes

Yes, additional config required

N/A

Windows 8

Yes

N/A

Yes

Yes, additional config required

N/A

Windows 7

Yes

N/A

Yes

Yes, additional config required

N/A

Mac OS X

N/A

N/A

Yes

Yes, additional config required

Yes, additional config required

The current release (at the time this blog post was written) do not support edge browser. Also this feature will not work when users use private browser mode on Firefox or when users have Enhanced Protection mode enabled in IE. 

How it works?

Before we look in to configuration, let’s go ahead and see how it’s really works. In following example, user is trying to access cloud based application (integrated with azure) using his on-premises username, password and domain joined device. 

Also, it is important to know what happen in corporate infrastructure when seamless SSO enabled.

System will create AZUREADSSOACCT computer object in on-premises AD to represent Azure AD

AZUREADSSOACCT computer account’s Kerberos decryption key is shared with Azure AD.

Two Kerberos service principal names (SPNs) are created to represent two URLs that are used during Azure AD sign-in which is https://autologon.microsoftazuread-sso.com and https://aadg.windows.net.nsatc.net 

sso3

1. User is accessing the application URL using his browser. He is doing it using his domain joined device in corporate network.

2. If user is not sign in already, it is pointed to Azure AD sign in page and then user type his user name.

3. Azure AD challenge back user via browser using 401 response to provide Kerberos ticket.

4. Browser request a Kerberos ticket for AZUREADSSOACCT computer object from on-premises AD. This account will be created in on premise AD as part of the process in order to represent Azure AD. 

5. On-premises AD locate the AZUREADSSOACCT computer object and return the Kerberos ticket to the browser encrypted using computer object’s secret. 

6. The browser forwards Kerberos ticket to Azure AD.

7. Azure AD decrypts the Kerberos ticket using Kerberos decryption key (This was shared with azure AD when SSO feature enable)

8. After evaluation, Azure AD pass the response back to the user (if required additional steps such as MFA required).

9. User allowed to access the application. 

Prerequisites

In order to implement this feature, we need the following,

1. Domain Admin / Enterprise Admin account to install and configure Azure AD Connect in on-premises 

2. Global Administrator Account for Azure subscription – in order to create custom domain, configure AD connect etc.

3. Latest Azure AD Connect https://www.microsoft.com/en-us/download/details.aspx?id=47594 – if you have older Azure AD connect version installed, you need to upgrade it to latest before we configure this feature.

4. Azure AD Connect can communicate with *.msappproxy.net URLs and over port 443. If connection is control via IP addresses, the range of azure IP addresses can find in here https://www.microsoft.com/en-us/download/details.aspx?id=41653 

5. Add is https://autologon.microsoftazuread-sso.com and https://aadg.windows.net.nsatc.net to browser intranet zone. If users are using IE and chrome, this can be done using group policy. I have written blog post before how to create policy targeting IE. You can find it here

6. Firefox need above URL added to the trusted Kerberos site list to do Kerberos authentication. To do that go to Firefox browser > Type about:config in address bar > in list look for network.negotiate-auth.trusted-uris > right click and select modify > type “https://autologon.microsoftazuread-sso.com, https://aadg.windows.net.nsatc.net" and click ok

7. if its MAC os, device need to be joined to AD. More details can be found in here

Configure Azure AD Seamless SSO
 
Configuration of this feature is straight forward, basically it’s just putting a one tick box. 
 
If its fresh Azure AD connect installation, select the customize option under express settings.
 
sso4
 
Then in User Sign-in page select the appropriate sign-in option and then select Enable single sign-on option.
 
sso5
 
If you have existing Azure AD connect instance running, double click on Azure AD connect short cut. In initial window click on Configure.
 
sso6
 
In additional task page click on Change user sign-in and then click on Next.
 
sso7
 
In next window, type the Azure AD sync account user name and password and click on Next.
 
sso8
 
Then under the User Sign-in page select Enable single sign-on option and then click Next
 
sso9
 
In next page, enter the credentials for on-premises domain admin account and click Next.  
 
sso10
 
At the end click on Configure to complete the process. 
 
sso11
 
This completes the configuration and next step is to verify if its configured SSO. First thing is to check if its create computer object called AZUREADSSOACCT under on-premises AD. You will be able to find it under default Computers OU.
 
sso12
 
Then log in to Azure Portal and go to Azure Active Directory > Azure AD Connect then under the user sign-in option we can see seamless sign-on option is enabled. 
 
sso13
 
This means it’s all good. Next step is to check if its working as expected. in order to do that I am login to corporate device with same user I used earlier which is R272845 and try to access same app url. 
 
This time, all I needed to type was the user name and it log me in. nice!!!!
 
sso14
 
Note – before testing make sure you added the two Azure AD urls to intranet zone as I mentioned in prerequisites section. 
 
Hope this information was useful and if you have any questions feel free to contact me on rebeladm@live.com

Step-by-Step Guide to enable password synchronization to Azure Active Directory Domain Services (AAD DS)

In my previous post I have explain how to enable azure ad domain services. If you not read it yet you can find it here.

Once the domain service are enabled the next step to sync the credentials to the Azure AD domain services. Then users can use their logins to log in to the managed domain services. This post is to explain how we can do it in cloud-only environment as well as in hybrid setup.

Cloud-Only Setup

If you have cloud only setup the users who is going to use azure ad domain services need to change their passwords. Once user reset the password it generate the credential hashes which is uses by azure ad domain services for Kerberos and NTLM Authentication.

There is 2 ways to do it,

1)    Force password reset – in the console we can reset the password for user. It will generate temporally password for the user. So in next login, user need to provide new password.

To do this, log in to Azure AD instance (which is enabled with Azure AD Domain services) and then click on users tab.

pass1

Then select the user to reset the password and in the bottom click on RESET PASSWORD button

pass2

pass3

2)    Change Passwords from use logins – By login in to the Azure portal, users can reset their passwords. (https://portal.azure.com)

Once user log in to the portal click on the right hand corner where user name displays and then click on “change password

pass4

pass5

Hybrid Setup

If you have on-premises AD and sync it already with Azure AD, we need to sync credential hashes required for NTLM and Kerberos authentication via Azure AD Connect. These are not sync with azure ad by default.

First thing first, if you have Azure AD connect installed in your servers, it need to upgrade with latest version. The latest recommended version is 1.1.130.0 – published on April 12, 2016. You can download it using https://www.microsoft.com/en-us/download/details.aspx?id=47594 , this is important as older version of Azure AD Connect do not have this sync feature.

After upgrade (or new install) make sure the password synchronization is enabled. To do that,

•    Log in to the server which have Azure Ad sync installed (with appropriate permissions).
•    Double click on Azure AD Connect

pass6

•    Then in new window select the option “View current configuration” and click on “Next

pass7

•    In next window check if the password sync is enabled

pass8

•    If not go back to the previous window and select option “Customize Synchronization Options” and click next 

pass9

•    Then under the “Optional Features” enable password hash synchronization.

pass10

With the install if use the express settings this is enabled by default. Also check if the synchronization happening without errors.

To check that go to start > azure ad connect > synchronization services

pass11

pass12

To do a full forceful password sync you can use following PowerShell script

$adConnector = "<CASE SENSITIVE AD CONNECTOR NAME>"
$aadConnector = "<CASE SENSITIVE AAD CONNECTOR NAME>"
Import-Module adsync
$c = Get-ADSyncConnector -Name $adConnector
$p = New-Object Microsoft.IdentityManagement.PowerShell.ObjectModel.ConfigurationParameter “Microsoft.Synchronize.ForceFullPasswordSync”, String, ConnectorGlobal, $null, $null, $null
$p.Value = 1
$c.GlobalParameters.Remove($p.Name)
$c.GlobalParameters.Add($p)
$c = Add-ADSyncConnector -Connector $c
Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $aadConnector -Enable $false
Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $aadConnector -Enable $true

In here
$adConnector = "<CASE SENSITIVE AD CONNECTOR NAME>"
$aadConnector = "<CASE SENSITIVE AAD CONNECTOR NAME>"

Should replace with the info related to your setup, this can find using “synchronization services” window. Click the “connectors” tab.

pass13

Once it’s edited with relevant info it can execute.

pass14

Hope this helped and if you have any questions about post feel free to contact me on rebeladm@live.com
 

Azure AD Join with Windows 10 Devices

In previous articles I have explain how to integrate on-premises active directory with Azure AD. So users can have SSO experience with SaaS apps which is in the cloud. Also can use services such as self-service password reset.

With Windows 10 Microsoft align it with Azure AD to provide more “cloud” experience. Azure AD Join is new feature in windows 10 devices where you can directly link your devices to Azure AD.

Let’s look in to some of the major capabilities introduced by windows 10 to align with Azure AD.

1)    Out-of-Box Experience and easy integration with Azure AD – when you switch on your windows 10 device first time, during the initial setup you can easily connect with the Azure AD using Azure AD Join option. It is few simple steps and if you do have the azure AD user account details without support of IT department easily can join your device.
2)    Single-sign-on to your SaaS apps – With Azure AD join devices you can start using your cloud applications with SSO. It can be Office365 and other services already in cloud.
3)    Automatic enrollment with Mobile device management solutions – if the organization uses the MDM solution such as Microsoft Intune, windows 10 devices can automatically enroll as part of Azure AD join.
4)    Better control over fast changing accounts – your organization may have fast changing accounts such as sales department, interns etc. sometime these accounts cause issues with security as they may login from remote locations. But now with azure AD join devices you can control the identities for those accounts easily and the changes to the accounts apply to devices fast.

Now let’s see how to connect windows 10 device with Azure AD.

In my demo I do have Azure AD premium instance setup and it got a user account called user1.
I am going to connect a pc which run windows 10 enterprise to azure AD using Azure AD join.

1)    Log in to the windows 10 PC > Start > Settings

adjoin2

2)    Then Systems in the panel

adjoin3

3)    Then option “About”, there you can select the option “Join Azure AD

adjoin4

4)    In next window click on next to start the process

adjoin5

5)    Type your Azure AD user name and password and click sign on

adjoin6

6)    Since this is new account it ask to set a password. Continue with click in “Sign In

adjoin7

7)    System confirms about account and organization info. Click on Join to continue

adjoin8

8)    At the end system confirms as device now joined to Azure AD

adjoin9

9)    Now let try to log in with Azure AD account

adjoin10

10)    Boom!, I am in with Azure AD User Account
11)    If you have MFA enable, it will ask to setup MFA in first login

adjoin11

adjoin12

12)    In Azure portal I can see the device is registered under the user too

adjoin13

In this post I explain what azure AD join is and how it can use with windows 10 devices. If you have any questions feel free to contact me on rebeladm@live.com

Step-by-Step guide to configure self-service password reset in Azure AD

Password reset for AD users is a common call, ticket for the help desk. This is sometime negatively affecting company operations. Because users will not have access to systems and applications until the password reset by help desk engineers. What if we can allow end users to reset their passwords them self in a secure manner?

Yes Azure AD is now gives opportunity to enable self-service password reset for the end-users. Also the password resets can sync with on-premises AD.

This feature is disabled by default. In this demo I will explain how to enable this feature and configure.

On the demo setup I am using have Azure AD instance which is sync with on-premises windows server 2016 TP4 AD.

1)    Log in to the Azure Portal and load the Azure AD Instance
2)    Then in Dashboard, under configure services you can find option “Self Service Password Reset” By default it’s disabled. Click on “Configure” to proceed with configuration.

spw1

3)    Then in next page under User Password Reset Policy select option “Yes” next to “Users enabled for password reset

spw2

4)    Now it will give you options to configure the policy for the password reset. Let’s look in to  some of these options and understand what they do.

Restrict access to password reset – Using this option password reset can only allow for a security group instead of allowing it for every user in the instance. Any member of allowed security group will get option to do a self-service password reset.

Authentication Methods Available to Users – its allow you to use following options to select with. We can allow to use any selected authentication methods for users. 

Number of Authentication Methods Required – In this option we can choose how many methods required for successful password reset

spw3

Require users to register when signing in?
– When this option is enabled users can register their own authentication method when sign up.

Write back passwords to on-premises active directory
– with this option if a user reset password using self-service portal it will write back to the on-premises AD too.

In order to get this write back option work, it need to be enabled in Azure AD connect in on-premises AD.

aad1

5)    In demo I am configuring “Security Questions” as authentication method. With that option you can define the different security questions, as well as the number of questions required to answer.

spw4

6)    Once options are configure click on save to apply the changes.

spw5

7)    Let’s see how it works in user end.  I am trying to log in to azure portal as standard user. In first login it’s ask additional information to setup for password reset. Click on setup to provide the additional info.

spw6

spw7

8)    Now all the additional info is saved. Let’s see how it works. I am going to log in with wrong password to simulate it. As soon as I done it, it ask if you need to reset the login.

spw8

9)    Clicked on “Forgot your password ?” option

10)    As first check it’s asking to enter the characters in picture. Click next to continue

spw9

11)    Then it ask which option to use for the password reset, according to the policy. Select the option you like to use.

spw10

12)    Then it’s ask for the second authentication. As per the policy.

spw11

13)    Once authentication success, it’s ask to submit the new password.

spw12
14)    Once its finish you can successfully login with new password.

spw13

If you have any questions about the post feel free to ask me on rebeladm@live.com