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