LDAP User Mapping in Build 8909

I am having an issue with mapping LDAP users in Build 8909.  My teamcity-ldap.log shows the correct number of users being returned from the LDAP search, but the attributes are not mapped per the config properties.  Any help or suggestions are greatly appreciated.

teamcity-ldap.log ::
========================================
[2009-04-22 21:26:29,225]  DEBUG - r.serverSide.ldap.LdapSettings - Initial LDAP properties: { java.naming.referral=follow, teamcity.options.synchronize=true, teamcity.groups.attribute.member=developeruid, teamcity.auth.loginFilter=.*, teamcity.groups.base=ou=Groups,dc=incursiontech,dc=com, java.naming.security.authentication=simple, teamcity.users.loginFilter=.*, teamcity.groups.filter=(objectClass=incursionproject), java.naming.security.principal=, teamcity.users.property.plugin=notificator:jabber:jabber-account=xmppUsername, teamcity.users.username=uid, teamcity.users.property.displayName=displayname, teamcity.users.property.mail=mail, teamcity.groups.attrubute.name=projectname, java.naming.provider.url=ldap://ldap.internal.incursiontech.com:389, teamcity.users.filter=(objectClass=incursionBuildConcerned), teamcity.users.base=ou=people,dc=incursiontech,dc=com, teamcity.auth.formatDN=uid=$login$,ou=people,dc=incursiontech,dc=com, }
[2009-04-22 21:26:29,254]   INFO - er.serverSide.ldap.LdapManager - ------ LdapManager Start ------
[2009-04-22 21:26:30,258]  DEBUG - er.serverSide.ldap.LdapManager - BaseEnvironmentProperties: {java.naming.security.authentication=simple, java.naming.referral=follow}
[2009-04-22 21:26:30,258]  DEBUG - er.serverSide.ldap.LdapManager - Custom properties: {mail=mail, plugin=notificator:jabber:jabber-account=xmppUsername}
[2009-04-22 21:26:30,264]   INFO - er.serverSide.ldap.LdapManager - LDAP properties loaded
[2009-04-22 21:26:30,267]   INFO - er.serverSide.ldap.LdapManager - LDAP groups mapping loaded
[2009-04-22 21:26:30,269]   INFO - er.serverSide.ldap.LdapManager - ------ Sync with LDAP users started ------
[2009-04-22 21:26:30,274]  DEBUG - er.serverSide.ldap.LdapManager - Searching users in 'ou=people,dc=incursiontech,dc=com' DN with filter'(objectClass=incursionBuildConcerned)'
[2009-04-22 21:26:30,321]   WARN - er.serverSide.ldap.LdapManager - No distinguishedName attribute
[2009-04-22 21:26:30,321]   WARN - er.serverSide.ldap.LdapManager - No distinguishedName attribute
[2009-04-22 21:26:30,322]   WARN - er.serverSide.ldap.LdapManager - No distinguishedName attribute
[2009-04-22 21:26:30,323]   WARN - er.serverSide.ldap.LdapManager - No distinguishedName attribute
[2009-04-22 21:26:30,323]   WARN - er.serverSide.ldap.LdapManager - No distinguishedName attribute
[2009-04-22 21:26:30,324]   WARN - er.serverSide.ldap.LdapManager - No distinguishedName attribute

[2009-04-22 21:26:30,324]  DEBUG - er.serverSide.ldap.LdapManager - Fetched users: [
  [user:username=,dn='',displayName=null,email=null,customProperties={}]
  [user:username=,dn='',displayName=null,email=null,customProperties={}]
  [user:username=,dn='',displayName=null,email=null,customProperties={}]
  [user:username=,dn='',displayName=null,email=null,customProperties={}]
  [user:username=,dn='',displayName=null,email=null,customProperties={}]
  [user:username=,dn='',displayName=null,email=null,customProperties={}]
]
[2009-04-22 21:26:30,326]   INFO - er.serverSide.ldap.LdapManager - Sync with LDAP users done
[2009-04-22 21:26:30,328]  DEBUG - er.serverSide.ldap.LdapManager - Groups mapping is empty, or not configured. User groups are not synchronized


ldap-config.properties ::
===================================
# Set to "true" to enable the synchronization.
teamcity.options.synchronize=true

# The credentials: name/password of user which will retrieve information from LDAP.
# The user must have a read access to all LDAP entries under 'teamcity.users.base' and
# 'teamcity.groups.base' (see below).
# These values are not used in login, only in synchronization.
java.naming.security.principal=
java.naming.security.credentials=

# The user base DN. Users are retrieved only from the subtree denoted by this DN.
# May be empty (in this case the root DN specified above is used).
teamcity.users.base=ou=people,dc=incursiontech,dc=com

# The user search filter. (external link for more details: [http://msdn.microsoft.com/en-us/library/aa746475(VS.85).aspx])
teamcity.users.filter=(objectClass=incursionBuildConcerned)
teamcity.users.loginFilter=.*
# The LDAP attributes that correspond to username, display name (full name) and e-mail.
teamcity.users.username=uid
teamcity.users.property.displayName=displayname
teamcity.users.property.mail=mail

# The custom user property. All custom properties must be prefixed with "teamcity.users.property.",
# the suffix "plugin:notificator:jabber:jabber-account" is TeamCity user property,
# "jabberAccount" is the name of LDAP attribute.
# More about TeamCity user properties here: [tbd].
teamcity.users.property.plugin:notificator:jabber:jabber-account=xmppUsername

# Similar settings for groups retrieval.
teamcity.groups.base=ou=Groups,dc=incursiontech,dc=com
teamcity.groups.filter=(objectClass=incursionproject)
teamcity.groups.attrubute.name=projectname

# The attribute that indicates the member of the group.

18 comments
Comment actions Permalink

Hi Matt,

The most probable reason for these errors: the principal that you've used to get the data from LDAP doesn't have permissions to read all attributes. I don't know if you've intentionally set empty principal and credentials, or just hidden the private data. Anyway please make sure that the principal has the access to the users and groups in LDAP. Also check the attribute names (just in case).

From the provided log it looks like the search has been performed successfully (which means that search properties are most likely correct), but the returned entries didn't have attributes at all, even 'distinguishedName'. Either there are none of them, or you just can't read it.

Other tool that can help you to browse your LDAP: http://www.jxplorer.org/
Also I suggest you to try our release version: http://www.jetbrains.com/teamcity/download/index.html


Please, let us know if you have more problems.

0
Comment actions Permalink

Hi,

I have exactly the same problem. I'm using the release version.

I've tested accessing the directory with JXplorer and true enough, there isn't any "distinguishedName" specified. However, I do have access to all the fields that I need. Why does TeamCity fail when this specific field doesn't exist?

- Markus

0
Comment actions Permalink

Markus,

The attribute that denotes the distinguished name is mandatory to bind users and groups entries. Seems like it is named differently than 'distinguishedName' (probably just 'dn').
We'll add an option for that name in the next version.

If you need this feature is urgent for you, we can send you an updated plugin jar.

0
Comment actions Permalink

The attribute that denotes the distinguished name is mandatory to bind users and groups entries. Seems like it is named differently than 'distinguishedName' (probably just 'dn').
We'll add an option for that name in the next version.


If you need this feature is urgent for you, we can send you an updated plugin jar.

Yes please ! We've got the same problem "jetbrains.buildServer.LDAP - No distinguishedName attribute". We don't have the "distinguishedName" attribute in our LDAP, we just have "dn" attribute (OpenLDAP).

Thanks,

David Wery

--
David Wery
CTO @ Manex
Rue Wagner 127, BE-4100 Boncelles, Belgium
Office : +32 4 330 37 33 - Fax : +32 4 338 06 06
Email : david.wery@manex.biz
Web : http://www.manex.biz


0
Comment actions Permalink

This appears to be my issue as well.  For Fedora Directory Server (OpenLDAP) the distinguishedName attribute is mapped as dn.  "distinguishedName" is defined as the description for the dn attribute.

If you have updated jar, can you please send it?

Thanks,
m.

0
Comment actions Permalink

Could you send me the updated jar.
We also use openldap.

0
Comment actions Permalink

Could you send me the updated jar.
We also use openldap.

0
Comment actions Permalink

Hi,

Please try an updated ldap-login.jar (see an attach to http://jetbrains.net/tracker/issue2/TW-8092). You should also set the 'teamcity.property.distinguishedName' property in your config file.

Thanks.

0
Comment actions Permalink

Maxim,

Okay, some more information.  With OpenLDAP (Fedora Directory Server), the dn, entrydn, distinguishedName is not being returned through a named attribute on a search.  It's in the result, but it is not tagged with an attribute name.  I installed the new jar, set the teamcity.property.distinguishedName=dn in ldap-config.properties and ended up with the same result.  I did some network traces to see what was going back and forth.  I have attached a tcpdump trace for the ldap search request from TeamCity as well as one from ldapsearch.  I have also included the ldapsearch output, which shows the dn attribute.  However, note that in the search results in both cases, dn is not specified as an attribute.

NOTE:  If I set teamcity.property.distinguishedName to an attribute that is returned in the results, i.e. uid, the users are populated.

Is the dn required and used for anything, or is using uid as the dn field acceptable?


Thanks,
m.



Attachment(s):
ldapsearch.out
ldap.tcpdump
ldapsearch.tcpdump
0
Comment actions Permalink

NOTE:  If I set teamcity.property.distinguishedName to an attribute that is returned in the results, i.e. uid, the users are populated.

Same for me, setting teamcity.property.distinguishedName=uid seems to work fine and I don't see yet any side effects...

0
Comment actions Permalink

Matt,

Thank you for additional information, we'll try to analyze it ASAP.

The DN is used:
- in logging and UI messages to show the administrator which LDAP entry corresponds to a particular TeamCity user. Unfortunately we can't use some kind of UID for this in general case, because not all LDAP servers support it. But you can, if it works for you fine.
- in LDAP user - group binding. Usually the members of LDAP groups are stored, i.e. referred to, via DN. If don't need automatic user group synchronization, you don't have to worry about it. Otherwise, there could be some problems in TC to understand which users are included in which group.

Regards, Maxim

0
Comment actions Permalink

I got the same issue on Debian Linux Lenny, using OpenLDAP 2.4.11. Note, that this issue also applies to group synchronization, as the groups don't seem to return a DN either on OpenLDAP.

0
Comment actions Permalink

Just checking in on this ...

Maxim, just to be sure, it would acceptable in the interim to map a new attribute that mirros the dn and use the distinguishedName property to refer to the new attribute.  TeamCity should not see the difference???


THanks.

0
Comment actions Permalink

Matt,


That's right, there would be no difference for TeamCity.
I'm trying to figure out a way to obtain the DN, if it is not accessible directly: to make a mirror attribute (accessible) is one option; probably there is an ad-hoc query for specific LDAP servers to get it. Please let me know if you'll have more ideas.

Thanks

0
Comment actions Permalink

It works fine.  I added a teamcityDN attribute to my users and to  my groups.  Set the distinguishedName property in TeamCity config, and after working through some string comparison issue swith spaces in the DN string, TeamCity is mapping my groups and users accordingly.

Thanks.

0
Comment actions Permalink

Matt,

Please try an updated version of ldap-login.jar. Thanks to Stefan Hansel, we're now able to get the correct DN if it is not present among search result attributes.
No additional changes are needed in config file (except for 'teamcity.property.distinguishedName' if you had set 'uid' value or similar - just comment this property).
The fix will be available in 4.5.2, I'm attaching just ldap-login.jar for now.

Thanks, Maxim



Attachment(s):
ldap-login.jar
0
Comment actions Permalink

Downloaded and installed the jar, made the config update to comment out teamcity.property.distinguishedName and restarted Tomcat.  The Users synced fine, but the groups did not.  Every group I have defined in ldap-mapping.xml failed to be found in LDAP.

Restored the previous jar, and uncommented the property and both users and groups sync fine.  All I have done to make this work is add a new objectClass and attribute, teamcityDN, to each user and group who is to have access to TeamCity.  I then set teamcity.property.distinguishedName=teamcityDN.  In the directory, teamcityDN is an exact copy of the entryDN.


m.



Attachment(s):
teamcity-ldap.log
0
Comment actions Permalink

Thanks Matt.

Glad users and groups are synced in your case, I wanted to check that everything works fine without additional work.
I'll try to figure out what's the problem with groups now.

Maxim

0

Please sign in to leave a comment.