There have been questions on this subject posted recently to comments and also on the TechNet forums, so I just wanted to quickly write up something about use of client certificates in the MFA (secondary) slot in AD FS 2012 R2. You may recall from earlier AD FS R2 posts, that we used virtual smart card and smart card as examples. Let’s broaden that to include “soft” client certificates as an MFA/secondary provider. This functionality is provided “out-of-the box” in AD FS 2012 R2. An Active Directory Certificate Services (AD CS) infrastructure is required to serve up certificates for enabling users for PKI.
In this post, I’ll be using an Active Directory Certificate Services (AD CS) role from Windows Server 2012 R2 as the Certification Authority (CA). I won’t be explaining the CA setup, beyond the templates used, as there’s been plenty of ink expended on this topic already on the Internet. A Windows 2003/2008/2012 CA setup will suffice for the activities concerned here.
Testing was done with client certificates from a Windows 8.1 clients using:
-
a non domain-joined machine, via Certificate Enrollment (Policy) Web Services and Microsoft Management Console (MMC)
-
a domain-joined machines, via an auto-enrollment policy User-Context GPO.
In AD Certificate Services (AD CS) a duplicate of the default User certificate template was made (called User V2). Under the Application Policy, the policy is limited to Client Authentication.
For domain-joined clients, we can enable auto-enrollment via the security tab of the template. Here we see a group called GU-SEC-ADCS-Managed, which is given the necessary read, enroll and autoenroll permissions and we can add users to that security group.
To enable auto-enrollment for domain-joined clients we need to activate a policy to accomplish this. Against best practices (boo), but for expediency (mine.. yay!), I enable the policy in the Default Domain Policy GPO. The actual settings can be find under Windows Settings|Security Settings|Public Key Policies. Select the Certificate Services Client – Auto Enrollment object and enable the Configuration model section as seen below.
For the non-domain joined client, read and enroll permissions are given to a group I’ve called GU-SEC-ADCS-Workgroup. The test user, who will be a member of that group, can request the UserV2 certificate template via the Certificates|User MMC plug-in using AD CS Certificate Enrollment Web Services. Again, I won’t be describing how to setup enrollment web services. If you need help, just post in the comments section.
With Certificate Services, we need to make available the template available to both sets of clients, by enabling the template in the Certification Authority MMC plugin – Certificate Templates|New|Certificate Template to Issue.
In a correctly configured setup, domain-joined clients will obtain a certificate on the next GPO refresh cycle for the user (e.g. logon).
As mentioned previously, I’m joining non-domain joined clients via enrollment web services using the MMC snap-in in Windows 8. In the Certificates|User context of the MMC snap-in, we request a new certificate. In this particular test setup, there are three certificate templates visible for enrollment by the client from the CA:
User V2 is the template we just created for use for “soft” client certificates.The certificate services enrollment point in this example is configured for Username/Password authentication. Logon is done with a test AD user account training@azuresprout.net, who is a member of the GU-SEC-ADCS-Workgroup and authorized with the enroll permission.
Once that’s done, a client certificate is installed in the user context.
On the AD FS side of things, let’s assume we now need to apply MFA for users (with client certificates) coming from the Internet. Before we jump into the actual AD FS settings, it’s worth mentioning that any firewalls in front of the Web Application Proxy (WAP) will need to allow port 49443/TCP inbound, as this is the port the AD FS Smartcard Authentication Service listens on.
We see evidence of this requirement in the Windows Firewall snap-in. AD FS creates a firewall rule during the installation allowing 49443/TCP inbound.
In AD FS Global Authentication Policy for MFA, we enable certificate authentication:
Note that at this point, I’m not enforcing the use of MFA globally, rather enabling it for use at a lower level on a relying party rule, for more incremental control. Whether to go for global or granular policies really boils down to a question of fit and the use cases may need to support. .
On a test Windows Identity Foundation (WIF) relying party, MFA is enforced for externally connecting users.
Logging on to the relying party, we hit the primary authentication handler (AD FS forms), enter our username/password.
Connecting from the Internet, with MFA enabled, the secondary (MFA) authentication handler kicks in and we’re presented with a login popup.
In the above graphic, we have an option to login with a virtual smart card (top) and an X509 client certificate (bottom). Click on the certificate and AD FS will authenticate the user using secondary authentication (MFA).
The enrolled certificate is stored by AD CS in the userCertificate attribute of the user object within AD. This attribute contains the DER-encoded X509v3 certificates issued to the user. We can lookup the necessary certificate reference, for example, in the Attribute Editor of AD Users & Computers (ADUC).
This is a multi-valued attribute.
One thing that can be useful, should you be working with multiple certificates for a given user, is being able to cut and paste the hex encoded value into Notepad, save it, then check to see what the certificate value corresponds to using CERTUTIL.
certutil –decodehex mylo.hex mylo.cer
We can then open the .cer file to see what the certificate is.
Returning to the test claims applications (having logged in successfully0, we pass all claims processed via an issuance transform rule of c:[] => issue(claim = c);
We can see the relevant authentication method references processed during primary and secondary logon.
As I mentioned in an earlier post, the nice thing here is that you can use the Enhanced Key Usage (EKU) claim emitted for both client certificates and smart cards / virtual smartcards to moderate access to resources as you see fit.
Looking at a user authenticating with a client certificate, the following EKU is emitted as a claim.
Smart cards also emit the smart card EKU
Access can also be further graded by using custom OIDs to differentiate between levels of access based on the type of MFA being used and the EKU value.
Use of certificates in the MFA slot in R2 (I suspect) are really geared for use in a true two-factor (2FA) authentication capability, i.e. smart cards. While the use of a client certificate does offer value in offering richer access possibilities, this is not 2FA, in that it does not satisfy the mantra of “something I have and something I know”. Instead, this is more akin to 1.5FA.
To finish up, Microsoft recently added support in Windows 7 for domain-joined clients via a hotfix. I’ll attempt to throw out a quick post on this, but in the meantime, I’ll be following up by looking at conditional access policies for MFA.
As always, thanks for reading and if you have any questions, please post a comment and I’ll do my best to answer quickly.
The Access Onion 
Mylo,
Thanks once again for the clarity.
I am working on the various options available for 2 factor authentication for Office 365 and would like to confirm if my understanding is correct.
Primary Auth: ADFS 3.0
2nd Factor Authentication options:
a) Multi Factor Authentication (MFA) from Office 365 (Limit App Password for Outlook, will than wont use Kerberos auth (Local AD), even while user connect to Outlook using the Local Lan network and will verify with MFA on Office 365.)
b) Certificate Based Authentication under ADFS – Windows Server 2012 (Need to upgrade the domain functional level to minimum Windows server 2008 or higher)
c) Device Registration Service under ADFS – Windows Server 2012 (not sure if it supports all kinds of smartphones, Windows OS)
d) Available Third Party authentication
Please suggest if there are any further options.
JSK
Hi again,
The MFA vendors I know as of now that support O365 are Windows Azure, SafeNet and Duo. Just to add to your list, Outlook 2013 doesn’t currently support MFA, although this is a fix due sometime in Q2/Q3 for Office 365 native and expected for AD FS 3.0 in on-premise scenarios for 2015. Workplace Join, AFAIK, is limited to Windows 7/Windows 8/iOS… (not tested Windows Phone)
Regards,
Mylo
Can we have Cert based authentication (soft cert) for devices that dont support Workplace Join example: Android device till version Kitkat & all supported workplace join devices to use Workplace Join feature as additional factor of authentication?
If yes, IS PKI server a mandate or internal CA server would do for an environment of 5000 users?
Hi JSK,
Yes you can, but the certificate is used as an MFA credential (on Android) and you’ll have to do your own OTA to get the certificate on the mobile device, i.e. no Workplace Join. I’m writing a post about MFA policies right now and it should be on the blog within a week.
From personal preference, I would always look at an internal PKI and use a two-tier CA hierachy for that number of users, although some sort of Managed PKI may also be up to the task.
Is Cert based auth (CBA) not available for Office 365?
Is it not supported by Microsoft for Office 365?
My recent discussion with few Microsoft folks, suggested that Cert based auth (CBA) not supported for Office 365. Because Outlook , Lync & Mobile uses Basic Auth & thus CBA wont work for them.
In your blog, u have pointed out Cert based as 2FA or MFA, so technically it should support user who are getting authenticated for Office 365?
please correct me?
Hi Mylo, great article, I’ve played with this config before but come up against use acceptance on the 2FA ‘popup’ when it asks which cert to use. We have our auto enrolled cert and a self signed one from Lync in the list for all standard users.
Do you know of a way to get ADFS to automatically select the domain issued cert? Either in ADFS3 or 2, hopefully natively, or do we need to resort to .NET coding 🙂 ?
Thanks,
Tim
Great article! We are using AirWatch to manage mobile devices. If we generate the user certificate internally, and apply the certificate to the mobile device, will that be fine?
Do I need to export the private key as well?
Hi Michael,
Thanks! You can use the certificate for MFA for user authentication, not for the device tho (a la Workplace join)
Regards,
Mylo
Hi Mylo, thanks a lot for the great article!
I have 2 questions:
– Is this a requirement not to use the default user certificate template?
– Does the CRL DP has to be reachable by the WAP servers (Using my internal CA to issue user certificates, this is an internal LDAP URL by default)
I suspect one of those to be the culprit because when trying to authenticate with my user certificate, I have the following error in the ADFS Tracing log on my WAP server:
Source: AD FS Tracing
Event ID: 52
Exception: There is a problem with the X509Certificate provided by the client. The certificate with thumbprint “E27B1815442E146051AE0E47A53EB65A69D55423” returned error code -2146885613
StackTrace: at Microsoft.IdentityServer.ProxyService.TlsClientRequestHandler.ProcessClientRequest(WrappedHttpListenerContext context)
at Microsoft.IdentityServer.ProxyService.ProxyHttpListener.OnGetContext(WrappedHttpListenerContext context)
Thanks,
Thomas
Hi Thomas,
I’ve not tried with the User certificate template, but whatever the cert you use it’ll need the client authentication OID .. On the CRL DP question, yes the CRL DP being an internal LDAP URL will be a problem as remote clients won’t be able to reach it.. I generally opt for HTTP CDP endpoints for that reason.
Regards,
Mylo
Hi There Mylo! Hope you’re ok.
I’m having the same error that Thomas has described: “There is a problem with the X509Certificate provided by the client”.
And I think my scenario is the same as his:
1. I have a test domain, where a I installed the AD FS, with no AD FS proxy at all. Certificates issued by this domain works fine when used to authenticate the domain’s users, and sign on to the AD FS auth page is done successfully;
2. I have a second test domain, where I use to issue client certificates, to simulate a third party certificate provider. With these certificates the error I mentioned is launched. Even after importing the second test domain Root CA and it’s CRL to the AD FS domain
Do you have a clue why is that happening? Is it maybe because the CRL DP can’t be reached by the AD FS (the two domains are isolated)?
Best Regards,
Diego Zanette.
Hi there Thomas,
I would appreciate if you could check the reply I just posted to Mylo out. I’m looking for help in this subject.
Hi There Mylo! Hope you’re ok.
I’m having the same error that Thomas has described: “There is a problem with the X509Certificate provided by the client”.
And I think my scenario is the same as his:
1. I have a test domain, where a I installed the AD FS, with no AD FS proxy at all. Certificates issued by this domain works fine when used to authenticate the domain’s users, and sign on to the AD FS auth page is done successfully;
2. I have a second test domain, where I use to issue client certificates, to simulate a third party certificate provider. With these certificates the error I mentioned is launched. Even after importing the second test domain Root CA and it’s CRL to the AD FS domain
Do you have a clue why is that happening? Is it maybe because the CRL DP can’t be reached by the AD FS (the two domains are isolated)?
Best Regards,
Diego Zanette.
Hi Diego,
The CDP should be reachable from both environments. Post back if you have any further questions.
Regards,
Mylo
I have everything setup, with the Internal CA’s root certificate trusted in the trusted root cert and NTAuth containers. But clients are not prompted to select a certificate. After they enter their credentials ADFS just sits there without any errors in the events logs. This is for internal clients only, no WAP involved yet. Any ideas where I should look?
Hi Eli,
Not sure what version of AD FS you’re running, but is Port 49443 also open on the firewall for certificate authentication?