1.  Authentication.  This is done via a simple bind to the LDAP server
2. Get user data. This is done as an LDAP query to the LDAP server as the system LDAP user, not as the end user. 3. Getting the roles for the user on the project. If you are request a project scoped token, this would fail if the user had no roles on the project.


You can rule out 3 by using the keystone command line to request an unscoped token: don't set the OS_PROJECT_ID or comparable variables. Explicitly unset them to be sure.

My guess is the problem is the 2nd step: your LDAP service account is not set up correctly. under [LDAP] it is the user and password values. Make sure that user can make queries against your AD.

Thanks for the reply! We have a speciifc account for binding to the AD server that is in use with a number of different systems, mostly Linux based. Off the top of my head many of them are java implementations but a few aren't.

I used ldapsearch to somewhat test the queries.

I did notice that between Havana and Icehouse Keystones, there is an extra field in the Icehouse query according to the debug output on console (running keystone foreground not as a daemon.) This is using a nearly identical config.

I did compare tcpdump captures as well (even tried to strace keystone) but nothing stood out. Was starting to wonder if it was an underlying library.

I'll try to cut down the queries tomorrow and I'll get hold of the difference in those queries as shown by the debug logs (and I should have the packet captures as well.)

                        - Ethan

_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to     : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Reply via email to