Pros and cons of using LDAP users as Edit+ authors

(Birdg) #1

Hi,

 

When our system (Matrix 5.1.10.0) was configured, we created an LDAP Bridge to connect to our 10,000+ accounts and set it up so that the LDAP users were "LDAP SimpleEdit Users".

 

The idea was that users could log in and edit content using their LDAP credentials. We also use the same credentials to allow staff to login to our intranet which is also on Matrix.

 

However, what we are finding is that:

 

1. when the organisation structure changes, the LDAP authors get detached from content and user groups because their dn has changed - this is very time consuming to fix even with the script

2. the audit trail (who edited what, when) for LDAP users is not as good as native users

3. authors are always logged in to Matrix when browsing the intranet which means they cannot see what non-authors really see

 

In this forum post from 2012, Dan Simmons suggests that LDAP users should not be added to native Matrix user groups and that LDAP groups should be used instead. We do do this for controlling visitor permissions to the intranet but we add LDAP users to native user groups for authoring permissions.

 

So to my question: do other Matrix system owners with LDAP authentication use LDAP users for both visitors and authors? Or do you keep LDAP users for visiting and give authors a second native SimpleEdit User account as well?

 

Many thanks in advance for your insight and advice.

 

Graham

(Gilles Olivier Guegan 1) #2

Hi Graham,

 

We have a similar (ish) setup at City.

 

All our users (staff members for our intranet and staff who are also editors) are LDAP users (although in our case they're LDAP Backend User).

 

We have two main groups in our AD, one for staff members and one for editors. We import both in Matrix, and new link those groups under various native Matrix groups. These native groups are then used to set permissions.

 

We've also recently started new linking individual LDAP users under native Matrix group to create more targeted admin groups for various section of our intranet.

 

This seems to work well for us. We've been running this config for about 4 years. For info, we have around 2-3k staff users and about 250 editors.

 

1. never had that issue before I don't think. I'm not sure I understand exactly but it sounds like the issue could just how things are organised? Is the issue when users move AD groups? Sounds like organising (ie creating more groups...) in Matrix could help?

2. that we've run into a bit. If users are removed from AD for example (staff leaving etc.), Matrix doesn't know who they are anymore and displays a "LDAP user unknown" message in logs. It's never caused us that much headache though. Unless you need very detailed logs of who does what (which you can get using the general system logs, but that's another story)

3. that we have. We're about to set up single sign on as well, which means our editors will always see the "dev" version of the entire website, as soon as they have logged in elsewhere. We're solving this by making sure we tell our editors this will happen and reminding them frequently that that's how it works. We usually recommend using an incognito window or another browser they're not logged in to view the "non-dev" site. It does mean having a good relationship with your editors and communicate with them. But it's never really been an issue. Once in a while we get a panic call because the page they're working on is live and shouldn't be, but that's about it!

 

Regarding Dan's comment, I think he meant "in an ideal world scenario". I agree with him that if you use a AD as your single source of data, all your groups "should" be there, at the source. And creating further groups in Matrix is in principle not ideal (those groups will only exist there and not for your other systems for example). It's just not as elegant  :)

 

In practice though, at least here, we'll have issues with this, as the dev team looking after the CMS doesn't have easy access to create groups and move users around in AD. So we go with moving around our LDAP users directly in Matrix.

 

We never apply permissions on LDAP users directly though, we always use native Matrix group as proxies.

 

I'm not sure if there are further technical issues with this but we've never come across any. Maybe a Squiz tech can comment on this.

 

Hope this helps!

 

Gilles