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

From: "Richard B. Ward" <[email-masked]>
Date: Fri, 22 Oct 2004 11:10:53 -0700

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Martin Rex

...

However, the two newer SSPI calls, which actually have a parameter to
distinguish name types, namely GetUserNameEx() and TranslateName() are
broken in that they

 (a) do not work at all without an Active Directory

[richardw] you can't claim that they are broken when their sole design
point was to provide an API to map among the different name strings
associated with an account in an active directory instance.  Nor are
they even part of the SSPI interface, for that very reason.  While you
may wish that they did something else, the only thing that they were
intended to do was deal with AD account objects.

 (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).

 (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.

But if you open a command shell and look at the environment of a Windows
W2K+ machine joined to a W2K+ domain, then there is the environment
variable "USERDNSDOMAIN", containing the DNS domain name in
_all_uppercase_ -- which is kind of funny, because it happens to be the
correct spelling for the Kerberos REALM name, and *NOT* the DNS domain
name (I know that the DNS name is actually case-insensitive). 

[richardw] A non-technical reason behind this.  The domain name was
uppercase to avoid worry among the early adopters of win2k who were used
to seeing the USERDOMAIN environment variable.

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

---

From: Martin Rex <[email-masked]>
Date: Fri, 22 Oct 2004 23:35:57 +0200 (MET DST)

Richard B. Ward wrote:
> Martin Rex wrote: 

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.

> 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