Log in

No account? Create an account

Previous Entry | Next Entry

In part 1, the focus is on the automated set up of FreeIPA, Active Directory, and Red Hat OpenStack 4, in Fedora 20, Windows Server 2008, and RHEL 6.5 respectively. The demo uses FreeIPA running on Fedora 20, but Red Hat Enterprise Linux version 7 (RHEL 7) with the built-in Identity Management (IdM) could be used just as well.

This part will show how to put them all together to use a Windows user in OpenStack via FreeIPA LDAP and cross domain trust. Here is the demo video:

What follows below will explain how the Windows users are made available in OpenStack.

Here is the initial OpenStack user list, with the service accounts.

OpenStack Keystone has been set up to use the LDAP Identity backend, using FreeIPA as the LDAP server. These service accounts have entries in FreeIPA, which are shown in the FreeIPA user list.

This FreeIPA has been set up with cross domain trust with the Windows domain ad1dom.test.

FreeIPA supports a "compatibility" subtree. This provides a sort of "virtual view" of data in the server in another suffix, and also, with trusts, data that exists outside of the server. For trust accounts, the trust code makes these entries look like posixAccount entries, and adds uidNumber, gidNumber, etc. values to make them look like a real POSIX user accounts. This is the cn=compat subtree. User entries are in the cn=users subtree. In the demo, the full suffix is cn=users,cn=compat,dc=ipa1dom,dc=test. This shows the output of the ldapsearch command:

ldapsearch -LLL -b cn=users,cn=compat,dc=ipa1dom,dc=test 'objectclass=posixAccount' dn

To show a Windows user account being used in OpenStack, the demo creates a Windows user account.

In order to use this account with OpenStack, it has to first be "pulled" into FreeIPA. Trusts are enabled in FreeIPA with the ipa-adtrust-install command. The option --enable-compat allows user accounts from trusted domains to show up as "virtual" entries in the cn=compat tree. When the trust is set up with the remote domain using ipa trust-add $otherdomain, this allows entries in that domain to be "viewed" in the cn=compat tree. FreeIPA will not automatically "pull" the entries from the trusted domain into the LDAP compat tree. In order for a trusted account to have a virtual entry in the compat tree, the entry must be requested explicitly by user ID. With trusts, this means to do an LDAP search with a search filter like (uid=$remoteuserid@$remotedomain). In the demo, this is (uid=openstack@ad1dom.test). When this user ID is searched for, FreeIPA will create a virtual entry in the cn=compat tree with the POSIX attributes.

In the demo, Keystone is configured to use uid for the user ID attribute. Many of the user specific Keystone commands will do an LDAP search like the above. The demo shows the use of the keystone user-role-add command, which will do the above LDAP search, and also enable the user account for Keystone with a tenant and a role. The command keystone user-get will also do the same LDAP search. In the demo, the keystone user-role-add command is used because it will both pull the AD account into the FreeIPA cn=compat tree and make it available via LDAP, and also enable the user for use in Keystone and OpenStack.

The Windows user can be used to login to the OpenStack dashboard,

and used to start a virtual machine instance.

The demo then shows that the Windows user can be used with the Nova command line client.

If we do the ldapsearch -LLL -b cn=users,cn=compat,dc=ipa1dom,dc=test 'objectclass=posixAccount' dn again in FreeIPA, we can see that the openstack@ad1dom.test user now has an entry in the compat tree.


The virtual entries in the cn=compat tree in LDAP are not persistent. If the FreeIPA LDAP server is restarted, the user entries from the trusts will disappear, and must be searched for explicitly again in order to make them available via LDAP. From an OpenStack perspective, this will cause the trusted users to disappear from user lists e.g. they will not be in the list of users in the dashboard, nor in the output of the keystone user-list command. Using OpenStack, the easiest way to make them available in LDAP again is to use the keystone user-get command - for example

keystone user-get openstack@ad1dom.test

The users from the trusted domain are stored in sssd. If the connection with Windows is lost (network, machine is down), the users will still be available from sssd.


( 2 comments — Leave a comment )
Ramon Acedo
Sep. 2nd, 2014 11:51 am (UTC)
Very nice demo. Thanks for sharing.

I understand that users can't change the password via 'keystone password-update' and admins can't add users, right? (I think this is expected, keystone gets a "INSUFFICIENT_ACCESS: {'info': "Insufficient 'add' privilege to the 'userPassword' attribute", 'desc': 'Insufficient access'}").
Sep. 2nd, 2014 01:16 pm (UTC)
I'm not sure. I suppose you could add access control to IPA to allow users to reset their passwords, and to allow the admin user to add users.
( 2 comments — Leave a comment )