OpenStack Icehouse – Active Directory Integration

By | August 9, 2013

Note: This article has been superseded by a new article: OpenStack Juno – Active Directory Integration

Updated for OpenStack Icehouse:  I’ve successfully configured the OpenStack Keystone identity service to authenticate against Active Directory. The idea is to use a centralized identity service (namely Active Directory) to store and manage your user accounts, roles and projects that would otherwise be managed within OpenStack. Many enterprises prefer to maintain a central directory service and not have islands of identity within their environment.  Active Directory is widely used in the corporate world, so it’s essential to be able to integrate platforms with Active Directory.

The good news is that OpenStack Keystone includes an LDAP identity provider, that can be configured to perform LDAP calls to Active Directory.  We’ll need to create (or point to existing) user accounts, and create objects for roles and tenants in Active Directory.  Then we’ll configure keystone to find and use those objects.

Creating the Active Directory Objects

The Keystone LDAP provider uses object classes that (though they may be considered standard in the Linux/LDAP world) are not widely used in Active Directory.  These classes include organizationalRole and groupOfNames. The classes do exist in the AD schema, but the familiar graphical administration tool (Active Directory Users and Computers) does not provide dialogs for managing these object types.

So, in order to create these objects, we’ll need to use an alternative tool.  For this post, I’ll use ADSIEDIT.msc, which can create and modify just about any object type.  However, for day-to-day administration, I may develop a custom GUI, web-based tool, or a handful of scripts.

But first, in the familiar Active Directory Users and Computers tool, I’ll create my OU structure.  From the root of my domain, I’ll create an OpenStack OU, and beneath that, I’ll create a Projects OU and a Roles OU.  Finally, below Projects, I’ll create an admin OU and a service OU.  The resulting OU structure is shown below.

aduc

Next, I’ll launch ADSIEDIT.msc and create two organizationalRole objects in the Roles OU.  The first one will be for the admin role.  In ADSIEDIT, right click the Roles OU and select newobject.  Select OrganizationalRole and click next.  Enter the name admin and click next. Click the More Attributes button, select the optional property roleOccupant, and enter the distringuishedName of a user that you want to grant admin rights in OpenStack.  For example, if you have a user called admin in the Users container, the dn is cn=admin,cn=Users,dc=mydomain,dc=net

OK, now we also need to create a Member role, so create another organizationalRole object for that. We don’t need to add any users to this role right now.

Now on to the Projects OU.  We’ve already created a sub-OU called admin.  Here we’ll create two objects, another organizationalRole object called admin, and a groupOfNames object called adminUsers.  Clarification here, this whole sub-OU represents the admin tenant, the admin role gives us admin access to OpenStack, and membership in the groupOfNames gives us use of the admin project.

To create these objects, in ADSIEDIT, as above, but this time under the admin OU, create an organizationalRole object, name: admin, roleOccupant: dn of our admin user.  Next create a groupOfNames object, name: adminUsers, member: dn of our admin user.  OK, now we have enough objects created to test authentication with our admin user.

Finally, we should enable the project OU’s (admin and service) by setting the attribute called extensionName to TRUE.

In summary, we created the OU structure, two role objects in our Roles OU, and a role object and a groupOfNAmes object in our admin project OU.

Configuring Keystone

Now we can modify our keystone config to point to Active Directory.  On the keystone server, edit /etc/keystone/keystone.conf.  First, we change the identity provider as follows.  Disable the SQL provider and add the line for the LDAP provider:

 

[identity]
#driver = keystone.identity.backends.sql.Identity
driver = keystone.identity.backends.ldap.Identity

Then we configure the LDAP section to point to our OU structure in Active Directory:

 

[ldap]
query_scope = sub
url = ldap://seltzer.net
user = cn=ldapuser,cn=Users,dc=seltzer,dc=net
password = LdapUserPassword
suffix = dc=seltzer,dc=net
use_dumb_member = True
dumb_member = cn=ldapuser,cn=Users,dc=seltzer,dc=net

user_tree_dn = cn=Users,dc=seltzer,dc=net
user_objectclass = organizationalPerson
user_id_attribute = cn
user_name_attribute = sAMAccountName
user_mail_attribute = mail
user_enabled_attribute = userAccountControl
user_enabled_mask = 2
user_enabled_default = 512
user_attribute_ignore = password,tenant_id,tenants
user_allow_create = False
user_allow_update = False
user_allow_delete = False

tenant_tree_dn = ou=Projects,ou=OpenStack,dc=seltzer,dc=net
tenant_objectclass = organizationalUnit
tenant_id_attribute = ou
tenant_member_attribute = member
tenant_name_attribute = ou
tenant_desc_attribute = description
tenant_enabled_attribute = extensionName
tenant_attribute_ignore = description,businessCategory,extensionName
tenant_allow_create = True
tenant_allow_update = True
tenant_allow_delete = True

role_tree_dn = ou=Roles,ou=OpenStack,dc=seltzer,dc=net
role_objectclass = organizationalRole
role_id_attribute = cn
role_name_attribute = cn
role_member_attribute = roleOccupant
role_allow_create = True
role_allow_update = True
role_allow_delete = True

Now restart the keystone service (service keystone restart or service openstack-keystone restart).  Now to test authentication, type keystone user-list.  Assuming that you’ve got the user name (samAccountName) and password of your Active Directory user exported in your bash session, or pasted on the end of the command, you should get back a user list from Active Directory.

 

root@localhost:~# keystone user-list
+---------------+---------------+---------+-------+
|       id      |      name     | enabled | email |
+---------------+---------------+---------+-------+
| Administrator | Administrator |   True  |       |
|     Guest     |     Guest     |  False  |       |
|   demo_user   |   demo_user   |   True  |       |
|     glance    |     glance    |   True  |       |
|     krbtgt    |     krbtgt    |  False  |       |
|    ldapuser   |    ldapuser   |   True  |       |
|     admin     |     admin     |   True  |       |
+---------------+---------------+---------+-------+
root@localhost:~#

Things to Note

Of course, your keystone server must be able to resolve the DNS name of your Active Directory domain, so make sure /etc/resolv.conf points to a DNS server that can resolve your domain.  Also note that the user_id_attribute should be set to cn.  The attribute that you use for user_name_attribute is what you may want to change depending on what your users use to logon to Windows, either sAMAccountName or userPrincipalName.  Note that these are case sensitive!

Caveats

The caveat, which I’ve already mentioned, is that the standard graphical tool Active Directory Users and Computers can’t be used to create and manage the objects.  This is perhaps not such a big deal if your AD admins are savvy, but may be a drag for the average administrator.

Adding Services

Next we need to add the service tenant, user accounts for the services, and add the service accounts to the required roles.  Let’s take care of glance.

First, in Active Directory Users and Computers, create a user object for glance (cn=glance) and set the password. The username and password would match what you’ve got in the keystone_authentication section of your glance-api.conf and glance-registry.conf.

Next, in ADSIEDIT, our Roles OU, edit the admin role object, edit the roleOccupant attribute, and add the dn of the glance user to the list (our admin user is already in there as well).  Then in our Projects/service OU, create an organizationalRole object and add our glance user’s dn as a roleOccupant, and create a groupOfNames object, name: serviceUsers, and add the glance user dn as a member.

Now, we can test glance.

 

root@localhost:~# glance image-create --is-public true --disk-format qcow2 --container-format bare --name "Ubuntu12.04" < ubuntu-12.04-server-cloudimg-amd64-disk1.img
+------------------+--------------------------------------+
| Property         | Value                                |
+------------------+--------------------------------------+
| checksum         | ec0a41eda5fb5efb8b08cfebe4a61f64     |
| container_format | bare                                 |
| created_at       | 2013-08-09T15:14:29                  |
| deleted          | False                                |
| deleted_at       | None                                 |
| disk_format      | qcow2                                |
| id               | e0ce72f2-4eb0-4108-a07e-b561c27dd979 |
| is_public        | True                                 |
| min_disk         | 0                                    |
| min_ram          | 0                                    |
| name             | Ubuntu12.04                          |
| owner            | admin                                |
| protected        | False                                |
| size             | 252510208                            |
| status           | active                               |
| updated_at       | 2013-08-09T15:14:31                  |
+------------------+--------------------------------------+
root@localhost:~#

Notice that instead of displaying the uuid of the owner, the user’s Active Directory cn is displayed. I’m not sure if there are any negative implications of this within OpenStack or not.  Certainly, the cn in Active Directory is not assured to be unique, although it would be advisable to make sure it is.  Only distinguishedName, samAccountName and userPrincipalName is guaranteed to be unique.  So there’s the potential for permissions conflicts to occur if you’re not careful.

If I lost you while creating objects.  Here’s an LDAP dump of the objects I created in Active Directory:

 

dn: OU=OpenStack,DC=seltzer,DC=net
objectClass: organizationalUnit
ou: OpenStack
distinguishedName: OU=OpenStack,DC=seltzer,DC=net
name: OpenStack

dn: OU=Projects,OU=OpenStack,DC=seltzer,DC=net
objectClass: organizationalUnit
ou: Projects
distinguishedName: OU=Projects,OU=OpenStack,DC=seltzer,DC=net
name: Projects

dn: OU=admin,OU=Projects,OU=OpenStack,DC=seltzer,DC=net
ou: admin
distinguishedName: OU=admin,OU=Projects,OU=OpenStack,DC=seltzer,DC=net
name: admin
extensionName: TRUE

dn: CN=admin,OU=admin,OU=Projects,OU=OpenStack,DC=seltzer,DC=net
objectClass: organizationalRole
cn: admin
roleOccupant: CN=admin,CN=Users,DC=seltzer,DC=net
distinguishedName: CN=admin,OU=admin,OU=Projects,OU=OpenStack,DC=seltzer,DC=net
name: admin

dn: CN=adminUsers,OU=admin,OU=Projects,OU=OpenStack,DC=seltzer,DC=net
objectClass: groupOfNames
cn: adminUsers
member: CN=admin,CN=Users,DC=seltzer,DC=net
distinguishedName: CN=adminUsers,OU=admin,OU=Projects,OU=OpenStack,DC=seltzer,DC=net
name: adminUsers

dn: OU=service,OU=Projects,OU=OpenStack,DC=seltzer,DC=net
objectClass: organizationalUnit
ou: service
distinguishedName: OU=service,OU=Projects,OU=OpenStack,DC=seltzer,DC=net
name: service
extensionName: TRUE

dn: CN=admin,OU=service,OU=Projects,OU=OpenStack,DC=seltzer,DC=net
objectClass: organizationalRole
cn: admin
roleOccupant: CN=glance,CN=Users,DC=seltzer,DC=net
distinguishedName: CN=admin,OU=service,OU=Projects,OU=OpenStack,DC=seltzer,DC=net
name: admin

dn: CN=serviceUsers,OU=service,OU=Projects,OU=OpenStack,DC=seltzer,DC=net
objectClass: groupOfNames
cn: serviceUsers
member: CN=glance,CN=Users,DC=seltzer,DC=net
distinguishedName: CN=serviceUsers,OU=service,OU=Projects,OU=OpenStack,DC=seltzer,DC=net
name: serviceUsers

dn: OU=Roles,OU=OpenStack,DC=seltzer,DC=net
objectClass: organizationalUnit
ou: Roles
distinguishedName: OU=Roles,OU=OpenStack,DC=seltzer,DC=net
name: Roles

dn: CN=admin,OU=Roles,OU=OpenStack,DC=seltzer,DC=net
objectClass: organizationalRole
cn: admin
ou: admin
roleOccupant: CN=glance,CN=Users,DC=seltzer,DC=net
roleOccupant: CN=admin,CN=Users,DC=seltzer,DC=net
distinguishedName: CN=admin,OU=Roles,OU=OpenStack,DC=seltzer,DC=net
name: admin

dn: CN=Member,OU=Roles,OU=OpenStack,DC=seltzer,DC=net
objectClass: organizationalRole
cn: Member
ou: Member
distinguishedName: CN=Member,OU=Roles,OU=OpenStack,DC=seltzer,DC=net
name: Member

To add the other services to AD, simply create AD user accounts for them, add them to the organizationalRole object and the groupOfNames object in the service project OU, and add them to the admin organizationalRole object as well. Here’s a link to another LDAP export where I’ve added Cinder, Nova and Swift.

I know it’s a lot of objects to manage by hand.  I’m currently working on an admin GUI to make things easier. Stay tuned…

Configuring the Horizon Dashboard

If you’ve gotten to this point, you should be able to logon to the dashboard without any trouble, assuming that you added yourself an account to at least one project and role (preferably admin).  However, if you now try to do anything with projects, such as modify memberships or quotas, you’ll get an error,  This seems to be due to the version 3 of the identity API missing some calls that haven’t been implemented yet.  However, we can configure the dashboard to use version 2 of the API and this will enable some of the functionality.

In reality, now that our objects are in Active Directory, we should use AD to manage projects and roles, at least from a membership perspective.  However, project quota settings are not stored in AD, and using the version 3 API, the quota controls seem to be broken in the dashboard.  The only way I’ve found to manage quotas outside the dashboard is to use the nova command line.

So, we should use the version 2 API in the dashboard for now, until the missing calls have been implemented (hopefully in the icehouse release?).  To configure the dashboard, edit the /etc/openstack-dashboard/local_settings.py file, and find the following lines. Uncomment the lines and change the version from 3 to 2.0 as shown.

 

OPENSTACK_API_VERSIONS = {
    "identity": 2.0
}

Next find the following lines and change the name to ldap and the can_edit_user to False as shown

 

OPENSTACK_KEYSTONE_BACKEND = {
    'name': 'ldap',
    'can_edit_user': False,
    'can_edit_group': True,
    'can_edit_project': True,
    'can_edit_domain': True,
    'can_edit_role': True
}

Now restart the web server (service apache2 restart on Ubuntu), and now the dashboard should be able to manage project quotas.  Note that if you want to manage project memberships from within the dashboard, then the ldap bind user specified in keystone.conf should be granted read/write permissions to the projects OU tree and the roles OU tree in AD, but you might consider this a security risk, as any user granted admin rights in OpenStack will then be able to modify these objects in AD via the bind user.

Good luck with your installation!  I know this is complicated, but I think AD authentication is critical for mainstream enterprise adoption of OpenStack.

44 thoughts on “OpenStack Icehouse – Active Directory Integration

  1. Rob Duncan

    Nice One Brian, maybe you should write for openstack wiki -as this is much better!

    Reply
  2. Michael Petersen

    I posted on the other one too. It seems counterintuitive but they seem to want to switch around the way you are using ID and Name. You’d assume that the USER_ID would be the users login, but apparently they allow the USER_NAME. If you had only USER_NAME then you’d assume that’s the login but then they confuse you with the other ID term.

    user_id_attribute = cn

    user_name_attribute = sAMAccountName

    Reply
    1. Barrow Kwan

      Hi Michael,
      I am having the same issue and was able to authenticate after I swap the user_id_attribute and user_name_attribute. However, when I login to the dashboard, I got some error ( like not authorized… unable to retrieve usage… ). I think the role and tenant will also need to change but i am not sure what exactly that will be. Did you successfully integrate AD with your Openstack? do you mind share the configuration? thanks!

      Reply
  3. Brian Seltzer

    You’d think OpenStack (and Microsoft for that matter) would endeavor to stick to the LDAP RFS’s and use common attribute names. We’re entering a time in history when we’re going to be doing IAM across hybrid clouds, SaaS providers, etc. Can we decide on what to call a user ID? LOL!

    Reply
  4. Michael Petersen

    I spent a few hours a couple months ago with Grizzly and this guide helped a bit. Then today I setup Havana and was messing around with it and figured I’d try swapping it since I was having no luck. If you just see user_name then you’d think it’s the login ID, but when you see ID and NAME it’s really confusing.

    Did that at least work for you? I’ve got it setup using AD for auth (users and groups) and SQL for Tenants/Roles. Troubleshooting the ID vs NAME issue was one of the most frustrating things I have ran into, even more so than the OVS plugin breaking on an upgrade from quantum to neutron.

    Reply
  5. Brian Seltzer

    I’ve got users, groups and tenants all in AD as configured in this post, but my problem is that I’ve got multiple AD forests, and no way to authenticate users from more than one forest. We do have a VIS server which can proxy LDAP queries to multiple forests, that will only work if members of a tenant all belong to the same forest, because the groupOfnames and organizationalRole objects can only contain members that are in the local forest. This is kind of a show stopper for me. I either have to create new user accounts in one forest for all my OpenStack users, or go back to SQL auth.

    Reply
  6. madhura s

    Thank you for a very useful article Brian! One quick question. How does this keystone integration work when you have multiple active directory domains?

    Reply
    1. madhura s

      never mind, I just saw your most recent discussion post that kinda answered my question. thanks!

      Reply
  7. Brian Seltzer

    Unfortunately, this configuration won’t work across multiple domains. All the users and other objects need to be in the same domain. As a result, I’ve decided that anyone requiring access to OpenStack in my organization should have a privileged account created in the central domain to use for OpenStack, I’ve got 11 domains 🙂

    Reply
    1. vix

      url = ldap://seltzer.net; ldap://brain.net

      Not sure but in moodle , this is how it works , may be you can try this out.
      Since thats also Linux kinda LDAP connector , I assume it may work.

      Apologies if you find this silly.

      Reply
      1. Brian Seltzer

        I’ll give that a try. I’m planning to update this article for icehouse so I’ll be doing a fresh round of testing shortly. Thanks.

        Reply
        1. vix

          What is your plan , I can try out for CentOS , I Know the current one is on Ubuntu

          Reply
  8. Barrow Kwan

    Brian,

    This is a great article. I got my AD integration working slightly ( not 100% working ). As per Michael said, I need to change the user_id_attribute and user_name_attribute in order to get , at least, the authentication working. If I don’t swap it, keystone is not able to find any of the user. ( log in keystone : WARNING keystone.common.wsgi [-] Authorization failed. Could not find user, admin. ). I saw you have it working. Unfortunately, this same configuration didn’t work for me. I am wondering if something is missing on the Windows server side? another question, I have is what is the exact steps to add new projects and associate a user ( as a member ) to the project?

    thanks

    Reply
      1. Brian Seltzer

        Yeah, I’m not sure what’s going on there, but in any case, I’ve updated the configuration above so that it works correctly. I also discovered that the attribute names are case-sensitive, so sAMAccountName works, samAccountName does not. That behavior comes from python-ldap.

        Reply
    1. Michael Petersen

      You’ll need to remove the database entries for the previous users you added, such as the first admin user. It’s under the user table in the keystone db.

      Then you’ll need to add users to the “admin” role to be able to login. I setup a “cloudadmin” in AD so that I could map it to the admin role. You can do:

      keystone user-list (get the user ID you want to use such as “cloudadmin”)
      keystone user-role-add –user=cloudadmin –role=admin –tenant=admin

      Basically make the AD users admins on the tenants.

      I’m using ldap for identity and sql for assignment. It makes life a little easier for me so that I don’t have to setup more on AD for roles/tenants.

      Reply
  9. Hüseyin Can

    After following your guide I can now authenticate users on the AD. When I try to create a Project I get an error in Horizon saying: Error: Unable to create project “test”.
    In the keystone.log file I get this error:
    ERROR keystone.common.wsgi [-] {‘info’: “00002081: NameErr: DSID-03050AE0, problem 2003 (BAD_ATT_SYNTAX), data 0, best match of:nt’ou=ddd6087895264b5e8aedf99ecf4d4376,ou=Projects,ou=Openstack,dc=engineering,dc=com’n”, ‘desc’: ‘Invalid DN syntax’}.

    Do you have an idea about this problem?
    By the way I’m on Havana.

    Reply
  10. Brian Seltzer

    I haven’t tried adding a project through Horizon. I’ve only created them by hand in AD, by creating the OU and other objects as explained in the article. I recommend you do it by hand, but I’ll setup a test when I get a chance…

    Reply
  11. Brian Seltzer

    I looks like the behavior has changed in Havana. I can’t seem to use samAccountName successfully now, where it worked in Grizzly. Looks like I’ll have to use cn for my user_id_attribute and user_name_attribute until they fix the darn ldap provider…

    Reply
  12. Brian Seltzer

    I’ve figured out that the attribute names are case sensitive, and also that the user_id_attribute really needs to be cn. That’s OK however, as it’s the user_name_attribute that specifies the logon name. So:

    user_id_attribute = cn
    user_name_attribute = sAMAccountName

    works. Note the case of sAMAccountName, it’s critical to get this exactly right.

    Reply
    1. Michael Petersen

      Let me know if you want some of the config files I used for my Centos 6.5 setup. I’ve got it working with keystone v3 + horizon so it now shows domains/projects/users/group/roles. The backend is:

      identity = ldap
      assignment = sql

      It seems easier to use sql for assignment instead of setting up groups/roles in AD. Although some people may want to have everything in AD.

      Reply
      1. Brian Seltzer

        Yeah if you can post a link to your config that would be great. As for using SQL for assignment, I agree it’s a good option technically, however, I think that organizations using Active Directory expect to keep access authorization in AD, so that they can easily report on who has access to what. SQL assignment unfortunately moves access control out of AD.

        Reply
  13. Deep

    Hello,

    I have configured keystone with AD and i want to use swift with keystone(AD), but i stuck in some issue. Following are the details of setup

    I followed your blog to create following entities in AD.

    dn: OU=OpenStack,DC=DEEP,DC=COM

    dn: OU=Projects,OU=OpenStack,DC=DEEP,DC=COM

    dn: OU=admin,OU=Projects,OU=OpenStack,DC=DEEP,DC=COM

    dn: CN=adminUsers,OU=admin,OU=Projects,OU=OpenStack,DC=DEEP,DC=COM

    dn: CN=admin,OU=admin,OU=Projects,OU=OpenStack,DC=DEEP,DC=COM

    dn: OU=service,OU=Projects,OU=OpenStack,DC=DEEP,DC=COM

    dn: CN=swift,OU=service,OU=Projects,OU=OpenStack,DC=DEEP,DC=COM

    dn: CN=serviceUsers,OU=service,OU=Projects,OU=OpenStack,DC=DEEP,DC=COM

    dn: CN=admin,OU=service,OU=Projects,OU=OpenStack,DC=DEEP,DC=COM

    dn: OU=Roles,OU=OpenStack,DC=DEEP,DC=COM

    dn: CN=admin,OU=Roles,OU=OpenStack,DC=DEEP,DC=COM

    dn: CN=Member,OU=Roles,OU=OpenStack,DC=DEEP,DC=COM

    with Administrator user i am able to create the container and object. but with swift user it is giving error “Unauthorised. Check username, password and tenant name/id”. Am i missing anything in setup ?

    Another Query:
    How do i enable all existing users from CN=users from AD, to create container/object in swift with this setup ? Do i need to add them to specific role or tenant on AD using ADSIedit ?

    Openstack version :
    openstack-swift-proxy-1.11.0-1.el6.noarch
    openstack-utils-2013.2-3.el6.noarch
    openstack-swift-plugin-swift3-1.7-1.el6.noarch
    openstack-swift-1.11.0-1.el6.noarch
    openstack-keystone-2014.1-0.3.b2.el6.noarch

    Reply
    1. Brian Seltzer

      Hi Deep. Just as you created admin and service projects, you need to create a project and make one or more users a user of that project. The user also needs to be in the member role. Once that’s done, Keystone will be able to identify the user’s tenant ID and swift authentication should work.

      Reply
      1. Deep

        Hello Brian,
        I created 2 users, swiftuser1 and swiftuser2 along with following entities

        OU=swiftProject,OU=Projects,OU=OpenStack,DC=DEEP,DC=COM
        CN=admin,OU=swiftProject,OU=Projects,OU=OpenStack,DC=DEEP,DC=COM
        CN=swiftusers,OU=swiftProject,OU=Projects,OU=OpenStack,DC=DEEP,DC=COM

        swiftuser1 and swiftuser2 are member of swiftusers.

        I also added swiftuser1 and swiftuser2 as a role occupant in CN=Member,OU=Roles,OU=OpenStack,DC=DEEP,DC=COM

        still i am getting same error (Unauthorised. Check username, password and tenant name/id) when i tried to create the container using user swiftuser1/swiftuser2 (Tenant=swiftProject).

        Am i still missing something ?

        Reply
          1. Deep

            As you suggested i created the member OrganizationalRole object
            CN=member,OU=swiftProject,OU=Projects,OU=OpenStack,DC=SONAS,DC=COM

            swiftuser1 and swiftuser2 are role occupant of it.

            Now error is changed to “swift post CONTAINER_4_SWIFTUSER2

            Container POST failed: http://controller:8080/v1/AUTH_swiftProject/CONTAINER_4_SWIFTUSER2 401 Unauthorized [first 60 chars of response] UnauthorizedThis server could not verify t”

            I can see following errors in /var/log/keystone/keystone.log

            2014-06-11 10:57:17.581 6866 WARNING keystone.openstack.common.versionutils [-] Deprecated: v2 API is deprecated as of Icehouse in favor of v3 API and may be removed in K.

            Errors in /var/log/messages

            Jun 11 10:57:17 node1 proxy-server: Unexpected response from keystone service: {u’error’: {u’message’: u’Could not find role, swift.’, u’code’: 404, u’title’: u’Not Found’}}

            Jun 11 10:57:17 node1 proxy-server: Authorization failed for token 8a769a057b67e97d31461a80cccddc42

            Jun 11 10:57:17 node1 proxy-server: Invalid user token – deferring reject downstream

          2. Deep

            Thank you Brian, I am waiting :).
            meanwhile i am also trying few things with setup, i will update you if there anything.

          3. Deep

            Hello,

            I added swift role under Roles, now i am getting following message in syslog

            Jun 12 03:18:30 node1 proxy-server: Authorization failed for token d2285b87bb950a416c17cccc61d5b6d4

            Jun 12 03:18:30 node1 proxy-server: Invalid user token – deferring reject downstream

            Jun 12 03:18:31 node1 proxy-server: Authorization failed for token 48c7d3e10a1ee23caea2b72a752132ba

            Jun 12 03:18:31 node1 proxy-server: Invalid user token – deferring reject downstream

            Jun 12 03:18:41 node1 proxy-server: Authorization failed for token 1f174dbadfab030ad970cc247b4fa392

            Jun 12 03:18:41 node1 proxy-server: Invalid user token – deferring reject downstream

            Jun 12 03:18:42 node1 proxy-server: Authorization failed for token e2e6e8b09916ac22dd714e3dbc155902

            Jun 12 03:18:42 node1 proxy-server: Invalid user token – deferring reject downstream

            not sure what is missing now ?

      2. Deep

        Hello Brian,
        I created two user swiftuser1 and swiftuser2 in AD. I also created following entities in AD

        OU=swiftProject,OU=Projects,OU=OpenStack,DC=DEEP,DC=COM

        CN=admin,OU=swiftProject,OU=Projects,OU=OpenStack,DC=DEEP,DC=COM

        CN=swiftusers,OU=swiftProject,OU=Projects,OU=OpenStack,DC=DEEP,DC=COM

        swiftuser1 and swiftuser2 are member of CN=swiftusers

        swiftuser1 and swiftuser2 are role Occupant in CN=Member,OU=Roles,OU=OpenStack,DC=SONAS,DC=COM

        But still i getting similar error “Unauthorised. Check username, password and tenant name/id” while creating container using swiftuser1 and swiftuser2 (Tenant=swiftProject ).

        Am i still missing something ?

        Reply
  14. Deep

    Hello Brian,
    Please help me in understanding the Roles you created in AD ? you have created admin and member role in OU=Roles and there is also admin role under OU=Project/admin as well under OU=Project/service? When all these admin/member roles are being used ?
    are these roles mandatory ?
    Also is it mandatory to have admin and service tenant ?

    Reply
    1. Brian Seltzer

      The roles in the Roles OU are OpenStack Role Objects. The roles in the Projects are user-role associations within the project. I know it’s a bit confusing, but that’s how OpenStack roles work.

      Reply
  15. Wyllys

    Im using Windows Server 2008 r2. I dont see any option in the ADSIEdit tool for creating organizationalRole objects as described above. I can create the new organizationalUnits with the AD Admin Center tool, but ADSIEdit wont let me create the organizationalRoles and I can’t see how they are supposed to get created.

    Does 2008r2 use an older, less functional ADSIEdit utility or am I missing something?

    Reply
    1. Brian Seltzer

      I too am using Windows 2008 R2. In AD Users and Computers, make sure you select View – Advanced Features in the menu. Then, you will see an attribute editor tab in the properties pages of an object. As for ADSIEDIT, you right click a container and select New – Object. You should see the organizationalRole and groupOfNames as choices in the objectClass selector. These are standard object classes in Windows 2008. No schema changes required.

      Reply
      1. Wyllys

        Thats not working for me. I did enable the Advanced Features in the AD Users/Computers window and I do see the attribute editor, but thats not the problem.

        My problem is with the ADSIEdit tool – when I create a new organizationalUnit, then right-click “New…”, “Object” is not an option. The options in the “New” menu are: Computer, Contact, Group, InetOrgPerson, msImaging-PSPs, MSMQ Queue Alias, Organizational Unit, User, Printer, Shared Folder.

        I think I worked around this by manually creating the entries with ‘ldapadd’ from my remote client, though.

        The last issue Im seeing is that my user is recognized and authenticated, but the ldap module is looking for something in “UserGroups” and ultimately says that my user is unauthorized to access my tenant.

        My installed keystone package is: 1:2014.1

        Reply
        1. Brian Seltzer

          Hmm. I are you running ADUC from a client? If so, what is the Windows version of the client? I also wonder what your forest and domain functional levels are? Finally, I wonder are you a full admin or do you have delegated rights in AD?

          Reply
          1. Wyllys

            Well, I got it working, albeit with a slightly different schema than you proposed but this was a big help despite my issues with ADSIEdit.

            Thanks!

        2. KZs

          Hi!
          I followed this instructions, and I came across too the “UserGroups” problem. After a series of authentication ldap module searches for “ou=UserGroups,dc=openstack,dc=local” which of course doesn’t exists in this guide, could you share youre solution?

          Another thing is that I traced the communication betweeen the AD server and the keystone, and there’s a lot of seemingly unnecessary authentication. Basicly the ldap module bounds and unbounds for every search request two times(first with the “ldapuser”, second with the authenticating user. Does this normal behaving? Thank for the help!

          Reply
          1. Brian Seltzer Post author

            You should check your LDAP settings in keystone.conf to make sure you are pointing at valid OU locations in your Active Directory.

  16. shiva

    Hi, I have followed your instructions and I am getting below error message

    windows 2008 AD and Juno

    1. Keystone tenant-create –name demo-project –description “Demo Tenant”
    An unexpected error prevented the server from fulfilling your request. (HTTP 500)

    Log:

    keystone.common.wsgi NAMING_VIOLATION: {‘info’: “00002081: NameErr: DSID-03050C3C, problem 2005 (NAMING_VIOLATION), data 0, best match of:\n\t’ou=aff9431869564a538ce4173e5aa07b8a,ou=Projects,ou=OpenStack,dc=keystone,dc=os,dc=com’\n”, ‘desc’: ‘Naming violation’}
    2015-01-26 23:13:58.110 6577 TRACE keystone.common.wsgi

    2. keystone token-get
    ‘NoneType’ object has no attribute ‘has_service_catalog’

    But, keystone tenant-list, keystone user-list ,keystone role-list are working

    Reply

Leave a Reply