Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Keystone LDAP Integration with Active Directory

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?

Thanks, Brian

Keystone LDAP Integration with Active Directory

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?

Thanks, Brian

Keystone LDAP Integration with Active Directory

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

user_id_attribute = cn 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?

Thanks, Brian

Keystone LDAP Integration with Active Directory

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

user_id_attribute = cn

cn user_name_attribute = cn

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)

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

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?

Thanks, Brian

Keystone LDAP Integration with Active DirectoryDirectory, 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?