Bugfix - User Principal Name (UPN) usernames should send up an empty "TargetName" in the authentication message

[Rican7]

This one was confusing/frustrating. Why? Probably because it is, again, a behavior that is: undocumented in the specification, seemingly implicit, and somewhat nonsensical.

So, as we've known for quite some time, there are 2 formats for "user name" designations:

1. DOMAIN\username
2. username@dnsdomainname.com

These formats are even documented on MSDN.

While this library doesn't attempt to hold anyone's hand in how these designations are separated into their respective username and domain name values (although maybe it should at some point), we've known for quite a while that we should separate these format values into two distinct values. Currently, in an application that we've built using this library, we look for any \ character or @ character and separate the strings into $domain and $username values, however we've noticed some authentication errors for certain setups when using this method of inference.

This style of data separation seems to even be supported by the aforementioned documentation (note the documents use of "part" designation). However, after some more extensive testing, it's become obvious that this just doesn't work. Unfortunately, we've instead noticed that domains and usernames should only be inferred from these compound representations when in the first, "Down-Level Logon Name" format. Not only does our testing support this, but the thankfully incredible unofficial documentation provided by Eric Glass (Davenport) also supports this practice:

In addition to the variations in message layout, user and target names can be presented in a few different formats within the Type 3 message. In the typical scenario, the User Name field is populated with the Windows account name, and the Target Name is populated with the NT domain name. However, the username and/or domain can also be presented in the Kerberos-style "user@domain.com" format in various combinations. It has been observed that several variations are supported, with some possible implications/caveats:

Format	Type 3 Field Content	Notes
DOMAIN\user	User Name = "user" Target Name = "DOMAIN"	This is the "normal" format; the User Name field contains the Windows user name, and the Target Name contains the NT-style NetBIOS domain or server name.
domain.com\user	User Name = "user" Target Name = "domain.com"	Here, the Target Name field in the Type 3 message is populated with the DNS domain/realm name (or fully-qualified DNS host name in the case of local machine accounts).
user@DOMAIN	User Name = "user@DOMAIN" Target Name is empty	In this case, the Target Name field is empty (zero-length), and the User Name field uses the Kerberos-style "user@realm" format; however, the NetBIOS domain name is used instead of the DNS domain. It has been observed that this format is not supported for local machine accounts; additionally, this form does not appear to be supported under NTLMv2/LMv2 authentication.
user@domain.com	User Name = "user@domain.com" Target Name is empty	Here, the Target Name field in the Type 3 message is empty; the User Name field contains the Kerberos-style "user@realm" format, with the DNS domain. This form does not appear to be supported for local machine accounts.

So, contrary to any official documentation or sense, we'll just have to trust both the reverse-engineered Eric Glass documentation and the functional integration testing that we've completed here.

NTLM... you're quite the challenge.

[jstruzik]

Nice nice.

[jstruzik]

LGTM 👍 ty for doing this.

[mcos]

Noticed this in the doc for strpos: http://php.net/manual/en/function.strpos.php#80363

As strpos may return either FALSE (substring absent) or 0 (substring at start of string), strict versus loose equivalency operators must be used very carefully.

We're good with this "truthy" style comparison here?

[Rican7]

Oh whoops! Weird, I'm usually the one reminding people of this one. Yea, great call. Let me fix that.

[jstruzik]

Good catch.

[jstruzik]

STILL lgtm 👍

[mcos]

LGTM 👍

[Rican7]

❤️ Thanks!

[Rican7]

Listing a few projects/code-snippets here for later reference:

• UPN Suffix doesn't work at all FreeRDP/FreeRDP#2427 (comment)
• Allowing UPN syntax for user argument. FreeRDP/FreeRDP#2701
• https://github.com/bagder/curl/blob/ebfe00c05001f9830aefb0ea10cdeccc4f27c66b/lib/curl_ntlm_msgs.c#L501-L523