Just a quick post describing how to request an AD FS SSL (service communications) certificate from within Windows Server Core. The OS being used is Windows Server 2016, but, unless otherwise stated, this also applies to Windows Server 2012 R2.

For the enrollment and submission of the request, as well as parsing of the response, we’ll look at two mechanisms:

This is the legacy tool uses for certificate enrollment since Windows 2000. While a little cumbersome, it’s provide to be very useful over the years. It’s a command-line utility that parameterizes the request, submission and processing of the request file and certificate response to the Certificate Authority (CA). As a rule-of-thumb, it’s used where traditional enrollment mechanisms: web enrollment or MMC are not available or valid.

To begin a configuration (TXT) file needs to be created. This serves as an input file for completing information concerning the request. We’ll call it ADFSDEMO.TXT.

A template called WebServerV2 has been created (this is a copy of the WebServer built-in template, with compatibility level set to Windows Server 2003 and with certificate duration to 2 years). From CERTREQ.TXT, we generate a REQ (Request) file for submission to the local issuing authority

This is done with the following command:

CERTREQ –new ADFSDEMO.TXT ADFSDEMO.REQ

A response from the local policy filter

Active Directory Enrollment Policy

{521CC4EE-C923-4AE3-9123-A12F655CE123}

ldap:

CertReq: Request Created

And it’s now possible to submit the request file to the CA

CERTREQ –submit ADFSDEMO.REQ

The authority requests confirmation via a popup-window

Click on OK and the CA requests a location to save the generated certificate on the local disk of the server. For consistency, we call it ADFSDEMO.CER.

To complete the installation of the certificate the following command is run:

certreq –accept ADFSDEMO.CER

PowerShell

This section is the picture of conciseness as PowerShell simplifies the enrolment process for us. Here’s the request, submission and installation of the certificate, succinctly rolled-up into one command.

Note that on the AD FS server, it’s possible to drop into Powershell to have a look at the issued certificate

dir cert:\localmachine\my

Assuming the server has already been domain-joined, has had the AD FS feature installed (Add-WindowsFeature ADFS-Federation) and a service account created in AD, then the configuration wizard of the AD FS farm can begin. Here’s an example of a WID-based deployment for the first farm node, utilizing the thumbprint of the SSL cert. The credentials for the service account are collected via the variable $cred, before being called in the Install-ADFSFarm cmdlet.

Before I finish the second article on Step-Up Authentication, I thought I’d write something quick about Virtual Smart Cards (VSC), as they also feature in the next post.

While Windows 8 has been taking lots of flak for various UI changes, there are a number of nice new features that have snuck in rather quietly. One of these is support for Virtual Smart Cards (VSC). VSC’s provide an alternate strong authentication mechanism that removes the need for a physical smart card reader. They emulate the use of a physical card reader via the use of the Trusted Platform Module (TPM) found in most modern business-grade computers. The TPM module stores the private key of the virtual smart card. While, it’s not two-factor authentication per se, (the virtual smart card is stored on the same device as the crypto module), it is nonetheless an improvement strength-wise over username/password and software-based digital certificates. We’ll give it the official 1.5x times authentication moniker (1.5FA) .

Private keys are stored in the crypto functionality of the Trusted Platform Module (TPM) of the laptop. The private key is device centric, with the virtual smartcard stored on the same computer. The TPM module needs to be enable on the computer. This can be done manually (woo-hoo!) or via some form of script, or in conjunction with vendor client instrumentation software.

VSCs provide a number of nice features, but they add a little more added complexity in the setup stakes. Given that we’re emulating physical smart card behaviour, we’re going to need a certificate and that means Certificate Services and an enterprise Public Key Infrastructure (PKI).

I’ve used a Windows 2008 R2 CA in this example. On the enterprise certification authority (CA) we can duplicate the built-in Smartcard Logon template found in certificate services using the V2 Windows Server 2003 compatible template.

With our new template, entitled Virtual Smart Card, on the Request Handling tab set the certificate purpose to Signature and Smart Card Logon and the minimum key size to 2048. On the Cryptography tab set the cryptographic provider to the Microsoft Base Smart Card Crypto Provider.

Give (authenticated) users Enrol permissions on the Security tab of the template and then issue the new certificate template.

We can use the built-in tool TPM Virtual Smart Card Manager (tpmvscmgr) to provision the smart card.

tpmvscmgr.exe create /name Auth360Test /adminkey random /generate

The generate command formats the TPM virtual smart card so it can be then used to enrol for certificates.

From a LAN or DirectAccess connected PC we can enrol via use the MMC Certificate Users snap-in, using the Request New Certificate option

Select the Virtual Smart Card template.

During enrolment a PIN needs to be set.

With the VSC enrolled. we can now logout and the virtual smart card should be available for logon.

Click on our enrolled user and then logon with our PIN.

I thought I’d give this a whirl with AD FS. For the purposes of this exercise, to support VSC smart logon, I changed my AD FS proxy configuration to support client certificate authentication, modifying the local authentication types parameter in the web.config on the AD FS proxy. We’ll cover other logon scenarios using VSCs in the next Step-Up authentication post.

Meanwhile, TLSClient (SSL Client Certificate) is elevated to the top of the list and switched with the default Forms authentication.

Users accessing the AD FS proxy with a VSC now get a prompt to select their certificate

Having highlighted and click my user, I now enter the PIN.

Users not possessing a smart card user certificate will get a 403 error.

The problem with this approach is that it’s a little generic. We’ve simply configured AD FS to authenticate users based on the presence of an X509 certificate.

We could always add our VSC users to a security group and reflect this in an authorization claim in AD FS, Even better we could configure authentication mechanism assurance and add an issuance policy to our virtual smart card template and then link that policy to a security group. Microsoft provide a couple of Powershell scripts to allow this, The Object Identifier (OID) of the certificate authenticating at AD FS needs to correspond to the linked claims rule to the OID in our “Virtual Smart Card Authentication” security group. We’ll look at this in a future post about Bring Your Own Device (BYOD), Workplace Join and Work Folders, new features in Windows 8.1.

AD FS 2.0 Rollup 3 provides support for the sharing of signing certificates between multiple relying parties. Prior to RU3, each relying party trust, should they elect to use one, required a unique signing certificate and attempts to share signing certificates between RPs would generate the following error:

MSIS7613: The signing certificate of the relying party trust is not unique across all relying party trusts in AD FS 2.0 configuration

So, following the release of RU3, I was fully expectant to see this fix working. Following various tests and assistance from PSS, it turns out this is an optional “tweak”, rather than one that is activated automatically through deployment of the rollup, i.e. a script needs to be run to activate this capability. Following the installation of RU3, in the C:\Program Files\Active Directory Federation Services 2.0\SQL folder is a PostReleaseSchemaChanges.ps1 PowerShell script. This needs to be run on the primary AD FS server from an elevated Powershell prompt. Once this is done, you should find that you can now configure RP trusts with the same signing certificate.

To test this I used two SimpleSAMLphp (SSP) service providers (App1 and App2) with online metadata endpoints.

Both Relying Parties (RP) are using the same X509 certificate key pair as defined in the authsources.php file. Creation of the two relying parties was then possible and exchange of metadata possible without AD FS throwing an error.

The above error surfaced recently when logging in at an O365 tenant. While the message itself is a fairly generic one, and can be attributed to a number of possible causes, in this case the organization (using identity federation) had an expired token signing certificate in their AD FS 2.0 configuration. They had automatic certificate rollover disabled on their AD FS farm so that AD FS could not rollover the configuration with new certificates. For some organizations, with web applications such as Sharepoint 2010, this may be a desirable configuration, with the process of certificate rollover being manually administered, rather than AD FS silently and automatically handling it.

Hindsight is a wonderful thing in this case and paying heed to warning messages about expiring certificates in the event logs in the preceding weeks may well avert some nasty surprises. However, calamities happen and should this problem evade your radar in the future, looking at what recovery options are available may be useful.

When the token signing certificate is due to expire (2-3 weeks before), the AD FS 2.0 Admin Event Log will begin to blurt out warning messages (Event ID:385).

AD FS 2.0 detected that one or more certificates in AD FS configuration database need to be updated manually because they are expired, or will expire soon. See additional details for more information

Additional Details: Token-signing certificate with thumbprint ‘4E8F5194309E48EDB7EF8440B47082FB3D1594B6’ is set to expire on 12/30/2011 1:00:00 AM.

Should the warnings be ignored, and the certificate has expired, the Event ID 385 warning changes to:

At this point the AD FS wheels are wobbling and an Event ID 381 may start popping up:

An error occurred during an attempt to build the certificate chain for configuration certificate identified by thumbprint ‘4E8F5194309E48EDB7EF8440B47082FB3D1594B6’. Possible causes are that the certificate has been revoked or certificate is not within its validity period. The following errors occurred while building the certificate chain: MSIS2013: A required certificate is not within its validity period when verifying against the current system clock.

User Action: Ensure that the certificate is valid and has not been revoked or expired.

This may be followed closely behind by Event ID 102:

There was an error in enabling endpoints of Federation Service. Fix configuration errors using PowerShell cmdlets and restart the Federation Service.

As the original title graphic intimated, federated logon at this point is not working.

Depending on your AD FS configuration you may have automatic certificate rollover enabled. This can be checked via Get-ADFSProperties

In this particular case it was set to:

This meant that that once the signing token certificate expired, a replacement was not automatically assigned. In this case a new certificate needs to be provisioned manually. Of course, you could also elect to activate the autocertificaterollover function.

Preparing to make the change

Whether you elect to go the manual or the automatic route, in either case, you’ll still have some investigation to do. Before nuking your AD FS configuration, consider the impact of assigning / replacing the token signing/decryption certificates in AD FS.

Who are the claims providers and relying parties involved?

Can they process metadata?

What application specific changes are required to support the certificate change?

Of course, if you’re facing a production federation service outage then there’s likely to be other pressures to consider as well , but try and determine which relying parties or claims providers will be able to process the details of the change (automatically) via updated federation metadata exchange or not. In the case of the latter, some sort of manual intervention may be required. Applications, for example, such as Office 365 and Sharepoint 2010 will need to be informed of this change.

Option 1: Manual Rollover

Via this method, you can generate your own certs using the Self-SSL feature built into IIS 7.x, or use Keytool, OpenSSL etc.. Alternatively, you may have your own internal PKI. I don’t see any benefit in using a third-party certificate for token signing encryption/decryption. No doubt someone out there may have a valid reason for doing so, but self-signed certs / internal PKI serve the purpose in this scenario. With IIS, under Service Certificates, I opted to create a self-signed certificate

Give the certificate a recognizable “friendly” name and IIS creates the certificate.

If you’ve elected to use an internal PKI, then there may be a certificate chain involved. Claims providers or relying parties will require a copy of the corresponding chain (.P7B) file or individual CA (.cer) files. The AD FS service account needs to be able to manage the private key of the certificate. This can be accomplished through the MMC Certificates|Computer snap-in. Right-click over the certificate:

Select Manage Private Keys and give the AD FS service account Full Control to the certificate. Now you need to prepare to make the change.

Option 2: Automatic Rollover

To configure automatic rollover:

Set-ADFSProperties -AutoCertificateRollover $true

To trigger an automatic replacement of the existing certificates the following needs to be entered.

Update-AdfsCertificate –Urgent

BEWARE! By selecting the urgent option you are voluntarily hitting the self-destruct button and hosing any working configuration. Relying parties and claims providers will not have refreshed their federation metadata with you and at this stage will be working against stale metadata. It is best, therefore, to carry out these activities out out-of-hours and co-ordinate with the parties concerned refreshing of metadata. As I discuss later in this post, some parties need manual intervention.

With the automatic rollover option selected, any existing token signing / decrypting certificates will be deprecated and replaced with a fresh one years’ validity alternate.

Exporting certificates to file

Once you’ve added a new token-signing certificate (manual route) or run the Powershell script to set automatic rollover you’ll need to export the certificate to file. Double click on the AD FS Token Signing certificate, click on the Details tab and then select Copy to File. The export format varies according to the target system. Windows systems will generally accept DER and Base64. If it’s a Java web container / application server then use Base64. Ditto with Linux/Unix…

In the examples below, I’ve used Office 365 and Sharepoint 2010 as two examples of web applications that need manual intervention.

Office 365 – MSOL

To rectify the problem of a token signing certificate change in Office 365, we need to update Online Services with new information concerning our certificate. As covered in the post here: https://blog.auth360.net/2011/10/15/ad-fs-2-0-rollup-i-multiple-issuer-support/ AD FS 2.0 now supports multiple UPN suffixes, so you’ll need to run this per UPN domain to update the respective information in Powershell.

Substitute your own UPN suffixes with the examples above and the effect should be instantaneous and logon to MSOL possible once the update has been carried out. Run this through your test environment first to make sure you get the desired effect.

An operation failed because the following certificate has validation errors:\n\nSubject Name: CN=ADFS Signing – sts.mydomain.com\nIssuer Name: CN=ADFS Signing – sts.mydomain.com\nThumbprint: 611CBD4AE55FE2F2C3F0648C16C57A231AA51491\n\nErrors:\n\n The root of the certificate chain is not a trusted root authority..

In the above example, I triggered automatic certificate rollover on the AD FS side without notifying Sharepoint of the change and this threw an error (screenshot). To rectify this we’ll need to export the token signing certificate from AD FS instance and import it into Sharepoint 2010. We’ll then assign the register and assign the replacement certificate. This occurs at two levels:

Registering the certificate as a root authority. The certificate is self-signed and Sharepoint stores its own certificate trust hierarchy, outside of normal Windows conventions. This means that the self-signed certificate, effectively a root certificate, needs to be assigned as a Trusted Root Authority.

Updating the existing trusted token issuer. This means replacing the existing trusted identity token issuer value for the signing certificate with the new one.

Socket Pooling in IIS, useful for improving SSL performance, can also be a pain if you’re trying to run multiple SSL-enabled web applications on the same server. I continue to run into this with IIS and Apache Web Server/ Tomcat. To specify which IP Addresses HTTP.SYS (IIS) should explicitly listen on can be manipulated through NETSH.

netsh
http
show iplisten

This should return blank if you have socket pooling enabled. To add a listener on a given IP use the add iplisten command

add iplisten ipaddress=x.x.x.x

where x.x.x.x is the IPv4 address of your choice. IPv6 is also supported.

There’s an article on MSDN that highlights this and other commands for manipulating http.sys.