none
Recursive member detection - Unexpected behaviour RRS feed

  • Question

  • Hi everyone,

    so we've asked a similiar question at SF (https://stackoverflow.com/questions/49451627/weird-behaviour-of-ldap-matching-rule-in-chain-1-2-840-113556-1-4-1941) but it seems the questions was too vague and I've the feeling it is better suited for this forum =).

    We try to get all members of e.g. the Backup Operators group in AD with the LDAP_MATCHING_RULE_IN_CHAIN / 1.2.840.113556.1.4.1941 like this

    (memberOf:1.2.840.113556.1.4.1941:=CN=Backup Operators,CN=Builtin,DC=test,DC=env)

    However we recognized that Foreign Security Principal accounts are likely to be missed in the results (e.g. the interesting Anonymous Login). Based on the SF-questions it seems to be related to the handling of linked attributes in AD.

    Our main questions is: Is there any way to form this into a single reliable query without falling back to script/c# recursion?

    Subquestion: The 1941-filter is mentioned all over the place to handle this kind of queries but I don't find any mentions of problems with Foreign Security Principals, I'm wondering why that is?

    We tested on three test AD-environments: 2008 R2, 2012 and 2016.

    Cheers,
    Finn


    Monday, March 26, 2018 7:08 AM

All replies

  • Hi Marcin,

    thank you for your reply. I actually know that post. However it sadly does not answer the question why the Filter Chain is not working and if it is possible at all to make that working.

    The author points several ways out:
    1/2) tokengroups attribute/tokenGroupsGlobalAndUniversal
    If the GC is optional that is indeed no alternative for us. (and on a first glimpse the fields have not been filled)

    3) LDAP filter chain:
    Our current problem

    4) Recursive retrieve
    This will be our fallback if 3 is not working

    5) Store memberOf attribute in local database
    This is also not an option since we require live data.


    Monday, March 26, 2018 12:06 PM
  • Finn,

    Can you explain the reported problem with foreign security principals (FSPs)? It seems to me the LDAP_MATCHING_RULE_IN_CHAIN should not have problems with these objects. They are objects like any other, except the relative distinguished name is a SID. And if the rule did have problems, other methods would as well. The link table used by AD to determine memberOf from the member attributes of groups should be unaffected if some members are FSPs. Am I missing something?


    Richard Mueller - MVP Enterprise Mobility (Identity and Access)

    Monday, March 26, 2018 12:29 PM
  • Hi Richard,

    I can't upload images so far, thus I would refer you to the stackoverflow post here: https://stackoverflow.com/questions/49451627/weird-behaviour-of-ldap-matching-rule-in-chain-1-2-840-113556-1-4-1941

    What we basically did was we've setup 3 ADs 2008 R2, 2012 and 2016 and added the "Anonymous Logon"-group to a built in group and searched with something like this:

    (memberOf:1.2.840.113556.1.4.1941:=CN=Backup Operators,CN=Builtin,DC=test,DC=env)

    What we found was the that the "Authenticated Users"-group correctly showed up in the results but "Anonymous Logon" was missing. We then added every FSP we found and some "normal" dummy user accounts and the behaviour was the same all the time: Every FSP besides "Authenticated Users" has been missing while normal users showed up as excpected.

    The only thing the objects have in common is that only the "Authorized Users" FSP has a memberOf attribute, while the others are only referred via links (memberOf was only visible after enabling Backlinks and seperate LDAP tools did not return a memberOf attribute).
    We asked some friends at another company and they experienced the same behaviour.


    Monday, March 26, 2018 1:15 PM
  • Sorry, I replied before I looked at your Stackoverflow thread.

    First, the Backup Operators group is a Built-in group in the Builtin container. Anonymous Logon. Authenticated Users, and Enterprise Domain Controllers are implicit (or special) groups (or identities). As such, they aren't really groups. They are in the Foreign Security Principals container so that permissions can be applied and they can be added to groups. Being FSPs gives them a SID, a well-known SID.

    I tested in my test domain. I added Anonymous Logon. Authenticated Users, and Enterprise Domain Controllers to the Backup Operators group. But when I queried for members of the Backup Operators group, using the LDAP_MATCHING_RULE_IN_CHAIN, I got all members. I used dsquery * as follows:

    dsquery * -Filter "(memberOf:1.2.840.113556.1.4.1941:=cn=BackUp Operators,cn=Builtin,dc=MyDomain,dc=com)"

    Anonymous Logon is cn=S-1-5-7, Authenticated Users is cn=S-1-5-11, and Enterprise Domain Controllers is cn=S-1-5-9. How did you query?

    Edit: Also, the Member Of tab is correct for all 3 implicit groups in my test domain, showing membership in Backup Operators.


    Richard Mueller - MVP Enterprise Mobility (Identity and Access)


    Monday, March 26, 2018 2:20 PM
  • Ah wrong wording, sorry. So we have a generic class in c# which is utilizing the DirectorySearcher (https://msdn.microsoft.com/en-au/library/system.directoryservices.directorysearcher(v=vs.110).aspx) with pretty much the same query you are using.

    I believe the Member Of tab shows the correct content because it is resolving the link attributes to build a correct memberOf.

    But I'll have a look into how dsquery is working. Hopefully that will lead to something.

    Thank you very much so far =)

    Monday, March 26, 2018 2:38 PM
  • Hi Richard,

    an important addon:

    So our friends are reading with us here and they just gave me a call that they tried your DSQuery with the same effect. But they added an important detail I totally forgot about:

    The query works when done by an admin user. But if we use a normal plain user account (which is indeed able to see the memberOf attributes) the SFPs are missing from the results.

    Are you aware of any thing that may cause that?


    Monday, March 26, 2018 2:49 PM
  • Are you saying Domain Admins get good results, but normal users do not? If so, permissions would be the problem. But in my domain Authenticated Users have Read permissions in the Foreign Security Principals container (looking at the Security tab of ADUC).

    I ran the following PowerShell script using DirectorySearcher, and got the same results, all members showed up (including all 3 implicit identities I added):

    # Use the DirectorySearcher class.
    $Searcher = New-Object System.DirectoryServices.DirectorySearcher
    
    # Specify the base of the query.
    $Base = New-Object System.DirectoryServices.DirectoryEntry "LDAP://dc=MyDomain,dc=com"
    
    # Specify the attribute values to retrieve.
    $Searcher.PropertiesToLoad.Add("distinguishedName") > $Null
    
    $Searcher.SearchRoot = $Base
    $Searcher.PageSize = 200
    # Specify the LDAP syntax filter
    $Searcher.Filter = "(memberOf:1.2.840.113556.1.4.1941:=cn=Backup Operators,cn=Builtin,dc=MyDomain,dc=com)"
    $Searcher.SearchScope = "subtree"
    
    # Query and retrieve the ResultSet.
    $Members = $Searcher.FindAll()
    
    # Display the results.
    ForEach ($Member In $Members)
    {
        $DN = $Member.Properties.Item("distinguishedName")
        "Member: $DN"
    }
    


    Richard Mueller - MVP Enterprise Mobility (Identity and Access)

    Monday, March 26, 2018 3:28 PM
  • Hi Richard,

    that is indeed our problem and we can't figure out why. Since we seem to be able to query the SFPs in the AD as a normal user.

    I've just executed your script as an admin:

    PS C:\Users\Public\Documents> C:\Users\Public\Documents\test.ps1
    Member: CN=S-1-5-11,CN=ForeignSecurityPrincipals,DC=test,DC=env
    Member: CN=S-1-5-17,CN=ForeignSecurityPrincipals,DC=test,DC=env
    Member: CN=S-1-5-9,CN=ForeignSecurityPrincipals,DC=test,DC=env
    Member: CN=Leea Aguilera,OU=dummy,DC=test,DC=env
    Member: CN=S-1-5-7,CN=ForeignSecurityPrincipals,DC=test,DC=en

    And as a normal user

    PS C:\> C:\Users\nuser\Documents\test.ps1
    
    Member: CN=S-1-5-11,CN=ForeignSecurityPrincipals,DC=test,DC=env
    Member: CN=Leea Aguilera,OU=dummy,DC=ranger,DC=DC=test,DC=env

    I also checked the permissions and authenticated users have read permissions on SFPs and have also read on the specific SFPs that are missing when using the filter. I'm totally out of ideas on this one :/

    Monday, March 26, 2018 3:45 PM
  • Must be permissions applied to the individual FSPs, rather than to the FSP container. At least that is my guess.

    Edit: My explanation is not complete. Like other FSP's, the entries for the Implicit Identities in the FSP container are just to allow permissions to be granted and group membership for foreign objects. In this case, the actual objects are in the Configuration partition of the Forest. They are in the "cn=WellKnown Security Principals,cn=Configuration,dc=MyDomain,cn=com" container. In my forest Everyone has read permission on the objects. The objects can be viewed using ADSIEdit. Or you can use dsquery *.

    dsquery * "cn=WellKnown Security Principals,cn=Configuration,dc=MyDomain,dc=com)" -Attr distinguishedName objectSID


    Richard Mueller - MVP Enterprise Mobility (Identity and Access)


    Monday, March 26, 2018 3:50 PM
  • Hi Richard,

    again thank you very much for your patience and help. If I understood you correctly you would guess that the normal user does not have read access to e.g. the "Anonymous Logon" SFP?

    This does not seem to be the case. "Everyone" has read access to the objects.

    I also checked the effective permissions for the user and read is pretty much everywhere, also for things like "read msds-memberOfTransitive". This is also true for the e.g. the "Backup Operators" group.

    I'll try your dsquery command from a normal user shell tomorrow. Maybe that will shed some light

    Monday, March 26, 2018 8:56 PM
  • Ok, so I've ran the dsquery, listing the object names and SIDs, for both admin and user and the results are the same.

    Whatever is causing the filter problem must be one weird setting which for some reason ist set at all our test ADs (which are pretty much default)


    Tuesday, March 27, 2018 6:27 AM
  • Thanks for all the help, we simply have no clue why when the filter is working, thus, in order to get reliable results, we switched to a recursive collection of the group members now.
    Wednesday, March 28, 2018 12:31 PM
  • Finn, I must apologize. I was testing with an account that is a member of Domain Admins. When I tested with a normal user account I got the same results as you reported. The only members of the group Backup Operators the normal user can see is Authenticated Users, plus normal user accounts. The user cannot see any other Special Identities, such as Anonymous Logon or Enterprise Domain Controllers. I also see the same permissions you report. I have searched a great deal online and have found nothing to explain this.

    I also found that the only groups where I can add special identities (like Authenticated Users) are groups in the Builtin folder. Using ADUC, I cannot add any special identities to other groups. Again, I can find no verification or explanation.

    I am still investigating, and will update this thread when I learn more.

    Richard Mueller - MVP Enterprise Mobility (Identity and Access)

    Thursday, March 29, 2018 2:12 AM