LDAP Configuration

[Zac Harvey]

I am trying to set up Jenkins to authenticate using our AD domain over
LDAP. I have been working with the Systems Group trying to configure
all of the settings under Manage Jenkins >> Configure System >> Access
Control. We finally have all the settings configured correctly (at
least, in the eyes of the Systems people), and we are not getting any
red validation errors in the GUI. However I still cannot login via
LDAP/AD. Below is the console output. Any nudges in the right
direction are enormously appreciated!

Console Output:
Dec 14, 2011 1:47:21 PM
hudson.security.AuthenticationProcessingFilter2
onUnsuccessfulAuthentication
INFO: Login attempt failed
org.acegisecurity.AuthenticationServiceException: LdapCallback;[LDAP:
error code 32 - 0000208D: NameErr: DSID-031001E4, problem 2001
(NO_OBJECT), data 0, best match of:
'DC=MYPROJECT,DC=COM'
]; nested exception is javax.naming.NameNotFoundException: [LDAP:
error code 32 - 0000208D: NameErr: DSID-031001E4, problem 2001
(NO_OBJECT), data 0, best match of:
'DC=MYPROJECT,DC=COM'
]; remaining name 'dc=myproject,dc=com'; nested exception is
org.acegisecurity.ldap.LdapDataAccessException: LdapCallback;[LDAP:
error code 32 - 0000208D: NameErr: DSID-031001E4, problem 2001
(NO_OBJECT), data 0, best match of:
'DC=MYPROJECT,DC=COM'
]; nested exception is javax.naming.NameNotFoundException: [LDAP:
error code 32 - 0000208D: NameErr: DSID-031001E4, problem 2001
(NO_OBJECT), data 0, best match of:
'DC=MYPROJECT,DC=COM'
]; remaining name 'dc=myproject,dc=com'
at
org.acegisecurity.providers.ldap.LdapAuthenticationProvider.retrieveUser(LdapAuthenticationProvider.java:
238)
at
org.acegisecurity.providers.dao.AbstractUserDetailsAuthenticationProvider.authenticate(AbstractUserDetailsAuthenticationProvider.java:
119)
at
org.acegisecurity.providers.ProviderManager.doAuthentication(ProviderManager.java:
195)
at
org.acegisecurity.AbstractAuthenticationManager.authenticate(AbstractAuthenticationManager.java:
45)
at
org.acegisecurity.ui.webapp.AuthenticationProcessingFilter.attemptAuthentication(AuthenticationProcessingFilter.java:
71)
at
org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:
252)
at hudson.security.ChainedServletFilter
$1.doFilter(ChainedServletFilter.java:87)
at
org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:
173)
at hudson.security.ChainedServletFilter
$1.doFilter(ChainedServletFilter.java:87)
at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:61)
at hudson.security.ChainedServletFilter
$1.doFilter(ChainedServletFilter.java:87)
at
org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:
249)
at
hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:
66)
at hudson.security.ChainedServletFilter
$1.doFilter(ChainedServletFilter.java:87)
at
hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:
76)
at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
243)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
210)
at
hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:
81)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
243)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
210)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:
224)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:
185)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:
472)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
151)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:
100)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
929)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
405)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:
269)
at org.apache.coyote.AbstractProtocol
$AbstractConnectionHandler.process(AbstractProtocol.java:515)
at org.apache.tomcat.util.net.JIoEndpoint
$SocketProcessor.run(JIoEndpoint.java:302)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.acegisecurity.ldap.LdapDataAccessException:
LdapCallback;[LDAP: error code 32 - 0000208D: NameErr: DSID-031001E4,
problem 2001 (NO_OBJECT), data 0, best match of:
'DC=MYPROJECT,DC=COM'
]; nested exception is javax.naming.NameNotFoundException: [LDAP:
error code 32 - 0000208D: NameErr: DSID-031001E4, problem 2001
(NO_OBJECT), data 0, best match of:
'DC=MYPROJECT,DC=COM'
]; remaining name 'dc=myproject,dc=com'
at org.acegisecurity.ldap.LdapTemplate
$LdapExceptionTranslator.translate(LdapTemplate.java:295)
at org.acegisecurity.ldap.LdapTemplate.execute(LdapTemplate.java:128)
at
org.acegisecurity.ldap.LdapTemplate.searchForSingleEntry(LdapTemplate.java:
246)
at
org.acegisecurity.ldap.search.FilterBasedLdapUserSearch.searchForUser(FilterBasedLdapUserSearch.java:
119)
at
org.acegisecurity.providers.ldap.authenticator.BindAuthenticator.authenticate(BindAuthenticator.java:
71)
at
org.acegisecurity.providers.ldap.authenticator.BindAuthenticator2.authenticate(BindAuthenticator2.java:
49)
at
org.acegisecurity.providers.ldap.LdapAuthenticationProvider.retrieveUser(LdapAuthenticationProvider.java:
233)
... 34 more
Caused by: javax.naming.NameNotFoundException: [LDAP: error code 32 -
0000208D: NameErr: DSID-031001E4, problem 2001 (NO_OBJECT), data 0,
best match of:
'DC=MYPROJECT,DC=COM'
]; remaining name 'dc=myproject,dc=com'
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3066)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2987)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2794)
at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1826)
at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1749)
at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1766)
at
com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:
394)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:
376)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:
358)
at
javax.naming.directory.InitialDirContext.search(InitialDirContext.java:
267)
at org.acegisecurity.ldap.LdapTemplate
$3.doInDirContext(LdapTemplate.java:249)
at org.acegisecurity.ldap.LdapTemplate.execute(LdapTemplate.java:126)
... 39 more

[Harvey, Zachary]

There was an error in my last email. I spoke about prefixing AD usernames with "user/", but meant "usa/".

[Jeff Payne]

I've pasted below what I came up with (LDAP/AD setup) - note that this is significantly different that what I've used for other tools, so I'm not surprised that your Systems guys suggested something different that what ends up working.

Another thing to consider - if you are running Jenkins on a Windows server that is part of your domain, the Active Directory plugin works MUCH better.  Select it and it just works - no configuration needed.

Jeff

====

I seem to have wheedled out the problem by randomly reconfiguring the LDAP interface - the magic combination seemed to be:

Do specify a root DN:
OU=Example,DC=domain-ex,DC=tld-ex

Specify the User and Group search bases without fully qualifying (without the above)
OU=Users
OU=Groups

Our user search filter is based on sAMAccountName:
sAMAccountName={0}

And the Manager DN was not specified as a DN - just provide the login ID & password.

Other variations of the above (providing the full or different subsets of the DN for different fields above, providing the full DN for the Manager DN, etc) either resulted in what I reported before, or getting the word "ERROR" (not an icon) in the authorization matrix.  Not sure what aspect of this fixed the problem, just passing along what worked for me.

Now it seems to be working for users & groups, but my groups show up in the authorization matrix with the error icon instead of the group icon (users are fine).  Still permissions do seem to be handled properly based on these groups.  Anyone else see this issue?

[Ricardo García Fernández]

Hi Zac !

I was dealing with the same issue: authentication against LDAP/AD and your answer was the right one.

Also, I fixed the group filter and configured group properties using this filter:

Group search filter: (& (cn={0}) (objectclass=group) )

Group Search Base: your OU groups separated with comas (,).

Thus I can configure groups and users from general configuration to Job one.

Thanks for your solution it was very helpful

[Stephen Connolly]

Can we just ask one question:

WHY ARE YOU USING THE LDAP PLUGIN AND NOT THE ACTIVE DIRECTORY PLUGIN?

People seem to keep on wanting to inflict pain on themselves and go with the more complex LDAP plugin rather than the much much easier to use Active Directory plugin.

If there is some feature missing that causes you to decide to plump for the LDAP plugin it would be good to know so that the feature could be added to the Active Directory plugin.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[teilo]

The LDAP plugin is (at least it was before we unceremoniously ditched it) MUCH MUCH quicker to authenticate users than the AD one when you have a lovely large tree of domains…

 Now I will prefix this with I am not an AD expert but…

 http://technet.microsoft.com/en-us/library/cc728188(v=ws.10).aspx

 "The global catalog is a distributed data repository that contains a searchable, partial representation of every object in every domain in a multidomain Active Directory Domain Services (AD DS) forest. The global catalog is stored on domain controllers that have been designated as global catalog servers and is distributed through multimaster replication. Searches that are directed to the global catalog are faster because they do not involve referrals to different domain controllers."

 I don’t notice any delay using the global catalogue and LDAP – using AD we often saw multi second (into the tens) delays in authentication – the above may or may not be the reason for it.

 /James

[Stephen Connolly]

James, would you be amenable to firing up a test jenkins and giving some comparative timings?

At least in Unix mode they should be pretty much identical in performance, though theAD plugin should be much easier to configure

[teilo]

Hi Stephen,

I will see what I can do, but can't promise a quick turnaround (I need to get a fair amount done before the JUC next week)

This may have something to do with the location of the main servers for the domain.

e.g. 

nslookup -q=SRV _ldap._tcp.mydomain.com

returns servers that are not located in the same site as Jenkins (indeed some are on the other side of the globe and all have the same weight!).

The AD plugin does multiple queries as it recursively checks for group membership (a change that I did - so you can slap me with a wet fish for that). This was to support if you are a member of group Y and group Y is a member of Jenkins_Admins then you will correctly be identified as a user with ROLE_jenkins_admin.

pings to the server in the other side of the world are 72ms...

pings to my local global catalogue server - well that's <1 ms :-)

now you can imagine if each query took just a round trip time that 100 queries (lot of groups in large companies.) that that would be 100 * 72ms which is about 7 seconds, compared to a not noticeable 0.1s.

(NB: slight correction below).

/James

On Tuesday, 15 October 2013 15:32:14 UTC+1, Stephen Connolly wrote:

James, would you be amenable to firing up a test jenkins and giving some comparative timings?

At least in Unix mode they should be pretty much identical in performance, though theAD plugin should be much easier to configure

On 15 October 2013 14:47, teilo <teilo+...@teilo.net> wrote:

The LDAP plugin is (at least it was when we unceremoniously ditched the AD plugin) MUCH MUCH quicker to authenticate users than the AD one when you have a lovely large tree of domains…