Open Stack

> If you are going back and setting this up again you'll have to run the same
> steps you would with a normal keystone configuration. You'll need to make
> sure that you have applied the role Admin to the cloudadmin user. Then
> you'll need to make sure it is associated with the correct tenant again.
>
> When I set this up originally I was doing a recursive search for groups as
> well so you'll need to look into that. I also had to make modifications to
> openssl to allow TLS to work with LDAPS and import certs so you should test
> this with ldap if you don't have the same configuration.

I backed up the ldaps stuff, but validated it is possible to run in 
non-SSL mode as well (for troubleshooting.) I have the certs backed up.

> Did you actually save the keystone.conf with the original search strings
> and configuration? It took me a little while to get it to the correct state
> for Havana.

Yep, 100%!

After chatting with Adam Young and others on IRC they helped me work it 
out.

I did not do the OpenStack installs, I haven't installed it myself. I only 
chimed in when there were issues (mainly with the LDAP/AD portion.)

The software all installed and setup, and by default it's setup using SQL 
database for autehntication. My coworker had setup a 2nd admin account 
that matched what was in the LDAP (Active Directory) server on my request, 
and put it in the admin group.

But in the database the user ID is set to the hash string that matches the 
user table in SQL, when it should have the field from LDAP.

I think the ldap module might be backwards when used with AD? With the 
name and ID fields set right with cn/sAMAccountName so it's possible to 
pass authentication (because AD requires the bind operation, then I think 
client needs to use sAMAccountName to look up the Common Name, then uses 
Common Name for further lookups) I think in Openstack the user name and 
user ID end up backwards. The login screen in Horizon is fine but when it 
comes to the DB tables I ended up having to use the CN which is 
technically at risk for name collision in large environment but not so 
much an issue for us.

There should be a way to change the ID assignment using keystone commands 
as long as you do not assign tenant variable in environment, as before 
things are fully setup that will block access.

I'm going to try to write it all up tomorrow and post it somewhere online 
to add to LDAP/AD knowledge pool online.

Thanks again to Adam Young and others in the IRC channel for helping. It's 
been a mess and high stress issue at work!

 			- Ethan



>
> Regards,
>
> Michael Petersen
>
>
>
> On Tue, Nov 18, 2014 at 2:37 PM, <ethan at 757.org> wrote:
>
>> After difficulty and downtime spent with Icehouse we rolled back to Havana
>> as we had a once-working config that was integrated with our Active
>> Directory server.
>>
>> Everything was rebuilt, and things work fine with the exception of LDAP,
>> again.
>>
>> I'm fairly confident the system is passing the username/password
>> validation part, but fails with a "You are not authorized for any projects."
>>
>> I've read pretty much every page on the internet related to LDAP and
>> OpenStack over the past week, and do know there is notes about this error
>> on the earlier Grizzly version but they were corrected by the time Havana
>> was deployed here.
>>
>> When a valid account is supplied, the front Web end replies with a "You
>> are not authorized for any projects."
>>
>> In the database tables, the user is assigned to the admin project. The
>> admin project under_project_metadata table has two user IDs assigned to it
>> including the account I'm trying to use.
>>
>> On the LDAP side there are accounts for all of the services, but I am not
>> sure if the tokens are making it through.
>>
>> The setup has the ldap driver enabled for identity and sql driver enabled
>> for Assignment and Catalog.
>>
>>
>> Any help is greatly appreciated. My coworkers went to the redhat openstack
>> courses and such but I don't' believe the LDAP stuff was covered and this
>> seems more like a bug. I really wish I had saved a copy of the LDAP core.py
>> module from the working install so I could narrow down when in time the
>> code was from :-(
>>
>> The logging in Icehouse is of course improved over Havana:
>>
>>
>> 2014-11-18 22:15:40.573 17771 WARNING keystone.common.wsgi [-]
>> Authorization failed. The request you have made requires authentication.
>> from 10.100.x.x
>> 2014-11-18 22:16:06.848 17771 WARNING keystone.common.wsgi [-]
>> Authorization failed. The request you have made requires authentication.
>> from 10.100.x.x
>> 2014-11-18 22:18:21.515 17771 WARNING keystone.common.wsgi [-]
>> Authorization failed. The request you have made requires authentication.
>> from 10.100.x.x
>> 2014-11-18 22:18:32.477 17771 WARNING keystone.common.wsgi [-]
>> Authorization failed. The request you have made requires authentication.
>> from 10.100.x.x
>>
>>
>> _______________________________________________
>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
>> openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
>> openstack
>>
>
>
>
> -- 
> Michael Petersen
> OpenStack Operations Engineer
> Mirantis, Inc.
> (650) 963-9828 x1041
>

--
Ethan O'Toole
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Flickr photos      : http://www.flickr.com/photos/ethanotoole
757 Labs Hackerspace    : www.757labs.org
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-