Restricting Access to Yammer Using ADFS Claims Transformation Rule

  • Articolo

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 jetlee@contoso.com</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.

 

Disclaimer:  

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.  

Tweet to @israel_ogbole

[bing_translator]

Comments

  • Anonymous
    January 01, 2003
    Thanks for sharing your experience, Thomas. Glad it worked for you! I am not exactly sure why your AD server takes up to 15mins to propagate the changes (sometimes), but it could be most likely due to latency in your Global Catalog multimaster replication.
  • Anonymous
    March 27, 2015
    Thank you for a very detailed guide! I experienced that it took up to 15 mins after changing group membership before it took effect at some times. Thanks for this!
  • Anonymous
    July 09, 2015
    Hi, very nice article, thanks very much for sharing you knowledge.
    Is there any way we can allow Yammer access to multiple groups?
  • Anonymous
    July 31, 2015
    Yammer supports any SAML 2.0 compliant Identity Provider (IdP). These include ADF 2.0 & 3.0, Windows
  • Anonymous
    October 09, 2015
    Thanks for a great article Israel. How would this work if you're not using Yammer SSO though and are just using Office 365 with ADFS (as Microsoft now recommend). I've tried adding a rule to the Microsoft Office 365 Identity Platform relying party trust but of course that then blocks access to Office 365 in its entirety (except to members of my group) rather than to just Yammer. Have you any ideas please? Thanks, Mark
  • Anonymous
    October 12, 2015
    Hi Mark. Thanks for the feedback. This wouldn't work for Office 365 sign-in for Yammer since yammer delegates authentication requests to Office 365. There isn't any way to implement yammer restrictions in Office 365 yet, but it's part of the roadmap to add 'per user license' in Office 365 at some point in the near future. That way, yammer will only be available to Office 365 users who are assigned yammer licenses.
  • Anonymous
    October 12, 2015
    Thanks for the reply Israel - and for the comment on the roadmap. In the end I worked around the issue by applying IP restrictions!
  • Anonymous
    November 10, 2015
    Hi Israel, I am after something similar... How could you login to any ADFS Relying Party application (like O365) with a user other than a user who you are logged in with?
    We have numerous meeting rooms where a default user is logged in but staff members would need to use O365 and other federated applications. They can`t login to the machine as it locked down.
    Thanks
  • Anonymous
    November 28, 2015
    Hey Gabor, I think it's possible to achieve your aim. However, I can't post it here as it could be wrong coz I don't have the full context of your use case and your current setup. I'd suggest you file a support case with the ADFS team and they should be able to give you a definite answer.
  • Anonymous
    January 17, 2016
    Hi Israel, Thank you very much for your great posting. I have a question about the error message.
    For IDP-initiated sign-on, I can see the customize error message in ADFS. but with SAML SP-initiated sign-on, user will be redirected to SP and see something went wrong in Yammer. how to fix it?
    Thank you
  • Anonymous
    January 19, 2016
    Thanks for the feedback, Winne. As noted in the blogpost, yammer (the SP in this case) does not provide the granularity to customise the error message when ADFS sends RequestDenied response. FYI, the yammer team are in the process of phasing out SSO in favour of Office365 sign-in so I don't think they will consider making any improvements w.r.t customising the "something went wrong" error.
  • Anonymous
    March 29, 2016
    The comment has been removed