The Base DN we're using for our LDAP bridge is importing about 8000 users, which makes finding users amongst that somewhat… difficult.
Modifying the structure of our LDAP source is out of our hands (handled by another area within the institution) and while there's been some discussion about improving it, that discussion hasn't progressed very far and any changes would take time.
From playing with an LDAP query tool, I've found a few other Base DN's we can use that respond more quickly - targeting a specific sub-OU which contains a group that we can control for example - leading to two questions:
(1) Is there any reason why we shouldn't have more than one LDAP Bridge setup within one instance of Matrix?
(2) Is there any way to get the LDAP bridge to use an LDAP filter?
You can have more than one, as long as you don't expose the same username in more than one. Matrix attempts to authenticate in the order it sees the external bridges. If you apply permissions to users/groups from one LDAP Bridge, but they are actually getting authenticated by another one, they won't get the permissions assigned properly.
However, if you can setup multiple bridges each pointing at a different set of users, you should be fine. :)
[quote](2) Is there any way to get the LDAP bridge to use an LDAP filter?[/quote]
Not without changing the LDAP code.
Though, if you're using v3.14 or higher, there is a simple way to find an LDAP user using the Quick Search in the administration interface. Just search for:
<asset id>:<fqdn>
So, if your bridge is 1234 and your LDAP FQDN is cn=amiller,dc=squiz,dc=net, you would search for:
1234:cn=amiller,dc=squiz,dc=net
Matrix will then load the Details screen for that user. :) You can then use the right-hand menu to switch to the Linking screen and you can link that user to a user group.
We're using HTTP authentication, so the LDAP Bridge(s) shouldn't be trying to do any authentication separate of that, which should make that a non issue for us?
[quote]However, if you can setup multiple bridges each pointing at a different set of users, you should be fine. :)[/quote]
That's back in the 'restructuring the LDAP directory' territory unfortunately 
[quote]Though, if you're using v3.14 or higher, there is a simple way to find an LDAP user using the Quick Search in the administration interface. Just search for:[/quote]
Ah! Thanks for that tip - I'd remembered it the other day but then forgotten it again.
A followup question however, we have a couple of ldap users linked in to the System Administrators group, including myself. However, there are a couple of bits of the System Management folder in the Asset Map that I get told I don't have permission to access. I'm also having some issues adding people to the System Administrators group (despite having done it last year). Any ideas?
No, it still uses the LDAP Bridge for authentication, so it is an issue. HTTP is the mechanism, LDAP is the source, so it uses both. If your bridges would point at (potentially) the same users, you will have to use a single bridge instead, or else your permissions will be a mess.
[quote]A followup question however, we have a couple of ldap users linked in to the System Administrators group, including myself. However, there are a couple of bits of the System Management folder in the Asset Map that I get told I don't have permission to access. I'm also having some issues adding people to the System Administrators group (despite having done it last year). Any ideas?[/quote]
Make sure your LDAP Bridge is set to "LDAP Backed User" mode. Otherwise, contact Squiz Support. :)
Avi - do you meanthat the LDAP bridge is still trying to do a LDAP bind with whatever user credentials it has for the current user when we're using HTTP Authentication?
Yes.
That's a bind to the ldap server, using the base DN we've specified with the current user's username and password? We have the HTTP Authentication Variable set to 'REMOTE_USER' and our homegrown SSO is handling the authentication such that Matrix never gets anywhere near the current user's password ...
In which case, Matrix does not do a bind -- it uses the default user configured on the bridge to find the user specified in the header and then just loads up the user details automatically (i.e. seamless login in the background). It wouldn't bind as the individual user in this case.
But presumably the problem of multiple ldap bridges potentially causing permissions issues remains, since 49:cn=douglasd... isn't treated the same as 50:cn=douglasd... ?
My lack of access (despite a link from System Administrators) continues, so it looks like a support job for that.
Correct -- the bridge that finds your user account needs to be the same bridge to which permissions are assigned.