Re: LDAP Help

[Saša Živkov]

On Mon, Feb 25, 2013 at 6:43 PM, Brian S <brian...@gmail.com> wrote:

I am trying to set up gerrit to use an existing active directory server.

To prove i can query the server I ran the following command. Which returns information related to SearchUser.

ldapsearch -x -H ldap://server.company.corp  -D BindUser -W -b "cn=Users,dc=company,dc=corp" sAMAccountName=SearchUser

However when I run gerrit with the following config settings I see "[2013-02-25 12:40:48,819] ERROR com.google.gerrit.server.auth.ldap.LdapRealm : Cannot query LDAP to autenticate user javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 525, vece]" in the error logs.

[auth]

        type = LDAP

[ldap]

        server = ldap://server.company.corp

        username = BindUser

        password = password 

        accountBase = cn=users,dc=company,dc=corp

        referral=follow

        accountPattern = (sAMAccountName=${username))

 

Why did you set the accountPattern?

Gerrit has a default setting for the Active Directory which should

work and which is different than this one. See ldap.accountPattern at [1].

I would remove it and try with the default value.

Saša

[1] https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#_a_id_ldap_a_section_ldap

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
 
---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Brandon Casey]

On Mon, Feb 25, 2013 at 9:43 AM, Brian S <brian...@gmail.com> wrote:
> I am trying to set up gerrit to use an existing active directory server.
>
> To prove i can query the server I ran the following command. Which returns
> information related to SearchUser.
>
> ldapsearch -x -H ldap://server.company.corp -D BindUser -W -b
> "cn=Users,dc=company,dc=corp" sAMAccountName=SearchUser
>
> However when I run gerrit with the following config settings I see
> "[2013-02-25 12:40:48,819] ERROR
> com.google.gerrit.server.auth.ldap.LdapRealm : Cannot query LDAP to
> autenticate user javax.naming.AuthenticationException: [LDAP: error code 49
> - 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error,
> data 525, vece]" in the error logs.
>
> [auth]
> type = LDAP
> [ldap]
> server = ldap://server.company.corp
> username = BindUser
> password = password
> accountBase = cn=users,dc=company,dc=corp
> referral=follow
> accountPattern = (sAMAccountName=${username))

The right-hand side of ${username} above should be a curly brace. You
have an extra closing parenthesis instead.

-Brandon

[Brian S]

Brandon I updated my config file and received the same results

[auth]

        type = LDAP

[ldap]

        server = ldap://server.company.corp

        username = BindUser

        password = password

        accountBase = cn=users,dc=company,dc=corp

        referral = follow

        accountPattern = (sAMAccountName=${username})

javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 525, vece]

        at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3087)

        at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3033)

        at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2835)

        at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2749)

        at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316)

        at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193)

        at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211)

        at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154)

        at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84)

        at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)

        at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)

        at javax.naming.InitialContext.init(InitialContext.java:242)

        at javax.naming.InitialContext.<init>(InitialContext.java:216)

        at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101)

        at com.google.gerrit.server.auth.ldap.Helper.open(Helper.java:107)

        at com.google.gerrit.server.auth.ldap.LdapRealm.authenticate(LdapRealm.java:198)

[Brandon Casey]

IIUC, error code 525 means "user not found". I suspect this is
pertaining to ldap.username. i.e. what you have listed above as
"BindUser". I assume that's just a placeholder for the real username,
but I'd double check the value you have there.

One thing to think about is that the config file parsing consumes one
level of backslashes. So if the name of the account is
"domain\username", you need to use two backslashes like
"domain\\username".

e.g.

[ldap]
username = domain\\username

But, I am not an expert on this code.

-Brandon

[Brandon Casey]

On Mon, Feb 25, 2013 at 9:43 AM, Brian S <brian...@gmail.com> wrote:

> However when I run gerrit with the following config settings I see
> "[2013-02-25 12:40:48,819] ERROR
> com.google.gerrit.server.auth.ldap.LdapRealm : Cannot query LDAP to
> autenticate user javax.naming.AuthenticationException: [LDAP: error code 49
> - 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error,
> data 525, vece]" in the error logs.

Plus, a piece of low-hanging fruit in
gerrit-server/src/main/java/com/google/gerrit/server/auth/ldap/LdapRealm.java
can be seen in the error message above.

"authenticate" is misspelled as "autenticate".

If I remember to do so, I'll submit a patch for this when I get home.
Or someone else can feel free to beat me to it. Not sure yet whether
this sort of thing is going to be possible for me to do at $dayjob. :(

-Brandon

[Brian S]

You are correct.  However, BindUser has domain\BindUser in my config file.

For what it's worth if I remove the domain prefix I get error 52e (Invalid Credentials). This makes me believe that the username is working in through but the query is failing.

[Brandon Casey]

On Mon, Feb 25, 2013 at 3:29 PM, Brian S <brian...@gmail.com> wrote:
> On Monday, February 25, 2013 5:24:18 PM UTC-5, Brandon Casey wrote:

>> One thing to think about is that the config file parsing consumes one
>> level of backslashes. So if the name of the account is
>> "domain\username", you need to use two backslashes like
>> "domain\\username".
>>
>> e.g.
>>
>> [ldap]
>> username = domain\\username
>>

> BindUser has domain\BindUser in my config file.

So, are you saying your gerrit.config file looks like this:

[ldap]
username = domain\BindUser

or like this:

[ldap]
username = domain\\BindUser

?

-Brandon

[Brian S]

My gerrit.config file looks like this

   [ldap] 
          username = domain/BindUser 

If I use

   [ldap] 

          username = domain\BindUser 

Restarting gerrit fails wirh

fatal: bad config file line 11 in /home/gerrit2/gerrit_testsite/etc/gerrit.config

and if I use

   [ldap] 

          username = domain\\BindUser 

I get error 52e as follows:

[2013-02-25 19:08:27,510] ERROR com.google.gerrit.server.auth.ldap.LdapRealm : Cannot query LDAP to autenticate user

javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece]

 

[Brandon Casey]

On Mon, Feb 25, 2013 at 4:16 PM, Brian S <brian...@gmail.com> wrote:
>
>
> On Monday, February 25, 2013 6:42:40 PM UTC-5, Brandon Casey wrote:
>>
>> On Mon, Feb 25, 2013 at 3:29 PM, Brian S <brian...@gmail.com> wrote:
>> > On Monday, February 25, 2013 5:24:18 PM UTC-5, Brandon Casey wrote:
>>
>> >> One thing to think about is that the config file parsing consumes one
>> >> level of backslashes. So if the name of the account is
>> >> "domain\username", you need to use two backslashes like
>> >> "domain\\username".
>> >>
>> >> e.g.
>> >>
>> >> [ldap]
>> >> username = domain\\username
>> >>
>>
>> > BindUser has domain\BindUser in my config file.
>>
>> So, are you saying your gerrit.config file looks like this:
>>
>> [ldap]
>> username = domain\BindUser
>>
>> or like this:
>>
>> [ldap]
>> username = domain\\BindUser
>>
>> ?
>>
>> -Brandon
>
>
> My gerrit.config file looks like this

<snip>

> and if I use
> [ldap]
> username = domain\\BindUser

This one is correct.

> I get error 52e as follows:
>
> [2013-02-25 19:08:27,510] ERROR com.google.gerrit.server.auth.ldap.LdapRealm
> : Cannot query LDAP to autenticate user
> javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308:
> LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e,
> vece]

I would again suspect that this is related to the username/password
used to bind to the LDAP server, not to the user that is
authenticating through the web ui. I'd double-check the value
assigned to ldap.password in your gerrit.config or secure.config.

Not necessarily related to the above (*yet*), but your account base
looks funny to me:

cn=Users,dc=company,dc=corp

I've more commonly seen that look like:

ou=Users,dc=company,dc=corp

So, additionally, you may want to check that your accountBase setting
has the same elements that exist on the dn (or distinguishedName) line
returned by your ldapsearch query.

-Brandon

[Brian S]

> I would again suspect that this is related to the username/password
> used to bind to the LDAP server, not to the user that is
> authenticating through the web ui. I'd double-check the value
> assigned to ldap.password in your gerrit.config or secure.config.

I did not have the password set in the secure.config file because I
assumed that it was unnecessary when defined in the gerrit.config
file. I added the following to the secure.config file and have the
same results.

[ldap]
password = MyPassword

> Not necessarily related to the above (*yet*), but your account base
> looks funny to me:
>
> cn=Users,dc=company,dc=corp
>
> I've more commonly seen that look like:
>
> ou=Users,dc=company,dc=corp
>
> So, additionally, you may want to check that your accountBase setting
> has the same elements that exist on the dn (or distinguishedName) line
> returned by your ldapsearch query.

here are the dn results of the search

ldapsearch -x -H ldap://server.compnay.corp -D BindUser -W -b
"cn=Users,dc=company,dc=corp" sAMAccountName=SearchUser

dn: CN=SearchUser,CN=Users,DC=company,DC=corp

[Brandon Casey]

On Mon, Feb 25, 2013 at 6:08 PM, Brian S <brian...@gmail.com> wrote:
>> I would again suspect that this is related to the username/password
>> used to bind to the LDAP server, not to the user that is
>> authenticating through the web ui. I'd double-check the value
>> assigned to ldap.password in your gerrit.config or secure.config.
>
> I did not have the password set in the secure.config file because I
> assumed that it was unnecessary when defined in the gerrit.config
> file.

That is correct. I mentioned both more as a reminder that there were
two files where settings could live.

> I added the following to the secure.config file and have the
> same results.
>
> [ldap]
> password = MyPassword
>
>
>> Not necessarily related to the above (*yet*), but your account base
>> looks funny to me:
>>
>> cn=Users,dc=company,dc=corp
>>
>> I've more commonly seen that look like:
>>
>> ou=Users,dc=company,dc=corp
>>
>> So, additionally, you may want to check that your accountBase setting
>> has the same elements that exist on the dn (or distinguishedName) line
>> returned by your ldapsearch query.
>
> here are the dn results of the search
>
> ldapsearch -x -H ldap://server.compnay.corp -D BindUser -W -b
> "cn=Users,dc=company,dc=corp" sAMAccountName=SearchUser
>
> dn: CN=SearchUser,CN=Users,DC=company,DC=corp

Based on the results of your ldapsearch, your accountBase looks correct to me.

Sorry, but I'm out of ideas. Like I said before, I'm not an expert in
this area, so hopefully someone more knowledgeable than me will chime
in.

-Brandon

[Saša Živkov]

Gerrit will perform 2 ldap requests in order to authenticate a user.

The FIRST request bind using the configured ldap.username (and ldap.password) 

uses the ldap.accountPattern as the query. The purpose of this request is

to find the full DN of the real user that needs to be authenticated.

To test this request you need an ldapsearch like:

$ ldapsearch -x -H ldap.server -D ldap.user -W -b ldap.accountBase ldap.accountPattern DN

In case ldap.accountPattern is not configured in your gerrit.config then the default

query for an Active Directory is used: (&(objectClass=user)(sAMAccountName=${username}))

$ ldapsearch -x -H ldap://server.company.corp:389 -D BindUser -W -b cn=Users,dc=company,dc=corp (&(objectClass=user)(sAMAccountName=${username})) DN

Replace ${username} with the username exactly as the real user would type into the login dialog.

When this query returns it should contain the DN of the real user, something like:

dn: CN=...,OU=...,DC=...,DC=...,DC=...

The SECOND query uses that (full) DN to authenticate this user:

$ ldapsearch -x -H ldap://server.company.corp:389 -D copy-full-dn-here -b cn=Users,dc=company,dc=corp -W

When prompted enter the password of the real user this time.

Do both of these queries work for you?

dn: CN=SearchUser,CN=Users,DC=company,DC=corp

[Brian S]

Thanks for your reply. Both replies do work.

ldapsearch -x -H ldap://server.company.corp -D BindUser -W -b
"cn=Users,dc=company,dc=corp" sAMAccountName=username DN

returns

# extended LDIF
#
# LDAPv3
# base <cn=Users,dc=company,dc=corp> with scope subtree
# filter: sAMAccountName=username
# requesting: DN
#

# username, Users, company.corp
dn: CN=username,CN=Users,DC=company,DC=corp

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

and

ldapsearch -x -H ldap://server.toyon.corp:389 -D
CN=username,CN=Users,DC=toyon,DC=corp -b cn=Users,dc=company,dc=corp
-W

returns a long list of active directory contents.

One thing I noticed was that I had to include the domain in
ldap.username for the gerrit.config but not at the command line. Is
that to be expected?

[Saša Živkov]

Yes. The service account may not necessarily have the same account base as

the real user accounts.

Is your ldap authentication issue now solved?

[Brian S]

No. I still receive the error "LDAP authentication unavailable." when
trying to login using username and the error_log reads.

[2013-02-26 10:07:01,015] ERROR

com.google.gerrit.server.auth.ldap.LdapRealm : Cannot query LDAP to
autenticate user
javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308:
LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data

525, vece]
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3087)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3033)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2835)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2749)
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211)
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154)
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
at javax.naming.InitialContext.init(InitialContext.java:242)
at javax.naming.InitialContext.<init>(InitialContext.java:216)
at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101)
at com.google.gerrit.server.auth.ldap.Helper.open(Helper.java:107)
at com.google.gerrit.server.auth.ldap.LdapRealm.authenticate(LdapRealm.java:198)

at com.google.gerrit.server.account.AccountManager.authenticate(AccountManager.java:113)
at com.google.gerrit.httpd.auth.ldap.UserPassAuthServiceImpl.authenticate(UserPassAuthServiceImpl.java:70)

[Saša Živkov]

And you have an accountBase entry in gerrit.config that has the same value

as the value of the -b option from the second ldapsearch?

If no, add it.

If yes, then I am out of options and can only recommend to debug Gerrit

and see if you can figure out something. In this case set a break point

in the LdapAuthBackend class on this line:

          helper.authenticate(m.getDN(), req.getPassword());

m.getDN() will give you the full DN of that user. The 'helper' contains

the rest of the ldap relevant data.

[Brian S]

Yup as shown below. I am at a loss. I will download the source and try
to debug when I have time

[auth]
type = LDAP
[ldap]
server = ldap://server.company.corp

username = domain/BindUser
password = MyPassword

accountBase = cn=users,dc=company,dc=corp
referral = follow
accountPattern = (sAMAccountName=${username})

[Mihai Rusu]

On Tue, Feb 26, 2013 at 03:02:36PM -0500, Brian S wrote:
> Yup as shown below. I am at a loss. I will download the source and try
> to debug when I have time
>
> [auth]
> type = LDAP
> [ldap]
> server = ldap://server.company.corp
> username = domain/BindUser
> password = MyPassword
> accountBase = cn=users,dc=company,dc=corp
> referral = follow
> accountPattern = (sAMAccountName=${username})

Sysadmin like suggestion: if the LDAP connection is not encrypted, could
you tcpdump the traffic sent by ldapsearch and by Gerrit to your LDAP
server? See what the difference is... Alternatively there are ways to
use strace to get the full data sent/received with write/read
(send/recv). Or if you have access to the LDAP server logs, any way to
get the client sent query in the log?

> --
> --
> To unsubscribe, email repo-discuss...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
Mihai Rusu

[Brian S]

Sorry for the delayed response.

I took another look at this today and the answer ended up being pretty
simple. I need SslVerify set to false.

Thanks for all the help.

[valenti...@gmx.de]

Why would that have made any difference? The docs state that this only applies to ldaps:// servers.