Group memberships and nested groups

The group memberships only appear to return the first level of groups that the user is a member of. So in an environment where a user is a member of a department group, which is part of a larger or separate security group, the user is not listed as a member of that other group. Ideally there should be a recursive check to get the full group membership listing.

Not against this, as I can easily see the usefulness of this. My hesitancy is how much time will be spent doing LDAP lookups as chasing down all of the nested memberships could be rather processor and time consuming.

Agreed. I've literally, just this last fortnight, implemented the same functionality in an AppleScript app I use in my environment for mounting network drives. The time taken to do the extra lookups just about tripled the total time taken for the app to run. Having said that, for an app like NoMAD that runs all the time, this could be something that runs periodically. The group memberships are already cached in the plist, which my app doesn't currently do, and groups don't tend to change drastically or that often. It could be implemented as a periodical update with an admin trigger and/or menu option to force reload.

Do you mind sharing how you're looking up the extended groups? This would be easy enough to put in a as a pref key so that it wouldn't be the default behavior.

Hi Joel.

No problem. Below is a bit of AppleScript code that I used. Note: this is a slightly edited version of what I have deployed - apologies but I don't have access to the latest version as I write this.

I'm sure it's not the best or most efficient way to do this, but will give a basic workflow. Probably good to note also that the sanitation of all of the variables is handled outside this block of code, so it would be good to probably add in some further sanitation of the fields that are passed in.

##recursiveGroupCheck
## Input: 
## = groups - An initial list of the users groups. These will be what is returned from a basic search for the memberOf field of a user
## = actualMemberGroups - This will be the array that stores the full recursively populated list of groups. Depending on what language you implement this in, make sure it's passed by reference.
## = server - LDAP(S) server URI
## = base - LDAP search base path
##NOTE: The following three fields are included in case username/password are required for each LDAPsearch call - needed in some cases depending on security permissions structure on the OU's
## = domain - search users AD Domain suffix
## = user - search users AD username (sAMAccountName)
## = pass - search users password

## Output:
## - At the end of the procedure, "actualMemberGroups" should contain an array of the distinguishedName's of all of the users groups found recursively

to recursiveGroupCheck(groups, actualMemberGroups, server, user, domain, pass, base)
    ## Now, recurse over the groups to capture any nested group memberships
    repeat with theCurrentGroup in groups
        if (actualMemberGroups does not contain (theCurrentGroup as string)) then
            set end of actualMemberGroups to (theCurrentGroup as string)
        end if

        set currentGroupsMembershipText to do shell script "ldapsearch -LLL -H " & server & " -b " & quoted form of base & " -o ldif-wrap=no -x -D " & user & domain & " -w " & quoted form of pass & " '(&(objectclass=group)(distinguishedName=" & theCurrentGroup & "))' memberof | grep \"memberOf: \" | cut -c 11-"
        set currentGroupsMembership to paragraphs of currentGroupsMembershipText
        if (count of currentGroupsMembership) is not 0 then
            recursiveGroupCheck(currentGroupsMembership, actualMemberGroups, server, user, domain, pass, base)
        end if
    end repeat
    return memberGroups
end recursiveGroupCheck

I think we can get this done in one line. Although not sure how far back in AD this syntax works. I think this appeared in 2k3, so any remaining domains that are at a lower functional level would be out.

ldapsearch -LLL -N -Q -H ldap://dc1.nomad.test -b "dc=nomad,dc=test" "(member:1.2.840.113556.1.4.1941:=CN=Andrew Eng,OU=Demo Users,DC=nomad,DC=test)" | grep name:

assigned to @Mactroll

changed milestone to %V. 1.1

I've confirmed in my testing that given our functional AD level (2008) enabling the new recursive group preference incorrectly lists the logged in user in no groups whatsoever.

We're at 2008 level too. I had to remove the -N flag to get that to work, but other than that it seems to work OK. It did also return mailnickname for some mail-enabled groups, so the grep may need to be altered a bit for that, but otherwise worked OK for me.