Grouper Developers Forum

[Chris Hyzer <>]

Yes, please open a Jira and a github pull request for the 2.2 branch.  
Thanks, Chris


-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Chris Hyzer
Sent: Wednesday, November 04, 2015 12:43 PM
To: 

Subject: [grouper-dev] FW: Additions/Modifications to the LoaderLdapElUtils 
class



-----Original Message-----
From: Marwan Shaher 
[mailto:]
 
Sent: Wednesday, November 04, 2015 12:19 PM
To: Chris Hyzer
Subject: Fwd: Additions/Modifications to the LoaderLdapElUtils class




-------- Forwarded Message --------
Subject: Additions/Modifications to the LoaderLdapElUtils class
Date: Mon, 2 Nov 2015 18:18:34 -0700
From: Marwan Shaher 
<>
To: 


We are in the process of loading into Grouper, using the LDAP Loader,
OUs and groups in Active Directory that are delegated to and managed by
people/departments outside of the identity management team. Therefore,
these groups do not get a unique identifier, as subjects (users) do,
assigned to them. We are using the "convertDnToSubPath" method for
"Grouper loader LDAP group name expression" and the
"convertAdMemberDnToSpecificValue" method for "Grouper loader LDAP
subject expression". The setup works great and the result is the
accurate representation of the AD OUs and Groups into Grouper stems and
groups, including group nestings.
However, as the name indicates, "convertAdMemberDnToSpecificValue" is
very specific to AD. But the code can be used as a base for another
method that can work in any LDAP environments, both AD and non-AD. Here
are a couple of suggestions, and I apologize in advance for any
pseudo-code if any:

--- Begin: 1st suggestion ------

         // see if the dn is in the space that is managed by grouper
         if (dn.indexOf(baseDn) < 0) {
                 LOG.error("Group member isn't managed in Grouper : " + dn);
                 return dn; // this will cause an error since the
subject cant be found...
         }

- This is not AD specific, but if the check is no longer case-sensitive,
that would be helpful. Something like this maybe?

         // see if the dn is in the space that is managed by grouper
         if (dn.toLowerCase().indexOf(baseDn.toLowerCase()) < 0 ) {
                 ........
                 ........

--- End: 1st suggestion ------

--- Begin: 2nd suggestion ------

         // Send a request to LDAP. Note, in the future we can make this
part of the original filter maybe
         List<String> results = LdapSession.list(String.class, "personLdap",
         "", null, "(&(sAMAccountName=" + cn
+")(objectClass=person))","sAMAccountName");

- This is the part of the code that makes it AD specific, since it
relies on sAMAccountName. Additionally, the assumption here is that
sAMAccountName values are the same as cn values for any given subject.
This should satisfy almost all environments. However, we have some admin
accounts where the sAMAccountName values don't match the cn values, and
they are members of groups. The result is that the LDAP query returns no
matches and these accounts get treated and created in Grouper as groups,
with their containing stems.
There are also hard-coded parameters such as "personLdap" and
"sAMAccountName" which may not work for anyone who changes the default
grouper config files.
A perhaps more general approach is to have the search and session
constructed from variables that get provided as part of the method
argument/parameters:
e.g:

public static String convertAdMemberDnToSpecificValue(String dn, String
baseDn, String grouperBaseStem, boolean idOrIdentifier)

becomes

public static String convertLDAPMemberDnToSpecificValue(String dn,
String baseDn, String grouperBaseStem, String ldapServerId, String
attr1, boolean idOrIdentifier)

then the above call to LDAP to check if the subject is a person or group
could be something like this:

         // Send a request to LDAP. Note, in the future we can make this
part of the original filter maybe
         List<String> results = LdapSession.list(String.class,
ldapServerId, dn, null, "(|(objectClass=person))",attr1);

or to check for group objects,

         // Send a request to LDAP. Note, in the future we can make this
part of the original filter maybe
         List<String> results = LdapSession.list(String.class,
ldapServerId, dn, null,
"(|(objectClass=group)(objectclass=*group*))",attr1);

- Basically, in both cases the search base is set to the object dn,
which I believe is more efficient, especially if the search scope is set
to base. The search filter only checks for the object class type. For
some reason, AD didn't return a match when the object class filter was
only (objectclass=*group*) but did when it was (objectclass=group). The
(objectclass=*group*) should satisfy other group object types like
groupofnames or groupofuniquenames found in non-AD LDAPs, hence
"(|(objectClass=group)(objectclass=*group*))" . attr1 could be "*" but
ideally should be the attribute that contains the unique subject ID.

--- End: 2nd suggestion ------

The rest of the convertAdMemberDnToSpecificValue can remain unchanged.
Further code can be added when either a match for a person or a group is
found. For example, in AD, computer objects inherit from the "Person"
object class, so further code can be added to address this. Or to
exclude computer objects the filter to check for people objects can be
"(&(objectClass=person)(!(objectClass=computer)))"  .

We are  interested in knowing how others have tackled this issue.
Perhaps there are other better ways that we've missed entirely to use
the ldap loader functionality.
On our end, we can add/modify the existing code, recompile and report
back with the findings. To the Grouper developers, we think this would
be beneficial for the rest of the Grouper community. Is this worth
opening a JIRA request to have incorporated into future patch or release?

Thanks!

Marwan Shaher
Identity and Access Management
University of Colorado Boulder