Ensure cname precisely matches what was in request

[MaximeKjaer]

What's the problem?

The current handling of cname is not always spec-compliant. The spec requires the Kerberos server to essentially echo back cname and crealm to the client. However, in some scenarios, Kerberos.NET responds with a slightly different cname.

This is an issue for Kerberos clients that check that the cname in the response exactly matches what was in the request (such as MIT krb5, see code pointer).

The current handling of cname is only subtly wrong. It works in the most common scenario (let's call this scenario 1), where:

• cname is ["username", "realm"]
• crealm is "realm"

However, it does not work in this scenario (let's call this scenario 2):

• cname is ["username"]
• crealm is "realm"

This latter scenario can occur in practice. For instance, see the Wireshark trace below, where a Linux client got a referral TGT from an on-prem AD DS server. The cname only has one part.

Using this referral TGT gave

• Bugfix
• New Feature

What's the solution?

Currently Kerberos.NET uses crealm and cname from the request to Find an IKerberosPrincipal, and then re-constructs cname and crealm fields in the response from the found principal.

However, this conversion from cname/crealm to IKerberosPrincipal isn't injective. In both scenarios 1 and 2, we can find the same client principal from the cname and crealm fields. When we convert that principal back to cname and crealm, we don't necessarily get the same values back.

The solution is to copy cname and crealm from the request. This aligns with the spec, section 3.3.3 Generation of KRB_TGS_REP Message:

By default, the address field, the client's name and realm, the list of transited realms, the time of initial authentication, the expiration time, and the authorization data of the newly-issued ticket will be copied from the TGT or renewable ticket.

• Includes unit tests
• Requires manual test

What issue is this related to, if any?

None.

[MaximeKjaer]

I made this obsolete because you can achieve the same result via ClientName (and you have more control over the number of Name parts, and the Type of the principal name).

Also I wanted to ensure Kerberos.NET avoids using SamAccountName as much as possible, as it's the cause of non spec compliant behavior -- and that any usages are appropriately marked as dangerous / deprecated way of doing things.

But I think it's debatable if it really should be marked as deprecated. Happy to roll this back if you would rather keep it as-is.