Tag Archives: SSO

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.



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. 


Internet Explorer


Google Chrome

Mozilla Firefox


Windows 10




Yes, additional config required


Windows 8.1




Yes, additional config required


Windows 8




Yes, additional config required


Windows 7




Yes, additional config required


Mac OS X




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 


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. 


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.
Then in User Sign-in page select the appropriate sign-in option and then select Enable single sign-on option.
If you have existing Azure AD connect instance running, double click on Azure AD connect short cut. In initial window click on Configure.
In additional task page click on Change user sign-in and then click on Next.
In next window, type the Azure AD sync account user name and password and click on Next.
Then under the User Sign-in page select Enable single sign-on option and then click Next
In next page, enter the credentials for on-premises domain admin account and click Next.  
At the end click on Configure to complete the process. 
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.
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. 
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!!!!
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

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


2)    Then Systems in the panel


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


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


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


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


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


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


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


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



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


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 setup windows azure active directory – Part 02

This is the part 2 of the series of articles which will explain the setup and configuration of windows azure active directory. If you still not ready it you can find it here.

Step-by-Step Guide to setup windows azure active directory – Part 01

In part 01 we install a WAAD instance and add a domain. In this post let’s see how we can configure integration with local domain infrastructure.

WAAD can integrate with Local AD on 3 way.

1)    DirSync with Password Sync – Using this sync local users can log in to the windows azure service using same user name and password. But this is only sync the password. This is not providing SSO.
2)    DirSync with SSO – This is the most seamless integration method. To setup SSO it needs to have security token service installed and configured in local AD infrastructure such as active directory federation services (AD FS)
3)    Multi-Forest DirSync with SSO – This is very similar to the above option but this is works with multiple forest infrastructure. It’s quite complex but still seamless method for authentication.

In this demo I am going to use DirSync with SSO option. I will be using AD FS as the STS. This provides SSO experience for users to log in to local resources as well as cloud services.


The detail check list for this process available on here it includes detail description about all the steps.

Here I list few major points which you should consider.

1)    The domain name you going to integrate should be a public domain name. Which means if you using domain name such as contoso.local you should add complete UPN suffix such as contoso.com. you can find a post I wrote about changing UPN on http://www.rebeladmin.com/2015/01/how-to-configure-multiple-user-principal-name-upn-suffixes/
2)    AD must be running with windows server 2003 R2 or greater.
3)    Based on the STS model you will need use the WAAD module for windows PowerShell to establish federation trust between azure AD and local AD.


In demo I am using active directory federation service (AD FS) as the STS. I am not going to demonstrate how it can be set up in here. But if you not aware how to setup AD FS you can follow up the series of articles I wrote about AD FS. It can be found on http://www.rebeladmin.com/?s=Active+Directory+Federation+Services+%28AD+FS%29+

UPN Suffix

Before the integration process I add UPN suffix with public domain name to use for SSO. I also match it with the domain I added in Azure AD instance.



Install Azure AD PowerShell module for AD FS

To install the Azure AD PowerShell module for AD FS, log in to server as domain admin or enterprise admin. First install the Microsoft Online Services Sign-In Assistant for IT Professionals RTW from http://go.microsoft.com/fwlink/?LinkID=286152. Then download the module from http://go.microsoft.com/fwlink/p/?linkid=236297

Once download completes, double click on the installation file. Click next to continue.


In next window accept the terms and click next.


In next window select the installation path and click next.


Then click install, to start the installation process.


Setup Trust Relationship between AD FS and Azure AD

Load the PowerShell module we installed on above step.


Run $msolcred = get-credential command. Once it prompt for the login, type the cloud administrator logins ( Global Admin user under the WaaD instance.


Then run connect-msolservice -credential $msolcred and it will connect you to the Azure AD.


If you are executing this commands from different server than AD FS server you need to run Set-MsolAdfscontext -Computer <AD FS primary server> . You need to replace <AD FS primary server> with AD FS server FQDN.

Then run New-MsolFederatedDomain –DomainName <domain> and <domain> need to replace with domain name which will use for SSO.


Then you will get error similar to following. As it says we need to create proper DNS entry on our public DNS zone. I go ahead and created it as error says.
Then I can add domain using same command successfully. (Please note it take time to propagate dns changes once you do it in public dns)


Now we have create the trust between Azure AD and local AD. Next step is to do the sync.

DirSync in Action

Go to https://go.microsoft.com/fwLink/?LinkID=278924&clcid=0x409 and download the DirSync Tool.

Once download finishes, double click on it. Then click next to continue.


In next window accept the terms and click next.


In next window can specify the installation path. Once done click on next to continue.


Then it will start to do the installation.


Once it finish select the option to “start the configuration wizard now” and click finish.


Then it will start the configuration wizard. Click next to continue


Then it ask for the Azure Ad credential. Provide the cloud administrator account info and click next.


If you not set the directory sync to activate state in azure you will get error. You must activate it before continue.


In next window it ask for local AD enterprise admin credentials. Once done click next to continue.


In next window it asks if need to enable hybrid deployment. In here we giving permissions to azure AD to write changes to local AD. If you wish to allow, select the option and click next.


Then it ask about password sync. It is required feature so I enable it and click next.


Then it starting the configuration.

Once its completed, click next. Then it gives option to start the sync now. Click finish to start the sync.


Once sync is done we can see azure AD updated with user accounts etc.


Also Directory integration page shows when was the last sync happens etc.


This ends the long article which were explaining the DirSync configuration with SSO.

If you have any question feel free to contact me on rebeladm@live.com

Image Source : https://msdn.microsoft.com/en-us/library/azure/dn441213.aspx

Windows Azure Active Directory (WAAD)


In previous article I explain the difficulties had on “cloud” to extend organization’s identity management. Therefor most of the applications, services on cloud used to have their own identity stores.

With Windows Azure AD, it allows to extend the local infrastructure identity management to the cloud seamlessly to allow users to get self-service capabilities and single-sign-on access. So end users no need to worry about the way they can access organization’s resources, services etc. or where it’s located (on-premises or cloud).

In before when deal with identity management in hybrid cloud setup, most of time you need to “replicate” the setup on cloud and on-premises in order to get them work with proper access control. But Azure AD allows to “sync” with existing system and allows to control access management in central location.

Windows Azure Active Directory provides centralized identify management for office365, windows intune, over 1000 SaaS applications. Not only that it provides techniques, tools to integrate your own cloud-based application or services. It also allows to “sync” with in-house active directory environment using “DirSync” and AD FS (Active Directory Federation Services) features.

Currently there is 3 versions of Windows Azure Active Directory.

Free – Free edition allow you to sync with in-house active directory environments, get SSO with Azure services and thousands of Saas applications.

Basic – This version gets all the features of free version plus group-based access management, self-service password reset, windows azure active directory application proxy to publish on-premises web applications in to cloud. It also includes enterprise level SLA which guarantee 99.9% uptime. 

Premium – This version includes all the features of free and basic versions plus self-service group management, security reports and alerts, multi-factor authentication and Microsoft identity manager (MIM).

You can get more info from following nice video.

Major benefits of WAAD

1.    Centralized identify management – You can manage logins for AD or WAAD from any remote location and from any device.
2.    Advanced Access Control – you can set rules to control the access to cloud application and resources based on users, devices, locations etc.
3.    Single-Sign-On (SSO) – Provides SSO for cloud, on-premises resources and applications. It also supports for thousands of SaaS applications available in market.
4.    Application Proxy – we can allow external user access to applications published via in-built AD application proxy. Its access can control via rules and policies according to company requirements.
5.    Advanced Reporting – It provides daily usage reports, access reports. It also allow to use custom reporting based on azure Ad reporting API.

This is the end of the post and in next post lets see how to setup WAAD. If you have any question about the post, feel free to contact me on rebeladm@live.com

Image source: http://files.channel9.msdn.com/thumbnail/4ac52e5b-b3ac-4fbd-bbc7-bd4bae8403da.png

Active Directory Federation Services (AD FS) – Part 1

AD FS is a service which allows to securely exchange identity information between trusted business partners. Let’s assume Company A and Company B is business partners. Company B management wants to access Share point portal runs on Company A in secure manner. With use of ADFS Company B can provides the authentication information in form of “Claims” to Company A. then Company A will use “trust policy” to map these claims in to claims which share point web application will understand. Then based on that outcome system will make the authorization decisions.

This ADFS services also used to provide single sign on (SSO) experience between on premises active directory and windows azure active directory instance.


1.    Single Sign On (SSO)

ADFS service will give SSO experience to federation partners to access its partner’s web based applications.

2.    Easy Partner’s User Account Management 

Between federation partners, the user identities, attributes, group memberships etc. managed by the partner’s organization. So you do not need to worry about changing, activate/deactivate user accounts used for the authentication.  Also in event of partnership termination, it can be done with single trust policy change and do not need to worry about user accounts.

3.    Web services Interoperability

AD FS federated identity management solution is interoperates with other security products that supports WS-* web services architecture. It allows to make federation partnerships with environments which do not use windows identity model. 

4.    Centralized federation partner management

All the federation partnerships can manage using AD FS MMC.

5.    Extensible architecture

Organizations can use the extensibility to modify AD FS to support its business policies.

AD FS Deployment

In order to install AD FS need at least 2 servers. One server is to hold AD FS and other server will holds Web Application Proxy service. This 2 roles can’t install in one server.

To install AD FS, servers must be joined to the domain.

Client – Web Application Proxy – Federation communications are based on HTTPS. So if your organization do not runs with CA, make sure you apply 3rd party SSL along with proper DNS entries before AD FS configurations.

Also port 443 should open in order to proceed with following communications,

1)    Client computer should be able to connect AD FS or Web Application Proxy Server using HTTPS (443)
2)    AD FS and Web Application Proxy servers should be able to communicate using HTTPS (443)

Web Application Proxy

Prior to Windows server 2012 R2, this service was called as Federation server proxy. This service should be hosted in a server in perimeter network. This will be act as a gateway connecting a host in unprotected network to federation server in protected network.

This is the end of post and in next article let’s look in to AD FS deployment in demo environment. If you have any question about the post feel free to contact me on rebeladm@live.com

Identity and Access (IDA) Management Solutions

In previous article I have explain what IDA solution is and what we need to consider on implementing such a solution to business. If you didn’t read it yet you can find it on here

What is IDA Management Solutions?

IDA management solutions used to integrate, sync, manage different identities an organization uses. It can be different directories, different systems. For ex- Company ABC use Active Directory Domain Services (AD DS) to manage its users. It also have another web application hosted on linux platform which is using different identity store. Billing platform is maintaining another authentication system for customers and employers. Company XYZ its merge with using Novell eDirectory as its directory service. So IDA management solution it will help organization to integrate and maintain these different authentication systems without additional management efforts.

What are the features of IDA Management Solutions?

Multiple Authentication Systems

In an organization, there can be various authentication systems. It can be different directory services or databases. Most of the time IT professionals are used to merge these various system to one authentication system to provide Single Sign on (SSO) experience. Majority of applications, authentication systems allow to integrate them with different directory services. But some time it is important to maintain different identity stores while sync or exchange certain information among them. IDA management solutions allow to maintain multiple authentication systems while providing SSO or filtered information exchange.

Determining Authoritative Identity

As I explain before IDA management solution can integrate, synchronize and maintain identity data from multiple identity stores. When those systems works together it’s important to identify the attributes and the source of them. For ex- If “System A” requesting user information from “System B” for authentication it’s important to make sure “System A” is same source its claims to be before pass the sensitive information. There for IDA management solution will act as trusted information source which we can use for validate the information which are sync between multiple identity stores.

Authentication and Authorization

IDA solution will make sure to authenticate and authorize users based on the access control permissions or policies.

Add/Remove User accounts automation

When an organization deals with multiple identity stores it makes more work for IT staff for user account provisioning and de-provisioning. For ex- if company have 5 different systems when new use comes in IT department need to create use in all 5 systems along with appropriate ACL etc. imagine with 25 users how much of work load it will create ? Also the process can increase the possibilities for errors and it even can create security risks to entire network.
With IDA solution we can automate this user add/remove process across multiple systems. It will ensure the integrity, security, productivity compare to manual process.

Secure data exchange between companies

Due to business needs some time organizations needs to exchange access to data and resources with other companies, vendors or partners. It is not practical to force the other party to change their systems to compatible with ours. IDA management solutions allows to securely share access information to data and resources with minimum administrative efforts. It can be using domain trusts, federation services, forest trusts etc.

Secure Data Exchange

When deals with multiple systems its obvious sensitive information will share or sync between them. This communications may happens between multiple networks. IDA solutions will ensure all of the communication between different systems are secure and data exchanged between them are secured.

Safeguard sensitive data 

Let’s assume “company ABC” merge with “company XYZ”. These are interconnected using domain trust. CEO of company ABC is sending email attached with office excel file contains salary information to CEO of company XYZ. So defiantly its very sensitive data which should not access by any other person. Even though it’s secure communication what if someone else in company got access to it? IDA solution can use to make sure the confident data only access by the authorized person. As example Active Directory Right Management Services (AD RMS) can use as tool to ensure only CEO of XYZ can open that excel file and no one else.

In next article let’s look in to some of IDA tools and techniques we can use.