Giving permission to LDAP User Groups

(Jamie Smith) #1

Hello. I need to give Read permissions on an asset to all students within our department. The optimal way to do this would be to grant permissions to the LDAP User Groups of which students are members (undergrad, postgrad taught etc.). These User Groups are accessible via the backend search field1 under an LDAP Bridge which lists all students2.

 

When I give, say, Read access to an LDAP User Group on the relevant asset's Permissions screen, I'm not able to authenticate by logging in as a user within that User Group. Giving Read permissions to an LDAP Backend User account itself lets me in. I believe that – in theory – it should be possible to give access to User Groups in this way3.

 

I'm not an expert on LDAP, so I may be missing something which will enable what I need to do. I need to be able to give access to a Custom Form to several thousand users. Any advice greatly welcomed :-)

 

Cheers.

 

1 See blue Tip box at https://manuals.matrix.squizsuite.net/ldap/chapters/ldap-bridge#Using-Users-and-Groups-from-the-LDAP-Bridge

2 There are too many users to link over manually to the Users folder

2 See https://manuals.matrix.squizsuite.net/ldap/chapters/attribute-setup-screen#How-the-Asset-Map-Displays-Groups-and-Users

(Nic Hubbard) #2

Have you tried linking that LDAP User Group under a regular Matrix User Group, of which has the read permissions?

 

Just an idea...

(Marcus Fong) #3

What Nic suggests is the way I’ve normally seen it done, because it’s easier to maintain in the longer term. That said, assigning the group permissions directly should still work. It may be worth checking that the “Group Attributes” fields of the LDAP bridge are properly set:

https://manuals.matrix.squizsuite.net/ldap/chapters/attribute-setup-screen


If your Matrix version is fairly old, you might also want to consider upgrading it to the current version, to ensure that you have all the latest enhancements and bugfixes.


It’s hard to say definitively what’s going on without being able to see the system, though. If you’re a Squiz client and need this resolved quickly, then contacting Squiz Support could be the best option.

(Jamie Smith) #4

Have you tried linking that LDAP User Group under a regular Matrix User Group, of which has the read permissions?

 

Just an idea...

 

Thank you for your response, Nic. I planned to do that but, alas, LDAP User Groups don't have a Linking screen (at least on v4.14.1). I did just link an LDAP Bridge under a regular Matrix User Group and gave Read permissions to the Group but that didn't work either, unfortunately. 

(Tim Davison) #5

What Nic says is the way to do it.  Something to do with Matrix not having permissions to modify the LDAP elements directly (even though you're trying to set Matrix permissions).  Shadow assets (including groups) can only inherit permissions from linking, they can't have intrinsic properties or data assigned directly to them - they are shadow assets, not assets, so there's nowhere in Matrix to store the data.  E.g. they cannot have metadata or workflow schemas applied to them, or in this case permissions assigned to them.  However they *can* be linked under a Matrix group and inherit those permissions - the permissions info is stored in Matrix against the group.  Similarly a shadow asset can be referenced by a workflow or metadata schema (again, data is in Matrix) but cannot have a schema applied to them directly (nowhere in Matrix to store the data).  

 

Also confirm it may not always work, to import LDAP groups as shadow assets and link them.  In one system we support (v4.12) we have to individually link LDAP user assets under a Matrix group.  This is because (and definitely stretching my memory on the matter) of a combination of the older Matrix version coupled with a very complex and odd LDAP tree implementation.

 

As a trouble-shooting excersize, you should be able to assign permissions for a std page directly to an LDAP shadow asset.  If the LDAP user logs in and can't see it then that's your first issue to sort out, can be a number of things, and you will have proven unrelated to the groups.  We've had many issues with this, from having the wrong LDAP Bridge ID, and needing to use authentication filters, ensuring the login moniker is correct (LDAP is forgiving on whitespace etc, Matrix is not), user ID's set up weirdly and inconsistently in our LDAP, multiple entries in LDAP for the same users, etc.  It's a whole world of hurt.

(Jamie Smith) #6

What Nic suggests is the way I've normally seen it done, because it's easier to maintain in the longer term. That said, assigning the group permissions directly should still work. It may be worth checking that the "Group Attributes" fields of the LDAP bridge are properly set:
https://manuals.matrix.squizsuite.net/ldap/chapters/attribute-setup-screen

...

 

Thank you, Marcus. I checked the Group Attributes and put in values I found in another thread and it's now working  B)

 

Nic's suggestion of linking LDAP User Groups under a Matrix User Group would definitely be the best way to go, but is there a way to do this that doesn't involve a Linking screen (in our version of Matrix [4.14.1], there is no Linking screen for the LDAP User Group asset type)?

 

Many thanks for your help with this.

(Marcus Fong) #7

Do you use the Linking Screen to create links? I’ve always just linked LDAP groups (and pretty much anything else) using the Asset Map…

(Tim Davison) #8

Unless there's some other way to get the shadow asset into the system in the first place (such as from under an LDAP bridge) it may be the only way to do it initially.  Our LDAP bridge timed out before it showed any results, so to import the shadow asset first time we had to go to the children linking screen and manually enter the full shadow asset id.  Once it's in imported first time and appears in the asset map then you can drag and create links as usual with the asset map.

(Marcus Fong) #9

Strictly speaking there’s no such thing as “importing” a shadow asset or getting it into the system, because it never exists in Matrix at all - that’s the definition of a shadow asset, as you alluded to earlier.

What you can have are references to a shadow asset, such as in the linking table or in the permissions table, using the shadow asset ID you mentioned (which consists of the bridge’s asset ID, a colon, and then the ID of the shadow asset under the bridge, which in the case of an LDAP shadow asset is the LDAP object’s DN). I think that’s probably what you mean by “importing” - the link to the shadow asset allows you to interact with it in the asset map even though it still doesn’t exist in Matrix.


Normally you can just expand the LDAP bridge in the Asset Map, find the shadow asset and interact with it without needing to use the Linking screen of another asset - I don’t know why your LDAP bridge is timing out, but that’s definitely not normal.


BTW, it’s no longer the case that you can’t assign metadata to an LDAP user - a feature was added to Matrix 5.2 in April of this year, allowing metadata schemas to be applied to the LDAP bridge. The shadow assets will inherit the schema and you can store metadata values against the shadow assets.