For various reasons we've decided to not use the LDAP bridge. As we still require LDAP authentication I will be developing a new asset authentication_ldap based on authentication_default that will authenticate users from an ldap directory.
Can't you still authenticate using a bridge, even if you dont use it for permissions etc? The LDAP bridge /LDAP authentication assets will be the offically supported LDAP authentication module, so if it cannot authenticate for your bridge then we should fix it up.
Firstly, there is a problem with the LDAP bridge and Active Directory. You need to add the following code at line 104 in fudge/ldap/ldap.inc
ldap_set_option($this->ptr, LDAP_OPT_DEREF, LDAP_DEREF_NEVER);
ldap_set_option($this->ptr, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($this->ptr, LDAP_OPT_REFERRALS, 0);
From memory these lines are only required for a Windows 2003 Active Directory.
My problem isn't with the LDAP bridge. I'm looking for a simple solution that allows the web team to maintain users and, more importantly, group membership in matrix but authenticates the users against an LDAP directory. My understanding is that the bridge doesn't do this. If I use the LDAP bridge then users/group membership comes from the directory and the web team can't add users to groups created inside matrix.
There are a number of reasons I want users/groups maintained in matrix with authentication from LDAP:
- It isolates matrix from changes in the LDAP tree (containers being renamed, people being moved, etc). Am I correct in assuming that if the DN for a user changes I need to fix their permissions in matrix because the bridge gives them an asset id consisting of the bridge asset id plus their dn?
- Reduces clutter in AD because it doesn't have groups that exist only for matrix permissions. (Our Intranet will heavily depend on group membership for permissions)
- Allows the web team to maintain group membership.
The cost is that I need to create/delete accounts with matching usernames (something I can script now).
PS: I see the LDAP package from Squiz create an asset authentication_ldap so I'll rename my one to authentication_ldap_simple
Greg,
I've been thinking about LDAP bridge. Is the asset id for each user/group from the LDAP bridge made up of the bridge asset id and their DN? For example: John Smith might be 35:cn=John Smith,ou=A,o=Company.
If so, does this mean that if the users DN changes that I need to re-assign permissions or is the bridge smart enough to know it's the same John Smith because he has the same username and password?
Your thinking is correct. If the DN changes, Matrix doesnt know that the 2 users are the same. Just because people have the same name doesnt mean that they are the same user 
Passwords are never stored for LDAP users because they are not real assets in Matrix, meaning we can't compare name/password pairs either.
The problem of changing DNs is a big one. For the most part, using groups for permission would be best - but still doesnt get around the DN problem. I'm not sure what the best way of fixing this is.
I have two possible solutions:
- A "rapid update" tool that can fix permissions. I imagine that it would be run as "fix_perms old_dn new_dn". It would look for any permissions that ended with old_dn and change them to new_dn. For example:
If I had a user uid=jsmith,ou=A,o=Company and the container A was renamed to B then I would run the command
fix_perms ou=A,o=Company ou=B,o=Company
and it would located all permissions relating to uid=jsmith,ou=A,o=Company and change them to uid=jsmith,ou=B,o=Company.
- Having a flag in the LDAP bridge so that the search filter is used instead of the DN (i.e. sAMAccountName=jsmith). This is fine for AD because the samaccountname is unique in the entire tree.
I'll e-mail you privately about a third option.
Would it be possible to store the GUID of the object instead of the DN?
Both AD and eDirectory use GUIDs to keep track of objects (not sure about OpenLDAP).
It is unique across the entire system and never changes, even of the object is renamed or moved, solving these issues…
If there is a unique attribute of LDAP assets that we can use that will not change - we should be using it. I don't know a lot about LDAP (only enough to write the current stuff) so there are probably options that have not been explored.
LDAP - light weight directory ACCESS protocol
We're not really talking about LDAP here. We're talking about the schema for the directory. AD and NDS have a base schema and rules that you can count on. When you are using a generic product, like OpenLDAP, you have no idea what the schema is and the only thing you can count on being unique is the DN. I know there are a bunch of standard schema but there is no obligation to use these.
What askegg suggested is possible but would require the bridge to know which directory it was talking to. Then it would apply special rules for each type. i.e. OpenLDAP => DN, AD => GUID, NDS => GUID, etc.
Or, have an option in the bridge to allow you to specify which of the attributes the bridge is seeing is unique. That way, the bridge doesn't need to know itself, you just have to tell it.
Buggy is correct - it is schema based and will differ between directories.
I like your idea of being able to specify what is stored - we configure the other attributes, why not just include the UID as well?