Several issues upon 2.5.0 upgrade

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.

maverickws

My settings are a bit different from @LucSuryo's but what got it fixed was disabling the option RFC 2307 Groups:

I mean, fixed it in the sense that the Diagnostic > Authentication authenticates successfully. But then says:

This user is a member of groups: and it returns empty, not referring the group its a member of and set on the extended query.

Trying to login to the pfSense returns that error No page assigned to this user! Click here to logout. ...

mjsengineer

@maverickws I have something different. I'm running 21.02 on a netgate SG-3100:

Screenshot_2021-03-05 pfsense png - pfsense pdf.png

mjsengineer

@maverickws When I unselect "LDAP Server uses RFC 2307 style group membership", the authentication check under the Diagnostics returns "authenticated successfully." My OpenVPN connection also authenticates successfully.

Seems that clears the problem.

BossaOps

@mjsengineer I can confirm it's always been there on netgate hardware, I started doing LDAP authentication after I purchased it so I don't know if it's exclusive to their hardware images.

LucSuryo

@maverickws

yes it will not return any group unless you have setup group on pfsense
im trying to post PART 3, but get flagged as spam :-(

I had the same group in pfsense as a remote group and with the same name
but afterward, i t was not needed

in part 3 is creating the a user cert for the user and then export the client configuration : mind you i use openvpn-client-export (look in packages)

maverickws

I see. I don't even want to comment this new version divergence ... %$#%# ... but I guess the issue isn't there either.

I just wonder how much longer is it going to take for Netgate acknowledge they f***ed up something on LDAP Auth, or provide instructions to fix it. I've had RFC 2307 Groups enabled since forever, and as far as I know Red Hat IDM is RFC 2307 compliant so I'm still trying to find out why doesn't work with it enabled.
Also, realising this new bug of not identifying the group the user belongs to.

maverickws

@lucsuryo looking forward for that part 3. I have the group setup at:
System > User Manager > Users > Groups

Group name: the same name as the group on the LDAP server
Scope: Local (it was already set like that from before)
Group membership: I only see the local user.

LucSuryo

@maverickws and @mjsengineer

i use both 2.5.0 on a small box and 21.02 in AWS
both had the issue, but no longer

if everyone get their vpn + ldap working then there is no need for me to post PART 3 then :)

the only important part of the client export is

Host Name Resolution -> other
Host Name -> use a dns resolved entry for the vpn

and

Legacy Client : checked, Do not include OpenVPN 2.5 settings in the client configuration.

we have some user on old tunnelblick

BossaOps

@maverickws My problem isn't related to the RFC 2307 Groups unfortunately, never had it checked :(

Just saw that this recipe does state "For users of pfSense factory software version 2.4.4-RELEASE-p1 or later"

https://docs.netgate.com/pfsense/en/latest/recipes/auth-google-gsuite.html

LucSuryo

@maverickws

group should be remote :) since the user is not in the local database

Do you need part 3? (user cert + client export)
it seem the forum guard thinks I am a spammer :-(

maverickws

@LucSuryo I guess we do have different setups hehe but at least I've gotten a little further.
I'm going to review the part of that article where they mention the groups, maybe that has something to do with it. Hadn't checked there either because ... well... all was working before!

P.S. I've tried to make some posts before that also got flagged for spam. Sometimes still happens, never really understood why.

LucSuryo

@maverickws

same here , everything worked just fine (been using Pfsense for 7+ years)
never had this issue...

and i pulled my hairs for 2 days!
on the group : for us it works with our without no issue

this is just simple : vpn + ldap and it got broken in 2.5.0 and 21.02...

we have a commercial openvn (latest version) and zero issue
the one important thing pfsense is missing a built-in 2fa like the commercial openvpn...

i know i need to do some reading how to get radius + google authenticator working, but that is for an other day and other beer :-)

still need part 3?

maverickws

I'm not sure about part 3 really.

So I was talking with some folks that mentioned that Red Hat IDM uses RFC2 307bis so that may be part why my auth wasn't working.

Now my issue is to know why Diagnostic > Authentication returns This user is a member of groups: empty, and why when I login it says there are no pages assigned to the user.

I recreated the group, set as "remote" and added all privileges except "Deny config write".

Btw the other 2 pfSense that are on HA config didn't even had the groups and it worked.

maverickws

So looking at this:

https://redmine.pfsense.org/issues/9527

I don't really understand this "issue", as before having RFC2307 style membership WORKED JUST FINE, as others mentioned this has been working for a long time with extended query, querying the right containers. I really don't know what was the issue of the OP of that issue.

What I know is that now if I have RFC 2307 checked the authentication fails, and if I uncheck it it doesn't work as it returns no group.

@jimp I noticed you participated on that issue, could you please elucidate why was that "fix" merged, for a problem that honestly did not exist?

Doing an extended query memberOf=cn=fwadmin,cn=groups,cn=accounts,dc=domain,dc=io fails.

And Chris Linstruth said he tested against FreeIPA 2 months ago with what version?? what settings were those against what FreeIPA version?

jimp

The group membership worked fine but using them in the extended queries did not, as explained on that Redmine issue.

RFC 2307bis (AD Style) is not the same as RFC 2307 (OpenLDAP style)

For AD and anything else that uses RFC 2307bis you wouldn't want to check the RFC 2307 box.

As you can also see by the comments on the Redmine issue it was tested by multiple people with different LDAP servers as well, so it's possible there is some different issue at play or maybe something worked in the past by accident with the wrong settings.

maverickws

@jimp alright already learned about the RFC 2307 checkbox not being compatible with 2307bis ... moving on.

I see one person complaining on a redmine issue saying something wasn't working and here and all around you have people saying it did work for years until this update where its broken.

I can't say I'm an LDAP expert but I don't get what you mean that "group membership worked fine but using them in the extended queries did not" as I had it on the extended queries AND IT DID WORK FINE (or am I missing what extended queries we're talking here? Is some other "extended query" beside the one available on the authentication server config?).

Also, what version was tested really? That would be very interesting to learn. I have IDM/IPA 4.8.4 the same version as Chris said he tested against, if he tested using pfSense 2.4.5 then YES IT WAS WORKING. With 2.5.0 is not.

So I ask again, what version of pfSense did he test, and with what settings?

I've always heard throughout my life "if something isn't broken, don't fix it"