Use Kerberos PAC to allow group based fine-grained access control

[ondrejv2]

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

[simo5]

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.
So extracting the info in itself is probably not sufficient if you plan to perform access control using groups. Unless you'd be willing to use raw SIDs in the configuration.

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.

[ondrejv2]

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.

Looks like the library is doing that already, see:
https://mailman.mit.edu/pipermail/kerberos/2023-August/022991.html

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.

Well, true - having to resolve SIDs to something more meaningful makes the whole idea somewhat less appealing.
The thing is that mod_lookup_identity can not do any authentication/authorization on it's own - can we use it to resolve SIDs or we have to query SSSD via D-BUS directly?

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?

[simo5]

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.

Looks like the library is doing that already, see: https://mailman.mit.edu/pipermail/kerberos/2023-August/022991.html

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).

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.

Well, true - having to resolve SIDs to something more meaningful makes the whole idea somewhat less appealing. The thing is that mod_lookup_identity can not do any authentication/authorization on it's own - can we use it to resolve SIDs or we have to query SSSD via D-BUS directly?

The thing would work this way:
[authentication] httpd -> mod_auth_gssapi -> libkrb5 - --PAC---> SSSD
[authorization] httpd -> mod_lookup_identity <--- SSSD

You would have to have both basically.

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.

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..

BTW: Is IPA also using PAC attributes or it's Microsoft thing only?

IPA uses (and can generate) MS-PAC structures for its AD trust codepaths.

[ondrejv2]

Ok I see.
I was hoping to get some modern replacement for (a bit old-school) mod_authnz_ldap.
Now mod_auth_gssapi looked promising at first, but since it has no support for SSSD, it can't query SSSD for groups the user is member of so we can't really use it.

Is at least support for SSSD on your roadmap? I mean it could work even without PAC support, i.e.:
httpd -> mod_auth_gssapi -> SSSD (query groups the authenticated user is member of)
SSSD -> mod_auth_gssapi -> httpd (allow/deny access based on the configuration)

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.

IPA uses (and can generate) MS-PAC structures for its AD trust codepaths.

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.

[simo5]

Is at least support for SSSD on your roadmap? I mean it could work even without PAC support, i.e.: httpd -> mod_auth_gssapi -> SSSD (query groups the authenticated user is member of) SSSD -> mod_auth_gssapi -> httpd (allow/deny access based on the configuration)

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.

[michael-o]

It still would be very helpful if require group S-1-..., means group SIDs are available for authz. I'd be able to throw out my Python scripts to scrape groups via LDAP once in while.

[ondrejv2]

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.
Also not sure what the PAC attribute actually contains, does it contain all groups the user is member of (i.e. including nested ones)?

[michael-o]

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. Also not sure what the PAC attribute actually contains, does it contain all groups the user is member of (i.e. including nested ones)?

Yes, it should all groups in all domains.

[simo5]

It contains all of the SIDs as unpacked by the KDC, SSSD is needed to translate those into Unix Groups.

[michael-o]

While SSSD is a nice thing, not in every environment this is really required, given the overhead of packages and configuration required. I am still highly in favor of this. using raw SIDs isn't really a problem. It just works. I have written the same for Tomat this year and it works fantastically: https://github.com/michael-o/tomcatspnegoad/tree/main/tomcat90/src/main/java/net/sf/michaelo/tomcat/pac with the realm. Compared to LDAP requests this is light speed. It is a blessing in cross-forest setups.

[simo5]

I guess patches are welcome, but I am not going to accept any big dependency and any hand-decoding would have to be very robust to be accepted.

[michael-o]

I guess patches are welcome, but I am not going to accept any big dependency and any hand-decoding would have to be very robust to be accepted.

Based on my experience with the Java impl and looking at https://github.com/krb5/krb5/blob/a96541981ee34c8642ddeb6101b98e883e41c6e5/src/lib/krb5/krb/pac.c#L883-L907 you don't even need an ASN.1 parser because MIT Kerberos breaks up PACTYPE structure for us. Even better pac.c does verify the server signature for us.
Just fired up gss-client/gss-server and I properly see:

• Attribute urn:mspac: Authenticated Complete
• Attribute urn:mspac:logon-info Authenticated Complete
• Attribute urn:mspac:upn-dns-info Authenticated Complete

So at least urn:mspac:logon-info needs to be parsed and that should be feasable with HTTPd/APR/KRB5/OpenSSL functions.

The only bug my impl for thousands of PACs I have found was https://lists.samba.org/archive/samba-technical/2024-September/139132.html

Disclaimer: I am not a daily C hacker to do the job quickly :-(

[simo5]

I am well aware of what is available, I did write or contribute or review both krb5 and samba and freeipa code for many years exactly in these fields.
Which is why I decide not to add this code myself in this project and rather rely on existing code written and maintained elsewhere.

As I said, I am not against someone contributing code in this sense, if they feel like writing text representations of SIDs in configuration files is a reasonable thing to do, but the standard to accept a contribution that deal with parsing code coming from the network will be high.

[michael-o]

I am well aware of what is available, I did write or contribute or review both krb5 and samba and freeipa code for many years exactly in these fields. Which is why I decide not to add this code myself in this project and rather rely on existing code written and maintained elsewhere.

As I said, I am not against someone contributing code in this sense, if they feel like writing text representations of SIDs in configuration files is a reasonable thing to do, but the standard to accept a contribution that deal with parsing code coming from the network will be high.

Fair enough.

[DemiMarie]

As I said, I am not against someone contributing code in this sense, if they feel like writing text representations of SIDs in configuration files is a reasonable thing to do, but the standard to accept a contribution that deal with parsing code coming from the network will be high.

Isn’t the PAC signed by the KDC and thus trusted?