Subject: Grouper Users - Open Discussion List
RE: [grouper-users] Update on my AD PSP issue, some progress (New Update)
- From: "Bryan E. Wooten" <>
- To: Shilen Patel <>, "" <>
- Subject: RE: [grouper-users] Update on my AD PSP issue, some progress (New Update)
- Date: Fri, 21 Jun 2013 14:27:10 +0000
- Accept-language: en-US
- Authentication-results: sfpop-ironport04.merit.edu; dkim=neutral (message not signed) header.i=none
Ok, so I configured my sources.xml and ldap.properties to use AD instead of LDAP (I left all the psp*.xml files alone) and am able to provision a group to AD.
Checking the wireshark trace I see that the cn equals the group name. This confirms my speculation below.
So for some reason when the subject source is ldap the cn gets set to uofu:bryan22:groupname but when the subject source is AD the cn is set to just groupname.
If someone can point me to the code that sets cn when the ldap addrequest is made I’ll try and debug the cause. This will be a show stopper for me if I can’t find a work around. If I can’t get the PSP to provision groups to AD with an LDAP source I’ll probably be force to write my own change log consumer or something.
I am sure I will run into similar issues when I try and add members to a group. But I’ll save that hurdle for another day.
With the help of a colleague we noticed that the cn was passed as uofu:bryan22:group1 while the dn was cn=group1,ou=bryan22,ou=uofu,ou=groups,ou=grouper,dc=testad,dc=utah,dc=edu.
We think the cn value is the problem. I am going to reconfigure back to my known good AD provisioning (with AD subject source) and capture a group add request and do a comparison of the cn value passed.
I'll do the test tomorrow and get back with an update.
From the logs, what does the <addRequest> look like?
- RE: [grouper-users] Update on my AD PSP issue, some progress (New Update), Bryan E. Wooten, 06/21/2013
Archive powered by MHonArc 2.6.16.