LDAPs AD bind

[renat_kaa]

@rb_it_pf short answer is YES. By the way, best practice is using RO user.

[rb_it_pf]

I am not familiar with RO. I am assuming this is a read-only user. Could you refer me to any links? Thanks

[renat_kaa]

@rb_it_pf correct, read-only user (non-administrator)
You can read here https://docs.netgate.com/pfsense/en/latest/usermanager/ldap-troubleshooting.html

[rb_it_pf]

Context:
Currently, I am testing LDAPs in pfSense using the imported CA from AD, and an imported client certificate from AD. The client certificate is using the AD certificate template 'domain controller'. I have imported the private keys for both the CA and client certificate into pfSense. I'm not sure if this approach is good/correct.

Questions:

• Should the client certificate also be created in AD, and imported into pfSense? Or should the client certificate be created on the pfSense, using the CA that was imported from AD?

• Should either the CA or client certificate have a private key defined on the pfSense?

Thanks.

[awebster]

@rb_it_pf said in LDAPs AD bind:

imported CA from AD, and an imported client certificate from AD

You don't need the client certificate.

LDAPS authenticates with a username (use either user@domain, or DN of user) and password, and it is going to validate that the server certificate presented by AD's LDAPS was signed by the CA that you imported, AND that the hostname used matches what is on the server's certificate. If either condition is false, it won't work.
You can test by saving the config, then going back and editing the config and clicking on the Select a container button, if you see a list of AD containers pop-up, you know it can access LDAPS correctly.

Oddly enough, when I tested this, it was able to connect to my AD server with LDAPS by IP address even though I did not respect the NOTE: When using SSL or STARTTLS, this hostname MUST match the Common Name (CN) of the LDAP server's SSL Certificate. (pfSense 2.4.4-p3), and I didn't have the IP address of the server defined as a subject alternative name in the server's certificate.
When testing this on the CLI with openldapsearch, I was not able to connect using the IP address, only when the hostname matched, so I suspect that the devs are passing LDAPTLS_REQCERT=allow into the environment which will allow it to be more permissive in what it accepts, but also breaks the statement about that it must match.

[rb_it_pf]

Thanks awebster.

Referring to System -> UserManager -> Settings 'Save and Test', I get the following results:

TCP - Standard:
Attempting connection to DC1.local OK
Attempting bind to DC1.local OK
Attempting to fetch Organizational Units from DC1.local OK

SSL - Encrypted:
Attempting connection to DC1.local OK
Attempting bind to DC1.local failed!

Here are the settings for my LDAPs config under authentication servers:

• Descriptive name: DC1.local
• Type: LDAP
• Hostname or IP Address: DC1.local
• Port value: 636
• Transport: SSL- Encrypted
• Client Certificate: None

DC1.local matches the CN on the server certificate which lives on the DC.

So at the current moment, the CA is the only thing that has been plugged into the authentication server settings. Do I need to import the server certificate from the domain controller into pfSense and use that as the client certificate?

Thanks

[awebster]

You'll need to check that the server's certificate is indeed signed by the CA.
You can do this by opening a CLI on the pfSense and using the following:
openssl s_client -connect hostname:636
It is going to output a lot of information, including verify errors (this is normal since openssl has no idea what your CA is), but what you want to check specifically are the lines appearing immediately after ----END CERTIFICATE --- which are subject= and issuer=

issuer= will represent the CA that emitted the server's certificate. It must match what you've got loaded in Cert Manager's CA.
subject= will represent the certificate of the server, and the name there needs to match (well according to docs, but not what I observed in my previous post) the hostname you are using.

[rb_it_pf]

Thanks awebster. Great CLI tip!

The lines appearing immediately after ----END CERTIFICATE--- present the subject and issuer as expected.

Though, I did notice something towards the top of the output:
depth=0 CN = DC1.local
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = DC1.local
verify error:num=21:unable to verify the first certificate
verify return:1
CONNECTED(00000004)

[rb_it_pf]

Another thing I should mention is that the pfSense WAN is actually the same network that DC is on. I am testing things so I am technically double NATed. Not sure if that is making any difference here. WAN rules are deny all.

[awebster]

That's normal, it's due to openssl not recognizing the issuing CA, but it does prove that the server is accepting LDAPS connections.
However, I'm assuming it is still not working, so you might need to dig a bit deeper, you can go look at DC1's event viewer security log.
Look for event-id 4624 (success) and 4625 (failure) to see if you can see what's going on.
Note that if the user doing the bind doesn't exist in AD, nothing is logged.

You can also try the following from the CLI to prove to yourself that the server is actually working as expected.

setenv LDAPTLS_REQCERT allow
ldapsearch -v -H "ldaps://dc1.local:636"  -b "dc=local" -s sub -D "username@local" -w "password"

If it works, it'll output the contents of your AD.

If you don't know what your Base DN is (input to -b parameter above), you can use this to find it out - [Hint to pfSense dev's this would be a useful feature to add to automatically populate the naming context for the LDAP server config page.]

ldapsearch -v -h hostname_or_ip -s base -x  "namingContexts"

For AD, it will output several naming contexts, ignore the following:
CN=Configuration,DC=...
CN=Schema,DC=...
DC=ForestDnsZones,DC=...
DC=DomainDnsZones,DC=...
The one left over will be the DC=... part that's what you want to use as your base DN.

[rb_it_pf]

I am getting the following output in CLI
sh: setenv: not found

[awebster]

Oh, you are probably running the command via the WebGUI Command Line option, in which case do this:

export LDAPTLS_REQCERT=allow; ldapsearch -v -H "ldaps://dc1.local:636"  -b "dc=local" -s sub -D "username@local" -w "password"

[rb_it_pf]

Thanks. I plugged the following into the WebGUI CLI and obtained the following:

export LDAPTLS_REQCERT=allow; ldapsearch -v -h DC1.local:636 -s base -x "namingContexts"

ldap_initialize( ldap://DC1.local:636 )
ldap_result: Can't contact LDAP server (-1)

I also got the same result plugging the IP in place of the hostname.

On the domain controller, I filtered my security logs for 4625 and 4624 event IDs with no results.

Thanks.

[rb_it_pf]

I did see an event log on the DC with an event ID of 2085.

"Internal event: An LDAP over Secure Sockets Layer (SSL) connection could not be established with a client."

Under 'Additional Data'
"Error value
2148074289 The client and server cannot communicate, because they do not possess a common algorithm. Internal ID: c05088d

[awebster]

@rb_it_pf The command isn't correct, you cannot use -h host -p 636, as simply selecting a different port won't make ldapsearch use SSL, I know, its silly, but you really need to use -H "ldaps://host:636".

[rb_it_pf]

The command worked and outputted the DN.
I tried the other command that connects to the LDAP server and it worked as well. In fact i was able to see outputs for users that belong to the DC LDAP group.

I still can't seem to search on the containers or successfully bind using the GUI though.

Any thoughts?

[rb_it_pf]

Solved. I had to restart the PHP-FPM in order for the SSL Transport type to take affect. I remember hearing about this in a Netgate video on LDAP but didn't think much of it at the time. Restarting PHP-FPM fixed it. I really appreciate your help troubleshooting with the CLI.
Regards.

[awebster]

Happy to help, and glad you figured it out!

[stephenw10]

@awebster said in LDAPs AD bind:

Happy to help, and glad you figured it out!

This user deserves your upvote.

Steve

[rmonette]

I have similar issues, and in the end, Im not sure what the resolution was... I tested this:
export LDAPTLS_REQCERT=allow; ldapsearch -v -H "ldaps://IPADDRESS:636" -b "dc=XX,dc=YY,dc=com" -s sub -D "user@domain.com" -w "pwd" (with the proper values inserted of course)
from the Pf web CLI and I got a lot of output which seemed to indicate that the firewall was able to connect to my DC. I think part of my issue is that the CA cert from the DC does not have an IP in the SAN section, and/or that the Pf cant seem to associate the CA cert CN to an IP, which would make me think the issue is DNS resolution.
Any suggestions on the next move?