-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Kerberos PAC to allow group based fine-grained access control #288
Comments
In theory yes, but we defer that kind of action to the underlying krb5 library and then use the available APIs to extract that data like we do for other info already. Keep in mind that the PAC just includes bare bones Identifiers, not user or group names. In order to resolve users/groups from the PAC you would have to use a system mapping facility like SSSD or Windbind that can cache and unroll the extracted SIDs to the relative accounts. In libkrb5 there is already a module (used by SSSD too) that can extract a PAC and feed it to SSSD for priming its caches, winbindd can do something similar I believe. You can take a look at https://github.com/adelton/mod_lookup_identity/ it is a module that can talk to SSSD on its dbus listener to resolve identities properly. You may also want to test the GssapiNameAttributes option with the "json" value to see if you already have the information you want there. I know that krb5 libraries we use already extract some info from the authroization data, but I do not recall if they do any parsing of the PAC itself and expose it via Named Attributes. |
Looks like the library is doing that already, see:
Well, true - having to resolve SIDs to something more meaningful makes the whole idea somewhat less appealing. Anyway, I think for a start it would be nice to have this implemented via group SIDs at least - just to see how much audience it would get. I mean I can always stick the CN of the group in the config file as a comment. BTW: Is IPA also using PAC attributes or it's Microsoft thing only? |
The library is extracting only some krb5 level fields unfortunately, there is no parsing of the actual authorization data you care for due to the encoding format used (MS NDR).
The thing would work this way: You would have to have both basically.
Requires parsing NDR structures, and that is not very simple, samba has code for it, and SSSD uses some of it for parsing the PAC, but it is not something I would shove into mod_auth_gssapi, it is a huge dependency, for a rarely used feature..
IPA uses (and can generate) MS-PAC structures for its AD trust codepaths. |
Ok I see. Is at least support for SSSD on your roadmap? I mean it could work even without PAC support, i.e.: Unfortunately AFAIK mod_lookup_identity can not be used (or I do not know how to do it and did not find any fruitful documentation for that) for authentication process.
I see - but since IPA does not use PAC to store auxiliary groups the user is member of, then it probably does not make much sense to add support here, I agree. |
No, this definitely will not happen. mod_auth_gssapi is an authc (authentication) module, and does not deal with authorization beyond telling the principal/local name of the user and proding data (like that PAC) that some other module can deal with. Group based authorization is deferred to specialized authz (authorization) modules that can do that, like mod_lookup_identity. |
It still would be very helpful if |
I have created mod_authnz_sss which provides the functionality (requires SSSD so slightly more complicated to use, but works), see https://issues.redhat.com/browse/RHEL-3699. |
Yes, it should all groups in all domains. |
It contains all of the SIDs as unpacked by the KDC, SSSD is needed to translate those into Unix Groups. |
Hello,
I am wondering if it would be possible to extend mod_auth_gssapi abilities to decode Kerberos PAC and allow finer grained access control based on groups the authenticated user is member of.
These groups can be extracted from the Kerberos PAC (i.e. without any additional ldap lookup).
Is something like this doable?
Thanks
The text was updated successfully, but these errors were encountered: