Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

i figured out all my config issues!

part of my issue: make sure your ENV variable and keystone_rc file set auth API version to 3 like this

OS_AUTH_URL=http://10.20.10.70:5000/v3/
and not this
OS_AUTH_URL=http://10.20.10.70:5000/v3.0
even though API version 2.0 was like this
OS_AUTH_URL=http://10.20.10.70:5000/v2.0

furthermore, these directions really helped!

https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/integrate_with_identity_service/sec-generic-ldap

And also very importantly here is what my domain specific keystone file looked like:

vi /etc/keystone/domains/keystone.mydom.conf
[ldap]
url = ldap://10.10.10.2
user = ldapuser@mydom.com
password = ldapuserpass
user_tree_dn = ou=Corp,dc=mydom,dc=com
query_scope = sub
user_objectclass = person
user_id_attribute = cn
user_name_attribute = sAMAccountName
user_filter = (memberOf=CN=Openstack Users,OU=Groups,DC=mydom,DC=com)
user_mail_attribute = mail
user_pass_attribute =
user_allow_create = False
user_allow_update = False
user_allow_delete = False

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

This is with the corporate ldap/AD server here at my job. I had my IT team create the "Openstack Users" group in this corporate ldap and add everyone's username who I wanted to give access to Horizon to this group. (they'll be able to login with their "windows credentials"). This allowed me to use the above "user_filter" setting.

Other important settings:
query_scope = sub
(default scope = 1, whatever this is, our ldap seems to have more scope than a standard)
user_id_attribute = cn
user_name_attribute = sAMAccountName
(make sure everyone's login names "windows credentials" are under this CN in your ldap and not some other location)

in my journey I created my own temporary ldap server so I could understand how ldap works and the structure it uses and confirm that openstack was in fact communicating with ldap, so it was helpful to start with a server I could control. Once I got keystone.mydom.conf configured to connect with my temporary ldap server it was slightly easier to configure it to connect to our corporate ldap server.

http://www.thegeekstuff.com/2015/01/openldap-linux/
and
http://www.thegeekstuff.com/2015/02/openldap-add-users-groups/

my test that I was connecting correctly to either ldap server was this command returning users

openstack user list --domain mydom
+------------------------------------------------------------------+----------+
| ID                                                               | Name     |
+------------------------------------------------------------------+----------+
| 3434343434434343430b2a4fc1f7617d0f3a010aea62c444343333333335ab04 | user2    |
| 64560d734e3f5e6e951883bc12a566dgggccb25ea0619a6d71h9jjjkkgh96302 | user1    |

i must of edited the keystone.mydom.conf file 200 times trying different settings, googling and trying again, till I made fwd progress. A typical try would be:

vi /etc/keystone/domains/keystone.mydom.conf
systemctl restart httpd.service (restarts keystone which is needed each conf change)
tail -f /var/log/keystone/keystone.log
openstack user list --domain mydom (on another console, watch the tail command for errors)

these linux ldap commands helped me figure out the (corporate or temporary) ldap server object structure/usage. Any ldap user/pass should be able to search ldap. (google for help on ldapsearch to find different command line options)

ldapsearch -x -h 10.10.10.2 -D 'ldapuser@mydom.com' -W -b 'ou=Corp,dc=mydom,dc=com' -x sAMAccountName=User2 | more
ldapsearch -x -h 10.10.10.2 -D 'ldapuser@mydom.com' -W -b 'ou=Corp,dc=mydom,dc=com' -x sAMAccountName=User1 | grep member -i
ldapsearch -x -h 10.10.10.2 -D 'ldapuser@mydom.com' -W -b 'ou=Corp,dc=mydom,dc=com' -x sAMAccountName=*

in the end IT made me a owner of the "Openstack Users" ldap group they had created for me for this effort. Therefore I will be able to use these linux commands to add users to the group when our team expands...

use this command to see members in the group already, and to get an idea of what the syntax should be for the "member:" line in the "add.ldif" file described next. (the user's full name and not their username will be needed).
ldapsearch -x -h 10.10.10.2 -D 'ldapuser@mydom.com' -W -b 'CN=OpenStack Users,OU=Groups,DC=mydom,DC=com'

ldapmodify -D 'myself@mydom.com' -h 10.10.10.2 -W -f add.ldif
--and the add.ldif file contains--
dn: CN=OpenStack Users,OU=Groups,DC=mydom,DC=com
changetype: modify
add: member
member: CN=Joe Doe,OU=NJJ,OU=AMER,OU=Corp,DC=mydom,DC=com

use this command again, this time to see if your add was successful
ldapsearch -x -h 10.10.10.2 -D 'ldapuser@mydom.com' -W -b 'CN=OpenStack Users,OU=Groups,DC=mydom,DC=com'

i figured out all my config issues!

part of my issue: make sure your ENV variable and keystone_rc file set auth API version to 3 like this

OS_AUTH_URL=http://10.20.10.70:5000/v3/
and not this
OS_AUTH_URL=http://10.20.10.70:5000/v3.0
even though API version 2.0 was like this
OS_AUTH_URL=http://10.20.10.70:5000/v2.0

furthermore, these directions really helped!

https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/integrate_with_identity_service/sec-generic-ldap

And also very importantly here is what my domain specific keystone file looked like:

vi /etc/keystone/domains/keystone.mydom.conf
[ldap]
url = ldap://10.10.10.2
user = ldapuser@mydom.com
password = ldapuserpass
user_tree_dn = ou=Corp,dc=mydom,dc=com
query_scope = sub
user_objectclass = person
user_id_attribute = cn
user_name_attribute = sAMAccountName
user_filter = (memberOf=CN=Openstack Users,OU=Groups,DC=mydom,DC=com)
user_mail_attribute = mail
user_pass_attribute =
user_allow_create = False
user_allow_update = False
user_allow_delete = False
#group_filter =
group_id_attribute = cn
group_member_attribute = member
group_name_attribute = 'OpenStack Users'
group_objectclass = group
group_tree_dn = ou=Corp,dc=dialogic,dc=com

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

This is with the corporate ldap/AD server here at my job. I had my IT team create the "Openstack Users" group in this corporate ldap and add everyone's username who I wanted to give access to Horizon to this group. (they'll be able to login with their "windows credentials"). This allowed me to use the above "user_filter" setting.

Other important settings:
query_scope = sub
(default scope = 1, whatever this is, our ldap seems to have more scope than a standard)
user_id_attribute = cn
user_name_attribute = sAMAccountName
(make sure everyone's login names "windows credentials" are under this CN in your ldap and not some other location)

in my journey I created my own temporary ldap server so I could understand how ldap works and the structure it uses and confirm that openstack was in fact communicating with ldap, so it was helpful to start with a server I could control. Once I got keystone.mydom.conf configured to connect with my temporary ldap server it was slightly easier to configure it to connect to our corporate ldap server.

http://www.thegeekstuff.com/2015/01/openldap-linux/
and
http://www.thegeekstuff.com/2015/02/openldap-add-users-groups/

my test that I was connecting correctly to either ldap server was this command returning users

openstack user list --domain mydom
+------------------------------------------------------------------+----------+
| ID                                                               | Name     |
+------------------------------------------------------------------+----------+
| 3434343434434343430b2a4fc1f7617d0f3a010aea62c444343333333335ab04 | user2    |
| 64560d734e3f5e6e951883bc12a566dgggccb25ea0619a6d71h9jjjkkgh96302 | user1    |

i must of edited the keystone.mydom.conf file 200 times trying different settings, googling and trying again, till I made fwd progress. A typical try would be:

vi /etc/keystone/domains/keystone.mydom.conf
systemctl restart httpd.service (restarts keystone which is needed each conf change)
tail -f /var/log/keystone/keystone.log
openstack user list --domain mydom (on another console, watch the tail command for errors)

these linux ldap commands helped me figure out the (corporate or temporary) ldap server object structure/usage. Any ldap user/pass should be able to search ldap. (google for help on ldapsearch to find different command line options)

ldapsearch -x -h 10.10.10.2 -D 'ldapuser@mydom.com' -W -b 'ou=Corp,dc=mydom,dc=com' -x sAMAccountName=User2 | more
ldapsearch -x -h 10.10.10.2 -D 'ldapuser@mydom.com' -W -b 'ou=Corp,dc=mydom,dc=com' -x sAMAccountName=User1 | grep member -i
ldapsearch -x -h 10.10.10.2 -D 'ldapuser@mydom.com' -W -b 'ou=Corp,dc=mydom,dc=com' -x sAMAccountName=*

in the end IT made me a owner of the "Openstack Users" ldap group they had created for me for this effort. Therefore I will be able to use these linux commands to add users to the group when our team expands...

use this command to see members in the group already, and to get an idea of what the syntax should be for the "member:" line in the "add.ldif" file described next. (the user's full name and not their username will be needed).
ldapsearch -x -h 10.10.10.2 -D 'ldapuser@mydom.com' -W -b 'CN=OpenStack Users,OU=Groups,DC=mydom,DC=com'

ldapmodify -D 'myself@mydom.com' -h 10.10.10.2 -W -f add.ldif
--and the add.ldif file contains--
dn: CN=OpenStack Users,OU=Groups,DC=mydom,DC=com
changetype: modify
add: member
member: CN=Joe Doe,OU=NJJ,OU=AMER,OU=Corp,DC=mydom,DC=com

use this command again, this time to see if your add was successful
ldapsearch -x -h 10.10.10.2 -D 'ldapuser@mydom.com' -W -b 'CN=OpenStack Users,OU=Groups,DC=mydom,DC=com'

i figured out all my config issues!

part of my issue: make sure your ENV variable and keystone_rc file set auth API version to 3 like this

OS_AUTH_URL=http://10.20.10.70:5000/v3/
and not this
OS_AUTH_URL=http://10.20.10.70:5000/v3.0
even though API version 2.0 was like this
OS_AUTH_URL=http://10.20.10.70:5000/v2.0

furthermore, these directions really helped!

https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/integrate_with_identity_service/sec-generic-ldap

And also very importantly here is what my domain specific keystone file looked like:

vi /etc/keystone/domains/keystone.mydom.conf
[ldap]
url = ldap://10.10.10.2
user = ldapuser@mydom.com
password = ldapuserpass
user_tree_dn = ou=Corp,dc=mydom,dc=com
query_scope = sub
user_objectclass = person
user_id_attribute = cn
user_name_attribute = sAMAccountName
user_filter = (memberOf=CN=Openstack Users,OU=Groups,DC=mydom,DC=com)
user_mail_attribute = mail
user_pass_attribute =
user_allow_create = False
user_allow_update = False
user_allow_delete = False
#group_filter =
group_id_attribute = cn
group_member_attribute = member
group_name_attribute = 'OpenStack Users'
group_objectclass = group
group_tree_dn = ou=Corp,dc=dialogic,dc=com
ou=Corp,dc=mydom,dc=com

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

This is with the corporate ldap/AD server here at my job. I had my IT team create the "Openstack Users" group in this corporate ldap and add everyone's username who I wanted to give access to Horizon to this group. (they'll be able to login with their "windows credentials"). This allowed me to use the above "user_filter" setting.

Other important settings:
query_scope = sub
(default scope = 1, whatever this is, our ldap seems to have more scope than a standard)
user_id_attribute = cn
user_name_attribute = sAMAccountName
(make sure everyone's login names "windows credentials" are under this CN in your ldap and not some other location)

in my journey I created my own temporary ldap server so I could understand how ldap works and the structure it uses and confirm that openstack was in fact communicating with ldap, so it was helpful to start with a server I could control. Once I got keystone.mydom.conf configured to connect with my temporary ldap server it was slightly easier to configure it to connect to our corporate ldap server.

http://www.thegeekstuff.com/2015/01/openldap-linux/
and
http://www.thegeekstuff.com/2015/02/openldap-add-users-groups/

my test that I was connecting correctly to either ldap server was this command returning users

openstack user list --domain mydom
+------------------------------------------------------------------+----------+
| ID                                                               | Name     |
+------------------------------------------------------------------+----------+
| 3434343434434343430b2a4fc1f7617d0f3a010aea62c444343333333335ab04 | user2    |
| 64560d734e3f5e6e951883bc12a566dgggccb25ea0619a6d71h9jjjkkgh96302 | user1    |

i must of edited the keystone.mydom.conf file 200 times trying different settings, googling and trying again, till I made fwd progress. A typical try would be:

vi /etc/keystone/domains/keystone.mydom.conf
systemctl restart httpd.service (restarts keystone which is needed each conf change)
tail -f /var/log/keystone/keystone.log
openstack user list --domain mydom (on another console, watch the tail command for errors)

these linux ldap commands helped me figure out the (corporate or temporary) ldap server object structure/usage. Any ldap user/pass should be able to search ldap. (google for help on ldapsearch to find different command line options)

ldapsearch -x -h 10.10.10.2 -D 'ldapuser@mydom.com' -W -b 'ou=Corp,dc=mydom,dc=com' -x sAMAccountName=User2 | more
ldapsearch -x -h 10.10.10.2 -D 'ldapuser@mydom.com' -W -b 'ou=Corp,dc=mydom,dc=com' -x sAMAccountName=User1 | grep member -i
ldapsearch -x -h 10.10.10.2 -D 'ldapuser@mydom.com' -W -b 'ou=Corp,dc=mydom,dc=com' -x sAMAccountName=*

in the end IT made me a owner of the "Openstack Users" ldap group they had created for me for this effort. Therefore I will be able to use these linux commands to add users to the group when our team expands...

use this command to see members in the group already, and to get an idea of what the syntax should be for the "member:" line in the "add.ldif" file described next. (the user's full name and not their username will be needed).
ldapsearch -x -h 10.10.10.2 -D 'ldapuser@mydom.com' -W -b 'CN=OpenStack Users,OU=Groups,DC=mydom,DC=com'

ldapmodify -D 'myself@mydom.com' -h 10.10.10.2 -W -f add.ldif
--and the add.ldif file contains--
dn: CN=OpenStack Users,OU=Groups,DC=mydom,DC=com
changetype: modify
add: member
member: CN=Joe Doe,OU=NJJ,OU=AMER,OU=Corp,DC=mydom,DC=com

use this command again, this time to see if your add was successful
ldapsearch -x -h 10.10.10.2 -D 'ldapuser@mydom.com' -W -b 'CN=OpenStack Users,OU=Groups,DC=mydom,DC=com'