LDAP integration with SmartCloud Orchestrator v2.3 Davide Cosentino/Italy/IBM July 2014

LDAP integration with
SmartCloud Orchestrator v2.3
Davide Cosentino/Italy/IBM
July 2014
© 2014 IBM Corporation
 SCO-LDAP integration in short
 Single domain vs. multiple domains
 Single domain implementation
 Multiple domains implementation
 Troubleshooting
 Known limitations
 References
 Free questions
2
IBM Software Group | Cloud & Smarter Infrastructure
© 2014 IBM Corporation
LDAP integration in short




3
Designed to enable LDAP users to become accounts of
SCO. Authentication of the users (i.e. “who can login”) is
performed on the LDAP server side. Authorization (i.e.
“what they can do when they have logged in”) is retained in
SCO.
Allows auto-population at first login (i.e. the LDAP user is
created automatically in Keystone just after the first SCO
login)
Works with most common LDAP Servers (e.g. Microsoft
Active Directory or MSAD, OpenLDAP, Tivoli Directory
Server or TDS)
Easy and quick to implement
IBM Software Group | Cloud & Smarter Infrastructure
© 2014 IBM Corporation
Single domain vs multiple domains
 Single domain: all the users from the single LDAP server get registered
into one single SCO domain (for example: the Default domain). Useful for
not too complex users' hierarchy.
 Multiple domains: LDAP users can be registered into different SCO
domains based on administrative considerations
– In this case, domains must be manually predefined in SCO
– Options:
• With single LDAP server and complex hierarchy of users, the
groups of users can be mapped into separate domains
• With multiple LDAP servers, each of them is mapped into a
separate domain
4
IBM Software Group | Cloud & Smarter Infrastructure
© 2014 IBM Corporation
Single domain – How to implement (1)
 The Keystone configuration file /etc/keystone/keystone.conf (located in the
Central Server 2 of the SCO topology) needs to be edited as follows (LDAP
server ip address, dn, etc. are just examples):
Administrative account to
browse the LDAP server, if
anonymous query is not
available
[ldap_pre_auth]
url = ldap://10.10.0.254
user_tree_dn = cn=users,dc=ldap,dc=com
user_name_attribute = cn
user = cn=administrator,cn=users,dc=ldap,dc=com
password = pass00wd
[root]# keystone user-list
+-------------------------------+---------+-user_id_attribute = dn
|
id
| name | en
[auto_population]
default_project = admin
default_role = Member
5
At login, LDAP
users will be
registered into
the “admin”
project with
“Member” role
+-------------------------------+---------+--|CN=x2,CN=Users,DC=ldap,DC=com
|CN=x3,CN=Users,DC=ldap,DC=com
|CN=x5,CN=Users,DC=ldap,DC=com
|CN=x6,CN=Users,DC=ldap,DC=com
|
|
|
|
x2
x3
x5
x6
| Tr
| Tr
| Tr
| Tr
IBM Software Group | Cloud & Smarter Infrastructure
© 2014 IBM Corporation
Single domain – How to implement (2)
ldap_pre_auth section --- more details
With openldap configured,
you can point to your
secure LDAP server by
specifying 'url = ldaps://....'
NOTICE: The SCO
administrator account
admin will already exist in
the local OpenStack
database. Care must be
taken to make sure there
is not an LDAP account
that also has the name
admin, otherwise this will
now supersede the local
admin account.
Can use others, like “mail”,
“sAMAccountName” etc
Notice “mail” should be
combined with
user_mail_attribute = mail
6
IBM Software Group | Cloud & Smarter Infrastructure
© 2014 IBM Corporation
Single domain – How to implement (3)
To the Keystone configuration file /etc/keystone/keystone.conf also add
the following sections (the added stuff is in blue). The filters filter:ldapauth
and filter:autopop are needed to enable authentication to LDAP and autopopulation capabilities:
[filter:ldapauth]
paste.filter_factory =
keystone.middleware.ldapauth:LdapAuthAuthentication.factory
[filter:autopop]
paste.filter_factory = keystone.middleware.autopop:AutoPopulation.factory
[pipeline:api_v3]
pipeline = access_log sizelimit stats_monitoring url_normalize token_auth
admin_token_auth xml_body json_body simpletoken ldapauth autopop debug
stats_reporting ec2_extension s3_extension service_v3
7
IBM Software Group | Cloud & Smarter Infrastructure
© 2014 IBM Corporation
Single domain – How to implement (4)
Once the keystone configuration file has been modified, Keystone needs to be
restarted. Restart Keystone every time you need to make a change to keystone.conf
effective. Don't forget to make a backup copy of the last good working
configuration file before changing it:
[root]# service openstack-keystone restart
Stopping keystone:
[ OK ]
Starting keystone:
[ OK ]
NOTICE. All of the above details (and more) can be found at the following infocenter
page:
<<Configuring LDAP authentication independently of the domain>>
http://www01.ibm.com/support/knowledgecenter/SS4KMC_2.3.0/com.ibm.sco.doc_2.3/c_conf_
LDAP_all.html?lang=en
8
IBM Software Group | Cloud & Smarter Infrastructure
© 2014 IBM Corporation
Single domain – How to implement (5)
To demonstrate the auto-population feature, list the Keystone
users before any LDAP user has attempted a SCO login
[root]# keystone user-list
+----------------------------------+--------+---------+-------+
|
id
| name | enabled | email |
+----------------------------------+--------+---------+-------+
| c26d805cc48343d688de827384768a70 | admin | True
|
|
| 86440f8885464c90b2c98904f2882abb | cinder | True
|
|
| b751f402ff864d53afda29ccef381b40 | glance | True |
|
| 3f0a56f372ec480da3406f9146147df6 | nova | True |
9
IBM Software Group | Cloud & Smarter Infrastructure
© 2014 IBM Corporation
Single domain – How to implement (6)
Suppose now you have an LDAP user named x1. Log into SCO with x1 username
and password. User x1 gets created into Keystone automatically:
[root]# keystone user-list
+----------------------------------+--------+---------+-------+
|
id
| name | enabled | email |
+----------------------------------+--------+---------+-------+
| c26d805cc48343d688de827384768a70 | admin | True |
|
| 86440f8885464c90b2c98904f2882abb | cinder | True |
|
| b751f402ff864d53afda29ccef381b40 | glance | True |
|
| 3f0a56f372ec480da3406f9146147df6 | nova | True |
|
| CN=x1,CN=Users,DC=ldap,DC=com | x1 | True |
|
+----------------------------------+--------+---------+-------+
10
IBM Software Group | Cloud & Smarter Infrastructure
© 2014 IBM Corporation
Single domain – How to implement (7)
SCO UI – final view of the user x1
11
IBM Software Group | Cloud & Smarter Infrastructure
© 2014 IBM Corporation
Multiple domains – How to implement (1)
Suppose we just want to register users into two different domains,
namely Test1 and Test2. We will create those two domains in
SCO and, in them, we will create projects (aka “tenants”) e.g.
proj1 and proj2 (which will be the projects where LDAP users
will be registered by default, based on the domain they belong
to).
12
IBM Software Group | Cloud & Smarter Infrastructure
© 2014 IBM Corporation
Multiple domains – How to implement (2)
Under /etc/keystone create a directory named (e.g.) “domains”
/etc/keystone/domains
in that, create 2 configuration text files named respectively:
[root]# pwd
/etc/keystone/domains
[root]# ll
total 0
-rw-r--r-- 1 root root 0 Jul 22 11:33 keystone.Test1.conf
-rw-r--r-- 1 root root 0 Jul 22 11:33 keystone.Test2.conf
NOTICE. You can choose any other name for the mentioned subdir
and you can also choose to put domain-specific files in the very same
place as the main config file (i.e. /etc/keystone)
13
IBM Software Group | Cloud & Smarter Infrastructure
© 2014 IBM Corporation
Multiple domains – How to implement (3)
Edit the files to add the ldap_pre_auth and auto_population sections
and point to the relevant project. For example for Test1 (same will be
for Test2, replacing proj1 with proj2):
[root]# cat keystone.Test1.conf
[ldap_pre_auth]
url = ldap://10.10.0.254
user_tree_dn = cn=users,dc=ldap,dc=com
user_name_attribute = cn
user = cn=administrator,cn=users,dc=ldap,dc=com
password = pass00wd
user_id_attribute = dn
[auto_population]
default_project = proj1
default_role = Member
14
LDAP users logging into
domain Test1 will be assigned
to project proj1 with Member
role
IBM Software Group | Cloud & Smarter Infrastructure
© 2014 IBM Corporation
Multiple domains – How to implement (4)
The file /etc/keystone/keystone.conf will need to contain a “pointer”
to the domains subdir:
[ldap_pre_auth]
domain_specific_drivers_enabled = True
domain_config_dir = /etc/keystone/domains/
15
IBM Software Group | Cloud & Smarter Infrastructure
© 2014 IBM Corporation
Multiple domains – How to implement (5)
As usual, restart Keystone to make changes effective:
[root]# service openstack-keystone restart
Stopping keystone:
[ OK ]
Starting keystone:
[ OK ]
NOTICE. All of the above details (and more) can be found at the infocenter page:
<<Configuring LDAP authentication on a domain-by-domain basis>>
http://www01.ibm.com/support/knowledgecenter/SS4KMC_2.3.0/com.ibm.sco.doc_2.3/c_conf_LDA
P_domain.html?lang=en
16
IBM Software Group | Cloud & Smarter Infrastructure
© 2014 IBM Corporation
Multiple domains – How to implement (6)
Suppose now you have an LDAP user named x2 that you wish to register into
domain Test1. Log into SCO with x2 username and password, using Test1 as
domain. User x2 gets created into Keystone automatically, with project = proj1:
[root]# keystone user-list
+----------------------------------+--------+---------+-------+
|
id
| name | enabled | email |
+----------------------------------+--------+---------+-------+
| c26d805cc48343d688de827384768a70 | admin |
True |
|
| 86440f8885464c90b2c98904f2882abb | cinder |
True |
|
| b751f402ff864d53afda29ccef381b40 | glance | True
|
|
| 3f0a56f372ec480da3406f9146147df6 | nova | True
|
|
| CN=x2,CN=Users,DC=ldap,DC=com | x2 |
True |
|
17
IBM Software Group | Cloud & Smarter Infrastructure
© 2014 IBM Corporation
Multiple domains – How to implement (7)
Suppose the same for another LDAP user named x3. This time domain will be
Test2 and project = proj2:
[root]# keystone user-list
+----------------------------------+--------+---------+-------+
|
id
| name | enabled | email |
+----------------------------------+--------+---------+-------+
| c26d805cc48343d688de827384768a70 | admin | True |
|
| 86440f8885464c90b2c98904f2882abb | cinder | True |
|
| b751f402ff864d53afda29ccef381b40 | glance | True |
|
| 3f0a56f372ec480da3406f9146147df6 | nova | True |
|
| CN=x2,CN=Users,DC=ldap,DC=com | x2 | True |
|
| CN=x3,CN=Users,DC=ldap,DC=com | x3 | True |
|
+----------------------------------+--------+---------+-------+
18
IBM Software Group | Cloud & Smarter Infrastructure
© 2014 IBM Corporation
Troubleshooting (1)
The keystone.conf file contains a pointer to the Keystone log
configuration file:
# Show more verbose log output (sets INFO log level output)
verbose = true
# Show debugging output in logs (sets DEBUG log level output)
debug = true
log_config = /etc/keystone/logging.conf
And logging.conf on its turn:
[handler_file]
class=logging.handlers.WatchedFileHandler
level=WARNING
formatter=normal_with_name
args=('/var/log/keystone/keystone.log', 'w')
19
So the log file to collect is finally:
/var/log/keystone/keystone.log
IBM Software Group | Cloud & Smarter Infrastructure
© 2014 IBM Corporation
Troubleshooting (2)
OpenLDAP client tools can be useful to troubleshoot several
types of issue. These tools are especially aimed at
understanding if an issue is related to SCO or if it's a problem
in the LDAP server.
On a Linux box (e.g. The Keystone node) they can be installed
in this way:
yum install openldap-clients
Especially handy are ldapsearch and ldapwhoami
NOTICE. You can use the OpenLDAP client tools with any LDAP server (e.g. with
MSAD)
20
IBM Software Group | Cloud & Smarter Infrastructure
© 2014 IBM Corporation
Troubleshooting (3) - ldapsearch
This tool helps with issues related to the LDAP queries which
are performed in the context of the LDAP-SCO integration.
For example, if the section of the keystone.conf is the following:
[ldap_pre_auth]
url = ldap://10.10.0.254
user_tree_dn = cn=users,dc=ldap,dc=com
user = cn=administrator,cn=users,dc=ldap,dc=com
password = pass00wd
You can troubleshoot those parameters as follows:
ldapsearch -H ldap://10.10.0.254 -b cn=users,dc=ldap,dc=com -D
cn=administrator,cn=users,dc=ldap,dc=com -w pass00wd
and determine if the issue is in SCO or is in the LDAP server (e.g.
“user not found” case … is the user missing in the LDAP server? Or
it's just SCO which cannot find it?)
21
IBM Software Group | Cloud & Smarter Infrastructure
© 2014 IBM Corporation
Troubleshooting (4) - ldapwhoami
This tool helps with issues related to a specific user which
cannot login into SCO (“invalid credentials” use case). For
example, suppose you cannot login as user x4. The following
would show that the issue is on the LDAP server:
[root]# ldapwhoami -n -v -D cn=x4,cn=users,dc=ldap,dc=com -H ldap://10.10.0.254 -w Passw0rd
ldap_initialize( ldap://10.10.0.254:389/??base )
ldap_bind: Invalid credentials (49)
additional info: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 775,
v1db1
And vice versa ... suppose you cannot login with user x5. The
following would show that the problem is in SCO. In this case the
keystone.log would become the main help for troubleshooting:
[root@sco-vmw-41-fb keystone]# ldapwhoami -v -n -D cn=x5,cn=users,dc=ldap,dc=com -H ldap://10.10.0.254
-w Passw0rd
ldap_initialize( ldap://10.10.0.254:389/??base )
Result: Success (0)
22
IBM Software Group | Cloud & Smarter Infrastructure
© 2014 IBM Corporation
Known limitations (1)
The auto-population capability is not a replacement for a full directory
synchronization capability. While the plug-in will create a user-record the
first time a user authenticates, it will not, for example, delete that user
record in keystone if the LDAP user record is subsequently deleted. Such a
user would indeed no longer be able to log in to SmartCloud Orchestrator,
but the database cleanup is outside of the scope of the auto-population
capability. If such a full capability is required, then the use of an external
directory synchronization tool is recommended (for example: Tivoli
Directory Integrator).
For details refer to Using external Directory Integration tools with LDAP
authentication:
http://www01.ibm.com/support/knowledgecenter/SS4KMC_2.3.0/com.ibm.
sco.doc_2.3/c_conf_LDAP_external.html?lang=en
23
IBM Software Group | Cloud & Smarter Infrastructure
© 2014 IBM Corporation
Known limitations (2)
Referring to the default_role parameter of the [auto_population]
section of the keystone.conf (or keystone.<domain>.conf) file,
the role assigned here only affects the assignments held within
SCO and Keystone. They do not modify anything that is
actually stored in LDAP. The plug-in does not attempt to
propagate any roles stored explicitly within LDAP, although the
use of an external directory synchronization tool can enable
such a capability.
24
IBM Software Group | Cloud & Smarter Infrastructure
© 2014 IBM Corporation
REFERENCES
SCO 2.3 Infocenter
http://www-01.ibm.com/support/knowledgecenter/SS4KMC_2.3.0/
com.ibm.sco.doc_2.3/c_config_ldap_authentication.html?lang=en
25
IBM Software Group | Cloud & Smarter Infrastructure
© 2014 IBM Corporation
Any questions?
IBM Software Group | Cloud & Smarter Infrastructure
© 2014 IBM Corporation