Bug #16799
closed
LDAP Auth Source Shell Login Issue
100%
Description
I have setup a LDAPS source in pfsense plus 26.03.
It works.
I have also enabled the "Shell Authentication" for this source
Created a group for shell users and set the gid 10000 in AD
and put my group DN for shell-users in the LDAP source (Shell Authentication Group DN)
made my AD user is a member of shell-users group
Set these attributes in the AD user
objectclass: posixAccount (added to the list) uid: username uidNumber: 10001 (some random high number) gidNumber: 10000 (some random high number) loginShell: /bin/sh unixHomeDirectory: /root
trying to ssh into the pfsense, login succeeds.
with these weird console outputs
PS C:\Users\user> ssh username@firewall
(username@firewall) Password:
You must be a memberOf of CN=pfSense-Shell-Users,OU=User-Groups,OU=Groups,OU=home,DC=domain,DC=com to login.
You must be a memberOf of CN=pfSense-Shell-Users,OU=User-Groups,OU=Groups,OU=home,DC=domain,DC=com to login.
Last login: Mon Apr 6 00:33:05 2026 from 192.168.30.41
Could not chdir to home directory : No such file or directory
Netgate pfSense Plus - Serial: ***** - Netgate Device ID: *****
*** Welcome to Netgate pfSense Plus 26.03-RELEASE (amd64) on FIREWALL ***
Current Boot Environment: default
Next Boot Environment: default
WAN (wan) -> pppoe0 -> v4/PPPoE: 88.200.52.11/32
LAN (lan) -> ixl0 -> v4: 192.168.1.1/24
v6: fd8a:4e3b:9c9c:1::1/64
IOT (opt1) -> ixl0.25 -> v4: 192.168.25.1/24
v6: fd8a:4e3b:9c9c:25::1/64
MODEM (opt2) -> ixl3 -> v4: 192.168.0.2/24
CAMERA (opt3) -> ixl0.88 -> v4: 192.168.88.1/24
v6: fd8a:4e3b:9c9c:88::1/64
ISOLATED (opt4) -> ixl0.200 -> v4: 192.168.200.1/24
PRINT (opt5) -> ixl0.33 -> v4: 192.168.33.1/24
v6: fd8a:4e3b:9c9c:33::1/64
VPNAC_WG (opt7) -> tun_wg0 -> v4: 10.11.7.113/16
MNG (opt8) -> igb0 -> v4/DHCP4: 192.168.2.3/24
WG_S2S (opt9) -> tun_wg1 -> v4: 172.31.221.1/24
v6: fd00:172:31:221::1/64
TV (opt12) -> ixl0.150 -> v4: 192.168.150.1/24
MOBILE (opt16) -> ixl0.135 -> v4: 192.168.135.1/24
v6: fd8a:4e3b:9c9c:135::1/64
GUEST (opt17) -> ixl0.105 -> v4: 10.20.105.1/24
CLUSTER (opt18) -> ixl0.95 -> v4: 192.168.95.1/24
WANV6 (opt19) -> gif0 -> v6: 2001:210:1f2b:40d::2/128
PC (opt20) -> ixl0.30 -> v4: 192.168.30.1/24
v6: fd8a:4e3b:9c9c:30::1/64
NAS (opt21) -> ixl0.40 -> v4: 192.168.40.1/24
v6: fd8a:4e3b:9c9c:40::1/64
AD (opt22) -> ixl0.45 -> v4: 192.168.45.1/24
v6: fd8a:4e3b:9c9c:45::1/64
SERVER (opt23) -> ixl0.55 -> v4: 192.168.55.1/24
v6: fd8a:4e3b:9c9c:55::1/64
GAMESERVERS (opt25) -> ixl0.56 -> v4: 192.168.56.1/24
0) Logout / Disconnect SSH 9) pfTop
1) Assign Interfaces 10) Filter Logs
2) Set interface(s) IP address 11) Restart GUI
3) Reset admin account and password 12) PHP shell + Netgate pfSense Plus tools
4) Reset to factory defaults 13) Update from console
5) Reboot system 14) Disable Secure Shell (sshd)
6) Halt system 15) Restore recent configuration
7) Ping host 16) Restart PHP-FPM
8) Shell
Enter an option:
it prints double (so pfsense cannot tell if the user is a member of this group??)
"You must be a memberOf of CN=pfSense-Shell-Users"
"Could not chdir to home directory : No such file or directory" >> is an expected output so I am ignoring this.
This seemed weird to me.
After that I have removed the membership of my user from that group. The login succeeded again with the same outputs. This is giving me red flags now. Why would login succeed if I am not part of shell-users group?
I then removed the gidNumber from the shell-users group thinking this might be the reason.
Login succeeded again.
so the shell-users group has no say on who gets to login.
Then I have created a random AD user called "rad"
set the unix attributes in AD for this user. Basically this user has no security groups set up yet in AD.
and it logged in without a problem.
I tried using "su -" and thank god it did not have this privilege. However, this user already has access to basic pfsense shell menu options.
After that I have deleted the shell-users group from AD and tried logging in with "rad" again, it failed to log in. So, it appears this group only needs to be present in AD for shell login to work properly and any AD user can login via shell now.
Windows Server 2025 with Windows Server 2025 forest functional level
Related Topic:
https://forum.netgate.com/topic/200477/pfsense-ldap-auth-source-shell-login-issue
Updated by Jim Pingle 20 days ago
- Project changed from pfSense Plus to pfSense
- Category changed from Authentication to Authentication
- Status changed from New to Confirmed
- Assignee set to Jim Pingle
- Priority changed from Very High to Normal
- Target version set to 2.9.0
- Affected Plus Version deleted (
26.03) - Plus Target Version set to 26.07
This appears to be a quirk of the pam_ldap account management module configuration.
Logically it looks like marking it sufficient would flag the user not being a member of the group as a failure as there are no later modules that would otherwise pass an LDAP user, but in practice it doesn't appear to block the login in that case.
However, if it's marked as required it blocks as expected but still allows local shell users to login if/when LDAP is unavailable.
The following diff fixes it, though I will be committing a slightly different version that also corrects a lot of nearby whitespace.
diff --git a/src/etc/inc/auth.inc b/src/etc/inc/auth.inc
index 515f5caa9d..7c87c5c431 100644
--- a/src/etc/inc/auth.inc
+++ b/src/etc/inc/auth.inc
@@ -2502,7 +2502,7 @@ auth required pam_unix.so no_warn try_first_pass
# account
account required pam_nologin.so
account required pam_login_access.so
-account sufficient /usr/local/lib/pam_ldap.so ignore_authinfo_unavail ignore_unknown_user config=/var/etc/pam_ldap.conf
+account required /usr/local/lib/pam_ldap.so ignore_authinfo_unavail ignore_unknown_user config=/var/etc/pam_ldap.conf
# session
session required /usr/local/lib/pam_mkhomedir.so umask=0077 skel=/etc/skel/ silent
@@ -2522,8 +2522,7 @@ auth required pam_unix.so no_warn try_first_pass
# account
account required pam_login_access.so
-account sufficient pam_radius.so
-account sufficient /usr/local/lib/pam_ldap.so ignore_authinfo_unavail ignore_unknown_user config=/var/etc/pam_ldap.conf
+account required /usr/local/lib/pam_ldap.so ignore_authinfo_unavail ignore_unknown_user config=/var/etc/pam_ldap.conf
# session
session required /usr/local/lib/pam_mkhomedir.so umask=0077 skel=/etc/skel/ silent
With that diff applied account logins are allowed and denied as expected:
- LDAP admin group user: allowed
- LDAP non-admin group user: rejected
- Local admin group user: allowed
Behavior is as expected both for SSH users and console users. Though the console login does not print the warning message about group membership like the SSH login session does.
Updated by Jim Pingle 20 days ago
- Status changed from Confirmed to Feedback
- % Done changed from 0 to 100
Fixed in commit 17e10b6bd41f9e27a6970421789e924db657ff60
Updated by Jim Pingle 18 days ago
- Status changed from Feedback to Resolved
Still works as expected on the latest dev snapshot. Only users who are a member of the defined group can fully login.
Updated by Emre K 2 days ago
I am not sure if I should add this here but since it is related and I am not sure how the new patched ldap shell module will behave since I cannot test it yet, I will put it here.
While using ldap module I have noticed that when the DC is offline or unreachable, the shell login is not possible at all. What I mean is even the local built-in users like "root" cannot login via shell and they time out. I would expect only the ldap users time out and local users would be able to login via shell regardless of the DC availability.
Is it possible to test this on the patched module and see how it behaves?