Hey there, this is Ramiro Calderon from the Azure AD Customer Success Team. Remember us? We took a brief hiatus (sorry about that) but now we are back! I wanted to write up some answers to common AD FS questions we get in the context of hybrid identity with Azure AD. Let’s get into it.
I have multiple root domains in my on-premises environment and child domains on each of them (contoso.com, sales.contoso.com, fabrikam.com and procurement.fabrikam.com). How do I set the AD FS issuance rules for Azure AD?
You can do this in three steps:
1. Register Root Domains First (contoso.com and fabrikam.com), so you share the federation configuration with all subdomains
2. If you have multiple root domains, you must use the –SupportsMultipleDomains when configuring the rules. This will create the base ADFS rules that generate the issuer claim
3. We are not done quite yet. Now, we have to make sure the child domains get the issuer consistent with the configuration above. All child domains on *.contoso.com should have the issuer of http://contoso.com/adfs/services/trust and all child domains on *.fabrikam.com have to have the issuer of http://fabrikam.com/adfs/services/trust. Replace the default rule generated for the issuer claim and replace it with custom rules (one for each root domain, as shown below).
I want to have a clean username for my users to sign in to Azure. What options do I have?
This is a very common request for the following cases:
1. Users are not familiar with the UPN on premises, and confuse it with their email address. So, you want the users to use their email address
2. UserNames are arcane (example: internal employee ID), and the cloud offers an opportunity to clean up to a simpler login (e.g. email@example.com)
3. Domains on premises have naming conventions you don’t want to carry through the cloud (for example, old merger and acquisition, geography, or other attributes such as external/contractors, etc.).
See the flowchart below to navigate some different options to achieve this:
What is the difference between Service Communication and SSL certificate? I noticed my service communication expired and things continue to work.
The short answer: AD FS service communication certificate is used in a very specific subset of WS-Trust scenarios, which are not enabled by default and not used for Azure AD scenarios. Chances are you don’t need any of those and that’s why you did not noticed
Now, The long answer :
ADFS (in general, WCF) supports three security modes: Transport, Message, and Mixed. The Service Communications (known also internally in WCF lingo as the “Service Identity”) is used in Message Security. Basically, the soap message is encrypted using key material derived from the certificate of the service (as in service communications). When using message security, ADFS generates and encrypts a symmetric key that can be only be decrypted by the owner of the private key of the service itself. This is why these endpoints can go over http (no SSL), since the payload itself is encrypted without depending on the channel.
Conceptually, this is similar to what TLS provides in the actual HTTP channel, and this is why we set both SSL and Service Communication to be the same during the initial configuration.
How do I turn debug logs for AD FS?
If you want to debug something (for example, the flow of claims as the rules execute through different stages), that requires you to turn on detailed traces, run the following commands:
Then, to see the traces in the event log, do the following
1. Enable “Show Analytic and debug logs”:
2. Then, Navigate to “AD FS Tracing/Debug” to get your debug logs
When you are done with your debugging or investigation, turn the log off:
Can I use a third party proxy, or Azure AD Application Proxy instead of WAP for AD FS endpoints?
ADFS 2012 R2 requires the proxies to implement the protocol MS-ADFSPIP. Traditional endpoint proxies will not work out of the box.
What tools can I use to figure out if I have enough AD FS servers to handle my traffic?
In general terms, AD FS is driven by CPU, so that would be the main metric to keep an eye on. Azure AD Connect Health provides a great view of the load profile of the AD FS servers.
If you are planning a net new deployment or you want to verify your planned capacity, check out our update AD FS capacity planning spreadsheet.
Where can I find a list with the available updates for AD FS?
We hope you’ve found this post and this series to be helpful. For any questions you can reach us at
AskAzureADBlog@microsoft.com, the Microsoft Forums and on Twitter @AzureAD, @MarkMorow and @Alex_A_Simons
-Ramiro Calderon and Mark Morowczynski