How to Set up Azure AD Certificate-Based Authentication for Office Apps on Mobile Devices (iOS and Android) – PART 3


Part 3 - Set up ADFS

Active Directory Federation Services is a key requirement in making this solution work. You'll need to configure some claims (serial Number and Issuer) so that they are issued to users and eventually presented to Azure AD. You also need to make the "Sign in using an X.509 certificate" option available at your ADFS logon page. By this stage, you should have an externally reachable CRL and Setup Azure AD for cert-based auth. Make sure you have done that - See Part1 and Part2 of this series.

  1. On your ADFS Server, Go to Claims Provider Trusts, Select Active Directory and Edit Claims Rules.
  2. Click Add Rule, Pass through or Filter an incoming Claim
  3. Give the rule a Name like "Certificate Serial Number" and select Serial Number from the drop down and Finish

  4. Click Add Rule, Give it a name like "Issuer" and select Issue from the drop down menu.

  5. Now Go to Relying Party Trust, Microsoft Office 365 Identity Platform, right click and select edit claims rules
  6. On the Issuance Transform Rules tab, select Add Rule
  7. Choose Pass Through or Filter an Incoming Claim and add both the Serial and Issuer claim as was done for Active Directory in the last step.

  8. Now to add the Certificate sign-in option, go to Authentication Policies and Edit the primary authentication options.
  9. Enable Certificate Authentication (I'm enabling it for internal and External access so I can test this easily on my internal clients first)

  10. Test by going to portal.office.com, enter a username.domain.com and you are redirected to your ADFS Sign-in page. Notice that there is now a certificate option to sign-in. (Good idea to test internally and from the internet)

TIP: The default Text says ( "Sign in using an X.509 certificate") which isn't that user friendly. You can customise it by running some powershell on the ADFS server:

Set-AdfsAuthenticationProviderWebContent -Name CertificateAuthentication -DisplayName "Sign in with a certificate"

(Ignore my customised Sign-in message in the above screenshot – it's a left over from another configuration)

11. Make sure that the RootCA certificate exists in the Trusted Root Certification Authorities store on both your ADFS Server and WAP server. If it isn't, copy it over and import it into the machine store. Double-check that you can access the CRL from both servers (Certutil -verify -urlfetch).


12. Also, The certificate requests are going to come from the external devices and hit your WAP server on port 49443, If you have some sort of load balancer or external firewall in-front of WAP, make sure its configured to allow this port. The internal requests will hit your ADFS server, so make sure that's allowed too. A good way to check this is by running PowerShell:

Test-NetConnection -ComputerName WAPserver -Port 49443


13. That's the ADFS bit complete. Now you just need to get a certificate onto some devices to test it out. Head over to Part 4.


Comments (4)

  1. pirate8216 says:

    great write up. one small correction, WAP server port from clients to WAP is actually 49443.

    1. Thanks for the pickup pirate8216. I’ve updated the port number.

  2. K-Rokk21 says:

    HI Scott, great stuff so far. I have a few corrections around permissions in your part one. Also, did you do this with 2008r2 or 2012? It seems that some of the screens have a couple of extra options.
    Should the certutil contain a certificate name in order to verify the CRL?

    Thanks, Ken

    1. Thanks! Screenshots are from Server 2012. Yes you need to specify the certificate path at the end of the Certutil command. eg: Certutil -verify -urlfetch c:\temp\mycert.cer . I added a screenshot for clarity.

Skip to main content