Open Stack

On 11/13/2014 09:02 PM, ethan at 757.org wrote:
>
> Hello,
>
>  I'm in a bit of a pickle.
>
>  We had an OpenStack Havana install that ended up dead due to database 
> issues. It was installed by a co-worker that left.
>
>  Brand new install using Icehouse, and everything was going pretty good.
> Imported all of the snapshots and volumes.
>
>  Final part was to tie it back to the Active Directory server. This 
> will not work.
>
>  Total time spent is many hours. The error I get back is always 
> Invalid Username/Password.
>
>  I've turned on additional debug notifications by modifying the python 
> script for LDAP. I've got debugging turned on in keystone.conf.
>
>  the sAMAccount/cn thing is well known, I've tried it all ways. I'm 
> pretty sure I get past this as I see that when I key in my short name 
> -- the
> keystone.log has the full name in it. It makes first request to go from
> short name (sAMAccount) to long (cn) then proceeds to use that I believe.
>
>  I'm using the same queries and such from the older Havana 
> keystone.conf. I've even tried running the old config straight up 
> (modifying a few settings of course.)
>
>  Is there any known issues with the 0.9.0 keystone and Active 
> Directory? Could it be an issue with encryption?
>
>  Python is 2.6, python-ldap is centos distributed 2.3.10-1.el6.
>
>  I've tried both ldaps and ldap. I've confirmed using the old 
> partially working Havana deployment that switching down to ldap 
> authenticates fine.
>
>  Note, we can still actually use the older Havana install and use the 
> LDAP
> authentication with Active Directory.
>
>  I suppose I should beg. Can anyone shed insight into my failure?

Getting a token is three steps:

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 in advance. - Ethan
>
>
> -----------------
>
> 2014-11-14 01:57:09.517 13033 DEBUG keystone.common.ldap.core [-] LDAP 
> bind: dn=CN=AD Bind,OU=Service Accounts,OU=User 
> Accounts,DC=int,DC=domain,DC=com simple_bind_s 
> /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:771
>
> 2014-11-14 01:57:09.524 13033 DEBUG keystone.common.ldap.core [-] LDAP 
> search: dn=ou=User Accounts,dc=int,dc=aopslab,dc=com, scope=2, 
> query=(&(cn=Neutron 
> Service)(memberof:1.2.840.113556.1.4.1941:=CN=Cloud,OU=Security 
> Groups,OU=User Accounts,DC=int,DC=domain,DC=com)(objectClass=person)), 
> attrs=['', 'userAccountControl', 'sAMAccountName', 'mail'] search_s 
> /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:807
>
> 2014-11-14 01:57:09.527 13033 DEBUG keystone.common.ldap.core [-] LDAP 
> unbind unbind_s 
> /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:777
>
> 2014-11-14 01:57:09.528 13033 DEBUG keystone.common.ldap.core [-] LDAP 
> init: url=ldap://phatActiveDirectoryserver.domain.com:389 __init__ 
> /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:701
>
> 2014-11-14 01:57:09.529 13033 DEBUG keystone.common.ldap.core [-] LDAP 
> init: use_tls=False
>
>
>
>
>
> 2014-11-14 01:52:01.324 13033 DEBUG keystone.common.ldap.core [-] LDAP 
> bind: dn=CN=AD Bind,OU=Service Accounts,OU=User 
> Accounts,DC=int,DC=domain,DC=com simple_bind_s 
> /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:771
>
> 2014-11-14 01:52:01.329 13033 DEBUG keystone.common.ldap.core [-] LDAP 
> search: dn=ou=User Accounts,dc=int,dc=domain,dc=com, scope=2, 
> query=(&(cn=Neutron Service)(objectclass=person)), attrs=None search_s 
> /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:807
>
>
> 2014-11-14 01:52:01.335 13033 DEBUG keystone.notifications [-] CADF 
> Event: {'typeURI': 'http://schemas.dmtf.org/cloud/audit/1.0/event', 
> 'initiator': {'typeURI': 'service/security/account/user', 'host': 
> {'agent': 'python-neutronclient', 'address': '10.10.10.10'}, 'id': 
> 'openstack:1784b835-787a-4ece-a531-0a6f4111111', 'name': u'Neutron 
> Service'}, 'target': {'typeURI': 'service/security/account/user', 
> 'id': 'openstack:6944c582-5574-42e2-af8b-a11111111111'}, 'observer': 
> {'typeURI': 'service/security', 'id': 
> 'openstack:fb5afc49-a5e5-4dc0-9867-7c8a1111111'}, 'eventType': 
> 'activity', 'eventTime': '2014-11-14T01:52:01.335185+0000', 'action': 
> 'authenticate', 'outcome': 'failure', 'id': 
> 'openstack:ac8208e7-df94-4706-a1d1-5551111111'} 
> _send_audit_notification 
> /usr/lib/python2.6/site-packages/keystone/notifications.py:289
>
> 2014-11-14 01:52:01.337 13033 WARNING keystone.common.wsgi [-] 
> Authorization failed. Invalid user / password from 10.10.10.10
>
>
> --------------------------
>
>
>
>
>
> _______________________________________________
> 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