Tag Archives: single sign on

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 2

This is the part 2 of the series of articles which explains about the AD FS and configuration. If you still not read the part 1 you can find it here.

Active Directory Federation Services (AD FS) – Part 1

In this post let’s look in to the configuration of the AD FS.

Active Directory Federation Services (AD FS) Installation

DNS Record

Before start on the installation process, it is important to create appropriate DNS record for AD FS name. This need to be setup on the appropriate DNS service provider which company uses. In here I did setup A record for adfs.contoso.com and point it to the server where AD FS will install.



Please note AD FS will not have concept of internal and external URLs. This given URL should be resolve from internal and external access to the same server.

SSL Certificate

AD FS required valid SSL in place as all the communication will happen via only secure connection. So prior to the installation in the server which will hold AD FS, you need to deploy valid SSL to match with the URL created on above step.

In here for the demonstration, I have created SSL for adfs.contoso.com and deploy it on the server as following.


Installation Steps

To begin the installation log in to the selected server (This must be added to the domain) as domain admin or enterprise admin.

1)    Load the Server Manager > Add roles and features


2)    Then it will load “Add roles and features wizard” and click next to continue


3)    In next window select “Role-based or feature-based installation” and click next to continue


4)    Then leave the default selection in next window and click next


5)    In server role selection select “Active Directory Federation Services” and click next


6)    In features selection window, leave the default selection and click next to continue


7)    Then in next window it gives description about the AD FS and click next to continue


8)    In next window, click on install to begin the installation.


9)    Once installation completed, click on option “configure the federation services on this server” to start the configuration process


10)    Then it will open up the AD FS configuration wizard. Select the “create the first federation server in a federation server farm” and click next


11)    In next window leave the default and click next


12)    In next window select the SSL certificate which will use for the AD FS and provide the name space as well. ( Note – in demo I used self-signed SSL so it is not match with the A record I created )


13)    If required you can use GMSA as an ADFS service account. In this window, can select the service account and click next to continue.


14)    In next window, if need we can save the configuration database on separate SQL server in network. For demo I will just use the default option.


15)    In next window it will give brief review about the option selected and click next to continue


16)    Then it will proceed with pre-requites check, once it completed click on configure to proceed.


17)    Once process completed, click on close to exit from the wizard.

This completes the AD FS role installation and configuration. In next post I will explain how to install the proxy services. If you have any questions about the post, feel free to contact me on rebeladm@live.com


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