Assuming you have created the Yammer Relying Party Trust and SSO is now working with the default configuration, a need may arise to prevent some users from logging into Yammer. This will require writing a custom claims transformation rule. The first step to achieving this goal is to create an active directory security group and add the "allowed users" as members of the security group. Feel free to skip this step if you already have a security group.
Creating an AD Security Group
- Click Start, point to, point to Programs, Administrative Tools, and then click Active Directory Users and Computers
- In Active Directory Users and Computers window, expand <domain name>.com
- In the console tree, right-click the folder in which you want to add a new group.
- Click New and then click Group.
- Type the name of the new group. You may want to use a name that you can easily associate with the role you are creating.
In the New Object - Group dialogue box, do the following:
- In Group scope, select Global scope.
- In Group type, select Security
- Click OK
- Now double click on the group you just created and follow the direction of the arrows to add a member to the group:
Get SID of the Security Group
Now that we have a security group, we will need the ObjectSID of the group. This value can be found in the Attribute Editor pane of the group's properties:
The ObjectSID value cannot be easily copied from the Editor pane so we're going to have to use Powershell commands to retrieve the value. Open the PowerShell command prompt on the Active Directory server and run this two liner commands - remember to change GROUP-NAME-GOES-HERE to the name of the security group; YammerUsers in my case.
$name = “GROUP-NAME-GOES-HERE” (New-Object System.Security.Principal.NTAccount($name)).Translate([System.Security.Principal.SecurityIdentifier]).value
The above commands should then output the ObjectSID:
Copy the SID value into notepad.
Update the Yammer Relying Party Trust
- Open ADFS Management Snap-in and navigate to Relying Party Trust
- Right click the already existing Yammer Trust and click Edit Claim Rules
- Go to the "Issuance Authorization Rules" tab at the top
- Click Add Rule and select "Send Claims Using A Custom Rule" from the drop down.
- Copy/Paste this rule into the Custom rule text box:
NOT exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "\bSID-GOES-HERE\b"]) => issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");
- Replace SID-GOES-HERE with the ObjectSID value of the security Group:
Once that is done, move the new Yammer Custom Rule to the top, that way, it takes priority over the "Permit all" rule. Do not remove the Permit all rule. In all, it should look like this:
Click Apply, OK and get ready to TEST!
Testing Yammer SSO with Custom Claim Rule
Let's test this out. Open an Inprivate browsing session or Incognito if you're using Chrome, navigate to yammer.com/your-domain.com.
You should be redirected to your company's login page. Enter an active directory credential of a user who IS NOT a member of the security group and it should result to an error on successful authentication:
The above error is because your ADFS server sent a Request-Denied SAMLResponse to Yammer:
It is not possible to customize the error in Yammer at this time. However, you may configure ADFS to not redirect unauthorised users to yammer, and to display a user friendly message. Use the following Windows Powershell cmdlet and syntax to customize the relying party error message:
Set-AdfsRelyingPartyWebContent -Name fedpassive -ErrorPageAuthorizationErrorMessage "<br><p> You need to be a member of the Yammer Users Security group to access this Yammer network. Click <A href='http://requestyammeraccess/'>here</a> for more information or contact firstname.lastname@example.org</p>“
Finally, test this out with a user who is a member of the security group to be sure you haven't locked everybody out.
I tested this out on a non-production ADFS 3.0 server. Your mileage may differ so take extreme care before applying any changes to your production server and you may use the information in this blog at your discretion.