We are using 3.8.3 with postgres 8.1 on a intel box running Debian.
We have an LDAP bridge which is connecting ok as we can read back group information.
Some content is read only to LDAP authenticated accounts.
When an LDAP authenticated account attempts to access these pages the login prompt remains although it states the person is logged in! … they are not redirected to the requested page. 
I know the are logged in by the system as I can then alter the suffix of the URL to _admin and can access the backend (with only the permissions attributable to this account).
I would add that permissions for the pages have been set up for read only for these accounts.
Any thoughts? … anyone?
You need to grant at least Read Permission to your LDAP users. This is most easily done by granting Read Permission to an LDAP group that your users are a member of. If they are logging in successfully, but not seeing the page, they are not getting the appropriate permission.
[quote]You need to grant at least Read Permission to your LDAP users. This is most easily done by granting Read Permission to an LDAP group that your users are a member of. If they are logging in successfully, but not seeing the page, they are not getting the appropriate permission.
[right][post=“12189”]<{POST_SNAPBACK}>[/post][/right][/quote]
This is the case. It is very frustrating. The LDAP connection clearly returns an ok as I can then alter the URL to access the backend. I look at the Permissions screen for the page and all the staff groups are specified under ther top pane Read Permissions granted.
Hope you point me in the right direction.
Are you sure you have the right Group Membership attribute configured on the LDAP Bridge asset? Otherwise, Matrix is unable to calculate the correct group memberships for LDAP users.
For Active Directory, the correct attribute is "memberOf", for example.
[quote]Are you sure you have the right Group Membership attribute configured on the LDAP Bridge asset? Otherwise, Matrix is unable to calculate the correct group memberships for LDAP users.
For Active Directory, the correct attribute is “memberOf”, for example.
[right][post=“12195”]<{POST_SNAPBACK}>[/post][/right][/quote]
we have NDS group objects mapped to ‘groupOfNames’ and NDS Member attributes are mapped to ‘member’
LDAP returns positive on the authentication but the CMS does not redirect away from the login page to the requested target page.
Essentially, there needs to be an attribute in the User that is a list of DNs of groups the user is a member of. Otherwise, Matrix has no way to map user accounts to the groups they belong to.
Currently, the LDAP Bridge has only been tested with OpenLDAP and Active Directory. I know that we do have one or two clients using it with Novell eDirectory, so I'll have to check and see what attribute mappings they are using.
You may have to use the Directory hierarchy (i.e. assigning permissions to the container that contains the user accounts) to assign permissions instead of groups, as that is calculated differently.
jad?
Does the login page report:
"You do not have permission to access <Page Name>"?
If so I have the same problem when I try to accesss a page as as an LDAP user that only has read permissiosn to the page. If I instead give the user write permissions they can access the page–a bug perhaps?
[quote]jad?
Does the login page report:
“You do not have permission to access <Page Name>”?
If so I have the same problem when I try to accesss a page as as an LDAP user that only has read permissiosn to the page. If I instead give the user write permissions they can access the page–a bug perhaps?
[right][post=“12244”]<{POST_SNAPBACK}>[/post][/right][/quote]
The account gets authenticated, that is LDAP returns positive but the page with the prompt does not change. It just says I am logged in as the user but that the page is restricted. I have since specifically applied read permissions to the account and it DOES work. However if I try allocation permissions by group it fails.
I can change the URL and append _admin and see the backend (with only the appropriate permissions) which clearly proves that it connects and receives a response from LDAP.
[quote]Essentially, there needs to be an attribute in the User that is a list of DNs of groups the user is a member of. Otherwise, Matrix has no way to map user accounts to the groups they belong to.
Currently, the LDAP Bridge has only been tested with OpenLDAP and Active Directory. I know that we do have one or two clients using it with Novell eDirectory, so I’ll have to check and see what attribute mappings they are using.
You may have to use the Directory hierarchy (i.e. assigning permissions to the container that contains the user accounts) to assign permissions instead of groups, as that is calculated differently.
[right][post=“12222”]<{POST_SNAPBACK}>[/post][/right][/quote]
I relay this to my network people and get back to you… just to reaffirm the events that happen.
The account does get authenticated, that is LDAP returns positive but the page with the prompt does not change. It just says I am logged in as the user but that the page is restricted. I have since specifically applied read permissions to the account and it DOES work. However if I try allocation permissions by group it fails (ie I am authenticated but not redirected).
[quote]If so I have the same problem when I try to accesss a page as as an LDAP user that only has read permissiosn to the page. If I instead give the user write permissions they can access the page–a bug perhaps?
[right][post=“12244”]<{POST_SNAPBACK}>[/post][/right][/quote]
This would only be a bug if the page is Live – pages that are Under Construction are only visible to users with Write permission or higher.
[quote]However if I try allocation permissions by group it fails (ie I am authenticated but not redirected).
[right][post=“12247”]<{POST_SNAPBACK}>[/post][/right][/quote]
You will need to investigate your LDAP User attributes and best determine which Group Membership attribute to use. The Attribute should contain a list of groups the user is a member of, in DN format.
[quote]This would only be a bug if the page is Live – pages that are Under Construction are only visible to users with Write permission or higher.
[right][post=“12251”]<{POST_SNAPBACK}>[/post][/right][/quote]
Yes, that’s what it was–under construction.
[quote]Yes, that’s what it was–under construction.
[right][post=“12265”]<{POST_SNAPBACK}>[/post][/right][/quote]
Ok, great. 
This is by design. You only want users who have Write permission or higher to see pages that have not been published.
[quote]This would only be a bug if the page is Live – pages that are Under Construction are only visible to users with Write permission or higher.
[right][post=“12251”]<{POST_SNAPBACK}>[/post][/right][/quote]
Here is a summation from my network and systems colleague …
--------------------------------------
We’re using the LDAP bridge to authenticate against a Novell eDirectory-based LDAP server. We need to be able to use both groups and containers (OU) to protect restricted content. We have full control of the mapping of the LDAP server and we can also see the server logs.
However, all we seem to be able to do is restrict access to content to a particular user. We can set group/ou restrictions in the GUI, but whenever an appropriate user logs in, they do not get redirected. To clarify:
If we set a specific user restriction, the user gets access.
If we set a group restriction, users don’t get access, whether they are members of the group or not.
If we set an OU restriction, users don’t get access, whether they are in the OU, in a sub-OU, or not part of the OU at all.
We’ve mapped the eDirectory “Group Membership” attribute to a “squizMember” LDAP attribute. This is the eDirectory attribute that contains a list of DNs of groups that the user is member of. I’ve attached an example user’s attributes. We want to be able to restrict access to content via entities such as “cn=AH_LDAP_STAFF,ou=AH,o=gre” (which is a group), or via the user’s container, eg. “ou=Staff,ou=Services,ou=AH,o=gre”.
Is there a log file on the Squiz server that may contain useful information about these failed logins? Is there a known-good configuration for the LDAP bridge that works with eDirectory?
What does your LDAP Attribute screen look like for the LDAP bridge? The last thing to check is that you have the correct attribute mapping.
[quote]What does your LDAP Attribute screen look like for the LDAP bridge? The last thing to check is that you have the correct attribute mapping.
[right][post=“12324”]<{POST_SNAPBACK}>[/post][/right][/quote]
if you can follow the pasted listing below
This is attributed setup of the bridge
User Id uid
--------------------------------------
Common Name cn
First Name givenname
Last Name sn
Email Address mail
Group Membership squizMember
Group Name ou
This is the attribute pane details for the LDAP User setup screen
LDAP Attribute Name Common Name Display ? Use for Sorting ?
-------------------------------------------------------------------------------------
username username Yes Yes
password password Yes
first_name first_name Yes
last_name last_name Yes
email email Yes
locale locale Yes
restrictions restrictions
uniqueid uniqueid
language language Yes
sn sn Yes
passwordrequired passwordrequired Yes
passwordallowchange passwordallowchange Yes
objectclass objectclass Yes
networkaddress networkaddress
logintime logintime Yes
cn cn Yes
acl acl Yes
dn dn Yes
You're going to have to contact Squiz Support so that someone can debug your system to see why the group membership is not being recognised.