Bug 1113534

> File
> "/usr/lib/python2.7/site-packages/keystone/common/ldap/core.py", line 502,
> in _ldap_res_to_model
>      v =
> lower_res[self.attribute_mapping.get(k, k).lower()]
>  AttributeError:
> 'NoneType' object has no attribute 'lower'

This line is from a patch for a bug 1073011
take from stable/icehouse, so that'd mean 2014.1.1 would be broken the same way if we rebased.

As a quickfix, we can revert that patch but also need to investigate this upstream.

Please provide your "automatic script" so this can be replicated. Thanks.

Created attachment 912412 [details]
script to install freeipa and configure a schema for keystone

Created attachment 912413 [details]
keystone configuration for LDAP - part 1

Created attachment 912414 [details]
keystone configuration for LDAP - part 2

The scripts are attached to the bug, for anyone who is interested in replicating the setup. The server script is intended to run on a clean RHEL7 machine and the client setup is intended to run on a RHEL7 setup with a default keystone installation (Havana or Icehouse).

To install a FreeIPA server with the script:
1) Extract the tar.bz archive, it will create an "ldap" directory
2) In the ldap directory, run the runme-server.sh script which will run all the other scripts in order
3) A new file, called runonce-hostname-dns.txt, will be created and you need to copy it over to the keystone machine

To configure the client machine:
1) It is recommended to backup your keystone.conf file, so that you can revert the configuration changes
2) Make sure you copied the file runonce-hostname-dns.txt from the server
3) Run the 2 scripts in order: configure-client.sh and configure-client2.sh

I'll need to set up a test system to see what is happening, but there are a few things I notice:

- The error seems to be that a mapping isn't found, which indicates that this might be schema/config related.

- We definitely should be handlign the case where a mapping isn't found better (checking that before calling lower()).

- LDAP is being configured for the assignment backend in addition to identity.  This is not a normal use-case, so this problem might be assignment specific.

The problem here seems to be triggered by a configuration setting.  I added some instrumentation to see what mapping it was having a problem with, and the following was reported for both 'user-list' and 'tenant-list':

----------------------------------------------------------------------------
2014-06-26 19:51:43.339 13649 INFO keystone.common.ldap.core [-] mapping is {'email': 'mail', 'password': 'userPassword', 'enabled': 'enabled', 'default_project_id': None, 'name': 'uid'}
2014-06-26 19:51:43.340 13649 INFO keystone.common.ldap.core [-] k is id
2014-06-26 19:51:43.340 13649 INFO keystone.common.ldap.core [-] k is name
2014-06-26 19:51:43.340 13649 INFO keystone.common.ldap.core [-] k is domain_id
2014-06-26 19:51:43.340 13649 INFO keystone.common.ldap.core [-] k is password
2014-06-26 19:51:43.341 13649 INFO keystone.common.ldap.core [-] k is description
2014-06-26 19:51:43.341 13649 INFO keystone.common.ldap.core [-] k is email
2014-06-26 19:51:43.341 13649 INFO keystone.common.ldap.core [-] k is enabled
2014-06-26 19:51:43.341 13649 INFO keystone.common.ldap.core [-] k is default_project_id
2014-06-26 19:51:43.342 13649 ERROR keystone.common.wsgi [-] 'NoneType' object has no attribute 'lower'
----------------------------------------------------------------------------

As can be seen the mapping for the 'default_project_id' is None, and things break when this mapping is processed.  Keystone's default settings show this:

----------------------------------------------------
#user_attribute_ignore=default_project_id,tenants
#user_default_project_id_attribute=<None>
----------------------------------------------------

With these default settings, the 'default_project_id' is ignored, which causes us to skip processing the mapping.  This avoids the issue reported in this bug.  The test scripts in this bug don't ignore the 'default_project_id' attribute though, which triggers the 500 error:

----------------------------------------------------
user_attribute_ignore = tenant_id,tenants
----------------------------------------------------

If 'default_project_id' is added to the list of user attributes to ignore, the 500 error doesn't occur.

There is still a bug here, which is to improve the handling of a mapping that is set to None that is not ignored.  This is a misconfiguration, but we should handle it better.

This has merged in stable/icehouse upstream and will be included in the upstream 2014.1.3 release of Keystone.

*** Bug 1128916 has been marked as a duplicate of this bug. ***

no capacity to test this medium bug during Icehouse.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2014-1790.html