Embed Size (px)
Citation preview
Step by Step ADFS
Hussain Shakir
LinkedIn: https://www.linkedin.com/in/mrhussain
Twitter: https://twitter.com/hshakir_ms
Blog: http://mstechguru.blogspot.com/
Table of Contents
About Author ........................................................................................................................................................ 2
Product Overview ................................................................................................................................................. 3
Role description .................................................................................................................................................... 3
ADFS in Azure Test Lab Requirements ............................................................................................................... 4
Prerequisite ........................................................................................................................................................... 4
Prepare the Base Servers ...................................................................................................................................... 4
AD FS Server ......................................................................................................................................................... 4
AD FS Proxy Server ............................................................................................................................................... 4
Directory Sync Server ........................................................................................................................................... 5
Prepare Active Directory ...................................................................................................................................... 5
Add UPN Suffix ..................................................................................................................................................... 5
Clean up Active Directory .................................................................................................................................... 5
Create the SSL Certificate Request (CSR) ............................................................................................................ 6
Fulfill the Certificate Signing Request (CSR) ...................................................................................................... 11
Complete the Certificate Request (CSR) ............................................................................................................. 11
Assign the Completed SSL Certificate ................................................................................................................ 15
Configure Local AD FS Federation Server .......................................................................................................... 18
Configure Federation Trust with Office 365 .......................................................................................................25
Synchronizing your directory with Office 365 ...................................................................................................27
Requirements for running the Directory Sync tool ...........................................................................................27
It must be joined to Active Directory .................................................................................................................27
It must run Windows PowerShell ...................................................................................................................... 28
To add an alternative UPN suffix ....................................................................................................................... 29
Match On-Premise UPN with Office 365 UPN ................................................................................................. 29
Monitoring and Testing Directory Sync ............................................................................................................ 39
About Author
Shakir is IT Consultant with over 13 years of extensive experience working with Microsoft
Technologies AD, Exchange, O365, Windows Azure, PowerShell, Skype for Business, SQL,
SharePoint and Microsoft public clouds, and providing solutions to different local & international
Enterprise customers.
Shakir has been involved in Infrastructure Designing and Implementation, Virtualization, and
Disaster Recovery. Extensive hands-on experience in Core Server Infrastructure, Cloud Computing,
Virtualization/ Management and Information Protection. Analysis and Support of Microsoft
Windows Server based Client / Server network, AD, Messaging, Skype for Business, SQL Always ON,
Virtualization and System Center Infrastructure Products. Shakir has various industry certifications:
MCT, MCTS, MCITP, MCSA, MCSE: Messaging, MCPS, MCSE: Cloud Platform and Infrastructure
and also providing trainings on Microsoft Based Technologies.
Product Overview
Active Directory Federation Services (AD FS) simplifies access to systems and applications using a claims-
based access (CBA) authorization mechanism to maintain application security. AD FS supports Web single-
sign-on (SSO) technologies that help information technology (IT) organizations collaborate across
organizational boundaries. AD FS 2.0 is a downloadable Windows Server 2008 update that is the successor
to AD FS 1.0, which was first delivered in Windows Server 2003 R2, and AD FS 1.1, which was made available
as a server role in Windows Server 2008 and Windows Server 2008 R2. Previous versions of AD FS are referred
to collectively as AD FS 1.x.
Role description
AD FS provides simplified, secured identity federation and Web single sign-on (SSO) capabilities for end
users who want to access applications within an AD FS-secured enterprise, in federation partner
organizations, or in the cloud.
In Windows Server® 2012 R2, AD FS includes a federation service role service that acts as an identity provider
(authenticates users to provide security tokens to applications that trust AD FS) or as a federation provider
(consumes tokens from other identity providers and then provides security tokens to applications that trust
AD FS).
ADFS in Azure Test Lab Requirements
Prerequisite Azure Subscription for Creating Virtual Machines
Public Certificate
Public IP Address on ADFS
Public IP Address on ADFS Proxy
Four physical/virtual Server’s required for this Lab, (ADFS, ADFS Proxy, DC, DirSync)
Virtual Machines can be setup Azure cloud as per this guide.
Prepare the Base Servers
AD FS Server
Base build the AD FS server with Windows Server 2012
Setup a connection to the internal network
Add the server to the local domain
Update the server with all Windows Updates
AD FS Proxy Server
Base Build the AD FS Proxy server with Windows Server 2012
Setup a connection to the DMZ network (verify connectivity to the AD FS server on port 443)
DO NOT add the server to the local domain
Update the server with all Windows Updates
Directory Sync Server
Base build the Directory Synchronization server with Windows Server 2012
Setup a connection to the internal network
Add the server to the local domain
Update the server with all Windows Updates
Prepare Active Directory
Add UPN Suffix
If you are using and internal domain name that doesn’t match the domain that you want to federate with
Office 365 you will have to add a custom UPN suffix that matches that external name space. If you need to
add the UPN suffix, please follow these instructions, http://support.microsoft.com/kb/243629
Example
Internal Domain Name – yourdomain.local
Desired Federated Domain – contoso.com
Clean up Active Directory
This makes sense for so many reasons, but the most for Directory Sync. I generally make an OU for all the
Office 365 Services; then create more OUs within that one for all the user accounts, services accounts, groups,
servers and computers. This will allow us to filter on user accounts and groups when we enable Directory
Synchronization with Office 365. The less number of objects that you sync with Office 365 is better. If you
have thousands of objects replicating, that don’t need to be, things will get messy really quick. Keep it clean
and neat. This will prevent mistakes and keep you head ache free.
Setting up AD FS requires the use of a third party SSL certificate. In a production situation, I would
recommend that a single name SSL certificate. Wildcard and multi-name certificates will work, but I like to
keep things simple and use a standard SSL certificate in a production situation. Make sure that the common
name matches what you plan to call the AD FS server farm. Microsoft best practices recommends that you
use the host name, STS (secure token service). In the example below, I have used the value sts.domain.com.
Create the SSL Certificate Request (CSR)
1. Open Server Manager
2. Click Tools
3. Click Internet Information Services (IIS) Manager
4. Select the local server
5. Select Server Certificates
6. Click Open Feature (actions pane)
7. Click Create Certificate Request
8. Fill out the certificate request properties. Make sure that the common name matches what you
plan to call the AD FS server farm. Microsoft best practices recommends that you use the host
name STS (secure token service). In the example below, I have used the
value sts.domain.com.
9. lick Next
10. Leave the Cryptographic service provider at the default
11. Change the Bit Length to 2048
12. Click Next
Fulfill the Certificate Signing Request (CSR)
We need to take the CSR generated in the last step to a third party SSL certificate provider. I
choose to use GoDaddy. Here are GoDaddy’s instructions to fulfill the CSR at their site
– Requesting a Standard or Wildcard SSL Certificate. Once the certificate is issued, download the
completed CSR to the AD FS server.
Complete the Certificate Request (CSR)
1. Open Server Manager
2. Click Tools
3. Click Internet Information Services (IIS) Manager
4. Select the local server
5. Select Server Certificates
6. Click Open Feature (actions pane)
7. Click Complete Certificate Request
8. Select the path to the complete CSR file that you competed and downloaded from the third party certificate provider
9. Enter the friendly name for the certificate
10. Select Personal as the certificate store
11. Click OK
12. The certificate will be added
***Note*** The certificate shown below is a multi-name SSL certificate for my lab environment.
When your certificate is added, it should show sts.domain.com, which matches the request.
Assign the Completed SSL Certificate
Now that we have the third party certificate completed on the server, we need to assign and
bind it to the default website (HTTPS port 443).
1. Expand the local server
2. Expand Sites
3. Select Default Web Site
4. Click Bindings (actions pane)
5. Click Add
6. Change the type to HTTPS
7. Select your certificate from the drop down menu.
***Note*** The certificate shown below is a multi-name SSL certificate for my lab environment. When you select your certificate, it should show sts.domain.com, which matches the competed certificate.
8. Click OK
9. Click Close
10. Close IIS Manager
Now that we have the required software installed and the certificate in place, we can finally configure the AD FS role and federate with Microsoft.
Configure Local AD FS Federation Server
Open Server Manager
1. Open Server Manager
2. Click Tools
3. Click AD FS Management
4. Click AD FS Federation Server Configuration Wizard
5. Create a new Federation Service
6. New Federation Server Farm – Choose this option all the time, even if you only plan on deploying one server. If you choose Stand-alone federation server, then you won’t
be able to add more servers.
7. Click Next
8. SSL Certificate – This should be pre-populated. If it isn’t, go back and assign/bind the third party certificate to the default web site
9. Federation Service Name – This should match the SSL certificate name
*** NOTE *** Since I am using a multi-name certificate in a lab environment, my SSL
certificate name and Federation Service name don’t match. This is not recommended for
production environments. Use best practices always; a single name certificate.
10. Click Next
11. Enter the AD FS service account name and password
12. Click Next
13. Click Next
14. All green check marks mean everything is setup correctly
15. Click Close
Configure Federation Trust with Office 365
Now that we have our side of the federation setup, we can complete the federation with Office 365
Open the Desktop on the AD FS server
Download Windows Azure Active Directory Module for Windows PowerShell
Right Click and Run As Administrator
Set the credential variable
o $cred=Get-Credential
Enter a Global Administrator account from Office 365. I have a dedicated tenant
(@domain.onmicrosoft.com) service account setup for AD FS and Directory
Synchronization.
Connect to Microsoft Online Services with the credential variable set previously
o Connect-MsolService –Credential $cred
Set the MSOL ADFS Context server, to the ADFS server
o Set-MsolADFSContext –Computer adfs_servername.domain_name.com
Convert the domain to a federated domain
o Convert-MsolDomainToFederated –DomainName domain_name.com
Successful Federation
o Successfully updated ‘domain_name.com‘ domain.
Verify federation
o Get-MsolFederationProperty –DomainName domain_name.com
This completes the setup for federation to Office 365. Keep in mind that before you can
successfully use single sign-on with Office 365, you will need to setup and configure Directory
Synchronization. After Directory Synchronization is setup, you will have to license the synchronized
user in Office 365. This will provision the services for the user. If they want to access Office 365
from outside the internal network, the AD FS Proxy server needs to be setup and configured.
First we need to setup ADFS & SSO than we will configure DirSync server with O365.
Synchronizing your directory with Office 365
All customers of Azure Active Directory and Office 365 have a default object limit of 50,000 objects
(users, mail-enabled contacts, and groups) by default.
This limit determines how many objects you can create in your tenant.
Objects can be created using DirSync, Powershell or the GRAPH API.
When you verify your first domain, this object limit is automatically increased to 300,000 objects.
Requirements for running the Directory Sync tool
The directory synchronization computer must meet the following requirements:
It must run Windows Server as operating system. The following versions of the Windows Server operating system are supported:
64-bit edition of Windows Server 2008 Datacenter
64-bit edition of Windows Server 2008 R2 Standard or Enterprise, Windows Server 2008
R2 Datacenter
64-bit edition of Windows Server 2012 Standard or Datacenter
64-bit edition of Windows Server 2012 R2 Standard or Datacenter
It must be joined to Active Directory
The computer must be joined to the Active Directory forest that you plan to synchronize.
It must run the Microsoft .NET Framework 3.5 SP1 and the Microsoft .NET Framework 4.0. If you are running Windows Server 2008, the .NET Framework will already be installed; if not, you can download it from the following locations:
Microsoft .NET Framework 3.5 Service Pack 1
Microsoft .NET Framework 4.0
It must run Windows PowerShell
If you are running Windows Server 2003, you need to download Windows PowerShell. If you are
running Windows Server 2008, you need to enable Windows PowerShell.
Hardware Requirements for DirSync: -
To set up directory synchronization, you must designate one computer as your directory
synchronization computer, and then install the Directory Sync tool on that computer.
Number of objects in Active Directory CPU Memory Hard drive size
Fewer than 10,000 1.6 GHz 4 GB 70 GB
10,000–50,000 1.6 GHz 4 GB 70 GB
50,000–100,000
Requires full SQL Server
1.6 GHz 16 GB 100 GB
100,000–300,000
Requires full SQL Server
1.6 GHz 32 GB 300 GB
300,000–600,000 1.6 GHz 32 GB 450 GB
Requires full SQL Server
More than 600,000
Requires full SQL Server
1.6 GHz 32 GB 500 GB
UPN Requirement: -
Your Active Directory environment must be properly configured in order for your users to sign-in to
Microsoft online services. In particular, the userPrincipalName (UPN) attribute, also known as a user
logon name, must be set up correctly for each user in a specific way. The UserPrincipalName attribute
must use a publically routable domain. If you are not currently using a publically routable domain, you
will need to update your users UserPrincipalNames. To do this, add an alternative UPN suffix in your
on-premises Active Directory.
To add an alternative UPN suffix
Click Start, Administrative Tools, and then click Active Directory Domains and Trusts.
Log on to one your organization’s Active Directory domain controllers
In the console tree, right-click Active Directory Domains and Trusts and then click Properties.
Select the UPN Suffixes tab, type an alternative UPN suffix for the forest, and then click Add.
Repeat step 3 to add additional alternative UPN suffixes.
Match On-Premise UPN with Office 365 UPN
If you have not yet set up Active Directory synchronization, you can skip this task and continue
with the next section.
If you have already set up Active Directory synchronization, the user’s UPN for Office 365 may
not match the user’s on-premises UPN defined in Active Directory. This can occur when a user
was assigned a license before the domain was verified.
To remedy this issue, use Windows PowerShell to update users’ UPNs to ensure that their Office
365 UPN matches their corporate user name and domain.
The first thing we want to do is tell our Office 365 tenant that we are going to setup directory
synchronization. This can take some time, so best do this step first.
1. Log into Microsoft Online Portal
2. Select the Users and Groups button within the Office 365 admin center.
On the right-hand page select Active Directory Synchronization set up
4. Select Activate under Step 3, Activate Active Directory Synchronization. Please note that
this can take up to 24 hours to complete.
5. Once Active Directory Synchronization has been activated, you will see the task change to
activated
At this point we can go ahead and install the DirSync tool. From a member server in your on-
premise domain, open up a browser a log into your Office 365 tenant.
7. Repeat steps 1 -3 to get back to the Active Directory Synchronization page.
8. Select download against option 4, Install and Configure the Directory Sync Tool, this will
downloaddirsync.exe onto your local machine.
9. Once downloaded, run dirsync.exe (NOTE: You must have .NET Framework 3.51 and .NET
Framework 4.0 installed on the computer in order to run this tool) If you see an error message at
this point then you can install .NET 3.51 from the Administrative Tools > Server Manager >
Features > Add Features.
10. Select .Net Framework 3.5.1 Features and follow the installation instructions.
11. You may at this point need to check that you have also installed all security updates to .Net
Framework 3.5.1.
12. .NET Framework 4.0 can be downloaded from here.
13. Once you have the right version of .NET Framework, go ahead and install dirsync.exe. At
theWelcome screen click Next
14. Accept the EULA
15. Select the Installation Folder you wish to install the binaries into. The installation will begin.
16. When the installation is complete click Next
17. Check the Start Configuration Wizard now and click Finish
18. On the DirSync tool Configuration wizard welcome screen click Next
19. Provide credentials of an account with administrative permissions for your online tenant. These
credentials will be saved and used to synchronize changes from your organization’s on-premise
Active Directory with Windows Azure Active Directory.
Important: When you change the password for this account, you must run this wizard again to
change the password used by the DirSync tool. Click Next
20. Provide the credentials for an account with administrative permissions on your organizations
Active Directory. These credentials will be used to set the permission for the DirSync tool, which
will sync changes in your organization’s Active Directory with Windows Azure Active Directory.
These credentials are not saved.
21. The Hybrid Deployment page, if used, provides a unified email experience for you Office 365
and on-premise environment. A Hybrid deployment boasts features such as unified GAL, off-
boarding and others. A full list of these can be found here.
This requires an Exchange 2010 server on-premise, as we don’t have one for this setup, this is
greyed out.
22. Password Synchronization. The Sync’ing of password from on-premise to cloud allows users
to access Office 365 with the same password as the one they use for on-premise resources. If
you require this then select Enable Password Sync, and click Next.
23. The DirSync tool will now configure your settings.
24. Select Synchronize your directories now and click Finish.
25. The configuration wizard presents you with a link to see how you can verify your directory
has been synchronized. Click OK.
Monitoring and Testing Directory Sync
Once you have the dirsync tool installed we will need to test that it works correctly. There are a
couple of ways you can test and monitor dirsync, ideally what we want to do is test both forced &
automatic updates.
To monitor our changes, we can use the Synchronization Service Manager tool, which ships
with DirSync.
Navigate to the following directory on the member server you installed the dirsync tool C:\Program
Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell
Double-click miisclient
To summarize, in the top frame you have a list of when DirSync ran, the bottom left frame gives
you finer detail of the changes, for example the number of changes, add, deletes, etc.
To test a forced sync, navigate to you on-premise Active Directory and make a simple change
on an account that you have on both platforms. In this example I’ve updated the Job Title details
on the accountEdward Tester.
Then log onto the member server where the dirsync tool is installed.
Navigate to the following directory. C:\Program Files\Windows Azure Active Directory
Sync and runDirSyncConfigShell.psc1
Type Start-OnlineCoexistenceSync. Press Enter. This will force a sync between you on-
premise Active Directory and Windows Azure Directory Services.
If you now open up the Sync Service Manager and you will see the update going through.
If you click and navigate further you can see the finer detail of the updated object, in this
instance the object field we are attempting to sync.
You can now check your user object in Office 365, the change has been replicated.
The default sync between Office 365 and on premise Active Directory is 3 hours. This can be
changed to whatever suits your companies need. This previous article on changing the default
Office 365 DirSync Schedule outline the steps for this.
