Hi Greg, On Fri, Sep 23, 2016 at 5:50 PM, Greg Hudson <ghud...@mit.edu> 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
