Thank you Nathan, > Do you have more details on what your mapping is configured like? There > have been some changes around this area in Juno, but it's still possible > that there is some sort of bug here.
Here are my mapping details: # Search base for users. (string value) user_tree_dn=ou=People,dc=example,dc=com # LDAP search filter for users. (string value) #user_filter=(&(objectClass=posixAccount)) # LDAP objectClass for users. (string value) user_objectclass = posixAccount # LDAP attribute mapped to user id. (string value) user_id_attribute = uidNumber # LDAP attribute mapped to user name. (string value) user_name_attribute = uid # LDAP attribute mapped to user email. (string value) user_mail_attribute = mail However, I see that keystone does not make use of the "user_id_attribute", while checking for authorization of user. It defaults to "uid". Also, when i do -> keystone user-role-add --user-id="lohit.valleru" --tenant-id="xxx" --role-id="xxx" ( I see in the logs - that it uses the configuration value that i set above. i.e uidNumber. ) Now when i do -> keyston user-list , or keystone user-get lohit.valleru (I see that it defaults to picking up "uid" values, in place of uidNumber as above.) So since it stores "uid" as the user_id_attribute, and searches for "uidNumber" when i do user-role-add, it will always fail, unless uidNumber = uid which is impractical. In addition - i am confused, on why the user_id_attribute is being defaulted to "uid". Isn't user_id_attribute supposed to default to uidNumber? ( numerical) Why is the user_id_attribute being used to search, rather than user_name_attribute? As far as i understand - it is user_name_attribute that it stores in the mysql database. i would rather expect the logic to behave as follows : As soon as i authenticate using my kerberos principal : " lohit.vall...@example.com", keystone is supposed to use "lohit.valleru" to search against "user_name_attribute", and not "user_id_attribute" On swift storage or object storage - it is supposed to use "user_id_attribute", to be in sync with legacy file systems, so "user_id_attribute" is supposed to similar to posix uidNumber. Since there is no way, i can list groups using keystone, i cannot verify if it is mapping group information in the right way. Thank you for helping with Kerberos information. I can try testing the same, but i might not be able to go too forward, till the above issue is resolved. Lohit On Sat, Oct 18, 2014 at 10:13 PM, Nathan Kinder <nkin...@redhat.com> wrote: > > > On 10/18/2014 08:43 AM, lohit.valleru wrote: > > Hello, > > > > Thank you for posting this issue to openstack-dev. I had posted this on > the > > openstack general user list and was waiting for response. > > > > May i know, if we have any progress regarding this issue. > > > > I am trying to use external HTTPD authentication with kerberos and LDAP > > identity backend, in Havana. > > > > I think, few things have changed with Openstack Icehouse release and > > Keystone 0.9.0 on CentOS 6.5. > > > > Currently I face a similar issue to yours : I get a full username with > > domain as REMOTE_USER from apache, and keystone tries to search LDAP > along > > with my domain name. ( i have not mentioned any domain information to > > keystone. i assume it is called 'default', while my domain is: > example.com ) > > > > I see that - External Default and External Domain are no longer > supported by > > keystone but intstead - > > > > keystone.auth.plugins.external.DefaultDomain or > > external=keystone.auth.plugins.external.Domain are valid as of now. > > > > I also tried using keystone.auth.plugins.external.kerberos after checking > > the code, but it does not make any difference. > > > > For example: > > > > If i authenticate using kerberos with : lohit.vall...@example.com. I > see the > > following in the logs. > > > > DEBUG keystone.common.ldap.core [-] LDAP search: > > dn=ou=People,dc=example,dc=come, scope=1, > > query=(&(uid=lohit.vall...@example.com)(objectClass=posixAccount)), > > attrs=['mail', 'userPassword', 'enabled', 'uid'] search_s > > /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:807 > > 2014-10-18 02:34:36.459 5592 DEBUG keystone.common.ldap.core [-] LDAP > unbind > > unbind_s > /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:777 > > 2014-10-18 02:34:36.460 5592 WARNING keystone.common.wsgi [-] > Authorization > > failed. Unable to lookup user lohit.vall...@example.com from > 172.31.41.104 > > > > Also, i see that keystone always searches with "uid", no matter what i > enter > > as a mapping value for userid/username in keystone.conf . I do not > > understand if this is a bug or limitation. ( The above logs show that > they > > are not able to find uid with lohit.vall...@example.com since LDAP > contains > > uid without domain name) > > Do you have more details on what your mapping is configured like? There > have been some changes around this area in Juno, but it's still possible > that there is some sort of bug here. > > > > May i know, how do i request keystone to split REMOTE_USER? Do i need to > > mention default domain and sync with database in order for this to work? > > REMOTE_USER is set to the full user principal name, which incudes the > kerberos realm. Are you using mod_auth_kerb? If so, you can set the > following in your httpd config to split the realm off of the user > principal: > > KrbLocalUserMapping On > > > > > Also, May i know - what modifications do i need to do to Havana to > disable > > username and password authentication, but instead use external > > authentication such as Kerberos/REMOTE_USER. > > > > Is anyone working on these scenarios? or do we have any better solutions? > > There is work going on to make Kerberos a more pracitical solution, > including a Kerberos auth plugin for Keystone: > > https://review.openstack.org/123614 > > > > I have read about Federation and Shibboleth authentication, but i believe > > that is not the same as REMOTE_USER/Kerberos authentication. > > SAML federation uses REMOTE_USER, but it's quite a bit different than > what you are tryign do do since you still need to look up user > information via LDAP (it's all provided as a part of the SAML assertion > in the federation case). There are efforts going on in this area, but I > think it's still a release out (Kilo hopefully). > > Thanks, > -NGK > > > > > Thank you, > > > > Lohit > > > > Thank you, > > > > Lohit > > > > > > > > > > -- > > View this message in context: > http://openstack.10931.n7.nabble.com/keystone-Support-for-external-authentication-i-e-REMOTE-USER-in-Havana-tp22185p55528.html > > Sent from the Developer mailing list archive at Nabble.com. > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev