Ask Your Question

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

asked 2013-08-07 09:13:26 -0500

Brian gravatar image

updated 2014-09-05 17:06:14 -0500

smaffulli gravatar image

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 flag offensive close merge delete

4 answers

Sort by ยป oldest newest most voted

answered 2013-08-13 09:08:39 -0500

Brian gravatar image

I have found the bug in the keystone/common/ldap/ 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,

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
        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!

edit flag offensive delete link more


Haneef Ali gravatar imageHaneef Ali ( 2014-09-05 17:12:28 -0500 )edit

answered 2013-10-28 06:34:57 -0500

Vinoth gravatar image

updated 2014-09-05 17:04:03 -0500

smaffulli gravatar image

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

edit flag offensive delete link more

answered 2013-11-20 11:45:29 -0500

mpetason gravatar image

updated 2013-11-20 11:47:18 -0500

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.

edit flag offensive delete link more

answered 2013-08-07 11:32:45 -0500

tim-bell gravatar image

At CERN, we run with Active Directory backing our Keystone instance. The configuration is documented at . Does this address your configuration issue ?

edit flag offensive delete link 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.

Brian gravatar imageBrian ( 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

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

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower


Asked: 2013-08-07 09:13:26 -0500

Seen: 3,675 times

Last updated: Sep 05 '14