Bright OpenStack 7.3 uses a backend driver to communicate with AD using LDAP.
This keystone backend driver allows the administrator to use both the LDAP and the old SQL driver for the current users.
Integrate and activate driver
In order to integrate and activate this driver the following needs to be done:
#cmsh#openstack#settings%authentication%authbackends%remove sql%add ldap ad%showParameter Value--------------------------------- ------------------------------------------------Assignment driver keystone.assignment.backends.sql.AssignmentIdentity driver keystone.identity.backends.ldap.IdentityRevisionType OpenStackAuthBackendLDAPAlias dereferencing DefaultAllow subtree delete noChase referrals noName adPassword *********Query scope SubtreeSuffix DC=lab,DC=localTLS noURL ldap://lab.localUse dumb member noUsername brightGroup settings <submode>User settings <submode>Use SQL backend for assignments yesSQL Backend <submode>Use connection pool no
Multiple variables can be set, based on the need. A run through with the simplest configuration is shown here:
%set url%set username%set password%set chasereferrals no%set suffix
Configure settings and filters
The usersettings submode and groupsettings submode need to be accessed to configure settings and filters :
%usersettings%showParameter Value-------------------------------- ------------------------------------------------Additional attribute mappingsAllow create noAllow delete noAllow update noDefault project ID attributeEnabled default TrueEnabled emulation noIgnored attributes default_project_id,tenantsRevisionEnabled attribute enabledEnabled attribute inverted noEnabled bit 0FilterGroup member mapped attribute uidID attribute sAMAccountNameMail attribute mailName attribute sAMAccountNameObject class personPassword attribute userPasswordTree DN DC=lab,DC=local
Any of the following variables can be used to match the setup. The following are used as an example:%set idattribute sAMAccountName;%set nameattribute sAMAccountName;%set objectclass person;%set treedn “yourdn”
The filter can be set too:
%set filter “”%..
Groupsettings submode can then be accessed one level up:
%groupsettings%showParameter Value-------------------------------- ------------------------------------------------Additional attribute mappingsAllow create noAllow delete noAllow update noIgnored attributesRevisionDescription attribute descriptionFilterID attribute sAMAccountNameMember attribute memberName attribute cnObject class groupTree DN DC=lab,DC=local
The following values are used here:
%set idattribute sAMAccountName;%set memberattribute member;%set objectclass group;%set threedn <SEARCH TREE>;%..
The configuration can now be committed:
%commit
create ldap domain and project
cmsh can be exited now. From the head node, the following can be executed:
#openstack domain create ldap
openstack-keystone must be restarted on all of the controllers
#cmsh%device%foreach -n controller1..controller3 (services; restart openstack-keystone)
cmsh can be exited now. Users must now be listed for the first time so that OpenStack can create mappings
From the head node, the following is run:
#openstack user list --domain ldap
After, an ldap project must be created, and users must be assigned as members for this project. It is also an option to set up one of the users as admin.
#openstack project create ldap --domain $(openstack domain list -f value | grep ldap | awk ‘{print $1}’)
The following example script can be used to assign all users to the ldap project as members :
for i in $(openstack user list -f value --domain ldap -c Name ); do openstack role add --user $i --project <ldap project id > --user-domain < ldap domain id> member ; done
It is also possible to login using horizon , navigate to the OpenStack dashboard and use the following as input :
domain -> ldapuser -> your AD userpassword -> Your AD password