Active Directory Federation Services Part 2

Thomas Stensitzki
 AD FS | Deep Dive

Page 2
 AD FS Concept

Claims-aware Active Directory

application AD FS

Define STS as Define AD as

claims provider claims provider
APP STS
Define APP as
Relying party

Relationships between APP and STS established through the exchange of

federation metadata
- Can be manually configured

STS = Security Token Service

Page 3
 Issuer
Key Concepts Identity Provider (IP)
Security Token Service (STS)

Authentication request
User / Subject / Principal Active
Directory
ST Issues Security Token
Security Token
contains claims about the user
For example:
Name Security Token Authenticates
Group membership user to the application
User Principal Name (UPN)
Email address of user
Email address of manager Relying Party / Resource Provider
Phone number
Other attribute values

Trusts the Security Token

from the issuer
Signed by Issuer
Page 4
Claims-Aware Application

The application makes authorization decisions based on the claims contained in the
security token
- No longer required to make authentication decisions

Same authorization logic for Application

- Deployed on the Intranet or as a Cloud service
- Receiving claims from its own organizations users or users from trusted partners

Page 5
Passive Client

User Claims-aware App ADFS STS Active Directory

App trusts STS

Browse app

Not authenticated

Redirected to STS
Authenticate
Return Security Token
ST Query for user attributes

Send Token
ST

Return page and cookie

Page 6
X.509 Certificates

Relying party Issuer

Root for B A Communication B Root for A

Public key of C Signing ST C

D Encryption ST Public key of D

Private Key

Trust is managed through certificates

Certificates for
- HTTPS Communication
- Security token signing and encryption

Require PKI for A & B certificates, C & D can be self-signed by AD FS server

Page 7
Federation Metadata

During the establishment of the issuer / relying party trust, both parties will require
configuration which includes
- End-points for communication
- Claims offered by issuer
- Claims accepted by replying party
- Public keys for signing and encryption

This information can be manually configured or automatically via the exchange of federation
metadata
- Federation metadata can be automatically updated

Page 8
Offered Claims Types

Extract from federationmetadata.xml

<fed:UriNamedClaimTypesOffered>
<fed:ClaimType Uri="http://schemas.xmlsoap.org/claims/EmailAddress">
<fed:DisplayName>Email Address</fed:DisplayName>
</fed:ClaimType>
<fed:ClaimType Uri="http://schemas.xmlsoap.org/claims/UPN">
<fed:DisplayName>User Principal Name</fed:DisplayName>
</fed:ClaimType>
<fed:ClaimType Uri="http://schemas.xmlsoap.org/claims/CommonName">
<fed:DisplayName>Common Name</fed:DisplayName>
</fed:ClaimType>
<fed:ClaimType Uri="http://schemas.xmlsoap.org/claims/Group">
<fed:DisplayName>Group</fed:DisplayName>
</fed:ClaimType>
</fed:UriNamedClaimTypesOffered>

Page 9
Claims Pipeline How a Security Token is build

Claims
Specify the users that are permitted to access the
Provider
relying party
Input Input
Issuance Acceptance
Authorization Rules Transform Rules

Permits/denies rule processing and Specify incoming claims that will be accepted from the
claims issuance claims provider and the outgoing claims that will be sent
to the relying party trust
Output Input
Issuance
ST
Transform Rules

Specifies claims that will be

sent to the relying party

Resulting claims added to security token (ST)

Page 10
Claim Rules

Rule templates simplify the creation of rules

Examples of rules are:
- Permit / deny user based on incoming claim value
- Transform the incoming claim value
- Pass through / filter an incoming claim

Multiple claim rules can be specified and are processed in top to bottom order
- Results from previously processed claims can be used as the input for subsequent rules

Link: An ADFS Claims Rules Adventure

Page 11
Creating Claim Rules

Condition

Issuance Statement

A claim rule consists of two parts, condition and issuance statement

Page 12
Custom Claims

Capabilities of custom rules include

- Sending claims from a SQL attribute store
- Sending claims from an LDAP attribute store using a custom LDAP filter
- Sending claims from a custom attribute store
- Sending claims only when 2 or more incoming claims are met
- Sending claims only when an incoming claim matches a complex value
- Sending claims with complex changes to an incoming claim value
- Creating claims for use in later rules

Page 13
Claim Rule Language

The claim rule language consists of Condition => Issuance Statement

Pass through all role Claims

c:[Type == http://schema.microsoft.com/ws/2008/06/identity/claims/role]
issue(claim = c);

Change the value of the Role Claim SalesStaff to Purchasers

c:[Type == http://schema.microsoft.com/ws/2008/06/identity/claims/role, Value =~ ^(?i)SalesStaff$]
=> issue(http://schema.microsoft.com/ws/2008/06/identity/claims/role, Issuer = c.Issuer,
OriginalIssuer = c.OriginalIssuer, Value = Purchasers, ValueType = c.ValueType)

After a claim is issued it is added to both the input and output claims set allowing the transformed
claim to be processed by subsequent rules

To make a processed claim available just for reprocessing replace the issue statement with add

Link: AD FS 2.0 Claims Rule Language Primer

Link: Understanding Claim Rule Language In AD FS 2.0 And Higher

Page 14
How do to allow access for Partners?

Supporting claims aware applications within your organization

- Creating an identity (includes authentication) framework that can be consumed by all applications
regardless of their location internal or external
- Allowing the identity token to carry more information than just the user and group memberships

To allow partners to access your systems you must trust them to authenticate your partners
users

Page 15
 Partner organization Your organization
Partner ADFS Your AD FS
STS & IP STS
Claims Trust
Claims Trust
Relying Party Trust

Relying
Your STS now trusts your partner to provide a security token containing claims for their Party X
users
Your STS is no longer responsible for identifying the user but still processes the claims from
the partner as previously described
Page 16
 Summary

Your Organization AD FS
Partner user Security Token Service (STS)
ST from Partner
ST Trusted
Claims Trust
Partner
Client request token for access
to Relying Party X

ST
ST

Processes
ST Acceptance Transform Rules
Returns token
for Relying Party X Relying
Party X
Processes If denied
Issuance Authorization Rules processing ends

If allowed processes
Page 17 Issuance Rules
Passive Client

Partner user Your Claims-aware App Your ADFS STS Partner ADFS STS & IP Active Directory

Browse app

Not authenticated

Redirect to your STS

Home realm discovery

Redirected to partner STS requesting ST for partner user

Authenticate
Return ST for consumption by your STS
ST
Redirected to your STS
ST

Return new ST Process token

ST
Send Token
ST
Return page and cookie
Resources

ADFS How to enable Trace Debugging and advanced access logging

Troubleshooting ADFS: Enabling additional logging
Under the hood tour of Azure AD Connect Health: AD FS Diagnostics Module
AD FS Diagnostics Module
AD FS for Windows Server 2016 Best Practices
Backup and Recovery with the AD FS Rapid Restore Tool

Page 19
Questions

Thomas Stensitzki
Expert
Granikos GmbH & Co. KG
MCSM Messaging, MCM: Exchange 2010
MCT, MCSE, MCITP, MCTS, MCSA, MCSA:M

E-Mail: thomas.stensitzki@granikos.eu
Web: http://www.Granikos.eu
Blog: http://blog.Granikos.eu
Blog: http://JustCantGetEnough.Granikos.eu

Page 20