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
