[Building Sakai] Looking for debugging tips -- Sakai vs. AD
Peter Crowther
peter.crowther at melandra.com
Sat Aug 8 06:55:01 PDT 2009
Even in a live environment, that KB article applies per-domain controller
and hence could be set only on the domain controller to which you're
connecting; you could choose a relatively lightly-loaded domain controller
as your target.
Alternatively, Wireshark has a pretty good LDAP dissector, though it would
only give you the error that was sent over-the-wire rather than anything
internal to AD.
- Peter
2009/8/8 Berg, A.M. <A.M.Berg at uva.nl>
> Hi,
>
> If you have a test AD environment without to much traffic how about bumping
> up its own log level via http://support.microsoft.com/kb/314980 and seeing
> what error the specific GC returns from the LDAP query?
>
> Alan Berg
>
> Senior Developer / Quality Assurance
> Group Education and Research Services
> Central Computer Services
> University of Amsterdam
>
>
>
>
> -----Original Message-----
> From: sakai-dev-bounces at collab.sakaiproject.org on behalf of
> will at serensoft.com
> Sent: Sat 8/8/2009 0:03
> To: Kevin P. Foote
> Cc: Sakai-Dev Developers
> Subject: Re: [Building Sakai] Looking for debugging tips -- Sakai vs. AD
>
> Thanks, Kevin -- that's very helpful. (I wonder what other log.config
> items can be set? hmm!)
>
> Logging in as !admin and then trying 'become user' it doesn't matter
> whether we have a legit username or not, the results in catalina.out
> are the same:
>
> 2009-08-07 16:42:07,421 DEBUG http-8080-Processor25
> edu.amc.sakai.user.JLDAPDirectoryProvider - getUserByEid(): [eid =
> flathead]
> 2009-08-07 16:42:07,421 DEBUG http-8080-Processor25
> edu.amc.sakai.user.JLDAPDirectoryProvider - getCachedUserEntry(): [eid
> = flathead]
> 2009-08-07 16:42:07,421 DEBUG http-8080-Processor25
> edu.amc.sakai.user.JLDAPDirectoryProvider - getCachedUserEntry():
> cache access [found entry = false][entry expired = false]
> 2009-08-07 16:42:07,421 DEBUG http-8080-Processor25
> edu.amc.sakai.user.JLDAPDirectoryProvider -
> searchDirectoryForSingleEntry(): [filter =
> sAMAccountName=flathead][reusing conn = false]
> 2009-08-07 16:42:07,421 DEBUG http-8080-Processor25
> edu.amc.sakai.user.JLDAPDirectoryProvider - searchDirectory(): [filter
> = sAMAccountName=flathead][reusing conn = false]
> 2009-08-07 16:42:07,427 DEBUG http-8080-Processor25
> edu.amc.sakai.user.JLDAPDirectoryProvider - searchDirectory(): [baseDN
> = OU=unit,DC=school,DC=edu][filter = sAMAccountName=flathead][return
> attribs = [sAMAccountName, givenName, sn, mail]][max results = 1]
> 2009-08-07 16:42:07,428 DEBUG http-8080-Processor25
> edu.amc.sakai.user.JLDAPDirectoryProvider - searchDirectory():
> returning connection to connection manager
> 2009-08-07 16:42:07,429 WARN http-8080-Processor25
> org.sakaiproject.tool.su.SuTool - [SuTool] Exception: User account
> does not exist: flathead
>
> Sure enough, user "flathead" doesn't exist -- but "rli" does:
>
> 2009-08-07 17:00:30,378 DEBUG http-8080-Processor22
> edu.amc.sakai.user.JLDAPDirectoryProvider - getUserByEid(): [eid =
> rli]
> 2009-08-07 17:00:30,378 DEBUG http-8080-Processor22
> edu.amc.sakai.user.JLDAPDirectoryProvider - getCachedUserEntry(): [eid
> = rli]
> 2009-08-07 17:00:30,378 DEBUG http-8080-Processor22
> edu.amc.sakai.user.JLDAPDirectoryProvider - getCachedUserEntry():
> cache access [found entry = false][entry expired = false]
> 2009-08-07 17:00:30,378 DEBUG http-8080-Processor22
> edu.amc.sakai.user.JLDAPDirectoryProvider -
> searchDirectoryForSingleEntry(): [filter = sAMAccountName=rli][reusing
> conn = false]
> 2009-08-07 17:00:30,378 DEBUG http-8080-Processor22
> edu.amc.sakai.user.JLDAPDirectoryProvider - searchDirectory(): [filter
> = sAMAccountName=rli][reusing conn = false]
> 2009-08-07 17:00:30,384 DEBUG http-8080-Processor22
> edu.amc.sakai.user.JLDAPDirectoryProvider - searchDirectory(): [baseDN
> = OU=unit,DC=school,DC=edu][filter = sAMAccountName=rli][return
> attribs = [sAMAccountName, givenName, sn, mail]][max results = 1]
> 2009-08-07 17:00:30,385 DEBUG http-8080-Processor22
> edu.amc.sakai.user.JLDAPDirectoryProvider - searchDirectory():
> returning connection to connection manager
> 2009-08-07 17:00:30,386 WARN http-8080-Processor22
> org.sakaiproject.tool.su.SuTool - [SuTool] Exception: User account
> does not exist: rli
>
> The attributeMappings (gleaned from ldapsearch) are
> <entry key="login"><value>sAMAccountName</value></entry>
> <entry key="firstName"><value>givenName</value></entry>
> <entry key="lastName"><value>sn</value></entry>
> <entry key="email"><value>mail</value></entry>
> <!--
> <entry key="groupMembership"><value>groupMembership</value></entry>
> -->
>
> Guessing here -- could groupMembership be causing trouble here?
> There's no groupMembership attribute from LDAP.
>
> Other pointers are very welcome!
>
>
>
> On Fri, Aug 7, 2009 at 3:33 PM, Kevin P. Foote<kpfoote at iup.edu> wrote:
> >
> > Couple things.. don't know if you've tried these ..
> >
> > make sure you set your logging to DEBUG for ldap .. if you have not
> > already.
> >
> > log.config.count=1
> > log.config.1 = DEBUG.edu.amc.sakai.user.JLDAPDirectoryProvider
> >
> > And watch the ldap server event log on the AD side you should see a few
> logins
> > for your 'search' users.
> >
> > ------
> > thanks
> > kevin.foote
> >
> > On Fri, 7 Aug 2009, will at serensoft.com wrote:
> >
> > -> Short version:
> > ->
> > -> We have Sakai (running on Debian) trying to authenticate against
> > -> Active Directory (on windows of course) but are having no success. Are
> > -> there linux/windows tools/tricks you folks would recommend to check
> > -> for/confirm Sakai/LDAP traffic?
> > ->
> > ->
> > -> Long version:
> > ->
> > -> Sakai authenticates internal-only users just fine. So the database
> > -> (MySQL 5.0.51a) is fine, the OS (Debian 5.0.2) is fine, Sakai (2.6.x
> > -> r65601) is fine.
> > ->
> > -> We can connect to the Active Directory LDAP server via ldapsearch on
> > -> the command line:
> > -> $ ldapsearch -W -x -H ldap://ldap.school.edu \
> > -> -D "cn=ldapuser,ou=special accounts,ou=unit,dc=school,dc=edu" \
> > -> -b "ou=unit,dc=school,dc=edu" \
> > -> "(attr=value)"
> > ->
> > -> And once we enter the ldapuser password, we get our results back just
> > -> as expected. (Without the password we get empty, so authentication
> > -> from the command-line is confirmed.)
> > ->
> > -> So -- we translated those specs into the XML of jldap-beans.xml and
> > -> recompiled (mvn clean install sakai:deploy) and...
> > ->
> > -> No catalina.out messages, no stack traces, no runs no hits no errors.
> > -> :( Sakai still authenticates internal users just fine, but it's as if
> > -> there's no external LDAP at all. (We conscientiously mis-configured a
> > -> few variables in jldap-beans.xml earlier to make sure we would see
> > -> something in the logs, and yep, stack traces abounded. Then we put the
> > -> variables 'right' and... no info at all!)
> > ->
> > -> We're looking for some (hopefully LDAP-savvy) tools or tricks to see
> > -> if/how Sakai is actually trying to communicate with the AD server,
> > -> either on the Linux end, Windows end, or both. Network sniffers? LDAP
> > -> forwarding proxy?
> > ->
> > -> Ideas?
> > ->
> > -> --
> > -> will trillich
> > -> "Tis the set of the sails / And not the gales / That tells the way we
> > -> go." -- Ella Wheeler Wilcox
> > -> _______________________________________________
> > -> sakai-dev mailing list
> > -> sakai-dev at collab.sakaiproject.org
> > -> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> > ->
> > -> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
> > ->
> >
>
>
>
> --
> will trillich
> "Tis the set of the sails / And not the gales / That tells the way we
> go." -- Ella Wheeler Wilcox
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20090808/a103af9b/attachment.html
More information about the sakai-dev
mailing list