Subject: RE: Comments: draft-williams-krb5-gssapi-domain-based-name

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 21 Oct 2004 09:59:21 -0700

Nicolas Williams wrote:
> Does it use generic GSS name syntax?

No, it only uses single-string "flatten" names.

-- larry
-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Thursday, October 21, 2004 9:54 AM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; Paul Leach
Subject: Re: Comments: draft-williams-krb5-gssapi-domain-based-name

On Thu, Oct 21, 2004 at 09:51:14AM -0700, Liqiang(Larry) Zhu wrote:
>  Nicolas Williams wrote:
> > Or is there something about the SSPI that obviates the need for name
> type OIDs?
> 
> SSPI does not use OID at the API level.  

Does it use generic GSS name syntax?

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: "Richard B. Ward" <[email-masked]>
Date: Fri, 22 Oct 2004 15:03:42 -0700

Bah.  Sorry about that Martin, it appears that someone decided to change
the behavior from predictable (win2k) to this rather strange attempt to
populate that name mapping locally.  The oddity in win2k that you note
stems from the effort to get away from the flat names and accept "upn"
style names in as many places as possible; your case
'TranslateName(Principal->Sam,"[email-masked]") == "SAP_ALL\d019080" '
is a result of that flexibility.  I've filed bugs to get the translate
behavior consistant with the getusername.  

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Friday, October 22, 2004 2:36 PM
To: Richard B. Ward
Cc: [email-masked]; [email-masked]; [email-masked];
Liqiang(Larry) Zhu; Paul Leach
Subject: Re: Comments: draft-williams-krb5-gssapi-domain-based-name

Richard B. Ward wrote:
> Martin Rex wrote: 
> >
> > (b) fail most of the time to produce the default Kerberos principal
> >     name when requesting "NameUserPrincipal" on most W2K+ platforms.
> 
> [richardw] See above.  The 'NameUserPrincipal' value corresponds to 
> the userPrincipalName attribute on the account object, sometimes 
> referred to in kerberos crowds as the enterprise name type.  There was

> some debate whether this should default to the value 
> "'samAccountName'@'dns.domain.name'" if no explicit userPrincipalName 
> was defined, but eventually we decided against it for consistancy 
> reasons (you would get a different value from LDAP, and would greatly 
> complicate rename scenarios).

OK, lets do a reality check here:

Remember, I do not have that weird "userPrincipalName" defined for any
of my accounts in any of the ADs.

Account from W2K-domain

W2Ksp4 (member of W2K3-domain at W2K-level, account from trusted
W2K-domain):
  GetUserNameEx(NameSamCompatible)=="SAP_ALL\d019080"
  GetUserNameEx(NameUserPrincipal) failed with ERROR_NONE_MAPPED
  TranslateName(Sam->Principal,"SAP_ALL\d019080") failed with
ERROR_NONE_MAPPED
  TranslateName(Principal->Sam,"[email-masked]") == "SAP_ALL\d019080"

WinXPsp1 (member of W2K-domain)
  GetUserNameEx(NameSamCompatible)=="SAP_ALL\d019080"
  GetUserNameEx(NameUserPrincipal)=="[email-masked]"
  TranslateName(Sam->Principal,"SAP_ALL\d019080") failed with
ERROR_NONE_MAPPED
  TranslateName(Principal->Sam,"[email-masked]") == "SAP_ALL\d019080"

WinXPsp2 (member of W2K3-domain at W2K-level, account fron trusted
W2K-domain):
  GetUserNameEx(NameSamCompatible)=="SAP_ALL\d019080"
  GetUserNameEx(NameUserPrincipal)=="[email-masked]"
  TranslateName(Sam->Principal,"SAP_ALL\d019080") failed with
ERROR_NONE_MAPPED
  TranslateName(Principal->Sam,"[email-masked]") == "SAP_ALL\d019080"

W2K3 (member of W2K3-domain at W2K-level, account from trusted
W2K-domain):
  GetUserNameEx(NameSamCompatible)=="SAP_ALL\d019080"
  GetUserNameEx(NameUserPrincipal)=="[email-masked]"
  TranslateName(Sam->Principal,"SAP_ALL\d019080") failed with
ERROR_NONE_MAPPED
  TranslateName(Principal->Sam,"[email-masked]") == "SAP_ALL\d019080"

Account from W2K3-domain at w2k forest functional level

W2Ksp4:
  GetUserNameEx(NameSamCompatible)=="NT5\d019080"
  GetUserNameEx(NameUserPrincipal)=="[email-masked]"
  TranslateName(Principal->Sam,"[email-masked]") == "NT5\d019080"
  TranslateName(Sam->Principal,"NT5\d019080") == "[email-masked]"

WinXPsp2:
  GetUserNameEx(NameSamCompatible)=="NT5\d019080"
  GetUserNameEx(NameUserPrincipal)=="[email-masked]"
  TranslateName(Sam->Principal,"NT5\d019080") == "[email-masked]"
  TranslateName(Principal->Sam,"[email-masked]") == "NT5\d019080"
 
W2K3:
  GetUserNameEx(NameSamCompatible)=="NT5\d019080"
  GetUserNameEx(NameUserPrincipal)=="[email-masked]"
  TranslateName(Sam->Principal,"NT5\d019080") == "[email-masked]"
  TranslateName(Principal->Sam,"[email-masked]") == "NT5\d019080"

Now tell me again with a straight face that this works exactly as you
described and anywhere remotely consistent and you'll risk to loose a
lot of credibility in this forum.

- With an account created in a W2K3 AD, the mapping to the default
  principal appears to work even without a manually defined
userPrincipalName
  attribute in the AD -- contrary to what you claimed

- with an account from a W2K AD, the call to GetUserNameEx() succeeds
  on all but W2Ksp4 machines.

- when the WinXP is a member of a W2K-domain and using a W2K-domain
  account, then GetUserNameEx(UserPrincipal) returns a name with
  an upper case realm name

- when the W2K(+) machine is a member of a W2K3-domain, then
  GetUserNameEx(UserPrincipal) returns a lower-case realm name, even
  when the account is only from a trusted W2K-domain

- TranslateName(SamCompatible,UserPrincipal) never works for accounts
  from a W2K-domain on any NT5.x machine

- TranslateName(SamCompatible,UserPrincipal) always works for accounts
  from a W2K3-domain on any NT5.x machine

As long as we have to live with customer that use W2K domains and W2K
machines, the API calls GetUserNameEx() and TranslateName() are entirely
useless -- which is why I call them broken.

> 
>  (c) do not return correct Kerberos principal names, but instead
>      return lookalikes with the lowercase DNS domain name following
>      the @ character, which is obviously inconsistent with the
semantics
>      of QueryCredentialsAttributes(NAMES)
>      and QueryContextAttributes(NATIVE_NAMES)
> 
> [richardw] Again, you have confused the nature of the API.
> GetUserNameEx and TranslateName are for talking to a Windows (or
> compatible) directory.  QueryContextAttributes() is for talking to a 
> particular security implementation and security context.

I'm so sorry, but the code that Microsoft shipped does not align with
your explanation.  GetUserNameEx() on WinXPsp1 joined to a W2K domain
does in fact return a name with all-uppercase REALM name (and if it
really depends on the *directory*, then I would assume that even a W2K3
machine attached to a W2K domain would return an all-uppercase REALM
name from GetUserNameEx() -- I just don't have such a machine to check.

-Martin

---

From: "Paul Leach" <[email-masked]>
Date: Sat, 23 Oct 2004 16:45:08 -0700

> Sent: Friday, October 22, 2004 6:28 PM
> To: Liqiang(Larry) Zhu
> Yeah, but I want to to be convinced one way or the other.  I have one
> argument, obvious difference, that I find mildly convincing for one
way
> and none that I find convincing for the other.

[Paul Leach] I don't know that anyone will find this convincing, but I
make the following (perhaps purely personal) observation: I find it
difficult to deal with the indirection that happens at the GSS-API
level, because how one "sees" Kerberos through the lens of GSS-API and
what one sees on the wire are different. The proposal at hand adds one
more such indirection, and isn't an extension in spirit of the
"service/realm" model already in use.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sat, 23 Oct 2004 17:44:30 -0700

I agree with Paul.

The domain-based service name ought to be reduced to be simply the host-based service name, when the domain component is missing, without un-necessary indirections.

In other words, the argument for the "service@domain@host" proposal from Nico can be used against it: it is another indirection such that "service@@host" does not appear to be the same as "service@host" at least for naïve readers. 

I think we are getting into an argument (or an issue) similar to the "Big Endian" vs "Little Endian" issue.  There won't necessarily be a winning argument from either camp, thus your expectation might be too high when you wanted something really convincing.

-- Larry

-----Original Message-----
From: Paul Leach 
Sent: Saturday, October 23, 2004 4:45 PM
To: Nicolas Williams; Liqiang(Larry) Zhu
Cc: [email-masked]
Subject: RE: Comments: draft-williams-krb5-gssapi-domain-based-name

> way and none that I find convincing for the other.

[Paul Leach] I don't know that anyone will find this convincing, but I make the following (perhaps purely personal) observation: I find it difficult to deal with the indirection that happens at the GSS-API level, because how one "sees" Kerberos through the lens of GSS-API and what one sees on the wire are different. The proposal at hand adds one more such indirection, and isn't an extension in spirit of the "service/realm" model already in use.