yahoo-eng-team team mailing list archive

[OpenStack Infra <1889936@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/744251
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=8bf222ac5d390e25d306d35f69bd958b18bee4d8
Submitter: Zuul
Branch:    master

commit 8bf222ac5d390e25d306d35f69bd958b18bee4d8
Author: Lance Bragstad <lbragstad@xxxxxxxxx>
Date:   Fri Jul 31 15:28:15 2020 -0500

    Properly handle octet (byte) strings when converting LDAP responses
    
    If LDAP returns a UUID as an octet string the LDAP driver will fail to
    convert it to something meaningful. The error usually looks something
    like:
    
      ID attribute objectGUID not found in LDAP object
    
    Microsoft AD's `objectGUID` parameter is stored and transmitted as an
    octet string [0]. If you attempt to use the `objectGUID` to generate
    user or group IDs, you'll get an HTTP 404 because keystone can't decode
    it properly. This is unfortunate because `objectGUID` are a fixed
    length, UUID format, and ideal for generating IDs in keystone. As
    opposed to using the object's CN, which is variable length, and can
    generate hashes that are larger than keystone's database table limit for
    user IDs.
    
    [0] https://docs.microsoft.com/en-us/windows/win32/ad/reading-an-objectampaposs-objectguid-and-creating-a-string-representation-of-the-guid
    
    Change-Id: Id80b17bdff015e10340e636102576b7435bd564f
    Closes-Bug: 1889936


** Changed in: keystone
       Status: In Progress => Fix Released

-- 
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/1889936

Title:
  Using Microsoft AD's objectGUID attribute as user_id_attribute breaks

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  Microsoft AD has a default attribute in its schema for users and
  groups called objectGUID [0]. The attribute is assigned when new users
  and groups are created.

  If we attempt to use this attribute as a user's ID by setting
  user_id_attribute=objectGUID, keystone throws an HTTP 404 listing
  users.

  I was able to recreate this with using a 2016 AD server with the
  following keystone LDAP configuration file:

  [root@overcloud-controller-0 /]# cat /etc/keystone/domains/keystone.windows.conf
  [ldap]
  url=ldap://192.168.1.209
  user=CN=Administrator,CN=Users,DC=mycompany,DC=local
  password=p@ssw0rd1
  suffix=DC=mycompany,DC=local
  user_tree_dn=DC=mycompany,DC=local
  user_objectclass=user
  user_id_attribute=objectGUID
  query_scope=sub
  user_name_attribute=sAMAccountName

  [identity]
  driver=ldap
  [stack@undercloud ~]$ openstack --os-cloud overcloud user list --domain windows
  ID attribute objectGUID not found in LDAP object CN=Administrator,CN=Users,DC=mycompany,DC=local (HTTP 404) (Request-ID: req-cdc056fd-2ebc-4a24-81d9-8a0948fc56bf)

  The root of the issue is that keystone isn't properly decoding the
  value, which you can see from the logs as the ldap backend processes
  results from AD.

  /var/log/containers/keystone/keystone.log:2020-07-31 18:58:36.319 19
  WARNING keystone.common.wsgi [req-ae63fcc8-64a1-48f5-96c9-c107df9c4be0
  c4c7be68b7304ba884a0d15f3f882df4 b970c795de7749af821f1d53b51fa0d5 -
  default default] ID attribute objectGUID not found in LDAP object
  CN=Administrator,CN=Users,DC=mycompany,DC=local: NotFound: ID
  attribute objectGUID not found in LDAP object
  CN=Administrator,CN=Users,DC=mycompany,DC=local

  Relevant code:

  https://opendev.org/openstack/keystone/src/commit/bcc751b3a24a93b5d8aab1bfb7eb8027d8499e36/keystone/identity/backends/ldap/common.py#L1328-L1330
  https://opendev.org/openstack/keystone/src/commit/bcc751b3a24a93b5d8aab1bfb7eb8027d8499e36/keystone/identity/backends/ldap/common.py#L950
  https://opendev.org/openstack/keystone/src/commit/bcc751b3a24a93b5d8aab1bfb7eb8027d8499e36/keystone/identity/backends/ldap/common.py#L144-L183
  https://opendev.org/openstack/keystone/src/commit/bcc751b3a24a93b5d8aab1bfb7eb8027d8499e36/keystone/identity/backends/ldap/common.py#L174
  https://opendev.org/openstack/keystone/src/commit/bcc751b3a24a93b5d8aab1bfb7eb8027d8499e36/keystone/identity/backends/ldap/common.py#L141
  https://opendev.org/openstack/keystone/src/commit/bcc751b3a24a93b5d8aab1bfb7eb8027d8499e36/keystone/identity/backends/ldap/common.py#L81-L97

  We might need to consider handling this value similar what the python-
  ldap community suggests:

  https://mail.python.org/pipermail/python-ldap/2014q3/003410.html

  [0] https://docs.microsoft.com/en-
  us/windows/win32/adschema/a-objectguid

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