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.

%d bloggers like this: