Ldap connection with Openstack could not find user : admin

问题

I am confuring Ldap with openstack but when openstack send request to my ldap server, an error occured like could not find user: admin. Logs are below. Ldap server should send its information to my openstack environment. Is below warning important?

ldap_build_search_req ATTRS: cn userPassword enabled sn mail description

How can I handle this situation?

ldap_url_parse_ext(ldap://localhost/)
ldap_init: trying /etc/ldap/ldap.conf
ldap_init: using /etc/ldap/ldap.conf
ldap_init: HOME env is /var/lib/keystone
ldap_init: trying /var/lib/keystone/ldaprc
ldap_init: trying /var/lib/keystone/.ldaprc
ldap_init: trying ldaprc
ldap_init: LDAPCONF env is NULL
ldap_create
ldap_url_parse_ext(ldap://10.0.0.23)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP 10.0.0.23:389
ldap_new_socket: 18
ldap_prepare_socket: 18
ldap_connect_to_host: Trying 10.0.0.23:389
ldap_pvt_connect: fd: 18 tm: -1 async: 0
attempting to connect:
connect success
ldap_open_defconn: successful
ldap_send_server_request
ldap_result ld 0x7f0e31c9b150 msgid 1
wait4msg ld 0x7f0e31c9b150 msgid 1 (infinite timeout)
wait4msg continue ld 0x7f0e31c9b150 msgid 1 all 1
** ld 0x7f0e31c9b150 Connections:
* host: 10.0.0.23  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Thu Jun  1 12:11:40 2017


** ld 0x7f0e31c9b150 Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x7f0e31c9b150 request count 1 (abandoned 0)
** ld 0x7f0e31c9b150 Response Queue:
   Empty
  ld 0x7f0e31c9b150 response count 0
ldap_chkResponseList ld 0x7f0e31c9b150 msgid 1 all 1
ldap_chkResponseList returns ld 0x7f0e31c9b150 NULL
ldap_int_select
read1msg: ld 0x7f0e31c9b150 msgid 1 all 1
read1msg: ld 0x7f0e31c9b150 msgid 1 message type bind
read1msg: ld 0x7f0e31c9b150 0 new referrals
read1msg:  mark request completed, ld 0x7f0e31c9b150 msgid 1
request done: ld 0x7f0e31c9b150 msgid 1
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_parse_result
ldap_msgfree
ldap_search_ext
put_filter: "(&(sn=admin)(objectClass=organizationalUnit)(cn=*))"
put_filter: AND
put_filter_list "(sn=admin)(objectClass=organizationalUnit)(cn=*)"
put_filter: "(sn=admin)"
put_filter: simple
put_simple_filter: "sn=admin"
put_filter: "(objectClass=organizationalUnit)"
put_filter: simple
put_simple_filter: "objectClass=organizationalUnit"
put_filter: "(cn=*)"
put_filter: simple
put_simple_filter: "cn=*"
ldap_build_search_req ATTRS: cn userPassword enabled sn mail description
ldap_send_initial_request
ldap_send_server_request
ldap_result ld 0x7f0e31c9b150 msgid 2
wait4msg ld 0x7f0e31c9b150 msgid 2 (infinite timeout)
wait4msg continue ld 0x7f0e31c9b150 msgid 2 all 1
** ld 0x7f0e31c9b150 Connections:
* host: 10.0.0.23  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Thu Jun  1 12:11:40 2017


** ld 0x7f0e31c9b150 Outstanding Requests:
 * msgid 2,  origid 2, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x7f0e31c9b150 request count 1 (abandoned 0)
** ld 0x7f0e31c9b150 Response Queue:
   Empty
  ld 0x7f0e31c9b150 response count 0
ldap_chkResponseList ld 0x7f0e31c9b150 msgid 2 all 1
ldap_chkResponseList returns ld 0x7f0e31c9b150 NULL
ldap_int_select
read1msg: ld 0x7f0e31c9b150 msgid 2 all 1
read1msg: ld 0x7f0e31c9b150 msgid 2 message type search-result
read1msg: ld 0x7f0e31c9b150 0 new referrals
read1msg:  mark request completed, ld 0x7f0e31c9b150 msgid 2
request done: ld 0x7f0e31c9b150 msgid 2
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 2, msgid 2)
ldap_parse_result
ldap_msgfree
2017-06-01 12:11:40.512893 2017-06-01 12:11:40.512 5767 WARNING keystone.auth.plugins.core [req-07b3f423-d9fd-419a-836c-2d59fb53ac9d - - - - -] Could not find user: admin
2017-06-01 12:11:40.513608 2017-06-01 12:11:40.513 5767 WARNING keystone.common.wsgi [req-07b3f423-d9fd-419a-836c-2d59fb53ac9d - - - - -] Authorization failed. Could not find user: admin (Disable insecure_debug mode to suppress these det$

My keystone.ldap.conf like below

[identity]
driver = keystone.identity.backends.ldap.Identity
[assignment]
driver = keystone.assignment.backends.sql.Assignment
[ldap]
url = ldap://10.0.0.23
suffix = dc=openstack,dc=org
user = cn=admin,dc=openstack,dc=org
password = toor
user_tree_dn = ou=Users,dc=openstack,dc=org
user_objectclass = organizationalUnit
group_tree_dn = ou=Groups,dc=openstack,dc=org
group_objectclass = organizationalUnit
use_dumb_member = True
dumb_member = keystone_ldap
page_size = 0
alias_dereferencing = always
query_scope = sub

EDIT: Ldap structure

# openstack.org
dn: dc=openstack,dc=org
objectClass: top
objectClass: dcObject
objectClass: organization
o: openstack
dc: openstack

# admin, openstack.org
dn: cn=admin,dc=openstack,dc=org
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator

# Groups, openstack.org
dn: ou=Groups,dc=openstack,dc=org
objectClass: top
objectClass: organizationalUnit
ou: groups

# Users, openstack.org
dn: ou=Users,dc=openstack,dc=org
objectClass: top
objectClass: organizationalUnit
ou: users

EDIT: Inside keystone.conf I did not add any sn property but ldap always searching sn=admin as filter.

filter="(&(sn=admin)(objectClass=inetOrgPerson)(cn=*))"

Also I added ldap admin as user field of keystone.conf . Ldap searches this admin user inside user_tree but admin is not included user_tree. If someone knows working mechanism of keystone ldap, then problem could be easily solved.

回答1:

The problem is your user_objectclass = organizationalUnit , I don't think the user is an ou , it is more likely a inetOrgPerson, or Person or something referencing a user and not an organization

It generates a filter like : "(sn=admin)(objectClass=organizationalUnit)" which will never find your entry. Check the objectclass of the user admin to change with the right value.

Edit : From your newly posted info : Try : user_objectclass = organizationalRole

You will experience the same problem with the groups if they have not the organizationalUnit objectClass.

Edit 2 : Also the admin user is not located in the subtree set by the option user_tree_dn

If you want the admin user to be part of the selection of users, try this configuration :

[ldap]
url = ldap://10.0.0.23
suffix = dc=openstack,dc=org
user = cn=admin,dc=openstack,dc=org
password = toor
user_tree_dn = dc=openstack,dc=org
user_filter = (|(cn=admin)(objectClass=inetOrgPerson))
group_tree_dn = ou=Groups,dc=openstack,dc=org
group_objectclass = organizationalUnit
use_dumb_member = True
dumb_member = keystone_ldap
page_size = 0
alias_dereferencing = always
query_scope = sub

I put a filter to match the admin entry and the future users entries. If these entries are not inetOrgPerson but another objectClass, feel free to modify it accordingly.

Note : Any inetOrgPerson entry under the subtree dc=openstack,dc=org will be considered a user.

For more informations about the Openstack integration with ldap, see this doc