basically the same examples should apply. If LDAP is setup correctly you should be able to enter a username and password, and should get back a list of "group memberships" (or for LDAP any attribute you configured). You can access the username in the policy by checking the Authentication.Username property. You can access the LDAP attributes (most likely gorups) by checking the Authentication.UserGroups property.
That's how you access the details from the authentication within the policy. What you do with them is basically up to you.
Thanks for the quick reply, but once I get the user and group info into MWG, working with it is not the problem. What I am trying to do is see how to get the group membership information when the LDAP server does not store group membership in the user records, as in Open Directory. It appears based on what you posted back in March below....
Thats good! Usually you will only use "Get User Attributes" or "Get Group Attributes". As far as I understood you will use "Get User Attributes" if the User attribute contains all groups. As for AD this is the case, since a user (like Administrator) has a "memberOf" attribute for each group he is member in.
"Get Group Attibutes" would be used if the user does not contain information about his groups, but the groups are located elsewhere in the directory, and contain attributes for each user. For example you have a group "Internet Allowed Employees" somewhere in your directory, and this group object has attributes like "member=Andre, member=Administrator", etc. In this case MWG has to ask all group objects if the user is member of that groups.
I have tried this, where instead of getting the User Attributes, check the Get Group Attributes checkbox in the Authentication Server settings. But I can not get MWG to check the groups and find which ones this particular user is a member of. Here is an example of the group attributes for the group staff.
I can use memberUid as the attribute to retrieve but no matter what I put in the Filter Expression box, I get no Group Attribute results, or if I leave it blank, I get a list of all the groups. Any ideas?
Can you post your LDAP settings?
I have a hunch that the problem is that you are mapping the username to an DN which doesn't match the actual contents of the memberUid attribute.
Basically MWG is getting a username of gary, is then mapping that to cn=gary,cn=staff,cn=users,dc... Which of course doesn't exist in the staff group. On a lot of other LDAPs (openldap, edirectory, sun, etc) they store the full DN in a memberof or uniquememberof attribute, hence the default.
Try unchecking map username to DN, and then definitely only check get group attributes and put memberUid in. Then run an authentication test from the ldap server settings.
So I tried the settings above and if I uncheck the Map Username to DN box, then the authentication fails (using the test feature in settings) If I leave it checked then the authentication is successful but no group attributes are returned. (using the test feature) I have not tested this in an actual authentication process to see if the test feature does not function the same as an actual authentication process does.
It may not be necessary as we can modify our Open Directory user records to include the group membership as this will align more with our Active Directory users, which will be accessed via a referral in the Open Directory server, and they have those group attributes in the user record already.
On a different subject, has anyone tried to come up with an authentication policy where a user is not required to authenticate, until they hit a block based on a category list. Ideally for us, a user would not be required to authenticate initially and would hit a very restricted Category Block list. Then on the block page, we would give them the option to authenticate and then they would hit a different Category Block List based on their group membership.
I know we can use the Try Auth ruleset and then filter based on whether they are an un-authenticated user, or an authenticated one. The problem with this is they have to get the authentication dialog and cancel it, and that is not very intuitive since there is no explanation on the default http authenticate dialog as to why they are getting it.
I think I already had the same problem. The problem seems to be that MWG resolves the username first, so when looking for groups it does not send the "uid" of the user which is placed in the group object, but sends the "looked up" value of the username (the complete DN).
I will have a look into this.
I have a ruleset for this, I just have to find it.
This is what needs to happen because the group does not store the user as the full DN syntax:
-Authenticate the user and pull the "username" attribute from the user, this will be then stored in the property Authentication.UserGroups.
-Set the "Raw Username" property to be equal to the "UserGroups".tostring
-Perform another LDAP lookup using the "GetUserGroups" property, it will then plug the "rawusername" in as the username.
I hope this helps.
I wil give that a test, but I may not need it as we may just need to modify our Open Dirctory server to include the group attributes int the User record, since our Active Directory users are all configured that way and we will be pulling them in through refererals from the OD server.