Public bug reported:

Some operators configure their LDAP identity backends to allow anonymous
binds for access to read-only information. This is a valid configuration
within keystone, as keystone does not require LDAP credentials to be set
in its config. Currently, if keystone is given LDAP credentials, it will
attempt an initial authenticated bind at the same time that it creates a
connection object[1]. If keystone does not have LDAP credentials, the
first time it attempts to bind to the LDAP server will be upon the first
time it executes a query, because pyldap will automatically attempt a
"reconnect[2] if necessary, so there's not normally any problem. The
only reason this would be a problem would be if we were trying to do
some connection validation, which arose in a recent review[3]. In order
to validate the connection, the first connection needs to happen in a
predictable place regardless of the method of binding.

[1] 
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/identity/backends/ldap/common.py?h=11.0.0.0b1#n1286
[2] 
https://github.com/pyldap/pyldap/blob/pyldap-2.4.25.1/Lib/ldap/ldapobject.py#L1069
[3] https://review.openstack.org/#/c/390948/

** Affects: keystone
     Importance: Undecided
     Assignee: Colleen Murphy (krinkle)
         Status: In Progress

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1649138

Title:
  Initial LDAP bind occurs inconsistently depending on deployment
  configuration

Status in OpenStack Identity (keystone):
  In Progress

Bug description:
  Some operators configure their LDAP identity backends to allow
  anonymous binds for access to read-only information. This is a valid
  configuration within keystone, as keystone does not require LDAP
  credentials to be set in its config. Currently, if keystone is given
  LDAP credentials, it will attempt an initial authenticated bind at the
  same time that it creates a connection object[1]. If keystone does not
  have LDAP credentials, the first time it attempts to bind to the LDAP
  server will be upon the first time it executes a query, because pyldap
  will automatically attempt a "reconnect[2] if necessary, so there's
  not normally any problem. The only reason this would be a problem
  would be if we were trying to do some connection validation, which
  arose in a recent review[3]. In order to validate the connection, the
  first connection needs to happen in a predictable place regardless of
  the method of binding.

  [1] 
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/identity/backends/ldap/common.py?h=11.0.0.0b1#n1286
  [2] 
https://github.com/pyldap/pyldap/blob/pyldap-2.4.25.1/Lib/ldap/ldapobject.py#L1069
  [3] https://review.openstack.org/#/c/390948/

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1649138/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to     : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

Reply via email to