LDAP authentication, password is not verified

Hi Team,

We have installed and configured Teamcity 5.1.5 to use LDAP(LDS) for user authentication.
1. Using correct login and password works well.
2. Using correct login and wrong password works well too.....
3. Using correct login but no password, log says "password in not supplied"
4. Using incorrect login and any password, log says "cannot find user"

All the cases are correct except the # 2.
Could you please steer us in the correct direction? Why would Teamcity not check user's password during authentication?

Thanks,
EAS

8 comments

Hello Eas,

I'm not sure I understand the problem. Using correct login and wrong password works well - how exactly? TeamCity doesn't check user's password, it sends the request to LDAP server and handles the response from it.
What does the LDAP log say? What configuration do you use?


---
Maxim

0

Hi Maxim,

We have resolved this issue by commenting out the following:

java.naming.security.authentication=none

Thanks,
EAS

0

Could someone please comment on whether setting java.naming.security.authentication to something other than "none" is the proper way to cause TC to do the actual bind (authentication)?

I have a situation where I'm trying to get LDAP auth to work.   The expert for our company's LDAP server instructed me to use anonymous bind (i.e. set java.naming.security.authentication=none), and now I'm seeing the problem where TC finds the user in LDAP but apparently doesn't do the actual "bind" as using a bad password still lets me gain access to the system.    My understanding is that "java.naming.security.authentication" should only affect the JNDI-related calls and not prevent the actual LDAP bind operation from being done correctly, but obviously something is not working as I would expect :)

BTW... I've run into a different issue as well.   I currently have synchronization disabled (both users and groups), yet TC still requires me to set the java.naming.security.principal property.    This is especially odd since I have also set java.naming.security.authentication=none as well.   Is this a bug?

Thanks in advance for any help!

Phil

0

Hi Phil,

> Could someone please comment on whether setting java.naming.security.authentication to something other than "none" is the proper way to cause TC to do the actual bind (authentication)?
It greatly depends on server settings. The value can be "none", "simple" or "strong", each can be applicable in different environments.

> I have a situation where I'm trying to get LDAP auth to work.   The expert for our company's LDAP server instructed me to use anonymous bind (i.e. set java.naming.security.authentication=none), and now I'm seeing the problem where TC finds the user in LDAP but apparently doesn't do the actual "bind" as using a bad password still lets me gain access to the system.    My understanding is that "java.naming.security.authentication" should only affect the JNDI-related calls and not prevent the actual LDAP bind operation from being done correctly, but obviously something is not working as I would expect :)
Could you please detail why you think there is no actual "bind"? If the search phase succeeds, then the connection was established. Can it be possible that LDAP server doesn't check the password in this case?

> BTW... I've run into a different issue as well.   I currently have synchronization disabled (both users and groups), yet TC still requires me to set the java.naming.security.principal property.    This is especially odd since I have also set java.naming.security.authentication=none as well.   Is this a bug?
I think the idea behind it is that you should explicitly set the principal as it is one of the main ones. In most cases it is mandatory, but in your case you can just leave it empty.



---
Maxim

0

Hi Maxim,
Thanks for the reply.

>Could you please detail why you think there is no actual "bind"? If the  search phase succeeds, then the connection was established. Can it be  possible that LDAP server doesn't check the password in this case?
According to the debug log, it indicates that the bind operation is performed, but it simply accepts the bad password.  Here's a snippet from the debug log:


[2011-09-27 11:33:36,719]  DEBUG -     jetbrains.buildServer.LDAP - Current LDAP properties: { teamcity.options.createUsers=false, teamcity.users.property.email=mail, teamcity.options.users.synchronize=false, java.naming.security.principal=user1, teamcity.users.login.filter=(&(objectclass=person)(mail=$capturedLogin$)), teamcity.users.username=mail, teamcity.users.base=ou=users, teamcity.options.groups.synchronize=false, teamcity.auth.loginFilter=.+, teamcity.users.property.displayName=callupname, java.naming.provider.url=ldaps://xxx.company.com:636/o=company.com, teamcity.options.syncTimeout=3600000, teamcity.options.deleteUsers=false, java.naming.security.authentication=none, } 
[2011-09-27 11:33:40,234]   INFO -     jetbrains.buildServer.LDAP - ------ LdapManager Start ------
[2011-09-27 11:33:40,234]   INFO -     jetbrains.buildServer.LDAP - LDAP synchronization is not active: 'teamcity.options.users.synchronize' is not set or is set to 'false'. 
[2011-09-27 11:33:50,984]  DEBUG -     jetbrains.buildServer.LDAP - ------ Starting login sequence for user-entered login: 'myuser@my.company.com' ------ [2011-09-27 11:33:50,984]  DEBUG -     jetbrains.buildServer.LDAP - Constructed filter '(&(objectclass=person)(mail=myuser@my.company.com))' from teamcity.users.login.filter=(&(objectclass=person)(mail=myuser@my.company.com)) [2011-09-27 11:33:56,531]  DEBUG -     jetbrains.buildServer.LDAP - Searching for entry in LDAP with parameters: base=ou=users, filter=(&(objectclass=person)(mail=myuser@my.company.com)) [2011-09-27 11:33:56,578]  DEBUG -     jetbrains.buildServer.LDAP - Retrieving attribute mail set by teamcity.users.username in LDAP entry uid=120946897,c=us: null:null:{.............} [2011-09-27 11:33:56,578]  DEBUG -     jetbrains.buildServer.LDAP - Found username for 'myuser@my.company.com': myuser@my.company.com [2011-09-27 11:33:56,578]  DEBUG -     jetbrains.buildServer.LDAP - Set uid=120946897,c=us,ou=users,o=company.com as principal [2011-09-27 11:33:56,578]  DEBUG -     jetbrains.buildServer.LDAP - Performing LDAP bind with principal: uid=120946897,c=us,ou=users,o=company.com, context environment: {teamcity.users.base=ou=users, java.naming.security.principal=uid=120946897,c=us,ou=users,o=company.com, teamcity.options.createUsers=false, teamcity.options.users.synchronize=false, teamcity.options.syncTimeout=3600000, teamcity.users.property.email=mail, java.naming.security.authentication=none, java.naming.provider.url=ldaps://xxx.company.com:636/o=company.com, teamcity.options.groups.synchronize=false, teamcity.users.login.filter=(&(objectclass=person)(mail=$capturedLogin$)), java.naming.security.credentials=<hidden>, teamcity.options.deleteUsers=false, java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, teamcity.users.username=mail, teamcity.auth.loginFilter=.+, teamcity.users.property.displayName=callupname} [2011-09-27 11:33:56,766]  DEBUG -     jetbrains.buildServer.LDAP - LDAP bind for principal uid=120946897,c=us,ou=users,o=company.com successful [2011-09-27 11:33:56,766]  DEBUG -     jetbrains.buildServer.LDAP - Reporting successful login of user 'myuser@my.company.com', with old username 'myuser@my.company.com'


So, you can see that on the bind call, the java.naming.security.principal property is set to the (I assume) DN for the entry that was returned in the search, along with the java.naming.security.credentials property (which is most likely set to the password entered by the user at the login window - an incorrect password, btw...).   But yet the bind operation still succeeds.  

Perhaps the LDAP server is reacting to the java.naming.security.authentication=none property being set and bypassing the actual authentication step???

Edit:  I found out more from our LDAP server expert.   The setting of java.naming.security.authentication=none is in fact what is causing the bind to not check the password.  This is essentially an "unauthenticated" bind which is a perfectly valid way to bind against an LDAP server (it might make sense for some applications to bind this way).   So, it looks like I need to use "simple" authentication instead.   But, if I use this, TC requires me to also set the java.naming.security.principal property and I don't want to do that as the initial search step should be done anonymously.    If I set the property to "", then the search step fails with an LDAP error:   javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials]

When I use "simple" authentication, why does TC require me to set the "principal" property, when the description for that property says that it is only used during user and group synchronization (which I am not using currently)?

0

Hi Phil,

You're quite right. TeamCity plugin uses the principal obtained after the search, the password provided and the rest of properties.
After this moment it is up to the server to decide. I suppose it is java.naming.security.authentication=none property in action... yes, you've answered it yourself =)

As to anonymous access. To my knowledge allowing LDAP search without authorization isn't a recommended practice, and TeamCity plugin wasn't designed for this use case.
You can see that login process needs to perform the search so here principal is also used.
If the requirement is absolutely mandatory for your organization, I can build an ad-hoc version of the plugin. But it seems setting a real principal for the search operation (e.g. your own account) is easier.
Will be glad to hear the opinion of real LDAP expert =)


--
Maxim

0

Hi Maxim,
I've cobbled together an ad-hoc plugin of my own which removes the requirement to set the "principal" property when the "simple" authentication type is used.    I now have the LDAP authentication working such that the initial search step is done with "simple" authentication but no principal or credentials (i.e. anonymously).     I think a possible improvement to the TC ldap plugin would be to also remove the requirement that "principal" be set.   Perhaps it should be up to the TC administrator to either set it or not, depending on the behavior and requirements of the LDAP server that is being used?

Thanks for all your help!

Phil

0

Thanks Phil,

Probably you're right, this option would be an improvement.


---
Maxim

0

Please sign in to leave a comment.