A bit off-topic but, I'm wondering here... Don't you guys think that it would be great to have some kind of "LDAP as a Service", just live Trove, but for LDAP, of course?
So, each tenant will have its own LDAPaaS, then, their instances can be configured to use it. Also, Ubuntu have support for "389 Directory Service", from FedoraProject, effectively creating a nice replacement for Micro$oft AD. I think that OpenStack might have some kind of a "389aaS" built-in, so, it will be your new OpenSource AD! I'm curious, is this doable in OpenStack this way (as a Service, not only as a backend for Keystone), or even desired?! Cheers! Thiago On 21 January 2014 21:19, Miller, Mark M (EB SW Cloud - R&D - Corvallis) < mark.m.mil...@hp.com> wrote: > This feature didn't quite make it into the Havana code base in that it > still had a few bugs. I will be interested to see if it was fixed for > Icehouse. > > Mark > > > -----Original Message----- > > From: James [mailto:jamesze...@gmail.com] > > Sent: Tuesday, January 21, 2014 2:37 PM > > To: openstack@lists.openstack.org > > Subject: [Openstack] ldap + sql in keystone (multi-domain) > > > > All, > > > > I'm trying to get multiple domains configured in keystone so that users > can > > authenticate against LDAP, but service accounts can use locally-created, > SQL- > > based accounts. > > > > I've set up keystone.conf as follows: > > > > > > -->8-- > > > > [DEFAULT] > > admin_token = ADMIN > > debug = True > > verbose = True > > log_file = keystone.log > > log_dir = /var/log/keystone > > use_syslog = True > > [sql] > > connection = sqlite:////var/lib/keystone/keystone.db > > [identity] > > driver = keystone.identity.backends.sql.Identity > > default_domain_id = default > > domain_specific_drivers_enabled = True > > domain_config_dir = /etc/keystone/domains [credential] driver = > > keystone.credential.backends.sql.Credential > > [trust] > > driver = keystone.trust.backends.sql.Trust [os_inherit] [catalog] driver > = > > keystone.catalog.backends.sql.Catalog > > [endpoint_filter] > > [token] > > driver = keystone.token.backends.sql.Token [cache] [policy] driver = > > keystone.policy.backends.sql.Policy > > [ec2] > > driver = keystone.contrib.ec2.backends.kvs.Ec2 > > [assignment] > > [oauth1] > > [ssl] > > [signing] > > [ldap] > > [auth] > > methods = external,password,token,oauth1 password = > > keystone.auth.plugins.password.Password > > token = keystone.auth.plugins.token.Token > > oauth1 = keystone.auth.plugins.oauth1.OAuth > > [paste_deploy] > > config_file = keystone-paste.ini > > > > --8<-- > > > > > > /etc/keystone/domains/keystone.ldap.conf is configured as follows: > > > > > > -->8-- > > > > [identity] > > driver = keystone.identity.backends.ldap.Identity > > [assignment] > > driver = keystone.assignment.backends.sql.Assignment > > [ldap] > > url = ldap://ldap_server:389 > > user_tree_dn = dc=blah,dc=com > > user_objectclass = person > > user_pass_attribute = > > user_id_attribute = cn > > user_enabled_attribute = userAccountControl user_enabled_mask = 2 > > user_enabled_default = 512 user_mail_attribute = mail > > user_name_attribute = sAMAccountName user_filter = > > (memberof=CN=blah,DC=blah,DC=com) user = username password = > > password use_dumb_member = True dumb_member = keystone_ldap > > page_size = 0 alias_dereferencing = always query_scope = sub > > user_allow_create = False user_allow_update = False user_allow_delete = > > False > > > > --8<-- > > > > > > Super simple configuration. The issue I'm running into is with using the > v3 > > APIs. Take a look at the example below: > > > > > > -->8-- > > > > ~ % openstack --os-auth-url "http://10.34.208.9:35357/v3"; > > --os-username admin --os-password 'admin' --os-identity-api-version 3 > --os- > > domain-id=default domain list > > > +----------------------------------+---------+---------+----------------------------------- > > -----------------------------------+ > > | ID | Name | Enabled | Description > > | > > > +----------------------------------+---------+---------+----------------------------------- > > -----------------------------------+ > > | default | Default | True | Owns users > > and tenants (i.e. projects) available on Identity API v2. | > > | 89a6bbbdd13543739d602d2e6e9bebda | ldap | True | Active > > Directory Authentication (via LDAP) | > > > +----------------------------------+---------+---------+----------------------------------- > > -----------------------------------+ > > > > ~ % openstack --os-auth-url "http://10.34.208.9:35357/v3"; > > --os-username admin --os-password 'admin' --os-identity-api-version 3 > --os- > > domain-id=default user list > > +----------------------------------+--------+ > > | ID | Name | > > +----------------------------------+--------+ > > | d8a47a119650484ca7eebe7a379bdaab | admin | > > | 7f3da3ec686dbdda837d91485fc28e7e | test | > > +----------------------------------+--------+ > > > > ~ % openstack --os-auth-url "http://10.34.208.9:35357/v3"; > > --os-username admin --os-password 'admin' --os-identity-api-version 3 > --os- > > domain-id=89a6bbbdd13543739d602d2e6e9bebda user list > > +----------------------------------+--------+ > > | ID | Name | > > +----------------------------------+--------+ > > | d8a47a119650484ca7eebe7a379bdaab | admin | > > | 7f3da3ec686dbdda837d91485fc28e7e | test | > > +----------------------------------+--------+ > > > > --8<-- > > > > > > Note the 'user list' output returned in the last API call. Because we're > > explicitly setting the LDAP domain, the user list should come from LDAP > (not > > our local sqlite database). Debug output shows that keystone sees the > LDAP > > domain configuration in /etc/keystone/domains/keystone.ldap.conf, but it > > never actually makes an LDAP bind request. > > > > Debug logs can be found at: http://pastebin.com/eG2XxVEd > > > > Interestingly enough, however, if the default_domain_id in > > /etc/keystone/keystone.conf points to our LDAP domain > > (default_domain_id = 89a6bbbdd13543739d602d2e6e9bebda), then a > > *version 2.0* API call to keystone will return our LDAP user list (see > below), > > which indicates that the LDAP and multi-domain configuration is likely > > correct. > > > > > > -->8-- > > > > root@keystone:/etc/keystone# keystone user-list > > WARNING: Bypassing authentication using a token & endpoint > > (authentication credentials are being ignored). > > > +-----------------------------------+-----------------+---------+-------------------------- > > --+ > > | id | name | enabled | > > email | > > > +-----------------------------------+-----------------+---------+-------------------------- > > --+ > > | LDAP User 1 | lu1 | True | > > l...@blah.com | > > | LDAP User 2 | lu2 | True | > > l...@blah.com | > > | LDAP User 3 | lu3 | True | > > l...@blah.com | > > | ... | ... | ... | > > ... | > > > +-----------------------------------+-----------------+---------+-------------------------- > > --+ > > root@keystone:/etc/keystone# > > > > -8<- > > > > > > Again, the end-goal here is to have service accounts defined locally > (via SQL) > > since our corporate LDAP environment doesn't have a mechanism by which > > we can add OpenStack service accounts. > > > > Any help or thoughts would be greatly appreciated. > > > > Thanks! > > > > _______________________________________________ > > 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 >
_______________________________________________ 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
