Step by Step ADFS For Anyone
Step by Step ADFS For Anyone
Step by Step ADFS For Anyone
Hussain Shakir
LinkedIn: https://www.linkedin.com/in/mrhussain
Twitter: https://twitter.com/hshakir_ms
Blog: http://mstechguru.blogspot.com/
Table of Contents
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
Four physical/virtual Server’s required for this Lab, (ADFS, ADFS Proxy, DC, DirSync)
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
Example
2. Click Tools
9. lick Next
10. Leave the Cryptographic service provider at the default
2. Click Tools
8. Select the path to the complete CSR file that you competed and downloaded from the
third party certificate provider
11. Click OK
***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).
2. Expand Sites
***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
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.
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
Connect to Microsoft Online Services with the credential variable set previously
o Connect-MsolService –Credential $cred
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.
This limit determines how many objects you can create in your tenant.
When you verify your first domain, this object limit is automatically increased to 300,000 objects.
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 R2 Standard or Enterprise, Windows Server 2008
R2 Datacenter
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:
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.
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.
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.
2. Select the Users and Groups button within the Office 365 admin center.
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.
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.
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.
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.