Reliably looking up user's group membership SIDs

Isaac Boukris iboukris at gmail.com
Sun Mar 11 13:43:39 UTC 2018


Hi Stefan,

On Thu, Mar 8, 2018 at 1:39 PM, Stefan Metzmacher <metze at samba.org> wrote:
> But I see problems in the S4U2Self implementations
> of Heimdal and MIT. E.g. Heimdal currently only supports S4U2Self for
> services in the primary domain. MIT doesn't support S4U2Self with
> enterprice principals.



I've set up a little forest trust environment with one child domain
(testing domain-member scenario), and indeed Heimdal didn't work when
I try to impersonate a user from the child domain - while MIT works
just fine!

I was curious about enterprise-names in MIT (although it's probably
not a must-have), so I tested it by parsing the impersonate_princ as
KRB5_PRINCIPAL_PARSE_ENTERPRISE.
Then I got a failure when verifying the PAC at
k5_pac_validate_client(), here is what the output looks like:

# KRB5_TRACE=/dev/stderr /usr/local/samba/bin/net ads -P kerberos pac
dump impersonate=frenche at abc -d3
...
[31223] 1520766906.487368: AP-REQ ticket: frenche\@abc at ACME.COM ->
FS$@ACME.COM, session key rc4-hmac/793B
[31223] 1520766906.487369: PAC checksum verification failed:
-1765328250/Principal frenche at abc has realm present
[31223] 1520766906.487375: Filtering out unverified MS PAC
gssapi_obtain_pac_blob: obtaining PAC via GSSAPI
gss_get_name_attribute failed: The operation or option is not
available or unsupported: No such file or directory
gensec_generate_session_info_pac: Unable to find PAC for
frenche\@abc at ACME.COM, resorting to local user lookup
../source3/libads/authdata.c:298: Type mismatch: name[NULL]
expected[struct PAC_DATA_CTR]
PANIC (pid 31223): ../source3/libads/authdata.c:298: Type mismatch:
name[NULL] expected[struct PAC_DATA_CTR]

(btw, I think the abort() part of talloc_get_type_abort() in
kerberos_return_pac() is somewhat exaggerated)

I think what happens is that s4u2self never canonicalizes the client
name (even if the canonicalize flag is on), so when the PAC is
returned and we parse the KRB5_PAC_CLIENT_INFO buffer we get the UPN
format - this causes the library to fail when trying to parse it with
KRB5_PRINCIPAL_PARSE_NO_REALM as it takes the '@' sign as a realm
component.

I think it would be ok to check if the principal we compare with is an
enterprise one, and compare accordingly.
The below diff in krb5 lib fixes it for me.

$ git diff
diff --git a/src/lib/krb5/krb/pac.c b/src/lib/krb5/krb/pac.c
index 0eb19e6bb..38d25dc37 100644
--- a/src/lib/krb5/krb/pac.c
+++ b/src/lib/krb5/krb/pac.c
@@ -413,6 +413,7 @@ k5_pac_validate_client(krb5_context context,
     krb5_ui_2 pac_princname_length;
     int64_t pac_nt_authtime;
     krb5_principal pac_principal;
+    int enterprise = 0;

     ret = k5_pac_locate_buffer(context, pac, KRB5_PAC_CLIENT_INFO,
                                &client_info);
@@ -440,8 +441,13 @@ k5_pac_validate_client(krb5_context context,
     if (ret != 0)
         return ret;

+    if (principal->type == KRB5_NT_ENTERPRISE_PRINCIPAL)
+       enterprise = 1;
+
     ret = krb5_parse_name_flags(context, pac_princname,
-                                KRB5_PRINCIPAL_PARSE_NO_REALM, &pac_principal);
+                                KRB5_PRINCIPAL_PARSE_NO_REALM | enterprise ?
+                                KRB5_PRINCIPAL_PARSE_ENTERPRISE : 0,
+                                &pac_principal);
     if (ret != 0) {
         free(pac_princname);


With this fix, it now works ok even for a user from child domain with
the same UPN suffix (abc).
What do you think of this patch? Did you encounter this issue, other issues?

Regards.



More information about the samba-technical mailing list