LDAP authentication; some users work, some don't
-
I'm having a strange issue where some users authenticate to a security group while others don't.
Running SBS 2008
pfSense 2.2.4-Release (amd64)I currently have all users authenticating which is not what I want. However, If I add the extended query memberOf=CN=Mobile Users,OU=Security Groups,OU=MyBusiness,DC=mydomain,DC=local. Only some of the accounts authenticate properly.
I created a test user and added them to the security group. At first it would not authenticate to the group, but later it did.
I cannot re-create this success with existing users.
Any thoughts? Does pfSense or openVPN cache authentication or LDAP? Is there a password policy that would fail authentication?
I don't see my diagnostic authentication requests in any logs. So, I'm not seeing where my issue is.
-
So far what seems to work on test accounts is add all groups a working user has, wait a little while and they will authenticate properly. I can remove the other groups after that and they still authenticate.
-
Is the Diagnostic authentication page caching results? going to reboot the firewall after hours and hope for the best. Existing users don't seem to get security group updates very well.
-
If you are using plain TCP for LDAP, running a packet capture of the LDAP query and looking at it in wireshark will tell you all you need to know.
-
If you are using plain TCP for LDAP, running a packet capture of the LDAP query and looking at it in wireshark will tell you all you need to know.
Using UDP.
-
For pfSense auth it's either plain TCP or SSL (still TCP). There is no option for LDAP to run UDP. The selector in the auth server settings only has two choices, TCP on port 389, or SSL on port 636.
-
For pfSense auth it's either plain TCP or SSL (still TCP). There is no option for LDAP to run UDP. The selector in the auth server settings only has two choices, TCP on port 389, or SSL on port 636.
My mistake, I was looking at the protocol value on the openVPN config page. Yes I'm using TCP 389. I'm reviewing the capture in wireshark now.
-
From the packet capture viewed in wireshark, I do see this error after searchRequest "<root>" wholeSubtree.
LDAP 176 searchResDone(2) noSuchObject (0000208D: NameErr: DSID-031001A8, problem 2001 (NO_OBJECT), data 0, best match of:
''
) [0 results]Does this just mean, user not found in the root DN?</root>
-
If that was the server responding, that would appear to be the case.
-
If that was the server responding, that would appear to be the case.
I would agree, but there are successful sendRequests that follow.
Got a bit further now:
When I originally configured LDAP authentication, I used http://www.geeklk.com/2014/03/pfsense-configuring-windows-active-directory-authentication/ as a guide.
I created an OU and user in AD just like the guide.
As a test, I changed the bind credentials in LDAP server to an existing user in AD and now the extended query is working correctly.
-
It appears the pfsense user has to be a member of Domain admins or Administrators for it to work properly. Does this have something to do with how SBS Domains are configured?
I don't really want to have that user part of such a high level security group, but I'm unable to get it working correctly otherwise.
-
That's entirely up to the Windows box and what it allows with Anonymous binds vs binds with a service account. You might be able to find some other info on the net about that unrelated to pfSense (since it's a general Windows LDAP issue, not a pfSense issue)
-
That's entirely up to the Windows box and what it allows with Anonymous binds vs binds with a service account. You might be able to find some other info on the net about that unrelated to pfSense (since it's a general Windows LDAP issue, not a pfSense issue)
I agree this has to do with my own server configuration and nothing to do with pfsense LDAP implementation.
Thank you for your responses.