Over the years EPM Partners have configured our SharePoint farms to support ADFS (SSO) authentication for some of our clients.
Recently, a client use Project Online but have their SSRS reports hosted on our SharePoint servers hosted on Microsoft’s Azure platform (which is akin to on-premise environment). Their Project Online uses SSO against their own Active Directory. Obviously, they don’t want authentication prompts when navigating to an SSRS report, therefore requested for ADFS authentication to be enabled for the SSRS reports.
The key components of the client’s reporting solution are:
- A service to extract Project Online data to SQL databases hosted by EPM Partners
- A SharePoint Site hosted by EPM Partners where the SSRS reports are deployed
- ADFS authentication enabled on the SharePoint site
The client’s requirement is, if a user belonged in a certain Active Directory group, then the user should be granted access to certain reports deployed on our SharePoint farm.
When ADFS is configured, you will note that SharePoint user accounts are prefixed in the following way:
Yellow identifies the account as a Federated account (or identity claim). Green identifies the trusted issuer; I set this up as required for each client. Purple is the identifier and the email address is used for all of our ADFS implementation.
In comparison, the following is the convention used for a windows user account:
Yellow identifies the account as a windows account. Green identifies the domain. Purple identifies which is the AD user account.
The following is the convention used for a windows group account:
Yellow identifies the account as a windows group. Purple identifies the group; this is the group SID number from AD.
Now for the last part, the bit I learned recently for the client.
Yellow identifies that this is a “role” claim (think ADFS as an example). Green identifies the trusted issuer. Purple is the identifier; this is the name of the AD group in the client’s Active Directory.
Please note that for all our ADFS configurations used in EPMonDemand (our Azure based SharePoint farms), we insist on the following to be setup by the client on their ADFS server.
Configure the claim rules
Configure the following Issuance Transform Rules:
(Send LDAP Attributes as claim ‘LDAP Attribute’ -> ‘Outgoing Claim Type’)
- E-Mail-Addresses -> E-Mail Address
- User-Principal-Name -> UPN
- Token-Groups – Unqualified Names -> Role
If the client had configured everything perfectly on their site, when a “claim” is sent from their ADFS server to our SharePoint farm, it provided the three details mentioned above. Email, UPN and, importantly, Role. The Role is mapped internally in their ADFS server to the users AD group membership.
So all I had to do in SharePoint was:
- Run powershell commands:
Add-SPuser –web https://client.domain.com.au –UserAlias ‘c:0-.t|Client|ReportsALL’ –displayName ‘ReportsALL’
Add-SPuser –web https://client.domain.com.au –UserAlias ‘c:0-.t|Client|ReportsPMO’ –displayName ‘ReportsPMO’
- Login with a valid ADFS account into Client.domain.com.au; I couldn’t perform the following when signed in with a Windows account.
The client now can share a site, a list or anything with the SharePoint account ‘c:0-.t|Client|ReportsPMO’ (which in effect, is the AD group in the clients Active Directory).