First published on TechNet on Jan 26, 2015
The last blog was about planning for ADFS and what questions you should be asking when deploying it.
I said that the next blog would be about what conversations and questions you should have with the application owners. After some thought, I’ve changed my mind and decided to write about certificate planning. During almost every ADFS deployment I’ve been a part of, most of the conversations and planning revolve around certificates so I figured we should take some time to talk about this. ADFS relies heavily on public/private key certificate so if you’re not already familiar certificates, deploying ADFS will quickly get you re-acquainted. Like I’ve mentioned before, ADFS is a service that will need to grow with your organization’s needs and so proper planning is also required for certificates to ensure they will meet your growing needs and requirements.
The funny thing about certificates is that almost anything goes. For example, installing ADFS is really black and white – you either install it or you don’t. With certificates, there are so many options for deploying them that many customers forget the basics about public/private certificate signing and encryption. Like most things, certificates are mostly 90% planning and 10% execution.
In 95% of ADFS deployments, it will require three certificates to be properly installed:
- SSL certificate
- Token Signing Certificate
- Token “Decryption” Certificate
There may be times where you want to install a fourth certificate, separate from the SSL certificate, although in most cases these certificates are one in the same:
- Service-Communications Certificate
You can use the same certificate for all three of these purposes, use separate certificates for each purpose, the choice is really yours. You can acquire them from an internal CA, a public CA, or use the self-signed ones. Remember I said that all these options befuddle many customers.
Misconceptions
Before we dive into more details about each of these certificates and requirements, let’s first clear up some misconceptions about how these certificates work. To properly do this, we’ll have to take a step back and refresh our memory on how public/private certificates work.
Digital Signatures
When we want to digitally sign tokens, we will always use the private portion of our token signing certificate. When a partner or application wants to validate the signature, they will have to use the public portion of our signing certificate to do so. This doesn’t protect the data from someone viewing it but does ensure that if the data gets modified somehow, the signature verification will fail. What this means is that each ADFS server will only have one digital signature certificate. Digital signatures are required for ADFS.
Key Takeaway: The token signing certificate is considered the bedrock of security in regards to ADFS. If someone were to get ahold of this certificate, they could easily impersonate your ADFS server.
Mega Takeaway: What this also means is that every SaaS application must have a copy of the public portion of your ADFS token signing certificate.
Digital Encryption
When we want to encrypt something, we will always use the public portion of our partner’s encryption certificate. When that partner needs to decrypt the data, they will have to use the private portion of their encryption certificate to do so.
Consequently, just because you see the token decryption certificate in the ADFS console under the certificates container, doesn’t mean encryption of tokens is actually being performed. There is A LOT of confusion because of how the ADFS management console displays the self-signed certificates. It says Token-decrypting above the certificate but the CN on the certificate says ADFS Encryption .
If you want to verify whether token encryption is enabled for a specific relying party application, you will have to go and look at the encryption tab on that specific relying party application. As you can see here, I don’t have an encryption certificate installed for this relying party application, so encryption will not be used.
Digital Decryption
I know what you’re thinking – We just covered digital encryption so why are we covering it in the reverse – decryption. Because in this scenario, rather than our ADFS server sending tokens to a SaaS application, we’re receiving tokens from a partner Identity Provider (IDP). I know this one seems obvious but many customers get hung up on this. When a partner wants to send us something encrypted, they will use the public portion of our “decryption” certificate. To decrypt it, we will use the private portion of our “decryption” certificate to do so. Since we are the only person that has the private key, no one else can decrypt the data.
Mega Takeaway: The easiest way to remember which certificate is being used is by asking yourself the two following questions
- What direction is the token flowing? Are we on the receiving end or sending end?
- Is the token be digitally signed or encrypted?
If you’re sending a partner applications a token, ADFS will use the private key of your token signing certificate and optionally the public key of your partner’s token encryption certificate. If you’re receiving tokens from a third party identity provider because you are a SaaS provider, they’ll be sending you tokens signed with their token signing certificate private key and they’ll encrypt the token with the public portion of your token encryption certificate.
Now, with all that being said, who can explain the signature tab on each relying party application? Rarely does this ever get used but if I’m going to explain certificates, I might as well cover this one too:
If you remember from my blog back in November 2014, I compared sign-in protocols:
In this blog, I showed you what a SAML Protocol Sign-In request looked like. Well, the above signature tab is if the SaaS application provider also wants to digitally sign the SAML Sign-In request when the request is sent over to our ADFS server.
Why would you/they want to do this? Well, for the same reasons we digitally sign anything – To ensure the SAML request doesn’t get modified somehow. There typically isn’t anything really important in the SAML request but there are times when the SaaS application owner or you may want to enforce a certain authentication type by hardcoding it into the SAML request. If they also digitally sign the SAML request, they can ensure no one modifies the request and bypasses what they’re trying to enforce.
BTW, it’s also possible to encrypt the SAML request but I don’t think I’m personally ever seen this done. In most cases when the SAML request is obfuscated, it’s just Base-64 encoded.
Drawing out the Requirements
Now that we’ve covered the basics of digital signatures and encryption, let’s cover the questions you should be asking about the certificates required for ADFS. Once you answer these questions, they myriad options for certificates that I mentioned above will become clear.
1.) Will external customers, partners, or non-domain-joined devices being using your ADFS service in some capacity?
Why is this important: This question leads to whether you should use publically issued SSL (think Verisign) certificates or not. Since you may not be able to anticipate how ADFS will be used in the future, I would just recommend publically issued SSL certificates every time.
2.) Will external customers, partners or your users need to access ADFS from outside the corporate network?
Why is this important: This leads to two important requirements:
- whether you’ll need an ADFS Proxy/WAP server and corresponding SSL certificates.
- whether you should pick a Common Name (CN) or Subject Alternative Name (SAN) on the certificate(s) that has a publically available DNS namespace.
For example, if you plan for users to access ADFS from outside the corpnet network, you definitely wouldn’t want to pick adfs.root.local as the name on the SSL certificate since this name is not a publically routable DNS name. If you plan to publish an ADFS Proxy/WAP server to the internet, make sure that the name of the certificate is a publically routable DNS namespace.
3.) Will you be using Outlook or other thick client applications with O365 for Exchange Online?
Why is this important: If you remember from my first blog on ADFS back in August 2014, when thick clients like Outlook authenticate to O365, O365 will contact your ADFS Proxy/WAP to acquire a SAML token on behalf of the user. Consequently, if you plan to use Outlook with O365, the SSL certificate on your ADFS Proxy/WAP must be publically trusted. If the SSL certificate on the ADFS Proxy/WAP is not publically trusted, O365 will not be able to obtain a SAML token for users to access Exchange Online (EXO).
4.) If you must use an internal PKI infrastructure for the certificates, make sure your CA has the right certificate templates and other requirements in place.
Why is this important: If for some reason you must use internally-issued certificates from your own PKI infrastructure, the SSL certificate used by ADFS must have the Server Authentication Enhanced Key Usage (EKU). The token signing and token decryption certs can have any EKU. Make sure you have the right certificates templates published and you have rights to request said certificate templates.
5.) If you plan to use the self-signed certificate that ADFS generates for token signing and token decryption, are you a domain admin?
Why is this important: When you use the self-signed certificates for token signing and decryption, the private keys are stored in Active Directory in the following container:
CN=ADFS,CN=Microsoft,CN=Program Data,DC=domain,DC=com
Consequently, for the ADFS installation to install the private keys into this location, you must be a domain admin to install ADFS or have the appropriate rights assigned to this container.
6.) Do you have a policy about using Next Generation (NGen) certificates?
Why is this important: No version of ADFS supports Next Generation (NG) certificates. I was onsite with a customer helping them install and configure ADFS and couldn’t figure out why their SSL certificate wouldn’t work; they didn’t tell me they requested Next Generation certificates. Doh.
7.) Will you be using the device registration feature in ADFS 2012 R2? If so, how many UPN’s suffixes do you have in your Active Directory forest?
Why is this important: Clients will enroll in device registration and/or workplace join by typing in their UPN into the workplace join wizard on their device. If you have multiple UPN’s in your enterprise, all those UPN’s must resolve to the ADFS Proxy/WAP servers. To achieve this, you will typically want to ensure the SAN on the SSL certificate on the ADFS Proxy/WAP server(s) contains all enterprise-wide UPN’s. For example, let’s say you have both contoso.com and fabrikam.com UPN’s in your enterprise. You’d want to ensure that both enterpriseregistration.contoso.com and enterpriseregisteration.fabrikam.com are in the SAN of the SSL certificate installed on the ADFS Proxy/WAP servers(s). Another option is to go with a wildcard SSL certificate.
8.) What name have you decided for the ADFS service? Example – sts.domain.com or sso.domain.com? Have you ensured that the name isn’t already in use internally and publically?
Why is this important: If you must use a publically available DNS namespace for the SSL certificate name, ensure the name is not already in use somewhere else in the enterprise. Perform a DNS lookup internally and externally for the name you want to use before you purchase any certificates. While you’re at it, run a quick check to ensure the SPN isn’t already in use in the enterprise:
Get-ADObject -filter 'ServicePrincipalName -eq "Host/sts.domain.com"'
If the name isn’t already in use, unless your enterprise has specific naming conventions or policies, the name you pick for the SSL certificate is mostly arbitrary.
9.) Do you have any policy about using the same SSL certificates on the ADFS servers as you do the public-facing ADFS proxy/WAP servers?
Why is this important: While you can use the same SSL certificate across the ADFS servers and ADFS Proxy/WAP servers, some companies may have a security policy about using the same SSL certificate on the publically facing ADFS Proxy/WAP servers as the internal ADFS servers. While the internal ADFS servers have to use the same SSL certificate, the ADFS Proxy/WAP servers can use separate certificates as long as the Common Name (CN) or Subject Alternative Name (SAN) on the SSL certificate contains the same ADFS service name.
10.) Do you have any policy that dictates the use of wildcard SSL certificates?
Why is this important: While wild card SSL certificates are supported by all versions of ADFS, make sure that it complies with your corporate policy. I don’t typically recommend the use of wildcards certificate on the ADFS Proxy/WAP servers. If you have many UPN’s within the enterprise and plan to do device registration/workplace join, you may want to consider a wildcard certificate.
11.) Are you required to use a physical, virtual, or networked HSM for storing the certificates?
Why is this important: HSM devices are supported with ADFS but may cause performance issues since the private keys are stored on these other devices so make sure to test ADFS performance before going live.
12.) Do your monitoring devices support Server Name Indication (SNI)?
Why is this important: If you monitoring devices don’t support SNI and you’re using ADFS 2012 R2, then you will need to install August 2014 Windows Update rollup, so that you won’t need to modify the Subject Alternative Name (SAN) of all the ADFS certificates to ensure your HTTP probes work properly:
13.) If you are onboarding SaaS applications to your ADFS infrastructure, will the SaaS application want the SAML token encrypted and if so, do you know whether their encryption certificate is publically trusted?
Why is this important: If token encryption needs to be enabled, make sure to get a copy of your SaaS partners public encryption certificate. Additionally, you’ll want to verify whether this is a publically trusted certificate because ADFS, by default, tries to check the validity of all encryption certificates. You can reconfigure ADFS to change this behavior by changing the EncryptionCertificateRevocationCheck property using the Set-ADFSRelyingPartyTrust PowerShell cmdlet.
14.) If a partner Identity Provider (IDP) will be sending you SAML tokens, do you know whether their token signing certificate is publically issued?
Why is this important: Similar to the question above, by default, ADFS will check the validity of a partner’s token signing certificate. You can reconfigure ADFS to change this behavior by changing the SigningCertificateRevocationCheck property using the Set-ADFSClaimsProviderTrust PowerShell cmdlet.
15.) Do all your ADFS servers and ADFS Proxy/WAP servers have outbound TCP 80 open to the internet to perform certificate revocation checking?
Why is this important: To perform certificate revocation checking, all ADFS and ADFS Proxy/WAP servers must have TCP 80 outbound access.
ADFS Server SSL Certificate Guidelines
All of the back-end ADFS servers must use the same SSL certificate. The ADFS configuration contains the thumbprint of the SSL certificate in its database so the ADFS service across all servers will try to find the same certificate based on this thumbprint. If you need to confirm what SSL certificate needs to be installed on all the ADFS servers, compare the thumbprints on the certificates. All you have to do is install the same SSL certificate into the machine certificate store on all back-end ADFS servers and this includes a wildcard SSL certificate if you plan to use one.
Get a Publically Trusted SSL Certificate
You may have special circumstances, but I typically just recommend that customers acquire a publically trusted SSL certificate for use on all the ADFS servers. This ensures that all clients or partners that may use ADFS will inherently trust the SSL certificate. If you must use a SSL certificate from your internal CA, make sure it has the Server Authentication EKU.
Pick a solid ADFS Service Name and Confirm Uniqueness
Next, you’ll want to determine what to call your ADFS service. Whatever you pick, make sure the domain suffix you want to be put on the SSL (sts.domain.com) certificate is not already in use. If you plan to expose your ADFS to the internet via the ADFS Proxy/WAP, you’ll have to pick a domain suffix that is a publically routable DNS name. Your ADFS SSL certificate doesn’t have to match your Active Directory forest or domain name.
Be aware of DRS Naming Guidelines
The only time naming restrictions come into place is when you plan to do device registration on mobile devices since users will have to type in their UPN, which will need to resolve to the ADFS Proxy/WAP. So if you plan to do DRS, make sure the Common Name (CN) or Subject Alternative Name (SAN) contains all internal UPN’s.
After you’re done with these considerations, just pick a name – sts.domain.com, sso.domain.com, federation.domain.com, etc. It really doesn’t matter beyond the considerations above.
ADFS Proxy/WAP Server SSL Certificate Guidelines
While you could install the same SSL certificate on all of the ADFS Proxy/WAP servers as you did your ADF servers, I typically don’t recommend it. The ADFS Proxy/WAP servers are supposed to be installed into the DMZ and not domain joined for security reasons.
Get a Publically Trusted SSL Certificate
Once again, I recommend you get a publically trusted SSL certificate for your ADS Proxy/WAP servers.
Be Aware of Internally Issued SSL Certificate Caveats
If you installed an internally issued SSL certificate on your backend-ADFS servers, your ADFS Proxy/WAP servers, by default, won’t trust them. Consequently, you’ll have to either install the issuing CA certificate or the non-trusted SSL certificate into the Trusted Root certificate store on the Proxy/WAP servers so you can complete the installation wizard. The way to confirm whether the certificate is trusted is to open Internet Explorer on your Proxy/WAP server and navigate to the backend ADFS server and see whether you get any untrusted SSL prompts:
https://<sts.domain.com>/federationmetadata/2007-06/federationmetadata.xml
Get a Separate SSL certificate for your ADFS Proxy/WAP Servers
Due to security concerns with the ADFS Proxy/WAP server, I typically recommend that customers install a separate SSL certificate on their ADFS Proxy/WAP servers. The only thing you must ensure is that the Common Name (CN) or Subject Alternative Name (SAN) contain the same ADFS service name. You can install the same SSL certificate on all your ADFS Proxy/WAP servers though.
Don’t Install your Corporate Wildcard Certificate
I also don’t recommend you install your wildcard SSL certificate on your ADFS Proxy/WAP servers.
Be aware of DRS Naming Guidelines
Just remember that if you plan to do Device Registration for mobile devices, the Common Name (CN) and/or Subject Alternative Name (SAN) must contain all UPN’s within your enterprise. If you’re doing DRS, make sure to run the following PowerShell cmdlet on each ADFS Proxy/WAP to ensure it is aware and responding for all enterprise UPN’s:
Add-AdfsDeviceRegistrationUpnSuffix –UPNSuffix Contoso.com
Add-AdfsDeviceRegistrationUpnSuffix –UPNSuffix fabrikam.com
Mark the SSL Certificate Private Keys as Non-Exportable
Being that the ADFS Proxy/WAP servers are public facing, I typically recommend that the SSL certificates private keys are marked as non-exportable.
Token Signing Certificate Guidelines
It’s OK to use the Self-Signed Token Signing Certificate
Out of the box, ADFS generates some self-signed certificates for the token signing certificate. These self-signed certificates, by default, are good for one year. The token signing certificate will be used every time that a user needs to gain access to a relying party application.
It’s also OK to get a Token Signing Certificate from your internal CA
You can also get a certificate from your internal CA and the Enhanced Key Usage (EKU) on the certificate does not matter.
But be willing to get a Publically Trusted Token Signing Certificate
If the applications that you plan to federate with will perform certificate revocation on the public portion of your token signing certificate, I would just recommend you use a publically trusted certificate from VeriSign or another trusted certificate issuer.
Be aware of the Security Ramifications of BYOC
If you plan to not use the self-signed token signing certificate and bring your own certificates from your internal CA or get a publically trusted certificate, be aware that the private keys are no longer stored in Active Directory and are just installed into the computer certificate store on each ADFS server. You will want to restrict who can log onto the ADFS servers and may want to restrict the private keys from being exported as well.
Consider Extending the Validity Period
The self-signed certificates, by default, are good for one year. Most customer get SSL certificates that are good for 3 or more years. If you plan to use the self-signed token signing certificate, this means you’ll have to send the new public portion over to all SaaS applications - With the default setting, you’ll have to do this every year. Something you may want to consider is extending the validity period on the self-signed certificates to match your SSL certificate, so you can update them on the same schedule. To do this, you can run the following PowerShell to change the validity period on the self-signed certificates:
Set-AdfsProperties -CertificateDuration integer-number-in-days
Example for a 3-year certificate duration
Set-AdfsProperties -CertificateDuration 1095
If you want to force ADFS to immediately generate new self-signed certificates, you can run the following. Ensure that you only run this when you plan to change over your certificates (like a weekend). You’ll also have to send out the new token signing certificate to all relying party application owners.
Update-AdfsCertificate –Urgent
Have a Solid Plan when the Token Signing Certificate is Changing
When the token signing certificate needs to change, have a well documented plan about how you’re going to notify the owners of all of your relaying party applications. There is no way around this as this is just the nature of the beast . Tell them that if they don’t update to the new token signing certificate, users will fail to gain access to the application. If you are federated with O365 and have updated the token signing certificate, you can run the following to update the configuration in O365:
Update-MSOLFederatedDomain –Domain domain.com
Or use the following script to update the configuration in O365 with the new token signing certificate:
https://gallery.technet.microsoft.com/scriptcenter/Office-365-Federation-27410bdc
Rely on the Federation Metadata, if possible
Most SAML applications don’t support updating their configuration based on the federation metadata, but ask the vendor whether they support it. As long as you have a publically available ADFS Proxy/WAP, give them the following URL:
https://<sts.domain.com>/federationmetadata/2007-06/federationmetadata.xml
Be Aware of the Token Format Required for each Application
If the application is based on the Windows Identity Foundation (WIF) like SharePoint or other .Net web applications, all they need is the thumbprint of the token signing certificate. Just be aware that copying the thumbprint for a certificate can be tricky because there is a hidden character at the beginning, which won’t even display in notepad and may render the thumbprint invalid. A way to test whether this hidden character is present is to paste the thumbprint in a command prompt. As you can see here, the ? represents the hidden character:
Make sure to delete all spaces when sending the thumbprint to the application owners, like this:
8c7410dfdfbf4dd9cae23351a27ad86b5be42476
Some SAML relying parties will claim to need the token signing certificate in .PEM format. You can achieve this by exporting the token signing certificate as Base-64 Encoded X.509 (.Cer):
Don’t use the SSL certificate as your Token Signing Certificate
I’ve seen customers actually do this to simply their deployment but I don’t recommend this.
Token Decryption Certificate Guidelines
These guideline are actually just a subset of the token signing guidelines from above.
It’s OK to use the Self-Signed Token Decryption Certificate
Out of the box, ADFS generates some self-signed certificates for the token decryption certificate. These self-signed certificates, by default, are good for one year. Unless you have partner Identity Providers (IDP) sending you tokens that require encryption, this certificate will rarely be used.
It’s also OK to get the Token Decryption Certificate from your internal CA
You can also get a certificate from your internal CA and the Enhanced Key Usage (EKU) on the certificate does not matter.
But be willing to get a Publically Trusted Token Decryption Certificate
If you have partner IDP’s sending you tokens that require encryption and they plan to also perform certificate revocation checking on the public portion, I would just recommend you use a publically trusted certificate from VeriSign or another trusted certificate issuer.
Be aware of the Security Ramifications of BYOC
If you plan to not use the self-signed token decryption certificate and bring your own certificates from your internal CA or get a publically trusted certificate, be aware that the private keys are no longer stored in Active Directory and are just installed into the computer certificate store on each ADFS server. You will want to restrict who can log onto the ADFS servers and may want to restrict the private keys from being exported as well.
Don’t use the SSL certificate as your Token Decryption Certificate
I’ve seen customers actually do this to simply their deployment but I don’t recommend this.
Dave “ ? “ Gregory
As you know, on this blog, we assign ourselves fun middle names after each blog. Can anyone figure what my middle name is? There is a clue in the blog. +10 points for the first one to figure it out.
Next Blog in Series: http://blogs.technet.com/b/askpfeplat/archive/2015/03/02/adfs-deep-dive-onboarding-applications.asp...