On 11/13/2014 09:02 PM, et...@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@lists.openstack.org
Unsubscribe :
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
_______________________________________________
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
