Re: Using enterprise principal name in GSS-API
Hi Alan, On Thu, Oct 6, 2016 at 9:29 PM, Alan Braggins wrote: > I do have a patch that adds gss_nt_krb5_name_enterprise as a > recognised OID (szOID_NT_PRINCIPAL_NAME 1.3.6.1.4.1.311.20.2.3), > and replaces a call to krb5_parse_name with krb5_parse_name_flags > with KRB5_PRINCIPAL_PARSE_ENTERPRISE in gssapi/krb5/import_name.c Could you share your changes? I'd be interested to compare it with what I've got so far, namely: https://github.com/frenche/krb5/tree/gss_enterprise_name Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Using enterprise principal name in GSS-API
Apparently I also have a broken mail that truncated most of that message. I'll see if I can recover it. From: Alan Braggins Sent: 06 October 2016 19:45 To: Greg Hudson; Isaac Boukris; kerberos Subject: Re: Using enterprise principal name in GSS-API On 23/09/16 15:50, Greg Hudson wrote: > On 09/23/2016 03:52 AM, Isaac Boukris wrote: >> Maybe we need a new gss name type oid like GSS_NT_ENTERPRISE_NAME, >> though I guess it's more complicated than it sounds :) > > I think that might be reasonable for this use case. I've seen requests > to be able to import enterprise principal names before, although (IIRC) > sometimes for use cases where it might not have made as much sense. > > The concerns I can immediately think of are: > > * Is there any prior art we should try to be compatible with? I don't > see any in Heimdal, and MS doesn't directly implement GSS-API, so I > don't think there is. > > * If someone uses one of these GSS names in a different scenario (e.g. > for an acceptor credential), will it fail gracefully? I believe that's > generally the case. > > * Does canonicalization at cred acquisition time pose any issues for the > GSS-API model, because the name you get creds for won't be the same as > the name you asked for? gss_acquire_cred_with_password() is an > extension, not a standardized part of the API, so I think it shouldn't > be a problem. I have actually got a patch that adds gss_nt_krb5_name_enterprise as a recognised OID ( Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Using enterprise principal name in GSS-API
On 23/09/16 15:50, Greg Hudson wrote: > On 09/23/2016 03:52 AM, Isaac Boukris wrote: >> Maybe we need a new gss name type oid like GSS_NT_ENTERPRISE_NAME, >> though I guess it's more complicated than it sounds :) > > I think that might be reasonable for this use case. I've seen requests > to be able to import enterprise principal names before, although (IIRC) > sometimes for use cases where it might not have made as much sense. > > The concerns I can immediately think of are: > > * Is there any prior art we should try to be compatible with? I don't > see any in Heimdal, and MS doesn't directly implement GSS-API, so I > don't think there is. > > * If someone uses one of these GSS names in a different scenario (e.g. > for an acceptor credential), will it fail gracefully? I believe that's > generally the case. > > * Does canonicalization at cred acquisition time pose any issues for the > GSS-API model, because the name you get creds for won't be the same as > the name you asked for? gss_acquire_cred_with_password() is an > extension, not a standardized part of the API, so I think it shouldn't > be a problem. I have actually got a patch that adds gss_nt_krb5_name_enterprise as a recognised OID ( Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Using enterprise principal name in GSS-API
On 23/09/16 15:50, Greg Hudson wrote: > On 09/23/2016 03:52 AM, Isaac Boukris wrote: >> Maybe we need a new gss name type oid like GSS_NT_ENTERPRISE_NAME, >> though I guess it's more complicated than it sounds :) > > I think that might be reasonable for this use case. I've seen requests > to be able to import enterprise principal names before, although (IIRC) > sometimes for use cases where it might not have made as much sense. > > The concerns I can immediately think of are: > > * Is there any prior art we should try to be compatible with? I don't > see any in Heimdal, and MS doesn't directly implement GSS-API, so I > don't think there is. > > * If someone uses one of these GSS names in a different scenario (e.g. > for an acceptor credential), will it fail gracefully? I believe that's > generally the case. > > * Does canonicalization at cred acquisition time pose any issues for the > GSS-API model, because the name you get creds for won't be the same as > the name you asked for? gss_acquire_cred_with_password() is an > extension, not a standardized part of the API, so I think it shouldn't > be a problem. I do have a patch that adds gss_nt_krb5_name_enterprise as a recognised OID (szOID_NT_PRINCIPAL_NAME 1.3.6.1.4.1.311.20.2.3), and replaces a call to krb5_parse_name with krb5_parse_name_flags with KRB5_PRINCIPAL_PARSE_ENTERPRISE in gssapi/krb5/import_name.c It doesn't address any of your concerns though, and I'd welcome suggestions for a better approach. (I'm using gss_acquire_cred_impersonate_name with protocol transfer and constrained delegation.) -- Alan Braggins Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Using enterprise principal name in GSS-API
On Mon, Sep 26, 2016 at 7:09 PM, Greg Hudson wrote: > On 09/25/2016 04:32 PM, Isaac Boukris wrote: >> In such a case (no canonicalization), if the user is found, the KDC >> returns AS reply with the exact name and name-type (enterprise) as >> requested. > > Interesting. That's probably not a behavior we want; enterprise names > should ideally only exist on the edge of the krb5 protocol. I also > don't think that's the behavior we would see with an MIT krb5 KDC > (combined with a third-party KDB module that implements enterprise > principal name lookup). I've now looked further into the constrained delegation case. Using enterprise name works fine with upn, but I see no canonicalization happening (even with the flag on, enterprise name-type is returned in TGS-REP). This can be seen when using the 'kvno' tool to do constrained delegation, as it always parses the 'for_user' as an enterprise name. >From MS-SFU doc it sounds like the KDC copies back the username and realm from the request (PA-FOR-USER). Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Using enterprise principal name in GSS-API
On Mon, Sep 26, 2016 at 7:09 PM, Greg Hudson wrote: > On 09/25/2016 04:32 PM, Isaac Boukris wrote: >> The more a look at the code and on wire traffic, I think >> enterprise-name and canonicalization are different things (although >> related). >> Here is what my tests against AD (w2k3) seem to show so far. >> >> First, the 'kinit' man page says -E implies -C but it doesn't seem to >> be correct (according to observations). > > I see that we don't set the canonicalize KDC option when -E is given. > Our KDC implementation treats AS requests as having the canonicalize > flag if the client principal name type is KRB5-NT-ENTERPRISE-PRINCIPAL, > with the comment "Note that according to the referrals draft we should > always canonicalize enterprise principal names". My reading of RFC 6806 > is more ambiguous; in section 5 (defining the enterprise name type) it > says "The KDC will recognize this name type and then transform the > requested name into the true principal name if the client account > resides in the local realm." But in section 6 (defining the > canonicalize flag) it doesn't say that the canonicalize flag should be > inferred from the principal type, and its example AS-REQ scenario > includes both an enterprise client principal name and the canonicalize flag. > >> In such a case (no canonicalization), if the user is found, the KDC >> returns AS reply with the exact name and name-type (enterprise) as >> requested. > > Interesting. That's probably not a behavior we want; enterprise names > should ideally only exist on the edge of the krb5 protocol. I also > don't think that's the behavior we would see with an MIT krb5 KDC > (combined with a third-party KDB module that implements enterprise > principal name lookup). I think earlier drafts of the RFC sounded more like MIT implementation logic. Quote from the third draft: "The KDC will always return a different name type than KRB-NT-ENTERPRISE-PRINCIPAL. This is regardless of the presence of the "canonicalize" KDC option." However the standardized draft sound a bit less decisive, quote (on enterprise-name): "It is used for conveying the alias name, not for the real principal names within the realms, and thus is only useful when name canonicalization is requested." I've run more tests against w2k8 and the behavior seem the same as in w2k3, meaning it returns enterprise name-type if no canonicalization was requested. I think the name in the returned ticket is also enterprise type as I get the same name format on acceptor side (something like, user\@suffix@REALM). However, windows acceptor indicates the canonical username (perhaps it takes it from the PAC). >> We probably want to support both enterprise-name and canonicalization >> in GSS-API (the latter could be set via conf). > > I think perhaps we should be setting the canonicalize option whenever we > make an AS-REQ with an enterprise client principal name, although I'm > not entirely confident about this because Heimdal doesn't seem to do it. > (Heimdal's kinit actually seems to do the reverse; its kinit > --canonicalize parses the client principal as enterprise even if > --enterprise isn't given.) Heimdal's approach doesn't look right, as the RFC doesn't seem to limit canonicalization to enterprise names. In fact, the old version (03) even gives an example of an KRB-NT-PRINCIPAL canonicalized to an KRB-NT-UID. Perhaps we could change the -E option to (actually) imply canonicalization but at the API level I think I would prefer to have both options as each makes sense in its way (IMO). - Using enterprise name type indicate the KDC to look up the user by an alias (implementation dependent, globally unique identifier - like email, phone, upn). - Enabling canonicalization to allow KDC to change name and name-type. > I'm not sure how gss_acquire_cred_with_password() with its current > signature could express a desire for the canonicalize flag, other than > by importing an enterprise name. Yea, it would have been useful to have a flag argument to overload. In cred-store API we could perhap implement a mech_flags store, but it doesn't support acquiring with password. So I think I agree the simplest way would be to introduce a GSS enterprise-name which would also imply canonicalization. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Using enterprise principal name in GSS-API
On 09/25/2016 04:32 PM, Isaac Boukris wrote: > The more a look at the code and on wire traffic, I think > enterprise-name and canonicalization are different things (although > related). > Here is what my tests against AD (w2k3) seem to show so far. > > First, the 'kinit' man page says -E implies -C but it doesn't seem to > be correct (according to observations). I see that we don't set the canonicalize KDC option when -E is given. Our KDC implementation treats AS requests as having the canonicalize flag if the client principal name type is KRB5-NT-ENTERPRISE-PRINCIPAL, with the comment "Note that according to the referrals draft we should always canonicalize enterprise principal names". My reading of RFC 6806 is more ambiguous; in section 5 (defining the enterprise name type) it says "The KDC will recognize this name type and then transform the requested name into the true principal name if the client account resides in the local realm." But in section 6 (defining the canonicalize flag) it doesn't say that the canonicalize flag should be inferred from the principal type, and its example AS-REQ scenario includes both an enterprise client principal name and the canonicalize flag. > In such a case (no canonicalization), if the user is found, the KDC > returns AS reply with the exact name and name-type (enterprise) as > requested. Interesting. That's probably not a behavior we want; enterprise names should ideally only exist on the edge of the krb5 protocol. I also don't think that's the behavior we would see with an MIT krb5 KDC (combined with a third-party KDB module that implements enterprise principal name lookup). > Note that if canonicalization is requested in GSS-API (via conf), then > my trick above (changing krb5_gss_import_name) doesn't work, I get: > gss_acquire_cred_with_password(): Invalid credential was supplied > Principal in credential cache does not match desired name We would probably need to adjust gss_acquire_cred_with_password(). > We probably want to support both enterprise-name and canonicalization > in GSS-API (the latter could be set via conf). I think perhaps we should be setting the canonicalize option whenever we make an AS-REQ with an enterprise client principal name, although I'm not entirely confident about this because Heimdal doesn't seem to do it. (Heimdal's kinit actually seems to do the reverse; its kinit --canonicalize parses the client principal as enterprise even if --enterprise isn't given.) I'm not sure how gss_acquire_cred_with_password() with its current signature could express a desire for the canonicalize flag, other than by importing an enterprise name. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Using enterprise principal name in GSS-API
Hi Greg, On Fri, Sep 23, 2016 at 5:50 PM, Greg Hudson wrote: > On 09/23/2016 03:52 AM, Isaac Boukris wrote: >> Maybe we need a new gss name type oid like GSS_NT_ENTERPRISE_NAME, >> though I guess it's more complicated than it sounds :) > > I think that might be reasonable for this use case. I've seen requests > to be able to import enterprise principal names before, although (IIRC) > sometimes for use cases where it might not have made as much sense. > > The concerns I can immediately think of are: > > * Is there any prior art we should try to be compatible with? I don't > see any in Heimdal, and MS doesn't directly implement GSS-API, so I > don't think there is. Indeed. > * If someone uses one of these GSS names in a different scenario (e.g. > for an acceptor credential), will it fail gracefully? I believe that's > generally the case. Perhaps we'll need to fail gss_canonicalize_name() since we cannot know what MN it would produce on acceptor side. > * Does canonicalization at cred acquisition time pose any issues for the > GSS-API model, because the name you get creds for won't be the same as > the name you asked for? gss_acquire_cred_with_password() is an > extension, not a standardized part of the API, so I think it shouldn't > be a problem. The more a look at the code and on wire traffic, I think enterprise-name and canonicalization are different things (although related). Here is what my tests against AD (w2k3) seem to show so far. First, the 'kinit' man page says -E implies -C but it doesn't seem to be correct (according to observations). When using enterprise name with -E, the client library allows for embedded '@' sign in the client-name and sends it in AS request with KRB5-NT-ENTERPRISE-PRINCIPAL name-type, but it does not request canonicalization (flag off, unless -C was given or canonicalization is set to true in krb5.conf). In such a case (no canonicalization), if the user is found, the KDC returns AS reply with the exact name and name-type (enterprise) as requested. This still has the advantage of letting the KDC to lookup the user by UPN in local realm (especially when different UPN suffixes are used in local realm). If however, the user is not found on local realm, the KDC returns an error but also sets the 'crealm' field in the AS reply to a better realm and the client tries to get credentials from this realm's KDC. So the only canonicalization implied so far is perhaps for the realm name. If canonicalization flag is on (-C or conf), then the (last) KDC replies with a KRB5-NT-PRINCIPAL name-type containing the sAMAccountName. Note that if canonicalization is requested in GSS-API (via conf), then my trick above (changing krb5_gss_import_name) doesn't work, I get: gss_acquire_cred_with_password(): Invalid credential was supplied Principal in credential cache does not match desired name Also note, that I found one case where canonicalization occurs (when requested) even using regular KRB5-NT-PRINCIPAL name (the name changes, not the type). We probably want to support both enterprise-name and canonicalization in GSS-API (the latter could be set via conf). So far I couldn't see find in GSS-API doc any problem with, let's say returning a canonicalized name (e.g. in inquire_cred) different from what was imported at acquire. Thanks, Isaac B. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Using enterprise principal name in GSS-API
On 09/23/2016 03:52 AM, Isaac Boukris wrote: > Maybe we need a new gss name type oid like GSS_NT_ENTERPRISE_NAME, > though I guess it's more complicated than it sounds :) I think that might be reasonable for this use case. I've seen requests to be able to import enterprise principal names before, although (IIRC) sometimes for use cases where it might not have made as much sense. The concerns I can immediately think of are: * Is there any prior art we should try to be compatible with? I don't see any in Heimdal, and MS doesn't directly implement GSS-API, so I don't think there is. * If someone uses one of these GSS names in a different scenario (e.g. for an acceptor credential), will it fail gracefully? I believe that's generally the case. * Does canonicalization at cred acquisition time pose any issues for the GSS-API model, because the name you get creds for won't be the same as the name you asked for? gss_acquire_cred_with_password() is an extension, not a standardized part of the API, so I think it shouldn't be a problem. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Using enterprise principal name in GSS-API
Hi again, On Wed, Sep 21, 2016 at 12:07 AM, Isaac Boukris wrote: > Hi all, > > Is there a way to support name canonicalization (like kinit -E) when > acquiring creds via gss_acquire_cred_with_password() and > gss_acquire_cred_impersonate_name() ? > > The use case is to use userPrincipalName for client name against AD. I've found RFC 4768 already laments the lack of enterprise names in GSS-API (and raises some concerns, mainly ACL related). RFC 6860 on the other hand says nothing about GSS-API. Technically, if I change krb5_gss_import_name() to pass KRB5_PRINCIPAL_PARSE_ENTERPRISE flag when parsing the name, then both aforementioned functions work fine with UPN (even when the UPN suffix differs from realm name). Maybe we need a new gss name type oid like GSS_NT_ENTERPRISE_NAME, though I guess it's more complicated than it sounds :) Thanks and regards. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Using enterprise principal name in GSS-API
Hi all, Is there a way to support name canonicalization (like kinit -E) when acquiring creds via gss_acquire_cred_with_password() and gss_acquire_cred_impersonate_name() ? The use case is to use userPrincipalName for client name against AD. Thanks! Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
