Enhancements to ObjectServer LDAP authentication in 7.4 fixpack 2
GQ4Q_Simon_Knights 060000GQ4Q Comment (1) Visits (815)
Enhancements to the OMNIbus ObjectServer native LDAP support in version 7.4.0 fixpack 2 allows amongst other things: authentication with users in multiple OU's and use of sAMAccountName.
I will discuss the model currently used by the ObjectServer to authenticate with LDAP, restrictions with this and how they are addressed by the fixpack. I will also provide snippets of configuration, concentrating on the differences between the old and new models. Full details of how to configure can be found in the Netcool OMNIbus Information Centre (see references at the end of this blog).
First a whirlwind overview of the LDAP concepts relevant to this article. LDAP databases are hierarchical. They are typically used to store information about users. Individual users are represented by entries in the LDAP database. An entry is uniquely identified by a Distinguished Name (DN). DNs can be considered like fully qualified file paths and LDAP containers can be considered like directories. The Organisational Unit (OU) is a common container type. OU's are often used to represent departments or geographical regions within an organisation.
The existing model for ObjectServer authentication with LDAP.
User details are stored the ObjectServer. If a user is flagged as 'external', the password is not stored in the ObjectServer and an external password manager is used to validate passwords. In our example the ObjectServer is configured to use LDAP as its external password manager. The ObjectServer configuration contains a mapping between ObjectServer UserNames and LDAP Distinguished Names (DN).
For example when 'Some Operator' logs in to an ObjectServer and the ldap.props file is configured to:
DistiguishedName = 'cn=
the ObjectServer maps the user name to:
This works well as a simple authentication method with a number of restrictions:
LDAP search enhancement in version 7.4. fixpack 2
User details are still stored in the ObjectServer. However when configured for LDAP search , the ObjectServer builds a search query using a configured template and retrieves the DN. It then validates using the DN as before. This gives the additional flexibility of allowing searches in multiple OU's and the use of attributes not contained in the DN.
For example when 'Some Operator' logs in and the ObjectServer's ldap.props file is configured with
LDAPSearchFilter = '(cn=%s)' LDAPSearchBase = 'ou=
The ObjectServer issues a query for all entries in the 'Tivoli' branch of the LDAP tree for which have the 'cn' attribute equal to 'Some Operator'. When it finds an entry, the LDAP server returns a DN of 'cn=Some Oper
Backwards compatibility and upgrade considerations
The direct bind function is still available in the ObjectServer and no change will be seen to existing direct bind configurations. To make use of LDAP search, the DistinguishedName parameter should be removed (or commented out) and 'LDAPSearchFilter' and 'LDAPSearchBase' put in.
We have discussed how the ObjectServer authenticates with LDAP and the new capabilities added in fixpack 2. We also looked at the configuration changes exploit the new function. If there any other topics you would are interested in, I'd like to hear from you and I can consider them for a future blog entry. One example being a walk-through of an end-to-end configuration with an LDAP server.