Hi All
We’re running the 389 (http://en.wikipedia.org/wiki/389_Directory_Server) LDAP server on Linux and I’m trying to set up a LDAP connection for Ignition.
Has anybody managed to do it? There seem to be a couple of issues using the “Active Directory” LDAP setup when trying to connect to a 389/Redhat LDAP server:
- The Ignition setup seems to expect a property on the users that links them to roles (User Role Attribute). In our setup the property is on the group using the memberUid (using the posixGroup class). There doesn’t seem to be a way to set it up in Ignition so it reads the user membership form the groups.
- Ignition seems to expect the user role list (read from the User Role Attribute) to be in the same format as the Role list using the “Role Attribute Name”. For example the memberUid on the group object is an array of strings with linked user names. If I define a similar custom property on the user object and enter an array of strings (group names) then Ignition still doesn’t work since it is trying to retrieve an object and read the ‘cn’ (or Role Name Attribute) from the string and then fails. If I blank out the Role Name Attribute then it can read the user roles from the custom property but then Ignition can’t read the list of groups since that is a list of objects and it should use the ‘cn’ property. Using our setup the Role Name Attribute should be split into two separate properties so we can read a list of groups using the current Role Name Attribute, but have a different property to define how it would read user membership from the user table.
Point 2 is trying to work around issue 1.
There is also a smaller issue that has a workaround:
- You can’t have a blank username suffix. Ignition tries to add @domain at the back. If your username is cn=Admin you need to split the ‘Admin’ over the username/suffix field. For example Username=Adm, Suffix=in.
It seems that the setup is heavily geared towards the Active Directory structure and doesn’t work well with other LDAP servers.
Has anybody managed to get Ignition working using a LDAP directory other than AD?
[quote=“pvanderm”]It seems that the setup is heavily geared towards the Active Directory structure and doesn’t work well with other LDAP servers.[/quote]Yes, indeed, this is true. In fact, it was written specifically for Active Directory, and to my knowledge, you are the first person to ever hook it up to another LDAP server. And as you’re discovering: this may be a bumpy road.
-
Yes, you’re right. It expects an attribute on the user listing that user’s groups/roles. This is just how it is written and to be honest, I don’t see it changing. So, on to your workaround…
-
Have you tried using fully qualified distinguished names in the user’s group list? That way it will successfully find the object and read its cn?
-
Regarding the suffix: you’re right. This is unfortunate. I guess the @domain thing isn’t used across most LDAP servers huh? I can’t see away around this unless we change it. I know it’s a little cheesy, but we could have some suffix string that it recognized as special, like “-none”
Hi Carl
Thanks for the response.
Regarding issue 2:
Using the fully qualified distinguished names worked! I tried before but only went as far as cn=xxx and not cn=xxx,ou=Groups…
There are also some caching that makes testing difficult since it will work and then eventually stop working. For example if you change the cn=xxx,ou=Groups… back to cn=xxx then it will work for a while and only fail later.
The process doesn’t seem to be very robust. For example if one user has an invalid setting in the new property then no users are returned. If we are manually going to maintain a custom property I see that as a bit of a risk. It would be good if the process handled that error a little bit better than returning nothing at all. Bring in the caching and you can’t be sure that your test actually means that it will still be working later.
But at least that gets us going and we can work on processes to try and make sure we don’t make mistakes when setting up the data!
I actually prefer the cusom property since the ldap server is used for many other applications and the ignition server doesn’t need to know about the 100 other groups the user belongs to nor make it visible to ignition admins that normally don’t have access to that information. Other applications we use normally make use of some kind of mapping/setup to map specific LDAP groups (or groups prefixed with something) to the application in stead of exposing the entire directory. Using the custom property helps us get around that.
Regarding issue 3:
I’m not sure that other LDAP servers do but I wouldn’t think that the domain would be that common unless you are dealing with a domain controller. Don’t mind something like “-none” and putting it description so we know to use it.
Thanks again,
Pieter
Oh good, I’m glad the fully qualified names worked.
I agree - it was too fragile - I’ve made it so that if it fails to read the name of a group, it just returns the dn it was looking up instead and logs a warning.
You know, many of our customers use the “hybrid” style profiles so that the group management is done through Ignition instead of being looked up through LDAP - if managing the groups through LDAP is too cumbersome you might try one of those, that way the group lookup is skipped entirely.
I’ve put a ticket in to add an option to skip the automatic suffix assigning.