# Keystone LDAP Integration with Active Directory, cannot use cn as logon id

I've successfully setup keystone authentication with Active Directory, using these attributes in keystone.conf:

user_id_attribute = cn
user_name_attribute = cn


However, in my (and most) Active Directories, the cn is not used as the logon ID (often, the cn is the user's display name, moreover the cn is not necessarily unique within the domain), rather the attribute samAccountName is used as the user's logon ID. The trouble I have is that when I change the user_id_attribute to samAccountName, I get the error:

Unable to communicate with identity service: {"error": {"message": "Invalid user / password", "code": 401, "title": "Not Authorized"}}. (HTTP 401)


If I look at the keystone logs, I see that an attempt to bind my username is made, but the format of the distinguishedName is invalid:

2013-08-07 10:05:55    DEBUG [keystone.common.ldap.core] LDAP bind: dn=samAccountName=brian,cn=Users,dc=myActiveDirectory,dc=net


This would appear to be a code problem with the LDAP identity provider. I would expect the code to search for a user with the given samAccountName, and return the valid DN and use it in the bind. Is this a known issue, or perhaps I am doing something wrong?

edit retag close merge delete

Sort by » oldest newest most voted

I have found the bug in the keystone/common/ldap/core.py module. The problem is with the id_to_dn_string function. The function incorrectly assembles the object's distinguishedName if any attribute other than cn is used for the user_id_attribute. I can work around the issue by commenting out the lines that call this function within the associated function id_to_dn as shown below:

def _id_to_dn_string(self, id):
return '%s=%s,%s' % (self.id_attr,
ldap.dn.escape_dn_chars(str(id)),
self.tree_dn)

def _id_to_dn(self, id):
#if self.LDAP_SCOPE == ldap.SCOPE_ONELEVEL:
# return self._id_to_dn_string(id)
conn = self.get_connection()
search_result = conn.search_s(
self.tree_dn, self.LDAP_SCOPE,
'(&(%(id_attr)s=%(id)s)(objectclass=%(objclass)s))' %
{'id_attr': self.id_attr,
'id': ldap.filter.escape_filter_chars(str(id)),
'objclass': self.object_class})
if search_result:
dn, attrs = search_result[0]
return dn
else:
return self._id_to_dn_string(id)


With these lines removed, I can successfully use samAccountName as the user_id_attribute. I hope this is helpful!

more

( 2014-09-05 17:12:28 -0500 )edit

Since they show CN for both all the time, I got confused and assumed that USER_ID would be what the user wants to login with, but it works if you change the user_name to the sAMAccountName.

user_objectclass = person
user_id_attribute = cn
user_name_attribute = sAMAccountName
user_mail_attribute = mail

it is very confusing and I banged my head against the wall for a while.

more

As per my analysis with Openstack and AD integration there are two ways of integrating as suggested on this question about Swift and I haven't managed to successfully integrate AD with my OpenStack installation.

The suggestions for Swift are:

1. If your existing system is using LDAP or Active Directory, consider using the OpenStack Identity service backing on to this - it integrates well with swift.
2. If you have a 'special' system that has its own API, you can write a small module to put in the swift pipeline to handle the authorization decisions. You can find an example of how to develop a module in the OpenStack Operations Guide "Customize" chapter ()

I was trying for first option for last 4 days because there two type of attributes for tenant specially used for the integration with as keystone back end which are as follows:

a. AD tenant object creation with Class Organizationunit and change the Keystone .conf

more

At CERN, we run with Active Directory backing our Keystone instance. The configuration is documented at https://wiki.openstack.org/wiki/HowtoIntegrateKeystonewithAD . Does this address your configuration issue ?

more

Thanks, but no it does not address my issue. In your configuration, you are using user_id_attribute = cn, which I can not use since cn is not populated with the user's logon id in my Active Directory. As soon as I try to use another attribute such as samAccountName, the code fails as shown above.

( 2013-08-08 09:44:43 -0500 )edit

user_id_attribute = cn user_name_attribute = cn

^^ That is what is confusing about the Cern Documentation. In AD users often use sAMAccountName.

User_Name = sAMAccountName User_id = CN

( 2014-06-09 10:08:19 -0500 )edit