Open Stack

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.miller at 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:jameszee13 at gmail.com]
> > Sent: Tuesday, January 21, 2014 2:37 PM
> > To: openstack at 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 at 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  |
> > lu1 at blah.com            |
> > |            LDAP User 2            |     lu2         |   True  |
> > lu2 at blah.com            |
> > |            LDAP User 3            |     lu3         |   True  |
> > lu3 at blah.com            |
> > |               ...                 |       ...       |   ...   |
> >      ...              |
> >
> +-----------------------------------+-----------------+---------+--------------------------
> > --+
> > root at 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 at 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 at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140227/cef6d06c/attachment.html>