[quote]
Looks like you are using Active Directory. Currently Labs have been testing and debugging on an Open LDAP. Hang in there while we get access and debug a system using Active Directory.
Thanks
[/quote]
Thanks, I appreciate this help!
[quote]
Looks like you are using Active Directory. Currently Labs have been testing and debugging on an Open LDAP. Hang in there while we get access and debug a system using Active Directory.
Thanks
[/quote]
Any updates on this?
[quote]
Looks like you are using Active Directory. Currently Labs have been testing and debugging on an Open LDAP. Hang in there while we get access and debug a system using Active Directory.
Thanks
[/quote]
Mohamed, any updates on this? I am still trying to get our AD groups working but still having no luck. 
[quote]
Mohamed, any updates on this? I am still trying to get our AD groups working but still having no luck.
[/quote]
Sorry about the delay on updating the forums, I recall Bug fix #5050 http://bugs.matrix.squiz.net/view_bug.php?bug_id=5050 fixed this issue.
We tested it locally on Open LDAP and then we had a client with AD who had this same issue and this patch worked for them.
Have you tried the patch:
http://public-cvs.squiz.net/cgi-bin/viewvc.cgi/ldap/ldap_bridge/ldap_bridge.inc?root=matrix_ldap&r1=1.90.4.7&r2=1.90.4.8
[quote]
Sorry about the delay on updating the forums, I recall Bug fix #5050 http://bugs.matrix.squiz.net/view_bug.php?bug_id=5050 fixed this issue.
We tested it locally on Open LDAP and then we had a client with AD who had this same issue and this patch worked for them.
Have you tried the patch:
http://public-cvs.squiz.net/cgi-bin/viewvc.cgi/ldap/ldap_bridge/ldap_bridge.inc?root=matrix_ldap&r1=1.90.4.7&r2=1.90.4.8
[/quote]
Yes, I tried that patch, but my users that are inside of an LDAP group still never get permissions given to them…not sure what is wrong.
I just wanted to update this post with some additional questions/comments.
- I CAN see all of the LDAP groups in the asset map, and I can expand those groups to see users.
[*]I CANNOT give permissions to a user inside one of those groups or a group itself, it does nothing and doesn't let the user login to that page where permissions are given.
[*]We are using Active Directory.
[*]Group Memebership is set to: ou
[*]Group Memebers is set to: member
[*]When viewing the details of a LDAP group, I see the member attribute with all of the members listed, so I am 99% sure that I SHOULD be using memeber for the Group Memebers attribute.
Any additional help on this would be great, kind of pulling my hair out over this. Our ITSS department doesn't seem to know what else to do. Ideas?
Does anyone else have a AD setup with groups that they can share their configuration?
[quote]
I just wanted to update this post with some additional questions/comments.
- I CAN see all of the LDAP groups in the asset map, and I can expand those groups to see users.
[*]I CANNOT give permissions to a user inside one of those groups or a group itself, it does nothing and doesn't let the user login to that page where permissions are given.
[*]We are using Active Directory.
[*]Group Memebership is set to: ou
[*]Group Memebers is set to: member
[*]When viewing the details of a LDAP group, I see the member attribute with all of the members listed, so I am 99% sure that I SHOULD be using memeber for the Group Memebers attribute.
Any additional help on this would be great, kind of pulling my hair out over this. Our ITSS department doesn't seem to know what else to do. Ideas?
Does anyone else have a AD setup with groups that they can share their configuration?
[/quote]
Unfortunately we don't have access to an Active Directory system. Last time we had a client with a similar problem and we were hoping to debug it but that patch worked for them. However looking back on the posts it looks like your issue is not the same as Bug #5050 as you don't have nested LDAP User Groups.
Anyway I want to try my best to help you now, can you let me know a couple more things about your setup.
1- What is your setting for "Group Name"
2- Can you provide the DN of one of the User Groups and one if its Users please.
Also I would like to mention that there is a note of the LDAP Bridge Attributes Screen which says..."Only one of Group Membership and Group Members are required. If both are provided, groups will be expanded according to the Group Members setting, however the groups a user is a member of will be determined by the Group Membership setting first. If only Group Membership is provided, groups will not be expanded."
Considering your Groups are expanding correctly according to the "Group Members" setting of "members", you should try blanking out the "Group Membership" setting of "ou" so that the groups a user is a member of will also be determined by the "Group Members" setting of "members".
Thanks
Thanks Mohamed, I will get this info for you when I am back at work on Monday. 
[quote]
Anyway I want to try my best to help you now, can you let me know a couple more things about your setup.
1- What is your setting for "Group Name"
2- Can you provide the DN of one of the User Groups and one if its Users please.
Also I would like to mention that there is a note of the LDAP Bridge Attributes Screen which says…"Only one of Group Membership and Group Members are required. If both are provided, groups will be expanded according to the Group Members setting, however the groups a user is a member of will be determined by the Group Membership setting first. If only Group Membership is provided, groups will not be expanded."
Considering your Groups are expanding correctly according to the "Group Members" setting of "members", you should try blanking out the "Group Membership" setting of "ou" so that the groups a user is a member of will also be determined by the "Group Members" setting of "members".
[/quote]
Ok, I removed the group membership setting of "ou" and just left the group members setting of "member".
Here are the other settings you asked for:
Group Name: currently blank, as our ITSS tech said he didn't think I should put anything there
Example DN for Group:
CN=Staff,OU=Groups,DC=puc,DC=edu
Example User:
CN=Nic Hubbard [nnhubbard],OU=Staff,DC=puc,DC=edu
Let me know if there is any other info that you need.
Thanks so much!
To recap, the LDAP_Bridge::getParents() function uses three ways to determine the groups a user belongs to. First is by the "Group Membership" setting, second by the "Group Members" setting and third by the "OU" parts of the LDAP User DN.
[quote]
Ok, I removed the group membership setting of "ou" and just left the group members setting of "member".
[/quote]
So no luck by doing this?
[quote]
Group Name: currently blank, as our ITSS tech said he didn't think I should put anything there
Example DN for Group:
CN=Staff,OU=Groups,DC=puc,DC=edu
Example User:
CN=Nic Hubbard [nnhubbard],OU=Staff,DC=puc,DC=edu
[/quote]
With those DN's and you current configuration I can see that the Bridge won't detect the Users' Groups using the third method.
If Nic Hubbard belongs to the "Staff" Group, and the Group has a "CN" of "Staff", then I would try putting "CN" (upper case or lower case, don't know if it makes a difference) for the "Group Name" setting.
[quote]
With those DN's and you current configuration I can see that the Bridge won't detect the Users' Groups using the third method.
If Nic Hubbard belongs to the "Staff" Group, and the Group has a "CN" of "Staff", then I would try putting "CN" (upper case or lower case, don't know if it makes a difference) for the "Group Name" setting.
[/quote]
So I tried using CN and cn and neither worked.
Not sure what else to try.
[quote]
So I tried using CN and cn and neither worked.
Not sure what else to try.
[/quote]
Ok sorry I have nothing else I can suggest at the moment as I am not experienced with AD :-/. The DNs for that user group/user pair look very strange compared to OpenLDAP. I have something like this:
Group: ou=Staff,o=Squiz,c=au,dc=demo,dc=squiz,dc=net
User: cn=blee,ou=Staff,o=Squiz,c=au,dc=demo,dc=squiz,dc=net
I will let the team know about this thread to see if anyone else can help out.
To adequately debug ldap connections I generally find I need to use the "ldapsearch" command to see what's actually in the tree.
Something like:
# ldapsearch -h -LLL -x -D '' -w '' -b '' ''
should work.
Try looking both at a user and a group to see which end AD is reporting the group membership on.
User:
# ldapsearch -h -LLL -x -D 'CN=Nic Hubbard [nnhubbard],OU=Staff,DC=puc,DC=edu' -w '' -b '' '(cn=Nic Hubbard*)'
Group:
# ldapsearch -h -LLL -x -D 'CN=Nic Hubbard [nnhubbard],OU=Staff,DC=puc,DC=edu' -w '' -b '' '(CN=Staff)'
Assuming you can bind as a user and get the filters working sanely you should be able to interrogate a group and a user object to see how it's being returned to openldap (and further up the chain to Matrix).
[quote]
To adequately debug ldap connections I generally find I need to use the "ldapsearch" command to see what's actually in the tree.
Something like:
# ldapsearch -h -LLL -x -D '' -w '' -b '' ''
should work.
Try looking both at a user and a group to see which end AD is reporting the group membership on.
User:
# ldapsearch -h -LLL -x -D 'CN=Nic Hubbard [nnhubbard],OU=Staff,DC=puc,DC=edu' -w '' -b '' '(cn=Nic Hubbard*)'
Group:
# ldapsearch -h -LLL -x -D 'CN=Nic Hubbard [nnhubbard],OU=Staff,DC=puc,DC=edu' -w '' -b '' '(CN=Staff)'
Assuming you can bind as a user and get the filters working sanely you should be able to interrogate a group and a user object to see how it's being returned to openldap (and further up the chain to Matrix).
[/quote]
Thanks David, I will be working with our IT department to see if we can get this worked out, thanks for the tips!
Well, I have been working with our IT department and we still are not able to figure out what is going on. I do have a few more questions though:
- On our AD system the group membership is stored both in the group object and the user object, would this make a difference?
[*]Would having multiple LDAP Bridge assets conflict with each other, if some contained the same users?
[*]Why would creating a a LDAP Bridge using a base DN of a group name (ou=Faculty Contract,dc=puc,dc=edu only contains users) work of and allow permissions, but using a dn that contains groups (ou=Groups,dc=puc,dc=edu groups with users inside) not work at giving the users or groups permission?
[*]Are there any other users on this forum that are using Active Directory and giving groups permissions or users inside groups? Any success?
Thanks everyone.
[quote]
On our AD system the group membership is stored both in the group object and the user object, would this make a difference?
[/quote]
I believe in this case you will want whatever the attribute ldapsearch shows as groups belonging to users in "Group Membership", e.g. "memberOf" and the users showing up under a group in "Group Members" e.g. "member".
[quote]
Would having multiple LDAP Bridge assets conflict with each other, if some contained the same users?
[/quote]
The first bridge will be used IIRC but there will definitely be places where the behavior is unpredictable at best, it's probably not a great idea.
[quote]
Why would creating a a LDAP Bridge using a base DN of a group name (ou=Faculty Contract,dc=puc,dc=edu only contains users) work of and allow permissions, but using a dn that contains groups (ou=Groups,dc=puc,dc=edu groups with users inside) not work at giving the users or groups permission?
[/quote]
The Base DN has to match the full DN for user, when the user is listed against a group under "ou=Groups,dc=puc,dc=edu" their DN is still "ou=Faculty Contract,dc=puc,dc=edu".
[quote]
- On our AD system the group membership is stored both in the group object and the user object, would this make a difference?
[/quote]
It makes no difference. Essentially it gives you a choice of whether you use Group Members or Group Membership. Note that at least one of these is going to be a calculated attribute, though. AD's permissions may mean that the bind user can see one, but not the other if one is calculated. memberof for Group Membership is generally safer with AD.
[quote][list]
[*]Would having multiple LDAP Bridge assets conflict with each other, if some contained the same users?
[/list][/quote]
The different users and groups on each of the bridges are different, as far as Matrix is concerned, as they have different (shadow) assetids. So, if permissions have been granted to a particular group, then only the members who are authenticated on the same bridge will acquire the permissions for that group.
It's basically random which bridge a user gets authenticated on. In order to control this, if you have multiple bridges, they must either not have overlapping users, or, if they do, you need to use the Authentication Filter. The authentication filter is applied when searching for the LDAP object that corresponds to the user who is attempting to log in.
The most ordinary use of this would be to have a bridge that creates LDAP Users, and another which creates LDAP Backend Users. Then you can have two LDAP bridges with the same Base DN, but with Auth Filters of (for example) "memberof=ou=CMS-Backend…" and "!(memberof=ou=CMS-Backend…". Ordinarily, you will want the Authentication filters to form a complete subset of your BaseDN, with no overlaps between them, and having complementary filters like this is the easiest way to do that.
[quote][list]
[*]Why would creating a a LDAP Bridge using a base DN of a group name (ou=Faculty Contract,dc=puc,dc=edu only contains users) work of and allow permissions, but using a dn that contains groups (ou=Groups,dc=puc,dc=edu groups with users inside) not work at giving the users or groups permission?
[/list][/quote]
When you attempt to log into a Matrix system, matrix scans through the Authentication systems, in Asset Map order, looking for that username to attempt to authenticate. When it's searching for an LDAP user to attempt to authenticate, it will perform an ldap search on the AuthDN (or the BaseDN if none is set) looking for a userish object that has the ldap attribute of the bridge's "username" ldap attribute setting that is equal to the username entered.
In your case, I think what you're after is a BaseDN of "ou=Groups,dc=puc,dc=edu", and probably an AuthDN of either "ou=Staff,dc=puc,dc=edu" or just "dc=puc,dc=edu"
[quote]
In your case, I think what you're after is a BaseDN of "ou=Groups,dc=puc,dc=edu", and probably an AuthDN of either "ou=Staff,dc=puc,dc=edu" or just "dc=puc,dc=edu"
[/quote]
Wow, this is the best piece of information I have been given. Trying dc=puc,dc=edu as the AuthDN didn't work, but using ou=Staff,dc=puc,dc=edu DID WORK and I was able to login my user which is under the Staff group!
Now, one more question. Since the LDAP Bridge lists many groups, and in the AuthDN we are specifying the Staff Group, what if I need to give permissions to two groups, or even three? With the setup that just worked, I am assuming this would not be possible. How would I be able to do that?
Thanks so much!
[quote]
Wow, this is the best piece of information I have been given. Trying dc=puc,dc=edu as the AuthDN didn't work, but using ou=Staff,dc=puc,dc=edu DID WORK and I was able to login my user which is under the Staff group!
Now, one more question. Since the LDAP Bridge lists many groups, and in the AuthDN we are specifying the Staff Group, what if I need to give permissions to two groups, or even three? With the setup that just worked, I am assuming this would not be possible. How would I be able to do that?
Thanks so much!
[/quote]
I am not sure if this would work in AD, but maybe try AuthDN: dc=puc,dc=edu and AuthFilter: &(ou=Staff)(ou=Group2)
[quote]
Now, one more question. Since the LDAP Bridge lists many groups, and in the AuthDN we are specifying the Staff Group, what if I need to give permissions to two groups, or even three? With the setup that just worked, I am assuming this would not be possible. How would I be able to do that?
[/quote]
I'm not sure that I understand the question here. Once the LDAP Groups are visible to Matrix, with the LDAP Users in them that need the permissions granted on them, you can basically treat them exactly as you would Matrix Users and Groups. So long as bug #5050 is patched, you should be able to either grant the permissions individually to each of the two or three groups, link the two or three groups into a Matrix User Group, and grant permissions to that, or change the BaseDN of the LDAP Bridge to a higher level, so that the parent group is visible, and grant the permissions to that parent LDAP Group.
With a very few exceptions, LDAP Groups and Users can be used in the exact same way as you would use ordinary, Matrix ones.