locked
ADFS 3 - Cross Forest Sec Group Membership Claim RRS feed

  • Question

  • Hi there,

    I'm hoping someone can help me with this and that I'm in the right place.

    For a number of reasons we have the following set-up.

    General Office Domain:
    This domain contains our standard user objects, these users are what we want to authenticate to ADFS with.

    Division Domain
    This domain is for a specific division and is where we want to control ADFS access through the use of security group membership.

    The ADFS server is set-up in the Division Domain.

    Currently there is a 2 way, forest trust between the 2 domains.

    A computer client joined to the General Office Domain and logged in with a user also in the General Office Domain can successfully authenticate to the ADFS server in the Division Domain, this is all fine.

    What I would like to do and what I'm having issues with is the following...

    We have a number of security groups in the Division Domain, we have made users from the General Office Domain members of these groups.

    In ADFS I would like to query the group membership in the Division Domain of the incoming claim type of windowsaccountname. I think this failing because the General Office Domain user object that is a member of a group in the Division Domain is actually a place holder and not the actual user object. When ADFS is checking for group membership of the windowsaccountname, it's not finding the user as a member of the groups in the Division Domain.

    How would I get ADFS to retrieve/match group membership information of a user object (from a different forest) that has been made a member of a group?

    I can see that on the place holder object that is a member of the group, there is the objectSID attribute which ties it back to the actual user object in the General Office Domain but I've no idea if it's possible to get ADFS to match this or not.

    I hope this makes sense to people.

    Edit1: After a little more reading, I think this could be related to the fact that the security group type is Domain Local and ADFS can't read from these groups as it doesn't natively know which domain to pull them from, see here: http://social.technet.microsoft.com/wiki/contents/articles/13829.ad-fs-2-0-domain-local-groups-in-a-claim.aspx

    My groups have to be Domain Local as they contain members from a different forest.

    Just to recap, ADFS and the Sec Groups are in the Division Domain, the user objects for authentication and membership of the Sec Groups are in the Office Domain.

    Edit 2: I've tried the following as a claim rule but it doesn't work...

    c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", Issuer == "AD AUTHORITY"]
     => add(store = "Active Directory", types = ("http://test.com/phase1"), query = "name={0};memberOf;DivisionDomain\user", param = c.Value);

    Essentially I'm trying to match the place holder user object by it's SID and then looking for the groups it's a member of. Using memberOf should get around the fact that the sec group is domain local. I'm also telling the query to look in the Division Domain for an object with the name attribute that matches the SID of the incoming primarysid. I've checked that the values are all correct but this rule doesn't work.


    Monday, May 16, 2016 1:45 PM

Answers

  • Edit 2: I've tried the following as a claim rule but it doesn't work...

    c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", Issuer == "AD AUTHORITY"]
     => add(store = "Active Directory", types = ("http://test.com/phase1"), query = "name={0};memberOf;DivisionDomain\user", param = c.Value);

    Essentially I'm trying to match the place holder user object by it's SID and then looking for the groups it's a member of. Using memberOf should get around the fact that the sec group is domain local. I'm also telling the query to look in the Division Domain for an object with the name attribute that matches the SID of the incoming primarysid. I've checked that the values are all correct but this rule doesn't work.

    Just thought I'd come back and let other people know that I've found the fix for this in case it helps someone else.

    Essentially the service account that ADFS was running under didn't have permissions in AD to read the values under the "memberOf" attribute in AD for objects of type Foreign Security Principal.

    The above claim rule turned out to be fine, once I made the permission change then everything started working.

    See here for a link on how to apply the permission: https://social.technet.microsoft.com/Forums/windowsserver/en-US/bda33eb9-ff6e-4e79-967d-f5430ade7310/give-access-to-account-to-view-member-of-attribute-on-foreign-security-principal?forum=winserverDS

    Tuesday, May 17, 2016 3:39 PM

All replies

  • Edit 2: I've tried the following as a claim rule but it doesn't work...

    c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", Issuer == "AD AUTHORITY"]
     => add(store = "Active Directory", types = ("http://test.com/phase1"), query = "name={0};memberOf;DivisionDomain\user", param = c.Value);

    Essentially I'm trying to match the place holder user object by it's SID and then looking for the groups it's a member of. Using memberOf should get around the fact that the sec group is domain local. I'm also telling the query to look in the Division Domain for an object with the name attribute that matches the SID of the incoming primarysid. I've checked that the values are all correct but this rule doesn't work.

    Just thought I'd come back and let other people know that I've found the fix for this in case it helps someone else.

    Essentially the service account that ADFS was running under didn't have permissions in AD to read the values under the "memberOf" attribute in AD for objects of type Foreign Security Principal.

    The above claim rule turned out to be fine, once I made the permission change then everything started working.

    See here for a link on how to apply the permission: https://social.technet.microsoft.com/Forums/windowsserver/en-US/bda33eb9-ff6e-4e79-967d-f5430ade7310/give-access-to-account-to-view-member-of-attribute-on-foreign-security-principal?forum=winserverDS

    Tuesday, May 17, 2016 3:39 PM
  • Interesting.. This actually solves a longstanding problem I had with foreign security principals and service accounts with another piece of software... 

    Thanks!


    http://blog.auth360.net

    Friday, May 20, 2016 4:15 PM
  • One fix to the above as it will only work for foreign user. Normal users using the same rule will fail.

    So i have created a fix which works for both user types, groups of groups, as well as giv you the ability to filter on group names

    Full code can be found here:

    http://www.gi-architects.co.uk/2016/09/adfs-claim-rules-for-groups-and-cross-forest/





    Sunday, September 11, 2016 8:05 PM