Certificates used by federation servers

Replacing the SSL Certificate for an AD FS farm

1. Provide ADFS Farm Information
2. Provide new SSL Certificate
3. Select Servers for update

Prerequisites

• AD FS Farm: Make sure that your AD FS farm is Windows Server 2012 R2-based or later.
• Azure AD Connect: Ensure that the version of Azure AD Connect is 1.1.553.0 or higher. You'll use the task Update AD FS SSL certificate

Step 1: Provide AD FS farm information

Azure AD Connect attempts to obtain information about the AD FS farm automatically by:

1. 1. Querying the farm information from AD FS (Windows Server 2016 or later).
   2. Referencing the information from previous runs, which are stored locally with Azure AD Connect.

If the list contains a server that's no longer part of the AD FS farm, click Remove to delete the server from the list of servers in your AD FS farm.

Step 2: Provide a new SSL certificate

After you've confirmed the information about AD FS farm servers, Azure AD Connect asks for the new SSL certificate. Provide a password-protected PFX certificate to continue the installation.

After you provide the certificate, Azure AD Connect goes through a series of prerequisites. Verify the certificate to ensure that the certificate is correct for the AD FS farm:

• • The subject name/alternate subject name for the certificate is either the same as the federation service name, or it's a wildcard certificate.
  • The certificate is valid for more than 30 days.
  • The certificate trust chain is valid.
  • The certificate is password protected.

Step 3: Select servers for the update

In the next step, select the servers that need to have the SSL certificate updated. Servers that are offline can't be selected for the update.

After you complete the configuration, Azure AD Connect displays the message that indicates the status of the update and provides an option to verify the AD FS sign-in.

• Tip:Use the DigiCert SSL Installation Diagnostics Tool  to confirm that the certificate and all intermediate certs are installed correctly, This tool works with any third-party CA certificate, not just DigiCert's.

Replacing the Token-Signing and Token-Decrypting Certificate

• Simply turning AutoCertificateRollover back on via PowerShell will not immediately cause the self-signed certificates to be generated
• The self-signed certificates will only be generated once the critical threshold (close to expiration) of your existing certificates has been met
• There is a way to immediately cause the self-signed certificates to be generated, but this will cause service outage with your partners until they have refreshed from your federation metadata. We recommend causing the certificate generation after hours to avoid an outage.Alternatively, you could work closely with your partners to ensure that they are ready to immediately update via federation metadata (causing a short outage).

• Logon to the primary AD FS server and open an elevated PowerShell prompt. Run the following to configure the AD FS server to generate  self-sign Token-Signing and Token-Decrypting certificates that  last 10 years and enable Auto Certificate Rollover:

• These cmdlets will generate new self-signed Token-Signing and Token-Decrypting certificates which will be promoted immediately and then disable auto certificate rollover again. Relay partners will need to update their metadata to accept the new signed claims:

• Update the Office 365 metadata using Windows Azure PowerShell:

• Remember that you'll need to update other relaying party metadata, if you use them. For example, Yammer on-prem (not Office 365) must be updated manually by Microsoft by opening a support ticket in the Office 365 portal. You will need to supply them with the Token-Signing and Token-Decrypting certificates (minus the private keys).

A Note About WAP Servers

Overview of AAD Connect

Azure AD Connect is a single wizard that performs following steps automatically

• Install pre-requisites like the Azure Active Directory PowerShell Module and Microsoft Online Services Sign-In Assistant.
• Install and configure Azure AD Sync, as the sync engine, and enable directory synchronization in the customer's Azure tenant
• Configures either password sync or AD FS, depending on which sign-on option the customer prefers, and includes any required configuration in Azure

Different Synchronization Tools

With the release of Azure AD Connect we now have three tools that will provide directory synchronization to Azure AD / Office 365. 

• Microsoft Azure Active Directory Sync tool (DirSync) – This sync tool will eventually retire but there is no ETA at this time.
• Azure AD Sync – The “stand alone” version of this tool will retire when Azure AD Connect goes GA.
• Azure AD Connect – This sync tool will be the only tool available once DirSync is retired. It includes Azure AD Sync as the synchronization engine.

Azure AD Connect with additional sync options, seamless migration from DirSync,

There will no longer be separate releases of Azure AD Sync and Azure AD Connect. And we have no future releases of DirSync planned. Azure AD Connect is now your one stop shop for sync, sign on and all combinations of hybrid connections.

When stating the setup the Microsoft Azure Active Directory Connect tool assist you by installing the prerequisites that are needed to be able to synchronize users and groups from your on premise AD to Azure AD. It will automatically install the following products if they do not exist;

• Microsoft Online Services Sign-In Assistant for IT Professionals
• Windows Azure Active Directory Module for Windows PowerShell
• Microsoft Visual C++ 2013 Redistributable Package

Install the prereqs

After getting the prerequisites ready the Azure AD Connect synchronization service will be installed. Azure AD Connect synchronization service needs a SQL database, you can configure an existing one or a SQL Express version will be automatically installed. Next we need to provide the username of a Azure AD user that is a member of the Global Administrator role.

Connect to Azure AD

After the synchronization service installed and connected with Azure AD we are able to customize the configuration of Azure AD Connect synchronization service, and more  So if we do not choose to use the express settings as shown below we are able to
configure Single Sign On via Password Synchronization, Federation with AD FS.

 Use customize option

Custom options

I will choose Federation with AD FS and connect my Active Directory. Microsoft Azure Active Directory Connect allows you to synchronize more than one directory, which is really cool if you ask me.

Add your on premise AD

The next step is that you are able to filter users and groups by DN or Group Membership. So no hacking in FIM (which is not part of this solution anymore) anymore.

Filter or synchronize everything

Next you need configure how the user in on premise directories is identified. Is a user represented only once across multiple directories or does user identities exist across multiple directories. Based on attributes you are able to configure how a user must be matched. If you only use one Active Directory as a source, you can easily use the defaults as shown below.

Select the attributes

As you see the Microsoft Azure Active Directory Connect tool assist you heavily in setting up the synchronization service. But is does more, optionally you are able to configure the following features:

Exchange hybrid deployment

The Exchange hybrid deployment features allows co-existence of Exchange mailboxes on both on premises as in Azure by synchronizing a specific set of attributes from Azure AD back to your own Active Directory.

Password write back

If the password changes in Azure AD, it will be written back to your own Active Directory.

User write back

If a user is created in Azure AD, it will be written back to your own Active Directory.

And:

• Azure AD app and attribute filtering
• Group writeback
• Device writebrack
• Device Sync
• Directory extension attribute sync

Selecting two options as shown below allows us to configure the writeback location in the on premise Active Directory.

Additional options

Next you need to configure a new AD FS Farm Windows server 2012 R2. Specify the SSL certificate used to secure the communication between clients and AD FS. The certificate file should be in pfx.

Certificates

Since ADFS leverages SSL, we need to have a SSL certificate.  You could try three options, but only one will work:

1. Self-signed certificate
2. Certificate issued from internal PKI
3. Certificate from 3rd party public CA

Office 365 needs to see a valid Service Communication Certificate on your ADFS infrastructure, so you are going to have to buy a certificate from a public CA.  Office 365 will not trust a service communication certificate that is either self-signed or from your internal CA, which results in tears.  We can use self-signed certificates for the Token Decrypting and Token Signing Certificate.  These are separate from the service communication cert.

Please follow the documentation from your chosen CA to request, install and complete the certificate.  The steps required vary from vendor to vendor and also over time.  Make sure you are not missing any updated intermediate certificates!  How would you know?  Follow their process!!

For the purposes of this post we shall deploy the initial ADFS server, and in the future add another ADFS server for redundancy.

 Add Federation Servers On Windows Server 2012 R2, specify where to install AD FS services

Add Proxy servers On Windows Server 2012 R2, specify where to install Web Application proxy servers name

Next specify proxy trust credentials. The web application proxy requires credentials to request a certificate from federation server.

It is possible to use a GMSA as the ADFS service account.  GMSA will automatically update the service account’s credentials and administrators will also be oblivious as to its password.

In this case a standard service account was used.

 Select the Azure AD domain to federate with your on-premises Directory. The managed domain will be converted into a federated domain

 The Final step in the really great wizard is to install and configure the synchronization services, AD FS and WAP servers.

Configure!

At this time please make sure that you have created DNS records that allow clients to resolve your federation services from both internal and external. 

All done, 

Additional Steps

This topic covers additional steps to configure AD FS after you install the first federation server, including:

• Opening the ADFS Management Snap-in
• Configuring Name Resolution for AD FS Services
• Adding nodes to the farm
• Adding a Web Application Proxy
• Enabling Device Registration Service

For more information about how to deploy AD FS, see How to deploy AD FS in Windows Server 2012 R2.

Verify Federation Service Metadata

Open Internet Explorer and navigate to your ADFS server’s federation metadata URL.

This will be something like the below, just change the FQDN to match your environment.

https://sts.vin-o365.in/federationmetadata/2007-06/federationmetadata.xml

The result should show this:

Verify ADFS Sign-In Page

Browse to the ADFS sign-in page and test that you are able to authenticate.

The URL will be similar to the below, again change the FQDN to match your organisation’s.

https://sts.vin-o365.in/adfs/ls/idpinitiatedsignon.htm

AAD Sync is our new directory synchronization tool that simplifies the process of connecting Azure AD to Windows Server AD. It also makes it simpler to connect complex, multi-forest deployments. It also has the capabilities to: Azure Active Directory Sync is now GA!

• Active Directory and Exchange multi-forest environments can be extended now to the cloud.
• Control over which attributes are synchronized based on desired cloud services.
• Selection of accounts to be synchronized through domains, OUs, etc.
• Ability to set up the connection to AD with minimal Windows Server AD privileges.
• Setup synchronization rules by mapping attributes and controlling how the values flow to the cloud.
• Preview AAD Premium password change and reset to AD on-premises.

If you just want to get started, you can download it here.

First, make sure you have uninstalled the old version of DirSync. Then, to install AADSync, you need a computer running the Windows Server operating system.

• Windows Server 2008
• Windows Server 2008 R2
• Windows Server 2012
• Windows Server 2012 R2

Your target computer for installing AAD Sync can be stand-alone, a member server or a domain controller. And it must have the following components need installed:

• .Net 4.5
• PowerShell (preferably PS3 or better)

Note:

The tool needs an instance of SQL Server to store identity data. By default a SQL Express LocalDB is installed and the service account for the service is created on the local machine during the install.

Since Express has a 10GB size limit (it enables you to manage approximately 100.000 objects.) If you anticipate managing a higher volume of directory objects, you need to point the installation process to a different version of SQL Server.

Installing and configuring AADSync

1- Download the tool from here.

2- Execute MicrosoftAzureADConnectionTool.exe.

3- Once you get to the “Welcome to Azure AD Sync” dialogue box, Agree to the license terms and click Install

4- Once it’s installed, the tool will start (it may take a few seconds) and once you get to connect to Azure AD, Supply the credentials to connect to your Azure AD directory.  (The global account you created earlier)  I used a Global Admin in my directory in Azure called SysAdmin 

5- And as you would assume, you need to supply credentials for your local forest\domains to the Connect to AD DS dialogue box. And click “Add Forest” button and once you domain shows up.  Click next.

 6- In the uniquely identifying your users

 
You need to configure the following:

6.1- The Matching across forests feature allows you to define how users from your ADDS forests are represented in Azure AD.

A user might either be represented only once across all forests or have a combination of enabled and disabled accounts

6.2- You can use the Matching with Azure AD option to specify the attribute you want to use for identity federation. The sourceAnchor attribute is an attribute which is not changing during the lifetime of a user object. In single-forest and environments and where the account is never moved between forests, then objectGUID is a good candidate. If the user is moved between forests or domains, then an alternative attribute must be selected.

The userPrincipalName attribute is the user’s login ID in Azure AD. By default the userPrincipalName attribute in ADDS is used. If this attribute is not routable or not suitable as the login ID a different ttribute, such as mail, can be selected in the installation guide.

Click Next to move on to the Optional Features.

7- In the Optional features dialogue box, you can select Exchange hybrid deployment, if you have a Hybrid Exchange environment. For us we will NOT enable this setting.  The password write-back is an Azure Active Directory Premium feature. (which we do not  have enabled in our test environment so i will leave it checked off) and If you want to review or limit the attributes which are synchronized with Azure AD, then select Azure AD app and attribute filtering. You will then get two additional pages in the wizard. Right now we just want to get it synced, so we will leave that check off as well. 



8- The Configure screen allows you to start the configuration process.  Just click “Configure”

It will connect, and configure the sync rules and bring up the “Finished” screen. Where if you leave the “Synchronize Now” once you click Finished it will start the sync process 

 Sign out of Windows at this stage and log back in.

 
Locate and launch the Azure AD Sync Synchronization Service.
 


Open the Connectors tab. See the AD Domain Services connector. Double click to see the properties.

Navigate to "Configure Directory Partition". Select "Containers".

Enter your credentials.

 
Now you can choose your OUs. Select OK to close the dialog boxes
Select Run => Choose "Full Import".

See successful import to Azure. However, this is not immediate and it will take some time for the users to be available in Azure (I am impatient so thankfully there is a way to force the sync).

Previously with DirSync we used "start-onlinecoexistencesync". This has now been replaced in AAD Sync with "DirectorySyncClientCmd.exe".

Navigate to C:\Program Files\Microsoft Azure AD Sync\Bin and launch DirectorySyncClientCmd.exe

That’s it.  We now have our Local directory synced in Azure.

Password write back with On-Premise Sync in Azure AD Premium

Administrators have been able to reset their forgotten passwords in Azure AD for a long time now and we've heard lots of requests from customers who also want to enable their end users to reset their own passwords. To try it out, sign in to the Windows Azure Management Portal, click on Active Directory in the left navigation bar, then head to the directory configuration tab and look for the 'user password reset policy' section.

Self-Service Password Reset for Users is part of the latest set of changes included in Windows Azure Active Directory Premium. With this feature, users can reset their passwords using their mobile or office phones, or their alternate email addresses. Users can even self-register their own password reset data with a few mouse clicks! In addition to this, as the administrator you have total control over the policies applied to these users when they reset their passwords. You don't want users to reset using their mobile phone number? No problem! You want to specify how many verification steps users must go through.

There following questions that you'll be able to answer ater reading through this document

• How can I configure password reset from the Azure management portal?
• How can my users register for password reset?
• How can my users reset their passwords after they are registered?
• How can I configure password reset to write passwords back to a local Active Directory?

How to configure password reset in the Azure management portal

In order to enable Self-Service Password Reset, you'll need to be using Windows Azure Active Directory Premium. You can learn how to do that by following the instructions here. Once you've done that, sign in to the Windows Azure Management Portal, navigate to your directory, click on the CONFIGURE tab, and scroll down until you see the "user password reset policy" section (see Fig. 1). This is where all the magic happens.

Fig. 1: The directory configuration tab

Fig. 2: The user password reset policyconfiguration section

Once in configure tab, the above is what you'll see in the "user password reset policy" section (see Fig 2.). There are a lot of neat knobs you can tweak to change the behavior of password reset in your organization. They are split into a few logical categories:

• Security Policy
• Registration Policy
• Portal Customization

Let's take a moment to go through them one by one.

 Fig. 3: Password reset security policy

How to manage password reset security policy

Controls in this section (outlined in Fig 3. above) affect how password reset works in your organization. Read on below to see a description of what each of these controls does.

• Is password reset enabled for my directory? Once you're using Windows Azure Active Directory Premium, you'll see a new configuration setting which allows you to turn password reset on or off for all your users. In order to see the rest of the policy controls, you'll have to turn this on first. Also, stay tuned, we're looking at ways that will let you enable this feature on a  per-user or per-group basis.
• What types of contact methods can users use to reset their passwords? Once you've turned this feature on, you'll be able to choose which contact methods a user is able to use to reset his or her password. For those of  you with international phone numbers, you'll be happy to know that we support both voice and SMS calls for the mobile phone-based contact method. All of our SMS and voice messages are also fully localized for your users coming from different locales. Don't see a contact method you are interested in? Let us know!
• How many contact methods must a user provide when resetting their passwords? For those of you with high security requirements, or those who just want a bit more assurance that passwords are being reset securely, we allow you to require that your users go through either one or two of your selected contact methods above

Fig. 4: Password reset registration policy

How to manage your password reset registration policy

Controls in this section (outlined in Fig 4. above) affect how and when users register for password reset. Read on below to see a description of what each of these controls does.

• Where do my users go to register their data? Don't have contact data defined for all of your users? No problem! We provide an end-user accessible portal where users can provide their contact data in a simple and secure way. As we make our service richer over time, we'll make sure to all of the newest challenges we build so your users stay up-to-date.
• Are users required to register for password reset when signing into the access panel? Want to register users in your organization for password reset quickly and easily? You can configure password reset to gather contact data from your users when they go to https://myapps.microsoft.com. Also, stay tuned, we'll be looking into allowing you to enforce this when users sign in, too.
• How long before users must re-confirm their contact data? Want to keep your user's contact data up-to-date over time? You can do that, as well. With this feature, you can optionally configure the time that must elapse before a user is prompted to verify their contact data again after their initial registration. If you set this time to 0 days, we will never prompt users to re-verify their data.

Fig. 5: Password reset portal customization (tenant branding not shown)

How to manage password reset portal behavior and appearance

Controls in this section (outlined in Fig 5. above) customize the appearance and behavior of the password reset portal. Read onbelow to see a description of what each of these controls does.

• When a user has a problem, what helpdesk link do they see? We provide  a capability which will automatically dispatch an email to the user, password, or global administrators of a tenant if a user sees an error  while resetting his or her password. Don't like it? No problem, you can override the link users see when resetting their passwords to point to a custom email address or website URL where you can describe to them how they can access your organization's helpdesk.
• When branding do users see when they come to the password reset portal? Using the tenant branding and customization feature that we've talked about before, you can set an organizational logo to show up on your organization's sign in page and access panel. We'll show this same logo when users come to the password reset portal. Furthermore, we'll also use your directory name in all email communications we send to your users. Finally, if you have another branding requirement, we'd love to hear about it!

Want to learn more about how password reset for users works under the covers? Check out TechNet for more detailed documentation.

 How end users can register for password reset

Once you configure the service to your liking, you can provide contact data for your directory users by using DirSync, PowerShell, or he Azure or Office Admin Portals. If you choose to provide the data yourself, aka sure you include a country code and a + in the phone number, like this"+1 4251234567", so that we know how to reach you. The detailed documentation will give you more information about how you should format your phone numbers so that they work with our system.

In the case that you want your users to do this on their own, below is what they'll see when they come to the password reset registration portal. If you want to try it out yourself, you can access the registration portal by going to this link: https://aka.ms/SSPRSetup and logging in as a test user. Just make sure that you have SSPR enabled for that tenant, first.

Fig. 6: The password reset registration portal

Fig. 7: Verifying a phone number in the password reset registration portal

Users can register both their mobile phones and personal email addresses on this web page (see Fig. 6 and Fig. 7 above). They can then use this data to reset their passwords at a later time.

 Fig. 8: Updating an existing phone number or email on the registration portal

 Once they're configured, users can come back to this page later to update their contact info without having to bother you, the admin (see Fig. 8 above).

Fig. 9: Accessing the registration portal from the application access panel

Users can also access the registration page at a later time by clicking a tile on their profile page in the application access panel (see Fig. 9 above).

How end users can reset a password

When it comes time to reset a forgotten password users can access the password reset portal by clicking the "can't access your account?" link at the bottom of any Organizational ID sign in page, or going directly to https://passwordreset.microsoftonline.com.

Fig. 10: Accessing the password reset portal from the sign in screen

 Fig. 11: Starting the password reset process for a user

Once a user clicks on the link in Fig. 10 above, he or she will then be asked to enter a UserID and pass a captcha (see Fig. 11 above). Don't worry, we check to make sure all of their data is valid and that they meet your password reset security policies before sending them through the password reset process so that calls to your helpdesk are minimized.

 Fig. 12: Performing the first verification step to reset a password

Fig. 12 illustrates what a user might see if they have self-registered a mobile phone number and an alternate email address, and have an office phone defined by their administrator. Notice that any customized branding you may have defined shows up on this
page, too.

Fig. 13: Performing the second verification step to reset a password

As users proceed through the verification steps, the contact methods they've already used are removed, and they are left with only those options that are within policy and properly configured. In Fig. 13 above, you can see that because the user already used a mobile phone as his or her first contact method in Fig. 12, he or she doesn't have that as a verification option any longer.

Fig. 14: Contacting an administrator as part of the password reset experience

And, if any problem occurs, users can get in contact with your organization's helpdesk with a single click! As described in the "how to manage password reset portal behavior and appearance" section earlier, try overriding the link below to a custom URL or email address to give your users the best possible password reset experience.

Here's are some of the highlights of this new feature:

• Supports resetting passwords for users using ADFS or other federation technologies. With writeback, as long as users are DirSync'd into your cloud tenant, they'll be able to manage their local AD passwords from the cloud.
• Supports resetting passwords for users using password hash sync. When the password reset service detects a user is enabled for password hash sync, we reset both her on-prem and cloud password simultaneously.
• Enforces your local AD and cloud AD password policies. When a user resets her password, we first ensure that it meets your local and cloud AD password policies  before committing it to any directory.
• Doesn't require any new firewall rules. Password writeback uses an Azure Service Bus relay as an underlying communication channel, meaning that you do not have to open any new ports on your firewall for this feature to work.