Bug #10492
closed
LDAP groups conflict in privileges
100%
Description
I am running pfSense 2.4.5-RELEASE with a 389 Directory Server for LDAP user authentication.
I have configured the authentication server section on pfSense based on the official documentation and have confirmed that my LDAP admin user is detected properly at "Diagnostics-> Authentication":
User admin authenticated successfully. This user is a member of groups:
adminsThe admins user group at pfSense has the following privileges assigned:
WebCfg - All pages
User - System: Shell account access
However, when logging in with the admin LDAP user on the system, I do not get admin rights.
Details:
My LDAP admin user is part of two groups in LDAP:
admins: for full admin access
basic: for basic access to some tools
The two groups are also configured in pfSense, with the basic group being configured with the following privileges:
User - Config: Deny Config Write
User - Notices: View
WebCfg - Dashboard (all)
WebCfg - Diagnostics: ARP Table
WebCfg - Diagnostics: CPU Utilization
WebCfg - Diagnostics: DNS Lookup
WebCfg - Diagnostics: iperf client
WebCfg - Diagnostics: iperf server
WebCfg - Diagnostics: nmap package
WebCfg - Diagnostics: Ping
WebCfg - Diagnostics: Show States
WebCfg - Diagnostics: States Summary
WebCfg - Diagnostics: Test Port
WebCfg - Diagnostics: Traceroute
WebCfg - Firewall: NAT: 1:1
WebCfg - Firewall: NAT: NPt
WebCfg - Firewall: NAT: Outbound
WebCfg - Firewall: NAT: Port Forward
WebCfg - Firewall: Rules
WebCfg - Interfaces: Bridge
WebCfg - Interfaces: Groups
WebCfg - Interfaces: LAGG:
WebCfg - Interfaces: VLAN
WebCfg - Status: Logs: DHCP
WebCfg - Status: Logs: Firewall
WebCfg - Status: Logs: Gateways
WebCfg - Status: Logs: VPN
WebCfg - Status: Monitoring
WebCfg - Status: NTP
WebCfg - Status: OpenVPN
WebCfg - Status: System Logs: Firewall (Dynamic View)
WebCfg - Status: System Logs: Firewall Log Summary
WebCfg - Status: System Logs: NTP
WebCfg - Status: System Logs: OpenVPN
WebCfg - Status: System Logs: Portal Auth
WebCfg - Status: System Logs: Routing
WebCfg - Status: Traffic Graph
WebCfg - Status: DHCP leases
WebCfg - Status: Interfaces
WebCfg - Status: Services
WebCfg - Diagnostics: Sockets
WebCfg - Diagnostics: System Activity
User - System: Shell account access
The problem is that when authenticating against LDAP from the pfSense box, the LDAP admin user is identified as belonging to both the admins and the basic groups, causing a conflict in privileges. I could access all of the pages, yet I was unable to make changes in some (such as user configs or making firewall rule changes).
As a temporary solution, I have removed the LDAP admin user from the basic group and I can manage the firewall successfully. However, I will need to add the group membership back for other tools to work.
In my opinion, if a user has the "WebCfg - All pages" privilege, pfSense should overwrite any lower right from being a member of another group.
Updated by Jim Pingle over 4 years ago
- Status changed from New to In Progress
- Assignee set to Jim Pingle
- Target version set to 2.5.0
Updated by Jim Pingle over 4 years ago
In my opinion, if a user has the "WebCfg - All pages" privilege, pfSense should overwrite any lower right from being a member of another group.
We've had that come up in the past but it was decided that wasn't sufficient to treat someone as "admin" in cases like this.
pfSense does not have any concept of "higher" or "lower" privileges. The deny config write privilege does exactly what it says. When you give someone that "privilege", they can no longer take actions which result in a write to config.xml. Lots of people unintentionally make that mistake (usually by performing "select all" on the privilege list which is also a mistake), but it's still a user error. One we could probably handle better, but a user error nonetheless.
There may be some exceptions to that (like running commands on diag_command.php) but in general that should be respected as it is now.
What we can do is check that a user is the admin user (uid 0) or in the admins group (gid 1999) and ignore the 'user-config-readonly' privilege then.
Updated by Jim Pingle over 4 years ago
- Status changed from In Progress to Feedback
- % Done changed from 0 to 100
Applied in changeset fa0ed29ef58fe6758f2cdc96f5bf68da32241faf.
Updated by Jim Pingle over 4 years ago
- Target version changed from 2.5.0 to 2.4.5-p1
Updated by Jim Pingle over 4 years ago
- Status changed from Feedback to Resolved
Confirmed problem on stock 2.4.5 and confirmed fix after gitsync. The admin user (id=0) and members of the "admins" group are now exempt from the user-config-readonly privilege. This fixes the issue here and other common misconfigurations.