[Solved] AUTH_FAILED using Active Directory as backend for OpenVPN
-
Hello
I'm setting up a new OpenVPN server, as I have done several times before.
When I create a local user and use that for the VPN, it authenticates fine and the VPN works. So no firewall issues or anything there.The problem is that I want to authenticate against AD. I set this up exactly the way I do on other pfsense boxes, I actually have another pfsense with working AD authentication against the very same AD server that I cant get working now. That box is in another isolated network however and will not be able to host the VPN server that I need now.
Nov 13 16:16:14 openvpn[15043]: 94.234.170.83:21824 TLS Auth Error: Auth Username/Password verification failed for peer
Nov 13 16:16:14 openvpn[15043]: 94.234.170.83:21824 WARNING: Failed running command (–auth-user-pass-verify): external program exited with error status: 1
Nov 13 16:16:14 openvpn: user '<username>' could not authenticate.I get these errors in the log on the max loglevel for openvpn, loglevel 11. No idea whatsoever what command/external program returned status 1, so I have no idea what to troubleshoot. Can someone point me in the right direction? Is there a script somewhere I can run to test this locally via SSH or likewise?
This server is using pfsense 2.2.5-RELEASE, the one that is working is using 2.1-RELEASE.
/A</username>
-
Does it work with Diag > Authentication?
Is LDAP set for TCP or SSL? If it's on SSL, try switching to TCP – if that works, it's your SSL cert or other related settings.
-
LDAP is set to TCP. Both on this non-working and on the working pfsense.
I tried the diagnostics-thingy, but all it said was:
The following input errors were detected:
Authentication failed.Well.. yeah. I already knew that. I need debug stuff! What server is it querying? What response does it get? etc..
Its weird because I already have one server up and running, with an older version of pfsense, and that works just fine with the exact same settings, querying the exact same AD server..Does someone have a test-environment with AD authentication enabled that they can upgrade to the latest version to see if they have the same problem?
/A
-
Does someone have a test-environment with AD authentication enabled that they can upgrade to the latest version to see if they have the same problem?
Yeah. No such problem exists here.
Also, not exactly sure what you mean by " I need debug stuff! What server is it querying?" - like, the one you defined there, obviously… Huh. You also have logs on the AD controllers, use them, perhaps.
-
What I mean by debug stuff is:
- Is PFSense even able to connect to the AD? Connection refused? timeout?
- The AD account used to bind with, is that failing? Or is it the actual lookup of the user im trying to authenticate with that is failing?
- Other various stuff that could be useful for troubleshooting
Of course I can assume that its actually trying to connect to the server that I provided, but how can I verify this? The logs available in the pfsense gui does not actually confirm that this is the case. I only get a short message that the authentication failed.. not good enough for troubleshooting.
Good to know that your pfsense can authenticate using the latest version though. That means its not likely a bug that is causing my issue. Thanks.
/A
-
If LDAP is set for TCP, your best test is a packet capture of the LDAP traffic from the firewall to the AD server. Load it in wireshark and inspect the query/response.
PHP doesn't kick back much of anything helpful from the LDAP library when it fails so the GUI doesn't have the ability to tell you much.
-
Woho!
The problem was the binding account. For some reason, it accepts "<accountname>" on server, but needed to be "accountname@domain.tld" on this one. When I entered that, it worked.
No idea why.Wiresharking the packets pointed me in the direction of failing binding.. That information really should be prestented via some error method in the php class. It's sent from the AD server to the client, so its available..
Thank you guys!
/A/accountname@domain.tld</accountname>
-
The problem was the binding account. For some reason, it accepts "<accountname>" on server, but needed to be "accountname@domain.tld" on this one. When I entered that, it worked.
No idea why./accountname@domain.tld</accountname>Hmmm… In AD environment, it must be either DOMAINNAME\Username or Username@DOMAINNAME. "For some reason" it could have never worked unless used properly.
-
The problem was the binding account. For some reason, it accepts "<accountname>" on server, but needed to be "accountname@domain.tld" on this one. When I entered that, it worked.
No idea why./accountname@domain.tld</accountname>Hmmm… In AD environment, it must be either DOMAINNAME\Username or Username@DOMAINNAME. "For some reason" it could have never worked unless used properly.
Thats not true under all circumstances, I would argue.. I just rechecked, and I have 4 LDAP backends setup in my Servers-tab on the "working server", and all of them work. In fact, I'm connected via one of them right now. And neither of them have any domain specified in the binding credentials. All backends are AD.
The domain is, however, specified in the search scope, Base DN. But that's probably not used until the binding is complete, and the actual user is authenticated.If there is only one domain configured (no multi-domain forrests etc), maybe it assumes that domain? At least these are working for me, and have been for years :)