Open Stack

> 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