grouper-users - [grouper-users] RE: Grouper Loader LDAP with AD
Subject: Grouper Users - Open Discussion List
List archive
- From: Chris Hyzer <>
- To: Gagné Sébastien <>
- Cc: "" <>
- Subject: [grouper-users] RE: Grouper Loader LDAP with AD
- Date: Fri, 11 May 2012 18:08:20 +0000
- Accept-language: en-US
(moving back to list) The terminology is confusing. If you can generate the group id path (UI term) in the EL, that is actually the API “name”, or the g:gsa “identifier” So… if you are doing a loader job by identifier, and you return the group id path, then it should work (like you said, don’t specify the source)… if you need to convert to UUID in the EL, then try this: Group group = GrouperDAOFactory.getFactory().getGroup().findByName(idPath, false, null) ; You don’t need a grouper session for that method (it’s a backdoor). Then if you get null, the group isn’t there. If it is there, then the uuid is group.getId()… Does it work? J Thanks, Chris Ps. the GrouperSourceAdapter search by identifier is here:
public Map<String, Subject> getSubjectsByIdentifiers(final
Collection<String> identifiers) { Set<Group> groups =
null;
groups = (Set<Group>)GrouperSession.callbackGrouperSession( GrouperSourceAdapter.internal_getSessionOrRootForSubjectFinder(),
new GrouperSessionHandler() {
public Object callback(GrouperSession grouperSession)
throws GrouperSessionException {
return GrouperDAOFactory.getFactory().getGroup().findByNamesSecure(identifiers,
null, GrouperSourceAdapter.this.typeOfGroups()); } }); From: Gagné Sébastien [mailto:]
Hello Chris, I did the EL class and it works well by itself, BUT it’s still not finding the Group in g:gsa. ID Path is correct and I tried to specify no sources or g:gsa (to force the check) with no luck. I dug in the source and I think that the find subject for g:gsa only accepts UUIDS :
In : edu.internet2.middleware.grouper.GrouperSourceAdapter.java
groups = (Set<Group>)GrouperSession.callbackGrouperSession( GrouperSourceAdapter.internal_getSessionOrRootForSubjectFinder(),
new GrouperSessionHandler() {
public Object callback(GrouperSession grouperSession)
throws GrouperSessionException {
return GrouperDAOFactory.getFactory().getGroup().findByUuidsSecure(ids,
null, GrouperSourceAdapter.this.typeOfGroups());
} }); Is there an easy way to get Group UUIDS based on Group ID or Group ID Path ? Going with Group ID would be awesome since I would have to convert the DN to an ID path. Maybe this would require more global change in Grouper (I understand that IDs might not be unique, but ID Paths are) ? Thanks for your help De : Chris Hyzer []
> Thanks again, but how frequently should the loader run ? I was thinking about once a day so 5 hours might be too long Whatever you want to do…
> > How will the loader react if there are new members in Grouper’s group that aren’t in AD when the loader runs (lets say there was a problem with the PSP) ? > - Will the loader delete the new members to reflect what is in AD Yes. The loader assumes that group is the system of record. It should only be edited by the loader. If you want ad hoc additions, then add that system of record group to another “overall” group, and add more
members to that group. Or you could do a restrict list too with composites. Know what I mean? > - Will the loader add the missing members from the AD group in the grouper group without removing them > - Will the loader add the new members in AD (doubtful)
> > I was thinking of scheduling the PSP full sync before the loader, but it might be somewhat redundant. Sure, not sure which parts of AD are in the loader and which are in the PSP… up to you chris From: Gagné Sébastien
Thanks again, but how frequently should the loader run ? I was thinking about once a day so 5 hours might be too long How will the loader react if there are new members in Grouper’s group that aren’t in AD when the loader runs (lets say there was a problem with the PSP) ? -
Will the loader delete the new members to reflect what is in AD -
Will the loader add the missing members from the AD group in the grouper group without removing them -
Will the loader add the new members in AD (doubtful)
I was thinking of scheduling the PSP full sync before the loader, but it might be somewhat redundant. De : Chris Hyzer []
Btw, you should definitely cache this. Maybe a permanent or an expirable cache?
J
/** cache if cn is a person (false is group), for 5 hours */
private
static ExpirableCache<String, Boolean>
cacheIsPerson =
new ExpirableCache<String, Boolean>(60*5);
/** * convert a user dn to a user, and a group dn to a group *
@param dn *
@return the dn */
public
static String convertAdDnToSpecificValue(String dn) {
String cn = LoaderLdapElUtils.convertDnToSpecificValue(dn);
Boolean isPerson =
cacheIsPerson.get(cn);
if
(isPerson == null) {
//do ldap call, figure it out
...
//put back in cache
cacheIsPerson.put(cn, isPerson); }
if
(isPerson) {
return cn; }
//is group
//e.g. umontreal.grouper.ad.group.prefix = umontreal:adgroups: String grouperGroupPrefix = GrouperLoaderConfig.getPropertyString("umontreal.grouper.ad.group.prefix",
true);
return
grouperGroupPrefix + cn; }
From: Gagné Sébastien
Ok, thanks I’ll try that also.
About LdapSession : Do I need to get an object or can directly use “LdapSession.list” (static method) ? Will it manage everything ? Or should I use a callback or helper somewhere ? The “list” function seems to be returning a list of attributes so I’ll try to get the objectClass from there. What I find strange here is that this object seems to be made for the Loader, but is outside the Loader directory, it might confuse some people Anyway I got the source code so I think I’ll be able to get something decent. I’ll check back with you later Thanks a lot. De : Chris Hyzer []
You can do an EL that does a directory call… LdapSession might help you do a lookup by object class, if you want to bind as the user, you need to not use the same pool of directory connections I think… if you
need help let me know Chris From: Gagné Sébastien
Wow thanks a lot, I figure that with that option I have to leave the Source ID empty for the loader to try the AD source then the g :gsa source (which strangely doesn’t have any search or filter
configuration but I guess it’s managed in grouper). Unfortunately, groups and users are both under People (I know… you don’t have to tell me it’s wrong, we’re trying to fix this) so the Suffix condition might not work. I’ll have to check with our
experts here, there might be some string we could check for if where only managing a subset of groups, but I might not be foolproof (or any-user proof). I will give it a try to make it work if we want (or can) to go that way, it will eventually be useful. What would be best is if we could check against LDAP with loginID and if it fails check in Grouper Groups with a GroupID, but it might not be possible to configure that part of the process.
Another option would be to get the objectClass of the member DN and then transform the ID accordingly, but that would require a new connexion and search in LDAP. Is there some utilities in Grouper
to help with that ? Could I just create my own EL class that does the insert instead of the loader’s standard way ? Would it be practical ?
Thanks De : Chris Hyzer []
I think it can do it, but we have to adapt the convertDbToSpecificValue part… Ie. A person DN is CN=gagns,OU=People,DC=dev,DC=umontreal,DC=ca A group DN is (Im making this up): CN=someGroup,OU=Groups,DC=dev,DC=umontreal,DC=ca Then we need a simple Java method that we will add to the LDAP subject _expression_ which: Looks at the DB, and if it is in People, then return the CN value, if it is Groups (or wherever), then we need the group name in Grouper: umontreal:adgroups:someGroup or whatever the translation is… 1.
Edit the grouper-loader.properties: (edit this existing entry) loader.ldap.el.classes = ca.umontreal.grouper.UmontrealLoaderElUtils (add these [and configure to your env] ) umontreal.ad.group.suffix =,OU=Groups,DC=dev,DC=umontreal,DC=ca umontreal.grouper.ad.group.prefix = umontreal:adgroups: 2.
Add the attached jar to your lib dir 3.
Change your attribute: LDAP subject _expression_ ${umontrealLoaderElUtils.convertAdDnToSpecificValue(subjectId)} I didn’t test it… see if it helps…
J Chris Btw, the source of that jar is one file.. look at the logic, will it work or do you need something different? /** *
@author mchyzer * $Id$ */ package ca.umontreal.grouper; import org.apache.commons.lang.StringUtils; import edu.internet2.middleware.grouper.app.loader.GrouperLoaderConfig; import edu.internet2.middleware.grouper.app.loader.ldap.LoaderLdapElUtils; import edu.internet2.middleware.grouper.util.GrouperUtil; /** * */ public
class UmontrealLoaderElUtils {
/** * convert a user dn to a user, and a group dn to a group *
@param dn *
@return the dn */
public
static String convertAdDnToSpecificValue(String dn) {
//e.g. ,OU=Groups,DC=dev,DC=umontreal,DC=ca String adGroupSuffix = GrouperLoaderConfig.getPropertyString("umontreal.ad.group.suffix",
true);
//not sure why this would happen
if (dn ==
null) {
return dn; }
if
(dn.toLowerCase().endsWith(adGroupSuffix.toLowerCase())) { String cn = dn.substring(0, dn.length()-adGroupSuffix.length());
if
(StringUtils.countMatches(cn, "=") != 1) {
throw
new RuntimeException("Why
is there not 1 equals in this CN??? '" + cn +
"'"); }
//this should be CN=groupName, convert to groupName cn = GrouperUtil.prefixOrSuffix(cn,
"=",
false);
//e.g. umontreal.grouper.ad.group.prefix = umontreal:adgroups: String grouperGroupPrefix = GrouperLoaderConfig.getPropertyString("umontreal.grouper.ad.group.prefix",
true);
return
grouperGroupPrefix + cn; }
//not a group
return LoaderLdapElUtils.convertDnToSpecificValue(dn); }
} From:
On Behalf Of Gagné Sébastien Hello, I have a new question : Does the Loader LDAP support group membership in a group (i.e GroupA is a member of GroupB in LDAP) It seems the standard Grouper Loader can do this : “Penn is using it in production
to load membership for groups, and for groups of groups” When I tried it, the loader couldn’t find GroupA in the subject source (since I filter using objectClass=person). I removed this part of the filter, it added the group, but not as a Grouper group
but as an AD subject. So I put the filter back like it was with the objectClass=person and removed the source ID thinking the loader could search the Group Source Adapter (g:gsa), but it didn’t work. Here are my current configuration, I tried to keep it as plain as possible :
In the Group’s member attribute contains both Group DNs and Member DNs with no
Thank you again. De :
[]
De la part de Chris Hyzer This is what TomB asked at the member meeting and I said, “Uh, I think it does that”
J I think you need: grouperLoaderLdapSubjectExpression To the value:
That should work for subjectId, or subjectIdentifier, or subjectIdOrIdentifier. See if that works. If not can you let me know all the loader job attributes and values you have set? Thanks, Chris From:
On Behalf Of Gagné Sébastien Hello, I’m trying to configure the Grouper Loader LDAP to work with our AD, but I’m stuck with a problem. Basically what we would like is to retrieve all groups in AD and load them in Grouper. I’ve set the loader type to LDAP_GROUP_LIST with a filter
(objectClass=group)
(dev AD has 5-6 groups). This properly returns all groups and they are added in Grouper. The problem is with the members : it sees them in the AD group, but cannot find them in the source, which is the same AD. I’ve set the subject attribute name to
member and my source ID is
ldap (I’m also using the PSP) The group’s member attribute is a multivalued set of “Distinguished Name”
(e.g. CN=gagns,OU=People,DC=dev,DC=umontreal,DC=ca). This is a problem since my subject ID is the sAMAccountName (i.e. gagns). What I did, is use the search type
subjectIdentifier and modified the filter in sources.xml to use the full DN : <searchType>searchSubjectByIdentifier</searchType> <param> <param-name>filter</param-name> <param-value> (&(distinguishedName=%TERM%)(objectclass=person)) </param-value> </param> Unfortunately it doesn’t work and I don’t know why. When manually running the loader job (i.e. loaderRunOneJob(group) in gsh.sh), in the logs I see that it find the members of the groups, but that the every search for
one of the subject fails : 2012-05-09 09:06:24,001: [main] ERROR GrouperLoaderResultset$Row.getSubject(1112) - - Problem with subjectIdentifier: CN=gagns,OU=People,DC=dev,DC=umontreal,DC=ca,
subjectSourceId: ldap, in jobName: LDAP_GROUP_LIST__etc:confLDAPLoader__e7b97262558b477fab09c0b48f98ed1c edu.internet2.middleware.subject.SubjectNotFoundException: No results: searchSubjectByIdentifier filter:(&(distinguishedName=%TERM%)(objectclass=person)) searchValue:
CN=gagns,OU=People,DC=dev,DC=umontreal,DC=ca at edu.internet2.middleware.subject.provider.LdapSourceAdapter.getLdapUnique(LdapSourceAdapter.java:655) at edu.internet2.middleware.subject.provider.LdapSourceAdapter.getSubjectByIdentifier(LdapSourceAdapter.java:336) at edu.internet2.middleware.grouper.subj.SourcesXmlResolver.findByIdentifier(SourcesXmlResolver.java:403) [contd...] I tried an ldapsearch and manually changing the %TERM% to the DN and it works fine : ldapsearch -h husky.devsim.umontreal.ca -D "<grouper service account DN>" -w <pass> -b "OU=People,DC=dev,DC=umontreal,DC=ca" "(&(distinguishedName=CN=gagns,OU=People,DC=dev,DC=umontreal,DC=ca)(objectclass=person))" CN=gagns,OU=People,DC=devsim,DC=umontreal,DC=ca objectClass=top objectClass=person objectClass=organizationalPerson objectClass=user cn=gagns [continued...] Anyone has an idea what might be happening here ? Anyone did a successful AD configuration ? Thank you What I find weird is if I use subjectId (not subjectIdentifier), I get slightly different results in the exceptions. JobName is different and membership count also. 2012-05-09 10:22:49,165: [main] ERROR GrouperLoaderResultset$Row.getSubject(1112) - - Problem with subjectId: CN=gagns,OU=People,DC=devsim,DC=umontreal,DC=ca,
subjectSourceId: ldap, in jobName:
groups:UdeM:fromAD1 edu.internet2.middleware.subject.SubjectNotFoundException: No results: searchSubject filter:(&(sAMAccountName=%TERM%)(objectclass=person))
searchValue: CN=gagns,OU=People,DC=devsim,DC=umontreal,DC=ca with subjectIdentifier : loader ran successfully, inserted 0 memberships, deleted 0 memberships, total
membership count: 0 with subjectId : loader ran successfully, inserted 0 memberships, deleted 0 memberships, total
membership count: 40 Sébastien Gagné, |
Analyste en informatique 514-343-6111 x33844
|
Université de Montréal,
|
Pavillon Roger-Gaudry, local X-100-11 |
- RE: [grouper-users] RE: Grouper Loader LDAP with AD, Gagné Sébastien, 05/10/2012
- RE: [grouper-users] RE: Grouper Loader LDAP with AD, Pål Axelsson, 05/10/2012
- RE: [grouper-users] RE: Grouper Loader LDAP with AD, Gagné Sébastien, 05/10/2012
- RE: [grouper-users] RE: Grouper Loader LDAP with AD, Chris Hyzer, 05/10/2012
- RE: [grouper-users] RE: Grouper Loader LDAP with AD, Gagné Sébastien, 05/10/2012
- <Possible follow-up(s)>
- RE: [grouper-users] RE: Grouper Loader LDAP with AD, Gagné Sébastien, 05/10/2012
- [grouper-users] RE: Grouper Loader LDAP with AD, Chris Hyzer, 05/10/2012
- [grouper-users] RE: Grouper Loader LDAP with AD, Gagné Sébastien, 05/10/2012
- [grouper-users] RE: Grouper Loader LDAP with AD, Chris Hyzer, 05/10/2012
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- [grouper-users] RE: Grouper Loader LDAP with AD, Chris Hyzer, 05/11/2012
- [grouper-users] RE: Grouper Loader LDAP with AD, Gagné Sébastien, 05/14/2012
- [grouper-users] RE: Grouper Loader LDAP with AD, Chris Hyzer, 05/14/2012
- [grouper-users] A poll: Service name, Paul Donahue, 05/14/2012
- RE: [grouper-users] A poll: Service name, Chris Hyzer, 05/14/2012
- Re: [grouper-users] A poll: Service name, Niels van Dijk, 05/14/2012
- RE: [grouper-users] A poll: Service name, Gagné Sébastien, 05/15/2012
- Re: [grouper-users] A poll: Service name, Jim Fox, 05/15/2012
- RE: [grouper-users] A poll: Service name, Richard James, 05/15/2012
- Message not available
- Message not available
- [grouper-users] RE: Grouper Loader LDAP with AD, Chris Hyzer, 05/10/2012
- [grouper-users] RE: Grouper Loader LDAP with AD, Gagné Sébastien, 05/10/2012
- [grouper-users] RE: Grouper Loader LDAP with AD, Chris Hyzer, 05/10/2012
- RE: [grouper-users] RE: Grouper Loader LDAP with AD, Pål Axelsson, 05/10/2012
Archive powered by MHonArc 2.6.16.