Several issues upon 2.5.0 upgrade

jimp

The fact that it failed without TLS makes me think that it's something else in the LDAP query that's wrong.

Unless the server rejects queries without TLS, that is.

With TLS off you should be able to get a packet capture of the LDAP exchange and debug what's going wrong -- you can see exactly what query is being sent and the reply.

maverickws

@jimp please just amuse me and please reply to the following:
if the settings are wrong, why does it work under User Manager > Settings
selecting the LDAP server and hitting "Save & Exit"

the LDAP server (Red Hat IDM) only accepts authenticated queries, so it has to communicate somehow. This works with both TLS on or off.

jimp

Are you sure it's working and not falling back to local database authentication?

If that works and others don't, it still makes me think it's a problem in the LDAP settings. It's possible you are communicating with the LDAP server OK but something in your other settings is not making a proper query/search and isn't getting and results.

Packet capturing auth attempts with TLS disabled is the fastest way to diagnose that. Download the packet capture and load it in Wireshark and it can show you everything that's going on.

maverickws

@jimp thank you for the feedback.
Well I am sure because of the following:
Under User Manager > Settings I am not testing auth per se, so can't fall back to local database authentication because there's no authentication.
However what it does is to test the LDAP Settings. And it queries the LDAP server and it returns the Organisational Units, please check the image below.
User Manager Settings Test
This information can only be returned after connecting to the LDAP server AND using an authenticated system user. We don't allow anonymous queries. So I can't agree with the remark "It's possible you are communicating with the LDAP server OK but something in your other settings is not making a proper query/search and isn't getting and results" at least this far is making the proper queries.

If TLS failed, this would fail as well.
We've had certificates mismatching before and it would fail this test.

We haven't changed any settings from the previous version to this version.
The issue is occurring on 3 pfSense routers, one is our office router, which is connected via Site-to-Site IPSec VPN. But the other two are locally connected. The three worked before, the three are failing now, after the update to 2.5.0.
I must say I haven't done the packet capture yet as I got a lot on my plate and I'll have to spare some time to do that. So I was trying to see if this approach exposing the issue with maximum detail would take us somewhere.

jimp

Authenticated binds are much different that attempting to query for a user, which is affected by all the other settings on the page for the various containers/base dn/etc.

All that proves is you can communicate with the server, it doesn't mean your other settings are OK.

Turn off TLS, take a packet capture of some auth attempts. See what is happening. That's the only way forward.

LucSuryo

This post is deleted!

Polle

Got exactly the same issue: after upgrading to 2.5 LDAP authentication stopped working.

As jimp mentioned, when switching to LDAP under 'SystemUser/Manager/Settings' and hitting 'Save & Test', it succesfully connects to our LDAP server and lists the OUs. When I try authentication from the Diagnostics menu, it fails. Since we are (were ...) using LDAP authentication for our OVPN clients, that fails too.
We're using LDAPS on port 636 - I tried switching to port 389 with standard TCP but got the same results - authentication not working ...

One more related question about this note under 'Authentication' servers:
NOTE: When using SSL/TLS or STARTTLS, this hostname MUST match a Subject Alternative Name (SAN) or the Common Name (CN) of the LDAP server SSL/TLS Certificate.
Will this work with a wildcard certificate? It has *.<domain> and <domain> as SAN names whereas our server is ldap.<domain>. * should cover that but there is no exact match of course ...

Polle

Correction - it's maverickws who posted the issue - and he's right, LDAP authentication is broken - period.

BossaOps

@polle I've looked, it really depends on what RFC, usually your CN would be *.domain, and that is normally considered a match, and the same should apply to the SAN names..

maverickws

I still haven't done a tcpdump to see what's going on, but I would like to add to the comments regarding certificate, it DOES NOT WORK if connecting in plain, so that about the certificate seems like a mere detail that really doesn't influence here.

Thank god we did not have other services on the pfSense bound to LDAP auth as is @Polle's case. I feel whatever changes have been made here are poorly documented and this will keep happening to more people.

mjsengineer

As I noted above, I have a similar issue. However I do have a working LDAP/VPN authentication setup.

Both Authentication Server setups have the following:

Port: 636
Transport: SSL/TLS Encrypted
Peer Certificate Authority: Same_cert_on_both_setup
Protocol Version: 3
Server Timeout: 25
Search Scope: Entire Subtree
Base DN: Identical-on-both-setups
Authentication Containers: Identical-on-both-setups
Extended Query: Enabled
Query: Identical-on-both-setups
Bind Credentials: Identical-on-both-setups

The ONLY difference between the configuration of Server 1 and Server 2
is that Server 2 has a "Client Certificate" defined. Server 1 has the
"Client Certificate" set to None.

The Diagnostics/Authentication worked on both servers pre upgrade.
Post upgrade, Server 2 - the one with a "Client Certificate" - no longer
authenticates successfully.

maverickws

Hi @mjsengineer what do you mean by "client certificate" or you mean client certificate on the VPN authentication setup only? there's no client certificate to login on the pfsense iirc?

BossaOps

@maverickws I think he means pfsense and LDAP server use mutual certificate verification for the broken setup, but only bind credentials (both over TLS) for the functional one. That's what's broken with Cloud Identity LDAP, it uses client certificates, not credentials.

maverickws

@bossaops our LDAP server doesn't verify the client certificate, I mean many services that connect to it have self-signed certificate. Either way, that wouldn't apply to a plain auth setup, and as requested above I've disabled TLS/SSL and changed the port to 389 and tested, the issues persisted.

mjsengineer

@maverickws I am referring to the "Client Certificate" option under the LDAP Server Settings section of the Authentication Server configuration on pfsense (ie. System -> User Manager -> Authentication Servers).

BossaOps

@maverickws It would be interesting seeing what changed inside the pfsense LDAP code, though I think the issue myself and msjengineer have is actually the local (running onthe pfsense) code not dealing with the self signed certificate properly, with what you're demonstrating very possibly this isn't the only breaking change they made.

BTW mutual certificate verification can use self signed certificates, just like you can use self signed certificates on web servers, the verifier just needs to have a CA/intermediate certificate signed by the same CA (just like the OpenVPN client certs are signed by the pfsense CA, which is self signed).

I actually have an stunnel proxy running here locally, as I use Cloud Identity LDAP with an IDP service that doesn't support mutual certificate verification, I will try and see if I can't get auth working via that route as a test.

LucSuryo

@maverickws this finally works for me
(PART 1)

example values
user => netgate
base dn => dc=forum,dc=netgate,dc=org
user dn => uid=netgate,ou=users,dc=forum,dc=netgate,dc=org
so note we use uid! since ldap is use to shell to linux servers too

on the openldap server

create user : netgate
generate password for this user
add to group vpn (we use memberof !!)
(home made script)

on the pfense
User Manager / Authentication Servers

Authentication Servers

Descriptive name => myldap
Type => LDAP
Hostname or IP address =>10.10.10.10
Port value => 389
Transport => Standard TCP
Peer Certificate Authority => Global Root CA List
Client Certificate => None
Protocol version => 3
Server Timeout => 25
Search scope => Entire Subtree
Base DN => dc=forum,dc=netgate,dc=org
Authentication containers => ou=users,dc=forum,dc=netgate,dc=org;ou=groups,dc=forum,dc=netgate,dc=org
Extended query => checked
Query => memberOf=cn=vpn,ou=groups,dc=forum,dc=netgate,dc=org
Bind credentials => <your admin dn and password>
User naming attribute => uid
Group naming attribute => cn
Group member attribute => memberOf
RFC 2307 Groups => uncheck
Group Object Class => groupOfNames
rest all unchecked!

on the pfense
User Manager / Settings

Authentication Server => myldap
click save & test
make sure there are no error

on the pfense
Diagnostics / Authentication

Authentication Server => myldap
Username => netgate
Password => <generated password>
make sure there is are errors

Polle

Switched to port 389 and 'Standard TCP' - then tried authentication from the diagnostics and did a packet capture, what I see is that:

box contacts the LDAP server and performs a bind request using the bind credentials
ldap returns bindresponse success
box performs some search request - OUs I specified and finally the user (uid) for the user that is authenticating
next a bind request for the user
ldap again returns bindresponse success
and finally the box issues an unbindrequest
with the usual load of ACKs in between

So all that looks pretty much OK but nevertheless it returns "The following input errors were detected: Authentication failed." ....

LucSuryo

@maverickws
(PART 2)

i generate a new CA with values that reflects our company
(example )

Name => My OpenVPN
ST=CA, OU=forum, O=The Netgate Forum , L=Lala City, CN=vpn-ca, C=US

next setup OpenVPN Server

Server mode => Remote Access (SSL/TLS + User Auth)
Backend for authentication => myladp + Database
Protocal => UDP on IPv4 Only
Device mode => tun - layer 3 Tunnel Mode
Interface => WAN
Local port => 7070 <--- we use not the default to port value
Description OpenVPN Netgate Forum
TLS Configuration => checked <--- TLS key will be generated after save
TLS Key Usage Mode => TLS Authentication
TLS keydir direction => use Default Direction
Peer Certificate Authority => My OpenVPN
DH Parameter Length => 2048
ECDH Curve => Use Default
Data Encryption NegotiationEnable Data Encryption Negotiation => checked
Data Encryption Algorithm => <we use only the AES-256-x>
Fallback Data Encryption Algorithm -> ES-256_CBC (256 bit key, 128 bit block)
Auth digest algorithm => SHA256
Hardware Crypto => <no hardware since we are on a VM>
Certificate Depth : One (Client + Server)
Strict User-CN Matching : checked (Enforce match)

next only the important ones
IPv4 Tunnel Network => <your choice, buy use a /24!)
IPv4 Local network(s) => 10.10.0.0/16
Concurrent connections => <we set it to 25 to match the vm, which has 2 core and 2gb memory>
Allow Compression => Decompress incoming, do not compress outgoing
Compression => Adaptive LZO Compression
Username as Common Name => checked Use the authenticated client username instead of the certificate common name (CN).

maverickws

@mjsengineer You mean the "Peer Certificate Authority" then I assume? I have no option called "Client Certificate", so I'm guessing that must be it.

@BossaOps right what I meant is we haven't add trust for any extra CA most of the times they just get the plain old default cert so I meant that wouldn't be the case here.

Edit: While I was typing this I was looking at @LucSuryo's reply and he also mentions that Client Certificate option. I don't see that in mine.

Is that what you meant @mjsengineer too?

Authentication Servers

I checked two pfSense running 2.5.0, none has that "Client Certificate" option.

I'm reviewing @LucSuryo's settings to see if I find something that'll fix this.