LDAP > Active Directory configuration in 2.0 RC3 x64

  • I'm trying to get LDAP authentication working to a Windows 2003 domain controller for a specified 'VPNUsers' group.  The AD functional level is still mixed 2000/2003 domain, I believe.  If I configure as attached under 'System: Authentication Servers' I can get it to authenticate all domain users under 'Diagnostics: Authentication', however when I hit the 'Select' button under Authentication containers to specify only certain groups or users, I get a popup with the message: Could not connect to the LDAP server. Please check your LDAP configuration.  This error is also logged to the system log: php: /system_usermanager_settings_ldapacpicker.php: ERROR! ldap_get_user_ous() could not bind to server .

    Again, if I manually enter CN=Users,DC=ourdomain,DC=local in the Authentication containers line, it will allow all users to authenticate, but if I substitute another valid group (e.g., CN=VPNUsers,CN=Users,DC=ourdomain,DC=local or CN=VPNUsers,DC=ourdomin,DC=local) it will not authenticate anyone, and logs the following to the system log:

    php: /diag_authentication.php: ERROR! Either LDAP search failed, or multiple users were found.
    php: /diag_authentication.php: Now Searching in server AD, container CN=VPNUsers,CN=Users,DC=ourdomain,DC=local with filter (samaccountname=testuser).
    php: /diag_authentication.php: Now Searching for testuser in directory.

    If I append the other group to the users group (e.g., CN=VPNUsers,CN=Users,DC=ourdomain,DC=local;CN=Users,DC=ourdomain,DC=local) it will again authenticate anyone whether they're in the specified group or not.

    Testing under 'System: User manager settings' connects and binds to the server OK and returns some OUs:```
    OU=Distribution Groups,OU=MyBusiness,DC=ourdomain,DC=local
    OU=Domain Controllers,DC=ourdomain,DC=local

    Does anyone have any idea why trying to select Authentication containers tells me it can't connect to the LDAP server (though clearly it can), or how I can get it to filter to a certain group otherwise?  Thanks in advance for any suggestions.

  • After seeing another thread in a different area of the forum (http://forum.pfsense.org/index.php/topic,37549.0.html), I'm wondering if there's an issue with the way the LDAP connector deals with AD domains created by SBS.  I believe the OUs are setup up a bit differently and I'm wondering if the LDAP connector in pfSense can't deal with the structure of the OUs & directory as created by SBS.

    UPDATE:  I found a bugtracker page that discusses the issue regarding filtering by AD groups.  I downloaded and replaced my auth.inc file with the one linked there, and changed the Authentication containers line in the GUI LDAP server setup page to read CN=VPNUsers,CN=Users and now it correctly allows users in the VPN users group to log in and denies access to other users.  It still returns the Could not connect to the LDAP server. Please check your LDAP configuration. error if I use the Select button, but despite this it seems to appropriately allow and deny logins based on group.

    One other note, if there's a space in your group name (e.g., VPN Users instead of VPNUsers), this will not work and authentication will fail even if the user is in that group.

  • EDIT:  So, I changed the "group naming attribute" to "memberOf" - and created a group (with a space in the name) - and everything worked as-expected.  Huh.


    So - if I'm understanding this correctly, the LDAP support in pfSense 2.0 doesn't support spaces in group names, and doesn't support nested groups, and the fix isn't scheduled to be in 2.0 release?

    Darnit!  I was really looking forward to being able to move to 2.0, and get integration with Active Directory!  :(

    S'too bad - AD is my directory server - no choice in that matter.

  • No plans so far for doing anything on it for 2.0.
    You can get support for that through support.pfsense.com.

  • Doing a compare on the auth.inc from here and the RC3 version… it seems to include group support, but there's a lot of stuff not in that version that's in the RC3 release. So is replacing the auth.inc still a valid option?

Log in to reply