Open Stack

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.valleru at 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 <nkinder at 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.valleru at 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.valleru at 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.valleru at 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.valleru at 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141019/0a502b56/attachment.html>