pGina - LDAP and Groups (3.1.0.0)

[Allen Kirk]

Hi, hope someone can help me out on this one.. I *thought* I had this working already, but recently noticed that groups don't seem to be added anymore. 
I'm using IBM Tivoli server, works great..  My LDAP knowledge, however, sucks.. I've only been using it for about 3 days now..  here is quick outline.. (not sure why my "dc=example,dc=com" suffix won't work. but that's another day..)


--DIT (Root DSE, namingContexts(dc=example,dc=com)  namingContexts(o=example)
   |
   | O=EXAMPLE
          |
          |
          | ou=groups
          |         |
          |         | cn=admins
          |                   |=> objectClass: GroupOfuniqueNames
          |                   |=> cn: admins
          |                   |=> uniqueMember: uid=username1,ou=users,o=example
          |                   |=> uniqueMember: uid=username2,ou=users,o=example
          |
          | ou=users
                   |
                   | uid=username (cn=username1,sn=lastname,uid=username,userPassword=password)


So... I can authenticate my users using pGina to windows, but always had to use the Mandatory Groups to get it working..
 I authenticate with "User DN Pattern"  --  uid=%u,ou=users,o=example

I have been trying to use the LDAP groups to have pGina automatically add to windows..  not having much luck..

I've tried Group DN patterns ou=groups,O=example    using Member Attribute "uniqueMember" 

anonymous binding.. my installation is very limited right now.
I'm not exactly sure what my settings should be for the searching..

Can anyone suggest what I'm missing???

Thanks !

[Robert Howe]

We have a similar group setup (seperate groups with uniquemember instead of group attributes on the users), we had to make a modified version of the LDAP plugin that can take additional LDAP contexts/filters (one per group in our case), but I don't know if that requirement is due to limitations in our specific ldap, or because of the separate groups that use uniquemember attributes.

Thanks,

Robert

Robert Howe - ITS - Idaho State University

IT Systems Integration Analyst
Voice: 208-282-4168
Cell: 208-840-0486
Email: howe...@isu.edu

[Allen Kirk]

Thank you, I just spent the last hour attempting to define attributes for each user with no luck so far.  I can't seem to find any documentation on how to actually use the new features to add groups, maybe it's just too new so far.

Are you able to share your modified version?  or share some hints on how to include the group attributes to the user?  I've tried Group DN Pattern uid=%u,ou=users,o=example and Member Attribute "organizationalUnitName"

(not sure if it needs to be a specific aattribute name or not...) 

my user (exported from LDAP)

version: 1

dn: uid=FirstnameL,ou=users,O=example
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Firstname Lastname
sn: lastname
organizationalUnitName: Remote Desktop Users
uid: FirstnameL
userPassword:: ************

I'm pulling my hair out now (whats left of it) lol

Do I need to use the Gateway rules combined with a search??? 

Thanks to anyone that can help!

[Robert Howe]

If you're trying to add windows groups based on LDAP, that would have to happen during the Gateway phase.

I'll try to get permissions from the university to share out the code we've modified, technically anything I write while I'm here belongs to them, but I do not include any gateway phase portions, so you'd have to implement that yourself, so I'm not 100% sure it'll help you

We use a slightly modified vanilla phase (we just added a second set of ldap credentials so we can have different secure settings for the other ldap server pool we have), and then a completely customized authentication portion which handles the uniquemember style groups instead of group membership fields (we did the development while the new ldap plugin was still in development).

I would use the Local Accounts plugin as an example of how to implement the portion for adding groups after doing the ldap searches.

Thanks,

Robert

Robert Howe - ITS - Idaho State University

IT Systems Integration Analyst
Voice: 208-282-4168
Cell: 208-840-0486
Email: howe...@isu.edu

[Robert Howe]

Wow, apparently writing email in a meeting is a bad idea, let me try that again:

We use a slightly modified authentication phase (we just added a second set of ldap credentials so we can have different secure settings for the other ldap server pool we have), and then a completely customized authorization portion which handles the uniquemember style groups instead of group membership fields (we did the development while the new ldap plugin was still in development).

Thanks,

Robert

Robert Howe - ITS - Idaho State University

IT Systems Integration Analyst
Voice: 208-282-4168
Cell: 208-840-0486
Email: howe...@isu.edu

[Nate Yocom]

Note that the master branch (and corresponding beta release) has some group support added to the ldap plugin.  I don't know if it is what you need exactly - but no doubt feedback would be welcome!

[Allen Kirk]

Excellent, Thank you for all your help.  I'll check out the branch and see what I can discover.  I'll figure this out eventually lol.   

[Allen Kirk]

OK.  I am running the newest beta, with the expanded functionality on using LDAP groups.. but I can't seem to make it work.. is there some documentation so far on the new features?  or a 30 second example on how to use the search functions to find the groups that a uid is assigned too?  

[David Wolff]

Hi Allen,

The LDAP group support is available in 3.1.0.0 BETA, and supports adding local groups based on LDAP group membership in the gateway phase.  It also supports authorization based on LDAP groups in the authorization phase.   It is not documented yet, but will be fully documented as soon as I have time  :).

First, and most importantly, the current implementation has the object class posixGroup in mind, rather than groupOfUniqueNames.  Therefore, you'll have better results using the posixGroup object class.  The plugin searches the member attribute for the username (uid) only, not the full DN.  However, in the future, I'll almost certainly add a feature so that the plugin will also look for the full DN in the group member attribute.

If I understand your setup correctly, here's how you would get it working:

0.  Switch to the posixGroup object class, and use the memberUid attribute for your group membership.  Store the username only in the memberUid attribute (not the full DN).

1.  Enable the LDAP plugin gateway phase.

2.  In the LDAP config under "Group DN pattern" use something like the following:

     cn=%g,ou=groups,O=EXAMPLE

     Note that the "%g" is a place holder for the LDAP group (common) name.

3.  Under "Member attribute" use "memberUid"

4.  Under the Gateway tab in the LDAP config add a rule similar to the following:

     If member of LDAP group: admins add to local group Administrators

Basically this works by taking the LDAP group name ("admins" in this example) and replacing the %g in the group DN pattern with that name.  Then it searches for that entry and looks at the appropriate attribute for the username (not the user's DN). I'll add an issue to github to support the user DN in the member attribute shortly.

Hope that helps!

David  

[Allen Kirk]

Hi David, that's awesome.  I will be trying that ASAP.   I will post back here with my results. 
pGina is "exactly" what I have been looking for to completely remove more Microsoft fingers from my networks..  keep up the great work !!

[Allen Kirk]

David, that works like a charm!!   I have run several tests putting a member into different groups and using gateway rules and it works great.

One thing to note, ensure you have changed the "Gateway Plugin Order" so LDAP is first, otherwise all tests and authentication will pass, however the user will not actually be added to the Windows Groups.

On Wednesday, 20 June 2012 18:23:59 UTC-7, David Wolff wrote:

[David Wolff]

Allen,

Great!  Glad it works for you.

One thing to note, ensure you have changed the "Gateway Plugin Order" so LDAP is first, otherwise all tests and authentication will pass, however the user will not actually be added to the Windows Groups.

Yes, a good point to add to the documentation.  

Cheers,

David

[Allen Kirk]

Spoke a touch too soon..  :)

I just attempted to remove a user from an LDAP group to test if the user is removed from the Windows groups, and this does not seem to work.  I looked for a gateway rule to "if member of  x remove from local group"  but no options..  Tried un-checking Mirror groups from local user but the membership persists even after removing that user from all LDAP groups.

bug?  or perhaps a feature request for the gateway rules to remove from groups.?


Thanks again!  

[David Wolff]

This is not a bug.  It requires careful thought about how your local accounts are managed.  Remember that pGina works by authenticating/authorizing a user, and (if configured to do so) creates a local account for that user.  If the local account already exists, the user is of course logged in using that account, and the group membership for that local account may or may not be maintained depending on how you have configured things.

A simple solution that would remove a user from the group is to simply make sure that the local account is deleted after logout.  (The "remove account and profile after logout" option in the local machine plugin.)  Then when the local account is re-created (on the next logon) the user will not be added to the local group.

However, if you don't want local accounts to be deleted, you need to configure things carefully.   The important thing to understand is that the local machine plugin mirrors the local groups if it successfully authenticates the user.  So one option would be to configure the local machine plugin to scramble passwords after logout.  That would make sure that the local machine authentication would fail and the local groups would not be mirrored.   

If you don't want to scramble passwords, you could also achieve this by deselecting "Always authenticate local users" in the local machine plugin, and make sure that the local machine plugin executes after the LDAP plugin in the authentication stage.

Take a look at the documentation for the local machine plugin, and read through the section on "Local Groups" for more details.

http://pgina.org/docs/local_machine.html

Hope that helps,

David

[gcraiga]

I've been testing 3.1 beta connecting to Apple's Open Directory LDAP server and I ran into the same issue with removing users from groups.

David -- Thanks for the suggestions. I can confirm that deselecting "Always authenticate local users" in the Local Machine plugin works to remove users from the inherited LDAP groups on the local machine if they are modified on the LDAP server.

I had previously tried both the "remove account and profile after logout" and the "Scramble Password after Logout" options but they didn't seem to be working properly on my test machine (Windows 7 64 bit). How long does it generally take for the PGina service background thread to perform these operations after logout? I thought that may be my issue but I did attempt to leave the system for many hours and it still didn't seem to work.

Also, I've noticed that if a user is part of the Local Administrators group, the option in the LDAP Plugin Authorization settings to "Deny When LDAP authentication fails" does not appear to work. To test this I used a gateway rule in the LDAP plugin to add a user to the Administrators group and logged in. Then I changed the password on the LDAP server and tried to log back in. The old password still worked. When I test the same option for non Admin users, I get the expected "Authentication via LDAP failed. Invalid Credentials." error. Any ideas on this one.

Thanks,

Craig Anderson

[David Wolff]

Hi Craig,

I had previously tried both the "remove account and profile after logout" and the "Scramble Password after Logout" options but they didn't seem to be working properly on my test machine (Windows 7 64 bit). How long does it generally take for the PGina service background thread to perform these operations after logout? I thought that may be my issue but I did attempt to leave the system for many hours and it still didn't seem to work.

The local machine plugin tries to delete accounts every 60 seconds, however, it is VERY conservative about deleting accounts.  For example, it will not delete a local account or scramble the password if that account existed prior to the logon.  This might be the case for your accounts.  Try with an account that did not exist locally prior to the logon.

 

Also, I've noticed that if a user is part of the Local Administrators group, the option in the LDAP Plugin Authorization settings to "Deny When LDAP authentication fails" does not appear to work. To test this I used a gateway rule in the LDAP plugin to add a user to the Administrators group and logged in. Then I changed the password on the LDAP server and tried to log back in. The old password still worked. When I test the same option for non Admin users, I get the expected "Authentication via LDAP failed. Invalid Credentials." error. Any ideas on this one.

Do you have the LDAP plugin enabled for the authorization phase?  Note that the error message above is from the authentication phase not the authorization phase.

Cheers,

David

 

[gcraiga]

Hi David,

I ran a test and with a completely fresh account and the password scramble feature appeared to work after my first login. Will it not work with subsequent logins because the account exists? I ran a test and it doesn't seem to re-scramble after log out the second time. For security, I'd like the passwords for user accounts to scramble after logout.

I do have the LDAP plugin enabled for Authorization and I've selected the "Deny When LDAP authentication fails" option under that tab. Will it be possible to get this feature working for Admin users like it does for non-admins?

Thanks,

Craig

[David Wolff]

I ran a test and with a completely fresh account and the password scramble feature appeared to work after my first login. Will it not work with subsequent logins because the account exists? I ran a test and it doesn't seem to re-scramble after log out the second time. For security, I'd like the passwords for user accounts to scramble after logout.

Yes, this is an issue that we plan on addressing soon.  I've added an issue to github:

https://github.com/pgina/pgina/issues/136

For the time being, you can use one of the other workarounds discussed earlier.

 

I do have the LDAP plugin enabled for Authorization and I've selected the "Deny When LDAP authentication fails" option under that tab. Will it be possible to get this feature working for Admin users like it does for non-admins?

How do you know it is working for non-admins?  The error message you received was from the authentication stage.  When I get a chance, I'll run a test here.

David