The core components of AD FS are as follows:

  • An AD FS server which is responsible for issuance of claims and user authentication. This server must be able to connect to a Domain Controller. It authenticates users from multiple domains by using Windows Trust. The AD FS server can be set up in a cluster to ensure high availability.
  • An AD FS proxy server which protects the AD FS server from internet-based threats. The AD FS proxy server also authenticates users from the internet. Again, the AD FS proxy server can be set up in a cluster to ensure high availability.
  • An AD FS configuration database which can be stored in an SQL database or Windows Internal Database (maximum of 5 servers) but not both at the same time. This database stores the following items:
    • Relying Party Trust
    • Certificates
    • Claim Provider Trust
    • Claims description
    • Service configuration
    • Attributes

The diagram below shows a common authentication process flow for applications located in a resource organization and secured with AD FS, of which Office 365 is a popular example. The steps, which correspond to the numbers in the diagram, are outlined as follows.

  1. The internal user tries to access the AD FS-enabled resource.
  2. The client is redirected to the resource’s Federation Service.
  3. If the resource’s federation service is configured as a trusted partner, the client is redirected to the organisation’s internal Federation Service.
  4. The AD FS server uses the Active Directory to authenticate the user.
  5. The AD FS server sends an authorization cookie to the client. This contains the signed security token and a set of claims for the resource partner.
  6. The client connects to the resource partner’s Federation Service where the token and claims are verified. If appropriate, the resource partner may send a new security token.
  7. The client presents the new authorisation cookie with the security token to the resource in order to access it.