Auth against LDAP/AD fails with SSL
-
I've configured an LDAP connection to the AD/LDAP. PfSense can authenticate, and OpenVPN as well.
Next, I did import the server SSL cert, and switched the LDAP to SSL. PfSense still can authenticate, but OpenVPN fails. I couldn't find any error message. But it looks like an untrusted certificate error.
Tested on pfSense 2.0.2 and 2.0.3.
The server certificate is a self-signed (Samba4). The VPN certificates belong to a different CA on pfSense.Did anyone succeed with OpenVPN + LDAPS ? An idea for a workaround ?
-
Wondering how did you manage to make it auth (even without SSL). For me, auth against LDAP/AD fails, full stop.
-
I added a page in the last couple days for LDAP troubleshooting, with a specific focus on SSL. If you're on 2.1 you can enable some rather verbose debugging output that is sure to nail down the cause.
http://doc.pfsense.org/index.php/LDAP_Troubleshooting#Debugging_LDAP
-
Hello doktornotor,
I've tested it with Samba4 and Windows 2008R2 sucessfully. Here are my parameters:
Hostname: IP or FQDN of an AD server
Port value: 389
Transport: TCP-Standard
Protocol version: 3
Search scope: Entire Subtree
Base DN: DC=example,DC=com (1)
Authentication containers: CN=Users,DC=example,DC=com (2)
Bind credentials / User DN: EXAMPLE\administrator (3)
User naming attribute: samAccountName
Group naming attribute: cn
Group member attribute: memberOf(1) For BaseDN, I usually use the root. But it is important to use "Entire Subtree".
(2) CN=Users is the base subtree on Windows for users, and my users are there.
(3) This is the short way to define a user (DOMAIN\user). You can also give the full LDAP name: CN=administrator,CN=Users,DC=example,DC=comRemarks:
- LDAP names are not case sensitive (ie. CN=Administrator = cn=administrator)
- be very careful with the bind credentials user DN. Use the short syntax, or use an LDAP browser, and find your user to be sure of the full name. By the way, Apache Directory Studio is a really cool tool to browse the LDAP.
- DO NOT switch authentication to LDAP yet. You first must ensure that everything is working correctly.
- most errors are because the bind credentials user DN did not authenticate. You won't see any difference between a wrong password, or a defective binding.
- in a production state, you should not use CN=administrator, but an unprivileged user (security basics).
Once this is configured, go to Diagnostics / Authentication. Select your LDAP descriptive name and test a user. You may have 2 answers: login failed, or this user belongs to …
If you did pass the authentication test, you're not completely over yet. If you want your user to login to pfSense, it must have the rights to do it. You can do this in 2 ways:
- create a fake user with the same username, and give him the rights.
- create a fake group with the same name than one in the AD, and give it the rights. Of course, the user must belong to this group, and this group must be shown in the authentication test result.
And, finally, if your happy with your configuration, you can switch the LDAP auth first. Be very careful to have a local user that does not exist in the domain (ie. admin). If the LDAP user is not found, pfSense will fallback on the local user.
Hope it helps
-
Thank you jimp.
The connection related issues don't apply in my case, since I can authenticate on LDAPS. The problem only applies on OpenVPN.
I will try pfSense 2.1 and the patch. If it logs the query made by the /etc/inc/openvpn.auth-user.php script, it will help a lot.
-
@jice1230: Thanks for posting. The configuration/credentials etc. used by multiple other things and perfectly working (starting from production things like Fujitsu ServerView, IRMC auth or our mailserver and ending with toys such as Owncloud or Ajaxplorer) plain fails with pfSense. Definitely nothing wrong with bind credentials. Need some low-level debugging logs, since even the simple auth tests fail with completely bogus result messages, while I can see the credentials validation has been essentially sucessful from security audit logs on the DCs.) There are some patches floating around this forum, still did not have time to really dig into what is the issue with the pfS code.
-
I did try pfSense 2.1 with the patch. I'm stuck on a new problem: the self-signed certificates are forbidden.
TLS certificate verification: Error, self signed certificate
TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self signed certificate).Regarding comments about GNUTLS evolution, it seams that chained self-signed certificare are OK, but the CA and the server certificates must be different.
Doesn't really matter for 2.0.x, but it means we have to change the self-signed sertificates anyway in a near future.
-
Self-signed are a problem, but making your own CA and then your own server certificate works fine.
You can just make them in pfSense, make a new CA, then make a new server cert (with the CN the hostname of the ldap server) and then move them over/import them into your LDAP server as needed. I know that works with OpenLDAP since that's what I did. Not sure how you'd do all that in Windows, it may have a built-in mechanism to do something similar but in a weird Windows-y way. :-)
-
Hello doktornotor,
I've tested it with Samba4 and Windows 2008R2 sucessfully. Here are my parameters:
Hostname: IP or FQDN of an AD server
Port value: 389
Transport: TCP-Standard
Protocol version: 3
Search scope: Entire Subtree
Base DN: DC=example,DC=com (1)
Authentication containers: CN=Users,DC=example,DC=com (2)
Bind credentials / User DN: EXAMPLE\administrator (3)
User naming attribute: samAccountName
Group naming attribute: cn
Group member attribute: memberOf(1) For BaseDN, I usually use the root. But it is important to use "Entire Subtree".
(2) CN=Users is the base subtree on Windows for users, and my users are there.
(3) This is the short way to define a user (DOMAIN\user). You can also give the full LDAP name: CN=administrator,CN=Users,DC=example,DC=comRemarks:
- LDAP names are not case sensitive (ie. CN=Administrator = cn=administrator)
- be very careful with the bind credentials user DN. Use the short syntax, or use an LDAP browser, and find your user to be sure of the full name. By the way, Apache Directory Studio is a really cool tool to browse the LDAP.
- DO NOT switch authentication to LDAP yet. You first must ensure that everything is working correctly.
- most errors are because the bind credentials user DN did not authenticate. You won't see any difference between a wrong password, or a defective binding.
- in a production state, you should not use CN=administrator, but an unprivileged user (security basics).
Once this is configured, go to Diagnostics / Authentication. Select your LDAP descriptive name and test a user. You may have 2 answers: login failed, or this user belongs to …
If you did pass the authentication test, you're not completely over yet. If you want your user to login to pfSense, it must have the rights to do it. You can do this in 2 ways:
- create a fake user with the same username, and give him the rights.
- create a fake group with the same name than one in the AD, and give it the rights. Of course, the user must belong to this group, and this group must be shown in the authentication test result.
And, finally, if your happy with your configuration, you can switch the LDAP auth first. Be very careful to have a local user that does not exist in the domain (ie. admin). If the LDAP user is not found, pfSense will fallback on the local user.
Hope it helps
Lots of good info there, I may steal/borrow some of that for the wiki :-)
-
Go ahead, it is here for this ;-)
Here is my documentation on my private wiki. It's in french, but Google is your friend. Take whatever you want.
http://www.ordinoscope.net/index.php/Informatique/Syst%C3%A8mes_d%27exploitation/PfSense/Recettes/Authentification_LDAP
and also my reference:
http://forum.pfsense.org/index.php/topic,44689.0/topicseen.html
-
This post is deleted! -
J jimp locked this topic on