ADFS Certificate Requirements

Federation Trust and PKI

The federation trust is the key component by which secure communications in AD FS is made possible. It is not only the only PKI requirement for AD FS but it is a fundamental one, without which much of the functionality of AD FS would not be possible. There is nothing unique to ADFS about the federation trust, except the name, because it is a regular PKI implementation that may even already be in place and used by other server components for other purposes – so in this case, it can ALSO be used by AD FS.

Certificate Trust Models

It is possible to install and configure Microsoft Certificate Services to provide not only the federation trust but also all the other PKI certificate requirements. It is advisable in many cases, however, to purchase the appropriate certificates from a mutually trusted root CA (Internet root CA), so client computers from different organisations will be able to trust the various certificates involved in the AD FS deployment.

Although, this can increase the cost involved in deploying ADFS, it eases the process of establishing the PKI trust across organisational boundaries.

The main reasons to consider using an internal, corporate PKI, rather than using an externally trusted CA include;

  • Cost – Building a Windows PKI is free with the OS. (Although a catch-22 here may be that you will require on-site staff that can administer, maintain and secure the software and hardware associated with an internal PKI)
  • Control – Organisations have greater control over how the PKI is built and how, when, and where certificates are issued.
  • Existing Infrastructure – This provides an existing PKI that can be easily adapted to support ADFS.

 

Infrastructure Requirements – ADFS

At a minimum, deploying AD FS 2.0 within a single organisation requires the following infrastructure:

 

  • Active Directory – AD FS 2.0 requires Active Directory to authenticate users. This can be any version of AD, and does not require a specific schema revision, or domain or forest functional level.

 

  • Active Directory Federation Services 2.0 – Deploying AD FS in a single organisation requires a minimum of one AD FS 2.0 server. In its simplest configuration, this server will be configured with a claims provider trust to the corporate Active Directory (this is configured by default on every AD FS 2.0 server), and a relying party trust for each application that will be consuming claims produced by this AD FS server. By default, internal users will authenticate to the AD FS server via Integrated Windows Authentication in order to obtain AD FS tokens that they will present to any relying party applications. A single AD FS server can authenticate users in the same domain as the ADFS server, in any domain within the same Active Directory forest, and any users in any trusted forest.

 

  • Domain Name System (DNS) – The DNS requirements for the WebSSO deployment are fairly straightforward. All clients must be able to resolve the A record of the federation server and any relying party applications, in addition to the DNS requirements associated with Active Directory authentication (SRV records, and so on). If a Federation Server proxy (FSP) has been deployed, this will potentially add to the DNS requirements in this scenario.

 

Managing ADFS with PowerShell

Some of the items within ADFS can be managed via PowerShell, these include;

  • Add trust partners
  • Add SAML 2.0 federation trust partners
  • Manage trust partner settings
  • Configure claim types and ADFS 2.0 server policy
  • Manage policy using more complex sets of stored rules
  • Monitor partner metadata

For introductory information regarding Windows PowerShell please refer to the following link – Scripting with Windows PowerShell

The ADFS PowerShell snap-in is automatically installed when the ADFS Server role is installed on a Server 2008/201server. You can confirm the cmdlets are ready for use by entering the following command in the PowerShell prompt;

Add-PSSnapin Microsoft.AD FS.PowerShell

Once this has been ran, you will see the following as part of the output of the get-PSSnapin command:

Name        : Microsoft.AD FS.PowerShell

PSVersion: 1.0

Description: This PowerShell snap-in contains cmdlets used to manage Microsoft Identity Server resources.

To view a list of all the AD FS 2.0 cmdlets, run the following command in the PowerShell:

Get-Command *-AD FS*

 You can obtain syntax help for individual cmdlets by using Get-Help followed by the name of the cmdlet, as follows;

Get-Help Set-AD FSProperties

Similar to other PowerShell snap-ins, the AD FS cmdlets adhere to a predictable <Verb>-<Noun> syntax. So when managing an AD FS Relaying Party trust, you can use cmdlets such as;

  • Add-AD FSRelyingPartyTrust
  • Remove-ADFSRelyingPartyTrust
  • Set-AD FSRelyingPartyTrust
  • Enable-AD FSRelyingPartyTrust
  • Disable-AD FSRelyingPartyTrust
  • Update-AD FSRelyingPartyTrust

As is the case with other PowerShell snap-ins, you can autocomplete longer cmdlet names using the TAB key.

While the most comprehensive list of available cmdlets can be found using the Get-Command *-AD FS* syntax described as above, the following is a list of the AD FS properties and configuration items that can be managed using PowerShell;

  • AD FSClaimsProviderTrust
  • AD FSAttributeStore
  • AD FSClaimDescription
  • AD FSEndpoint
  • AD FSCertificate
  • AD FSProxyProperties
  • AD FSClaimRuleSet
  • AD FSSAMLEndpoint
  • AD FSContactPerson
  • AD FSOrganization
  • AD FSCertSharingContainer
  • AD FSSyncProperties

 

The Federation Server As a Claims Provider

To summarise this particular post;

  • The Claims Provider presents a web service that can issue security tokens containing claims in a standardized format (SAML – Security Assertion Mark-up Language)
  • The Claims Provider allows administrators to publish policy data about the claims provider, which a relying party federation server can retrieve and use as part of the federation relationship.

The federation server is a computer that runs a security conscious service that issues security tokens.

When the federation server is given the role of a Claims Provider (CP) it allows authentication capabilities; whereas in the Relaying Party (RP) role it acts as a passage that allows identities to travel between different security boundaries.

In the case of Office 365 – Active Directory Federation Services (AD FS 2.0) is the Windows Server role that provides this federation server functionality. In this implementation, ADFS can fulfil either of the above functions – Claims Provider or Relaying Party.

As a Claims Provider;

  • Processes requests from incoming users to provide signed tokens containing claims that represent the user’s digital identity.
  • Claim information can consist of – user’s name, role or group membership etc.
  • ADFS issues tokens in a SAML format.
  • ADFS can protect the contents of security tokens in transit by signing and encrypting them.

Side note – ADFS 2.0 allows you to encrypt tokens, previous versions were only digitally signed.

As a Relaying Party;

  • Receives tokens from a trusted Identity Provider.
  • Will issue new security tokens that a local application can consume to make authorisation and personalisation decisions.
  • By using a relaying party, organisations such as Microsoft are able to provide ‘Single Sign-On‘ (SSO) for Office 365, crossing the boundaries between ‘signing on locally’ and authorising use within the ‘cloud’.

The two above terms can be further defined as follows;

Claims Provider – An organisation that is responsible for the user identities in a federated relationship. (In our examples this will be the organisation with the Active Directory infrastructure (onsite))

Relaying Party – The organisation that is responsible for administering and protecting the web-based resources and other claims-based applications. (In our example this would be the cloud- Office 365)

Working together

In a Federation Trust Relationship, the Relaying Party is the partner that trusts (or relies on) a Claims Provider to authenticate users, this takes the process of user authentication from the applications and web services that are managed by the RP. The RP consumes the claims from the CP, which it verifies through, typically, a PKI certificate.

Cryptography – Symmetric & Asymmetric

Please don’t be scared by the name of this post, it is all Office 365 related. This method of exchanging information between collaborating parties makes it very difficult for others to access the information. So when you look into this, think ADFS and the way your organisation talks to Microsoft.

Cryptography aims to allow you to transmit sensitive information across an insecure network, for example, the internet, so it cannot be ready by anyone except the intended receiving party.

Modern cryptography is based around mathematics, encryption. In addition to this, modern cryptography techniques can also be used to sign data so that any reader is aware of the origination of the data and ensure it is from the publisher who transmitted it.

The primary two types of encryption are;

  • Symmetric
  • Asymmetric (or public)

Encryption and decryption requires the use of secret information, known as a key.

This ‘key’ is shared between two parties in advance, this key is used for both the encryption and decryption of a message.

Provided the recipient knows the key, they will be able to decipher the message, anyone who tries to intercept the message but does not have the symmetric key will be unable to convert it to something decipherable, although this will depend on the complexity of the key (much like a login password!).

Symmetric Encryption

The same key is used for both encryption and decryption. The parties must agree on the secret key in advance and then keep it to themselves, once they have done this they will be able to send each other secured messages.

However, a simple substitution algorithm is relatively easy to crack, not necessarily at human level, but with regards to computing, it could well be ‘crackable’. You could increase the digits of the key to complicate it further however, you will need a careful balancing act between security and performance. Something with a massive key would take longer to encrypt and decrypt, whereas a shorter key would be faster.

Symmetric key encryption provides good performance compared to asymmetric encryption, and is a good choice for bulk encryption.

Symmetric key encryption does have a rather large catch;

In order to create this ‘collaboration’ with another party, you will need to send the key to the other party, however, until the key is in place both ends, you are unsecure in your transmissions. If you had a secure channel to transfer this key in the first place, there would be no need for this solution. So in theory, a brave attempt at security, but it still leaves that gap of a ‘what if’ scenario, most wouldn’t want to test. I’d certainly hope my banking data isn’t transferred using this method.

 

Asymmetric Encryption (Public Key encryption)

Asymmetric encryption was developed by Whitfield Diffie and Martin Hellman (Diffie Helman if that rings a bell), however this was overshadowed by the ‘RSA’ algorithm.

The core principle for asymmetric encryption; Encryption that is performed in one direction cannot simply be decrypted by applying a rule in reverse – anything encrypted with a public key can only be decrypted with the corresponding private key.

In this encryption, there is the use of two keys, a public key accessible by anyone, and one private key stored in the safest of locations by one party.

Anything encrypted with the public key can only ever be decrypted by the party with the private key, so in this case, unlike symmetric, there is no need for the physical exchange of a secret. Encryption with the private key is used to prove the source of the message, because if you receive a decryptable message using the public key, you know it came from the party with the private key.

Asymmetric is generally used to initiate a secure channel and provides a means to exchange a temporary symmetric encryption key, so by combining the two, you generate a safe way of securing collaboration between the two parties. This is also know as a ‘session key’

 

ADFS Analogy

I’ve recently come across an analogy which perfectly sums up the use of ADFS and the requirement of certificates.

This kind of puts the whole process into context.

A woman, let’s call her Louise Smith, is offered the once-in-a-lifetime chance to buy a diamond for a great price. The seller, let’s call him Jonathan Jones, contacts Louise and, gives her his name, address, details of the gem registry entry for the diamond, and agrees on a price. She is a careful person by nature, so she makes enquiries. She confirms that the diamond is real, that it is worth the money, and that it really belongs to Jonathan Jones. Then she writes a cheque for the money and Jonathan Jones gives her the diamond.

A week later, the police call to collect the stolen diamond, because the seller wasn’t actually Jonathan Jones. It was all a question of identity. Adding amusement to injury, the police find that the actual buyer hasn’t lost anything either, because she wasn’t actually Louise Smith and was using a stolen chequebook.

The point being, is that all the permissions can exist to allow the participants to participate in a transaction, but if the identities are not verified, the security doesn’t have a firm base.

In this case we look at CA (Certificate Authorities) to issue certificates to organisations or individuals to ensure that ‘requests’ are who they say they are. This works much like a passport and the above analogy could have been prevented if each user had declared their passport to one another, however, this assumes a perfect world.

The CA’s basically ‘vouch’ for the subject for the usages agreed.

This is the basis for ADFS, creating trust and ensuring identity. A very complex subject that is difficult to visualise, so I’m hoping this short story helps!

ADFS Overview

Prerequisites

ADFS was first introduced in Windows Server 2003 R2 Enterprise Edition – This uses ADFS V1

In order to use the latest version of ADFS (V2) you will need to be running Windows Server 2008 SP2 or Windows Server 2008 R2. (This also includes Server 2012)

ADFS 2.0 does not require a particular operating system level and neither versions require a particular domain functional level or forest functional level for the AD Domain Controllers used for authentication.

The Federation service components consist of –

  • The Federation Server (FS)
  • The Federation Server Proxy (FSP)
  • The AD FS web agent (AD FS V1 only)

Networking Requirements

TCP/IP Connectivity –

FS in ADFS do not need to talk directly to each other for applications using the passive requester profile.

FS will communicate directly when using WS-trust, and optionally during metadata exchange.

ADFS and DNS –

Federation Service Proxy (FSP) servers should use the same host name as the federation server they are protecting.

Depending on the solution required, a split DNS configuration may be necessitated.

ADFS requires the deployment of a solid TCP/IP network and DNS name resolution for a successful implementation.

Directory Services and AD FS

AD FS is a technology that allows one location/company/party holding user accounts to project these identities to another party that hosts resources. In order to do this, authentication is required somewhere along the line, ADFS can use AD and ADLDS to accomplish this. ADFS uses Kerberos to authenticate with AD, and a LDAP call when communicating with AD’s younger brother, ADLDS, this call could be secured with an SSL but is not a requirement.

In both versions of ADFS (v1 and v2), Federation servers must be joined to an AD domain. However an Federation Server Proxy (FSP) does not need to be joined to a domain; it is recommended that this isn’t the case and instead used on a workgroup for best practice.

ADFS Terminology

A quick overview of the terminology used for ADFS

 

 Adfs-editFSproperties01Please click here for an overview video from MSDN’s Channel 9 service

 

%d bloggers like this: