Authorization via getpwent (users coming via SSSD)
Hi, We currently have our users authenticating via ntlm_auth and would like to make authorization decisions based on group membership. The radius server is joined to the domain and standard Unix commands calling getpwnam will return expected data: # id user.name uid=123456789(user.name) gid=234567890(domain users) groups=234567890(domain users),345679012(noc),4567890123(vpm),5678901234(ipmi) Looking at various modules available to handle this I'm encountering the following problems with each (usual caveats about how I may be misreading the docs): rlm_pam: appears to only be set up to work for authentication rlm_passwd: appears to want a file rlm_unix: also appears to want a file to read? (maybe?) I'm hoping one of these above or perhaps something else can be used in the authorize section such that if a user logs in, and that user's group membership includes the required group (say, ipmi), then the authorization will be accepted. It's just not clear to me how to proceed here.
On Aug 14, 2019, at 3:23 PM, Mike Ely <me@mikeely.org> wrote:
We currently have our users authenticating via ntlm_auth and would like to make authorization decisions based on group membership. The radius server is joined to the domain and standard Unix commands calling getpwnam will return expected data:
# id user.name uid=123456789(user.name) gid=234567890(domain users) groups=234567890(domain users),345679012(noc),4567890123(vpm),5678901234(ipmi)
Looking at various modules available to handle this I'm encountering the following problems with each (usual caveats about how I may be misreading the docs): rlm_pam: appears to only be set up to work for authentication rlm_passwd: appears to want a file rlm_unix: also appears to want a file to read? (maybe?)
The Unix module calls getpwent() and getspwent(). It doesn't look at files.
I'm hoping one of these above or perhaps something else can be used in the authorize section such that if a user logs in, and that user's group membership includes the required group (say, ipmi), then the authorization will be accepted. It's just not clear to me how to proceed here.
Enable the "unix" module. Use the "Group" attribute, which does Unix group checking. if (Group == "sales") { reject } else if (Group == "engineering") { accept } Alan DeKok.
On 8/14/19 12:46 PM, Alan DeKok wrote:
Enable the "unix" module. Use the "Group" attribute, which does Unix group checking.
if (Group == "sales") { reject } else if (Group == "engineering") { accept }
Thanks for that. Unfortunately it appears that this only works against the primary group. Here's the stanza I have in sites-enabled/default: if (Group == "ipmi") { accept } else { update reply { Reply-Message = "User not allowed to connect to this device" } reject } When trying to auth with a user who is very much part of the "ipmi" group: (0) if (Group == "ipmi") { (0) if (Group == "ipmi") -> FALSE After switching the Group check to "Domain Users" (0) if (Group == "Domain Users") { (0) if (Group == "Domain Users") -> TRUE Is there a known issue surrounding this and if so what if any workaround should I be looking for?
On Aug 15, 2019, at 12:27 PM, Mike Ely <me@mikeely.org> wrote:
Thanks for that. Unfortunately it appears that this only works against the primary group.
Hmm... that then is likely an issue with the underlying password / group store.
Here's the stanza I have in sites-enabled/default:
if (Group == "ipmi") { accept } else { update reply { Reply-Message = "User not allowed to connect to this device" } reject }
When trying to auth with a user who is very much part of the "ipmi" group: (0) if (Group == "ipmi") { (0) if (Group == "ipmi") -> FALSE
After switching the Group check to "Domain Users" (0) if (Group == "Domain Users") { (0) if (Group == "Domain Users") -> TRUE
Is there a known issue surrounding this and if so what if any workaround should I be looking for?
For "Group == foo", the Unix module does: - if primary group is "foo", return "match" - get group "foo" - walk through the list of members seeing if User-Name is a member - if User-Name is a member, return "match" - otherwise return "no match" Alan DeKok.
On 8/15/19 9:34 AM, Alan DeKok wrote:
Hmm... that then is likely an issue with the underlying password / group store.
Probably. User and group membership doesn't appear in what I'd regard as "normal" ways i.e.: getent. SSSD is quirky IMHO but so was winbind.
For "Group == foo", the Unix module does:
- if primary group is "foo", return "match" - get group "foo" - walk through the list of members seeing if User-Name is a member - if User-Name is a member, return "match" - otherwise return "no match"
Maybe someday add a check that trusts the output of "id" as an indicator of group membership? For now I'll have to (with reluctance because it gives me headaches) follow another user's suggestion and use LDAP for authorization.
On Aug 15, 2019, at 12:52 PM, Mike Ely <me@mikeely.org> wrote:
On 8/15/19 9:34 AM, Alan DeKok wrote:
Hmm... that then is likely an issue with the underlying password / group store.
Probably. User and group membership doesn't appear in what I'd regard as "normal" ways i.e.: getent. SSSD is quirky IMHO but so was winbind.
The Unix module uses getpwnt() and getgrent()
Maybe someday add a check that trusts the output of "id" as an indicator of group membership?
<sigh> Comments like that are unproductive, if not actively hostile. We use standard APIs to get standard information. If those APIs are broken, then blame the OS, not FreeRADIUS. If you want to run "id" to get group membership, then FreeRADIUS allows you to do that. It's better to do that, than to make snide remarks on the list about how we should do things better.
For now I'll have to (with reluctance because it gives me headaches) follow another user's suggestion and use LDAP for authorization.
With great reluctance you're using a method that we recommend, instead of APIs that you know are broken. But you're still complain about how we should do things better. This behaviour is not acceptable. Alan DeKok.
On Thu, 2019-08-15 at 09:27 -0700, Mike Ely wrote:
On 8/14/19 12:46 PM, Alan DeKok wrote: Thanks for that. Unfortunately it appears that this only works against the primary group. ...
After switching the Group check to "Domain Users" (0) if (Group == "Domain Users") { (0) if (Group == "Domain Users") -> TRUE
Is there a known issue surrounding this and if so what if any workaround should I be looking for?
It's AD, right? Just do it properly and use rlm_ldap. -- Matthew
participants (3)
-
Alan DeKok -
Matthew Newton -
Mike Ely