VMware Cloud Community
compwizpro
Enthusiast
Enthusiast
Jump to solution

Guidelines on configuring VMware Integrated Openstack with LDAP authentication against MS AD

We just deployed VIO 3.0 and are trying to configure it with Active Directory authentication.  We have an LDAP config that VIO accepts but nobody can login.  Does anyone have any pointers on how to configure?

Thanks!

-Michael Richter

1 Solution

Accepted Solutions
compwizpro
Enthusiast
Enthusiast
Jump to solution

Thank you for the help everyone!  We were finally able to figure it out.

Basically we were using the wrong filters for users.  Once we started filtering on the openstack group we created in AD, things started working a lot better.

We did end up having to use CLI to assign initial group access. 

As far as the AD Identity Source configuration looks in the GUI, here are what our settings look like.  We created a VIOUser account to bind to the domain and a VIO_Users group that we placed AD user accounts in that we wanted to grant login capability to VIO.

Domain Name:  example.com

Bind user / password:  User that is a member of the domain.

User Tree DN:  OU=Users,DC=example,DC=com

User filter: (memberOf=CN=VIO_users,OU=Groups,DC=example,DC=com)

Group tree DN:  OU=Groups,DC=example,DC=com

Advanced settings:

Encryption: SSL

Host name:  <domain controller 1>.example.com, <domain controller 2>.example.com

Port: 636

User objectclass: person

User ID attribute: sAMAccountName

User name attribute: sAMAccountName

User mail attribute: mail

User password attribute: userPassword

Group objectclass: group

Group ID attribute: cn

Group name attribute: sAMAccountName

Group member attribute: member

Group description attribute: description


Lastly, these were the steps we performed to configure the initial user accounts in the openstack project:


The next few steps will involve SSH-ing to the Openstack Management Server (OMS) and configuring the initial user accounts and related access to Openstack projects.

Note: Whatever name your domain is, VIO refers to it as 'default'.

  1. Determine the IP address of the OMS so you can SSH into it. You can find the IP address of the server in the summary screen of VM named 'management-server'. The IP address should be in the port group that was used for management.
  2. SSH into that machine as 'viouser' and use the password that you specified for the 'admin' user when you built VIO.
  3. Once logged into the OMS, you will use the OMS as a jump-off point to the two controller VMs. The reason for this is ease of use since the OMS uses password-less SSH to get to all of the Openstack specific VMs. You should be able to simply SSH into one of the controllers by typing in 'ssh controller01'. If that doesn't work, 'cat /etc/hosts' will bring up the list of server names.
  4. Once logged into one of the controllers (doesn't matter which one) you need to switch to the root user. The root user has the required files that you need to source into your shell's environment in order to communicate with Keystone. You can switch to the 'root' user from the 'viouser' shell by typing in 'sudo su -' and, if prompted, entering in the password you used for the 'admin' user when you set up VIO.
  5. Source the environment variables. There are two files in the root home directory, one is called 'cloudadmin.rc' and the other is 'cloudadmin_v3.rc'. The VIO version we are using is version 3, and that version uses Keystone v3 so we need to source the 'cloudadmin_v3.rc' file. We do that by typing in 'source ~/.cloudadmin_v3.rc' in the root shell.
  6. Now that we have sourced our environment, we can begin to issue commands that will communicate with the Openstack APIs.
  7. As a test, type in 'openstack user list –domain default' into the CLI. The Openstack client will prompt you for a password, make sure you use the same password that you used for the 'admin' user when you initially setup VIO.
  8. The output from the previous step should list out all the users that you have added to the group you specified in the LDAP configuration above. If this list matches what you expect, you can proceed.
  9. List out the active projects with 'openstack project list'. Once more with the password.
  10. If this is a freshly installed VIO, you will only see the 'service' and 'admin' projects. You do NOT want to grant users direct access to these projects. If needed, create a project with the following command 'openstack project create –domain default –enable <project name>' command. This project will most likely be for your administrator users.
  11. Retrieve a list of roles by typing in 'openstack role list'. Openstack will prompt you for a password again.
  12. Grant users access to Projects by adding them to one or more of these roles. If this is a vanilla VIO install, you'll probably want to grant access to the admins first. Do this by 'openstack role add --user <user ID> admin'.
  13. From here, test logging into the Horizon dashboard using 'default' for the domain and your AD username and password. Once logged in as an admin user, you can manage projects from either Horizon or the CLI.

Hope that helps others out there.

Thanks again!

View solution in original post

11 Replies
ssurana
VMware Employee
VMware Employee
Jump to solution

Can you try using "Default" as the domain name.

Also, if you can provide some more details around what configuration have you done as well as what steps did you complete.

In VIO 3.0 we configure keystone with multi-domain backend. For the LDAP configuration we setup the LDAP backend on the "Default" domain. Thus you will need to specify the "Default" domain on the horizon login screen in order to login.

Hope this information helps.

~ Sidharth

Reply
0 Kudos
zlao
Enthusiast
Enthusiast
Jump to solution

By default, no LDAP users are allowed to login as there is no active project

associated with LDAP users in a fresh deployment.

In such a case, you need to assign the "admin" or "member" role for LDAP users

with the administrative user "admin" created in the "local" domain

for the first login.

Reply
0 Kudos
compwizpro
Enthusiast
Enthusiast
Jump to solution

Thank you for that information.  We can login with the default domain and admin credentials but there is no way we can tell to specify ldap users or create a new project for a domain.

When we try to configure ldap settings, we specify the OU where all our users are created under in AD with the following User query filter:

(&(objectCategory=person)(objectClass=user)(!(|(objectClass=computer)(msExchResourceMetaData=ResourceType:Room)(userAccountControl:1.2.840.113556.1.4.803:=2))))


However, we get the error saying more than 1000 users were returned.  Have you had any success with being able to limit the users so it's less than 1000 and what did the query filter look like?


Thanks!

Reply
0 Kudos
compwizpro
Enthusiast
Enthusiast
Jump to solution

ssurana - Thanks for the info.  I was able to get in using the default domain but ran into more trouble.  Not sure if you saw but I posted some of the config I am using at the bottom of the thread. 

Thanks!

Reply
0 Kudos
zlao
Enthusiast
Enthusiast
Jump to solution

You can always use CLI to assign roles for LDAP users.

$ source ~/cloudadmin_v3.rc

$ openstack --os-identity-api-version 3 --os-user-domain-name local --os-project-name admin --os-region-name nova project create --domain default --description "Demo Project" --or-show demo

$ openstack --os-identity-api-version 3 --os-user-domain-name local --os-project-name admin --os-region-name nova role add --project demo --project-domain default --user SOMEUSER@SOMECORP.COM --user-domain default admin


As for limiting the results, you may add a new condition at end the of your filter.


(&(objectCategory=person)(objectClass=user)(!(|(objectClass=computer)(msExchResourceMetaData=ResourceType:Room)(userAccountControl:1.2.840.113556.1.4.803:=2))))(YOUR_CONDITION_HERE)


You can find a common attribute / value for all users you want them to show up in the result.

Reply
0 Kudos
compwizpro
Enthusiast
Enthusiast
Jump to solution

Thank you for the help everyone!  We were finally able to figure it out.

Basically we were using the wrong filters for users.  Once we started filtering on the openstack group we created in AD, things started working a lot better.

We did end up having to use CLI to assign initial group access. 

As far as the AD Identity Source configuration looks in the GUI, here are what our settings look like.  We created a VIOUser account to bind to the domain and a VIO_Users group that we placed AD user accounts in that we wanted to grant login capability to VIO.

Domain Name:  example.com

Bind user / password:  User that is a member of the domain.

User Tree DN:  OU=Users,DC=example,DC=com

User filter: (memberOf=CN=VIO_users,OU=Groups,DC=example,DC=com)

Group tree DN:  OU=Groups,DC=example,DC=com

Advanced settings:

Encryption: SSL

Host name:  <domain controller 1>.example.com, <domain controller 2>.example.com

Port: 636

User objectclass: person

User ID attribute: sAMAccountName

User name attribute: sAMAccountName

User mail attribute: mail

User password attribute: userPassword

Group objectclass: group

Group ID attribute: cn

Group name attribute: sAMAccountName

Group member attribute: member

Group description attribute: description


Lastly, these were the steps we performed to configure the initial user accounts in the openstack project:


The next few steps will involve SSH-ing to the Openstack Management Server (OMS) and configuring the initial user accounts and related access to Openstack projects.

Note: Whatever name your domain is, VIO refers to it as 'default'.

  1. Determine the IP address of the OMS so you can SSH into it. You can find the IP address of the server in the summary screen of VM named 'management-server'. The IP address should be in the port group that was used for management.
  2. SSH into that machine as 'viouser' and use the password that you specified for the 'admin' user when you built VIO.
  3. Once logged into the OMS, you will use the OMS as a jump-off point to the two controller VMs. The reason for this is ease of use since the OMS uses password-less SSH to get to all of the Openstack specific VMs. You should be able to simply SSH into one of the controllers by typing in 'ssh controller01'. If that doesn't work, 'cat /etc/hosts' will bring up the list of server names.
  4. Once logged into one of the controllers (doesn't matter which one) you need to switch to the root user. The root user has the required files that you need to source into your shell's environment in order to communicate with Keystone. You can switch to the 'root' user from the 'viouser' shell by typing in 'sudo su -' and, if prompted, entering in the password you used for the 'admin' user when you set up VIO.
  5. Source the environment variables. There are two files in the root home directory, one is called 'cloudadmin.rc' and the other is 'cloudadmin_v3.rc'. The VIO version we are using is version 3, and that version uses Keystone v3 so we need to source the 'cloudadmin_v3.rc' file. We do that by typing in 'source ~/.cloudadmin_v3.rc' in the root shell.
  6. Now that we have sourced our environment, we can begin to issue commands that will communicate with the Openstack APIs.
  7. As a test, type in 'openstack user list –domain default' into the CLI. The Openstack client will prompt you for a password, make sure you use the same password that you used for the 'admin' user when you initially setup VIO.
  8. The output from the previous step should list out all the users that you have added to the group you specified in the LDAP configuration above. If this list matches what you expect, you can proceed.
  9. List out the active projects with 'openstack project list'. Once more with the password.
  10. If this is a freshly installed VIO, you will only see the 'service' and 'admin' projects. You do NOT want to grant users direct access to these projects. If needed, create a project with the following command 'openstack project create –domain default –enable <project name>' command. This project will most likely be for your administrator users.
  11. Retrieve a list of roles by typing in 'openstack role list'. Openstack will prompt you for a password again.
  12. Grant users access to Projects by adding them to one or more of these roles. If this is a vanilla VIO install, you'll probably want to grant access to the admins first. Do this by 'openstack role add --user <user ID> admin'.
  13. From here, test logging into the Horizon dashboard using 'default' for the domain and your AD username and password. Once logged in as an admin user, you can manage projects from either Horizon or the CLI.

Hope that helps others out there.

Thanks again!

Stephane_Grandg
Enthusiast
Enthusiast
Jump to solution

Hi,

as a follow up we have updated our documentation and those steps are now detailed  :


new updated ldap documentation:

http://pubs.vmware.com/integrated-openstack-3/index.jsp#com.vmware.openstack.admin.doc/GUID-01B139D0...

add the clarification that you need to add filter if the queries returns more than a 1000 objects.

Modify the Default Domain Configuration

http://pubs.vmware.com/integrated-openstack-3/index.jsp#com.vmware.openstack.admin.doc/GUID-E961063D...

this include the cli step to add the first ad user as well at the end the steps to address non standard character in username

Reply
0 Kudos
victorkh
Enthusiast
Enthusiast
Jump to solution

Hi, I did all your steps, but in the last step (Grant users to project): If i put the same command, i get an output "Must specify either a domain or project ", is the last command right?

If i put openstack role --user demo@somecorp.com --domain default admin, I get: No user with a name or ID of 'demo@somecorp.com' exists.

if i put openstack role --user demo@somecorp.com --project lab admin, i also get: No user with a name or ID of 'demo@somecorp.com' exists.

Although when i put openstack user list --domain default, I see the user "demo@somecorp.com" listed there.

Any ideas?

Reply
0 Kudos
AMINEat
Enthusiast
Enthusiast
Jump to solution

hello,

i try to acces to cloudadmin_v3.rc but the file does not exist !!!!

any solution !

Reply
0 Kudos
RichJJohnson
Contributor
Contributor
Jump to solution

".cloudadmin_v3.rc" doesn't exist in our install either (doesn't the dot prefix mean its hidden file?). I used just cloudadmin.rc to perform the steps as defined above and it seems to be working, however I am having some issues with the filtering of AD groups so the queiries are not optimal as I'd like and a couple of the commands are lacking syntax but that's identified in the subsequent posts I won't bother to go over them again. 

Reply
0 Kudos
AMINEat
Enthusiast
Enthusiast
Jump to solution

Hii,

thanks, i have an other problem i can import just 100 users not more !!!!! i don't understand why

for information i have more than 100 users

any suggestion !! ??

Reply
0 Kudos