1

maybe somebody can give me a hint on this.

I am evaluating the prerequisites for changing all (human) user's UPN in a large Microsoft AD environment to the recommended MS format (aligned with the user's primary public mail address incluiding the user's publicly routable mail domain as UPN suffix).

Now changing a UPN may break applications or services or disrupt user logon processes when the UPN is utilized.

I am aware that the UPN is not widely used for logons in most environments today still i would like to elaborate if there is a way to diagnose usage of UPNs for logon processes.

We are talking about a funtional level of well above 2003 but with active NTLM. Relevant Domain Controllers are running 2012 and 2012R2. The scenario is in this case limited to a single forest with 3 domains. Though that is a fraction of the environment, it is the only portion relevant for the change of the UPN.

First and simplest would be to check the eventlog on domain controllers for logon events. Problem is: as far as I see it these always log in the "legacy" format of "DOMAIN\username", no matter which kind of user id representation was used to log on. Please correct me if I'm wrong as that would really speed up things massively.

Next thing that comes to my mind are network traces of Kerberos tickets going back and forth. If I'm not mistaken about Kerberos, these are initially encrypted using the user's password and to inspect them I would need to decrypt the ticket using data from the (probably) unknown client.

Now this is where I'm uncertain and hope to be wrong as at some point the DCs need to determine which password hash they utilize to decrypt the message. I admit that I didn't do a lot of testing on this yet as I didn't want to modify the DCs just now..

Maybe there is a different way to approach this that I didn't think of yet - anyway I hope somebody can give me a hint on possible apporaches to tackle this problem. I would hate to "apply the change and duck", I'd rather get it right the first time if in any way possible.

Matthias Raithel
  • 73
  • 1
  • 7
  • "I admit that I didn't do a lot of testing on this yet as I didn't want to modify the DCs just now.." - Is there a reason why you don't use a test lab / environment to investigate this? – BlueCompute Jan 22 '16 at 14:21
  • Quite simple actually. The project is still - let's call it "pre-eval" (Hasn't officially started yet) so I find it hard to request resources for it :) But I am going to borrow a differen project's test boxes next week and do some initial testing, watching the logs and capturing some traces – Matthias Raithel Jan 24 '16 at 16:11

1 Answers1

1

Ok I can now, after the testlab, answer this myself. The initial request for a TGT from the system being logged into to the domain controller contains the username in clear text in the kerberos payload of the network packet(s) (that much was already known).

But:

When logging in with domainname\username, this will be the username.

When logging in with the UPN, this will be the full UPN of the user

The packet you would be looking for is TCP, KRB5 payload, Message type krb-as-req (10) Username is under section "cname" with name-type "KRB5-NT-ENTERPRISE-PRINCIPAL"

So to find out if you have UPNs in use in your network, track all of these packets coming into your DCs, after some time save the traces to disk and filter for the "@" sign.

Matthias Raithel
  • 73
  • 1
  • 7