Authentication fails for only some users
-
I've been fighting this one on and off for a week and have now hit a wall.
OpenVPN server setup and authenticating against our Active Directory just fine for most of the users. However a few weeks ago one of my users reported that he couldn't get in, although he used to be able to just fine. He is getting an authentication failure message. After meticulously verifying with him that he is indeed entering the correct password, he's still failing. So I setup a test user mirroring his account and now I'm seeing the same thing with this test account. All the while I and others are able to authenticate just fine.
I've tested the accounts using Diagnostics -> Authentication and see similar results; I and others authenticate fine, he and test account do not (i.e., it's not a client software problem). Logging set to level 11 show nothing obvious, just authentication failed (but nothing indicating why). I can't claim it's a problem binding to the AD server, because others are able to authenticate fine. All accounts in question are members of the VPNusers group. I also tried placing these accounts in varying OU's on the Domain Controller with no change in status.
Running latest updates of pfSense (2.4.4-RELEASE-p3) on Netgate XG-7100. Clients tested with include the one exported from pfSense wizard as well as the OpenVPN Android client. All combinations produce the same results.
Where else can I look?
Thanks.
-
Are there any other logs or diagnostics I can use? The OpenVPN site references using auth-cli on the server to test authentication problems but this doesn't seem to exist in the pfSense package. Can I presume that Diagnostics -> Authentication is doing the same thing?
-
If some work and others do not, then more likely than not, the server is rejecting it for some reason. Have you enabled/checked authentication logs on the AD server?
Have you tried a packet capture of the authentication request being sent to AD? If it's using LDAPS you might try changing to LDAP (not secure) temporarily to check a packet capture of a working and non-working request.
In some cases it may be due to special characters (e.g. accents) in the username or password, if that's the case there is an option in the LDAP auth server config to enable UTF-8 encoding which should help.
If it's using RADIUS and not LDAP, then you'd still want to check a packet capture and the AD side logs, but it's even less likely to be pfSense in that case.
-
I just wanted to post a follow-up in case someone in the future has the same problem and comes across this thread. We were able to determine that the service account we were using to bind to AD was unable to properly access the entire directory structure (still not sure why not, but that doesn't matter). I could see it make a connection to the domain controller and then attempt to check each of the containers defined in the pfSense authentication server, but it would return "0 users found" in the LDAP query even though the account to be authenticated was there in that container.
What fixed it was to add that account we use for directory binding to the Built-In "Account Operators" group. After that everything has worked perfectly.