Several issues upon 2.5.0 upgrade
@maverickws I have something different. I'm running 21.02 on a netgate SG-3100:
@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.
@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.
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)
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.
@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.
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
- Legacy Client : checked, Do not include OpenVPN 2.5 settings in the client configuration.
we have some user on old tunnelblick
@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"
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 :-(
@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.
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?
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 > Authenticationreturns
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.
So looking at this:
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?
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.
@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"
Fetching groups from LDAP worked fine before, but trying to use an extended query to filter results so that the auth could only ever match a specific group did not, at least not for the person who submitted that PR.
There are so many differences in LDAP structures it's no surprise that there is some variation here, but those changes have also been in snapshots since September and worked for at least the people who took the time to test them before the release.
I can't speak to their specific settings, but it's working well for me with OpenLDAP and RFC 2307 groups, but I'm not using extended queries to filter anything. My LDAP settings haven't been adjusted in years, and they have kept working. As you can see on that issue when they broke, I reverted the change until the code was corrected.
@jimp I get that it wasn't working for the person who submitted the PR but there's an whole universe of people using both OpenLDAP and FreeIPA (which is exactly the same as Red Hat IDM) and using extended queries and it has been working fine for years. I've had extended query enabled from the start filtering results and it worked.
I actually wasn't aware that "RFC 2307bis" was used by IPA/IDM, but I went to confirm that, and apparently it is so. The extended query is on the "MSAD Style" as called on the GUI: memberOf=cn=fwadmin,cn=groups,cn=accounts,dc=domain,dc=io
I kindly ask you, please, if you have contact with Chris Linstruth, who said that tested against FreeIPA 4.8.4, could he pass you what settings he used, or maybe come here and shed some light on the matter? Thanks
Have you tried reverting the changes from that issue to test if that really is your problem? This thread is lengthy and I am short on time so I can't go back and check every post.
The complaint on that Redmine issue was for extended query for groups with RFC 2307, not -bis, so if you were actually using -bis style before then it could have been working for you. The RFC 2307 checkbox would change how the LDAP search worked to return groups, but if you were filtering to only one group that checkbox probably wasn't having much of any effect in the end.
@Derelict is the one who tested FreeIPA, so maybe he can chime in and tell you what his setup is like. I know he's fairly busy though so I don't know if he has time right now.
Thank you @jimp for the mention.
I agree this thread is lengthy I'm actually here already doing overtime at work cause I lost a lot of time here and let other responsibilities got behind. Will take a closer look to it on Monday hopefully with some more feedback here and I'll try to go through the issue and see about the changes.
@mjsengineer Confirmed - unchecking"LDAP Server uses RFC 2307 style group membership" fixes things for me too. Authentication test under diagnostics works and OpenVPN authentication too.
So is this a bug in pfSense? Our LDAP server is 389-DS - if I read the posts correctly, the same problem appeared with other LDAP servers so I tend to believe things should be fixed on pfSense side.
For those not liking the term 'bug' I'm also ok with a non-compliance ;-)
@polle 389-DS is Red Hat's Directory Server the same used by FreeIPA and Red Hat IDM uses RFC 2307bis (wasn't aware of this detail either).
So I guess regarding this we're all on the same boat. This change and its impact should, however, be documented.
@lucsuryo I looked into Radius/LDAP 2FA with TOTP, won't go into too much detail, but have a look at proxying the requests through things that can do 2FA..
I stumbled upon this after experiencing the same issues with LDAP Authentication when used with RedHat IdM/FreeIPA. Following settings worked for us on RedHat IdM (from RHEL 7) as well as FreeIPA (from CentOS 7). Our pfSense 2.4.x Instances are still using other settings, but 2.5.0 required us to go with the following.
Won't get into details with Server-Setting etc as it's site specific, but may be the following is proper directions for "the RHEL folks":
Search scope: Entire Subtree
Base DN: cn=accounts,dc=idm,dc=example,dc=com
Authentication containers: cn=users
Extended Query: unchecked (probably site specific)
Bind credentials: site specific
User naming attribute: uid
Group naming attribute: cn
Group member attribute: memberOf
RFC 2307 Groups: unchecked
Group Object Class: posixGroup
@cboenning man f***ing amazing kudus for you.
Group member attribute: memberUid
changing that to memberOf fixed my still existing issues.
You da man!!!! Cheers!!!