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