In the previous blog we discussed the basic concepts, ports, requirement, prerequisite and architecture. Now it’s time to configure Single Sign on.

This is a 7 blog series which was successfully tested and written with the help of Microsoft Exchange Deployment Assistant.

Here is the link of Microsoft Exchange Deployment Assistant: https://technet.microsoft.com/en-us/exdeploy2013/Checklist?state=2419-W-AABoAQqA0gCIAIEGAwAAAAg~

 

Exchange 2013: Hybrid Part 1

Exchange 2013: Hybrid Part 3

Exchange 2013: Hybrid Part 5

Exchange 2013: Hybrid Part 6

Exchange 2013: Hybrid Part 7

Information Collection:

Before we start the single sign on process we need to gather the information which will be used in configuring Hybrid between Exchange on premise and office 365. You can make the following table to gather information about your existing organization that you’re going to need before you get started.

The following table lists new services that you configure as part of the hybrid deployment. Replace G5.com with your domain name for the values you provide in the table.

 

Configure Single sign-on

Single sign-on enables users to access both the on-premises and Office 365 tenant service organizations with a single user name and password. Configuring single sign-on also allows you to enforce your organization’s password policies and account restrictions in both the on-premises and Office 365 tenant service organizations.

Follow the below steps to configure single sign-on for your on-premises organization:

• Prerequisites   Add additional physical or virtual servers to your on-premises organization to support an installation of Active Directory Federation Services (AD FS), and make sure the servers meet the requirements to run AD FS.
  

-Have Active Directory deployed and running in either Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2 with a functional level of mixed or native mode.

-If you plan to use AD FS as your STS, you will need to do one of the following:

-Download, install and deploy AD FS 2.0 on a Windows Server 2008 or Windows Server 2008 R2 server. Also, if users will be connecting from outside your company’s network, you must deploy an AD FS 2.0 proxy.

-Install the AD FS role service on a Windows Server 2012 or Windows Server 2012 R2 server.

-If you plan to use Shibboleth Identity Provider as your STS, you will need to install and prepare an operational Shibboleth Identity Provider.

-Based on the type of STS you will set up, use the Microsoft Azure Active Directory Module for Windows PowerShell to establish a federated trust between your on-premises STS and Azure AD.

-Install the required updates for your Microsoft cloud service subscriptions to ensure that your users are running the latest updates of either Windows 7, Windows Vista, or Windows XP. Some features may not work properly without the appropriate versions of operating systems, browsers, and software.

-Depending on each of your domains, you may need to do the following:

-The UPN must be set and known by the user.

-The UPN domain suffix must be under the domain that you choose to set up for single sign-on.

-The domain you choose to federate must be registered as a public domain with a domain registrar or within your own public DNS servers.

-To create UPNs, follow the instructions in the Active Directory topic Add User Principal Name Suffixes. Keep in mind that UPNs that are used for single sign-on can only contain letters, numbers, periods, dashes, and underscores.

-If your Active Directory domain name is not a public Internet domain (for example, it ends with a “.local” suffix), you must set a UPN to have a domain suffix that is under a Internet domain name that can be registered publically. We recommend that you use something familiar to your users, such as their email domain.

-If you have already set up Active Directory synchronization, the user’s UPN may not match the user’s on-premises UPN defined in Active Directory. To fix this, rename the user’s UPN using the Set-MsolUserPrincipalName cmdlet in the Microsoft Azure Active Directory Module for Windows PowerShell.

All in all fix the issues showing in this readiness check.

• Plan the Directory Sync Method: For sure you would like to go for single sign on so this is the time to decide and select the appropriate single sign-on deployment topology. Let us see what are the option here.
  

  Azure AD: Extending your on-premises directories to Azure AD provides the following benefits:
  

  • Simplifying your cloud-based administrative tasks
    
  • Providing your users with a more streamlined sign-in experience
    
  • Obtaining single sign-on to all cloud-based applications
    
  • Securely and seamlessly managing your user and device identities, both cloud and on-premises, through a unified experience
    
  • Managing your first- and third-party applications, SaaS and other existing enterprise cloud and on-premises applications through a unified experience
    

  Azure AD supported scenarios:
  

  • Directory synchronization: Once directory sync has been set up, administrators can manage directory objects from your on-premises Active Directory and those changes will be synchronized to your tenant. In this scenario, your users will use different user name and passwords to access your cloud and on-premises resources.
    
  • DirSync with Password Sync – Used when you want to enable your users to sign in to Azure AD and other services using the same user name and password as they use to log onto your corporate network and resources. Password sync is a feature of the Directory Sync tool. But this is not single sign-on. It means you will used the same user id and password but you will have to login multiple times.
    
  • DirSync with Single Sign-On – Used to provide users with the most seamless authentication experience as they access Microsoft cloud services while logged on to the corporate network. In order to set up single sign-on, organizations need to deploy a security token service on-premises, such as Active Directory Federation Services (AD FS). Once it has been set up, users can use their Active Directory corporate credentials (user name and password) to access the services in the cloud and their existing on-premises resources. ADFS is the key component here which allows us to configure Single sign-on.
    
  • Multi-forest – DirSync with Single Sign-On – Used to provide users with the most seamless authentication experience as they access Microsoft cloud services while logged on to the corporate network. In order to set up single sign-on, organizations need to deploy Active Directory Federation Services (AD FS) as security token service on-premises. Once it has been set up, users can use their Active Directory corporate credentials (user name and password) to access the services in the cloud and their existing on-premises resources. This is the 4^th scenario where you are using multiple forest.
    

  Directory Synchronization tools: There are 3 tools available to provide directory sync for hybrid setup.

  • DirySync – Azure Active Directory Synchronization Tool
    
  • AAD Sync – Azure Active Directory Synchronization Services
    
  • FIM – Forefront Identity Manager 2010 R2
    

  Azure Active Directory Connect: It is an innovative tool which is under preview.  Microsoft has released the AAD connect tool on June 18th 2015 which is next day of publishing this blog and it is no more under preview. AAD Connect streamlines the experience of extending your local directories into Azure AD so that fewer tools are required to install; it guides you through the entire experience so you are not required to read many pages of documentation; and it reduces the on-premises footprint because you are not required to deploy many servers. AAD Connect is a single wizard that performs all of the steps you would otherwise have to do manually for connecting your Windows Server Active Directory to Azure Active Directory:
  

  • It downloads and installs prerequisites like the .NET Framework, Azure Active Directory PowerShell Module, and Microsoft Online Services Sign-In Assistant
    
  • It downloads, installs and configures Dirsync (or AAD Sync), and enables it in your Azure AD directory.
    
  • It configures either the password sync or the single sign-on scenario, depending on which sign-on option you prefer, including any required configuration in Azure.
    
  • It checks to make sure that your configuration is working!
    

  Isn’t it awesome tool?  Down load from here: https://www.microsoft.com/en-us/download/details.aspx?id=47594

  Learn more about it here. https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect/

• Install and Configure: This is the most critical step where we need to configure single sign-on between your on-premises organization and Office 365 tenant service. Let us see in the following steps
  

  The best way to configure ADFS is to follow the check list mentioned in the below link
  

  https://technet.microsoft.com/en-us/library/jj205462.aspx
  

ADFS Terminology

You need to updated ADFS with this hotfix on Windows 2008 R2 server – https://support.microsoft.com/en-us/kb/2681584

There is no windows 2012 hotfix.

Certificate:
This SSL certificate must contain the following with private key:

Subject name and subject alternative name must contain your federation service name, such as fs.domain.com.

Subject alternative name must contain the value enterpriseregistration followed by the UPN suffix of your organization, such as, for example,enterpriseregistration.domain.com

I am using wildcard cert so it should be fine.

The token-signing certificate must contain a private key, and it should chain to a trusted root in the Federation Service. By default, AD FS creates a self-signed certificate. However, depending on the needs of your organization, you can change this later to a CA-issued certificate by using the AD FS Management snap-in.

Recommendation: Use the self-signed token-signing certificate generated by AD FS. By doing so, AD FS will manage this certificate for you by default. For example, in case this certificate is expiring, AD FS will generate a new self-signed certificate to use ahead of time.

Have a look on the certificate requirement here. https://technet.microsoft.com/en-us/library/dn151311.aspx

DNS record:

Create a host record for fs.domain.com for the ADFS server.

Create a CName record enterpriseregistration pointing to fs.domain.com. A CNAME record is required in order to enable name resolution for the Device Registration Service (DRS)

Service Account:

Create a service account which will be required while configuring ADFS to continuously sync directories.

I have created ADFS2SVC account and checked “password never expires”. Add this user to the domain admins of the AD domain.

Configure ADFS: This is the time to ensure ADFS is configured and working file

• Install the AD FS software on the computers that will become federation servers by running the following command: 
  

  Install-windowsfeature adfs-federation -IncludeManagementTools
  

• Configure the AD FS software on one of the computers to act in the federation server role.
  
  • On the Server Manager Dashboard page, click the Notifications flag, and then click Configure the federation service on the server.
    

• The Active Directory Federation Service Configuration Wizard is launched.
  
• On the Welcome page, select Create the first federation server in a federation server farm and click Next.
  

• On the Connect to AD DS page, specify the service account which we had created earlier then click Next.
  

• On the Specify Service Properties page, do the following and then click Next:
  
  • Import the .pfx certificate file or select from dropdown.
    
  • Provide a name for your federation service. For example, fs.domain.com. This name must match one of the subject or subject alternative names in the certificate.
    
  • Provide a display name for your federation service. For example, Domain Corporation. This name will be shown to users at the AD FS sign-in page.
    

• On the Specify Service Account page, specify a service account. You can either create or use an existing group Managed Service Account (gMSA) or use an existing domain user account.
  

  The benefit of using a gMSA is its auto-negotiated password update feature. If you want to use a gMSA, you must have at least one domain controller in your environment that is running Windows Server 2012 operating system.
  

  If the gMSA option is disabled and you see an error message similar to Group Managed Service Accounts are not available because the KDS Root Key has not been set, you can enable gMSA in your domain by executing the following Windows PowerShell command on a Windows Server 2012 or later domain controller in your Active Directory domain:
  

  Add-KdsRootKey –EffectiveTime (Get-Date).AddHours(-10)
  

   

  
  

   

  Then return to the wizard and click the Previous button followed by theNext button to re-enter the Specify Service Account page. The gMSA should now be enabled, and you can select it and enter a desired gMSA account name. I am using my service account.
  

  
  

   

   

• On the Specify Configuration Database page, specify an AD FS configuration database and then click Next. You can either create a database on this computer using Windows Internal Database (WID) or you can specify the location and the instance name of the SQL server.
  

  
  

• Now Review Options and click Next.
  

  
  

• On the Pre-requisite Checks page, verify that all pre-requisite checks were successfully completed, and then click Configure.
  

  
  

• On the Results page, review the results and whether the configuration has completed successfully, Click Close to exit the wizard.
  

  
  

• Try to browse the following urls to test the working of ADFS
  

                                https://fs.domain.com/federationmetadata/2007-06/federationmetadata.xml

            

                https://fs.domain.com/adfs/ls/idpinitiatedsignon.htm - here you can see the name is being used

       

If you are on windows 2016 then run the following command as IDPInitiatedSignon comes disabled in windows 2016 ADFS.


Set-AdfsProperties -EnableIdpInitiatedSignonPage $true				

           
 Add fs.domain.com in local intranet

• Open the AD FS Management from Server manager
  

  
  

• ADFS mmc will look like as shown below:
  

  
  

  Add another node in the ADFS farm. You can add another node by installing ADFS on another server.
  
  Add a Web Proxy. The Web Application Proxy can provide access to web applications from extranet clients using AD FS claims-based authentication or Windows Integrated Authentication. The Web Application Proxy can be used in conjunction with Active Directory workplace join, multifactor authentication, or multifactor access control in order to enable more flexible and manageable resource access by users and devices outside of a company firewall.

 

• Enabling Device Registration Service
  

  To enable the Device Registration Service in the local forest, the following prerequisites must be met:
  

  • The Active Directory schema must be at Windows Server® 2012 R2 level.
    
  • You need to run Windows PowerShell cmdlets as a member of the Enterprise Admins group in order to enable DRS.
    
  • The group managed service account that was specified for the AD FS configuration must be specified for the value of the –ServiceAccountName parameter in the format domainaccount_name.
    

                                          Run this command and give same user id which we just configured to update AD for device registration: 

                                         Initialize-ADDeviceRegistration –serviceaccountname domainsvc

                                    Now the command to enable device registration.
 Enable-AdfsDeviceRegistration

• On the ADFS1 server, in the AD FS Management console, navigate to Authentication Policies. Select Edit Global Primary Authentication. Select the check box next to Enable Device Authentication, and then click Apply, OK.
  

 

Configuring ADFS extranet access

We need to configure the proxy ADFS in DMZ to secure ADFS server. More info is listed here. https://technet.microsoft.com/en-us/library/dn528859.aspx

Connect/Install Azure AD Powershell

Follow the steps from my blog here – https://msexchangeguru.com/2015/06/17/o365-connect-azure-ad/

Set up a trust between AD FS and Azure AD

This is one of the crucial step. Let us see the steps. Each domain that you want to federate must either be added as a single sign-on domain or converted to be a single sign-on domain from a standard domain. Adding or converting a domain sets up a trust between AD FS and Microsoft Azure Active Directory (Microsoft Azure AD).

Continue on the same Azure AD powershell.

      Run the following command to add a federation

        Run New-MsolFederatedDomain –DomainName <domain>, where <domain> is the domain to be added and enabled for single sign-on.

      In our case we will convert so we have to run the following command

          Run Convert-MsolDomainToFederated –DomainName <domain>, where <domain> is the domain to be converted. This cmdlet changes the domain from standard authentication to single sign-on.

           

To verify that the conversion has worked, compare the settings on the AD FS server and in Azure AD by running Get-MsolFederationProperty –DomainName <domain>. If they don’t match, you can run Update-MsolFederatedDomain –DomainName <domain> to sync the settings.

My domain got this

At the same time you will see “Possible Service issue” in the office 365 portal. This is because of the federation has updated and it might have broken the SPF record. I simply stopped checking dns issue.

So I ran Update-MsolFederatedDomain –DomainName domainname because federated service displayname showing different and after the command it got fixed.

Our Next Step is Directory Synchronization which will be covered in the Part 3. Stay Tuned.

Exchange 2013: Hybrid Part 1

Exchange 2013: Hybrid Part 3

Exchange 2013: Hybrid Part 5

Exchange 2013: Hybrid Part 6

Exchange 2013: Hybrid Part 7

 

Prabhat Nigam

Microsoft MVP | Exchange Server

Team@MSExchangeGuru

Tweet me @PrabhatNigamXHG

Posted June 17th, 2015 under ADFS, Exchange 2013, Office 365. Tags: ADFS, Exchange 2013 Hybrid
RSS 2.0 feed. Leave a response, or trackback.