Random accounts locking after global UPN change

I was instructed to change the UPN for users because of O365 migration and Bit Titan. I tested with my user account chris@newupnA.com and everything seemed to work fine. I did every user's and now I'm getting a bunch of Kerberos errors like this:

================================================

A Kerberos authentication ticket (TGT) was requested.

Account Information:
      Account Name:            Username@newupnB.com
      Supplied Realm Name:      DOMAINNAME.LOCAL
      User ID:                  NULL SID

Service Information:
      Service Name:            krbtgt/DOMAINNAME.LOCAL
      Service ID:            NULL SID

Network Information:
      Client Address:            ::ffff:10.1.0.182
      Client Port:            57618

Additional Information:
      Ticket Options:            0x40810010
      Result Code:            0x6
      Ticket Encryption Type:      0xFFFFFFFF
      Pre-Authentication Type:      -

Certificate Information:
      Certificate Issuer Name:
      Certificate Serial Number:
      Certificate Thumbprint:

Certificate information is only provided if a certificate was used for pre-authentication.

Pre-authentication types, ticket options, encryption types and result codes are defined in RFC 4120.

================================================

There are 3 new UPNs that are different based off of which department the users are in, but they're all still members of the same domain realm in AD. It looks like the Kerberos ticket includes the FQDN(with the new UPN) as the authenticating accountname, but is trying to access using the old domain realm. Obviously this is going to fail..

Anyone seen this issue before?

Anyone know if adding the suffix's to Domains and Trusts will fix this and is a smart thing to do?

Any help is welcome.

Thanks in advance!

Chris

Active Directory* kerberos

Last Comment

Chris H

8/22/2022 - Mon

Jose Gabriel Ortega Castro

11/28/2017

The UPN is unique, indeed in a multidomain environment, you should add the suffix, indeed here's a script for it:
https://gallery.technet.microsoft.com/scriptcenter/Add-Suffixes-to-Active-cfa9bb48

In exchange environments, the point is to make the UPN match the email of the person so the person just uses the UPN to login into their email.

Make sure that the request is well formatted (using Prewindows 2000:: DOMAIN\User) or (UPN)

look at this: krbtgt/DOMAINNAME.LOCAL (this is backward, the format is USER\DOMAIN instead of DOMAIN\USER)

Chris H

11/28/2017

ASKER

It's a single domain as far as Active Directory is aware. However, the hosted email is multiple domains within our organization. So, the UPN's are not actual internal domains, just external domains for their email. In order to deploy bit titan and make the transition seamless, this was a necessity. Are you saying that I should add the suffixes (even though they don't exist in my active directory) to domains and trust suffixes?

Thanks!

Chris

Chris H

11/29/2017

ASKER

bump?

I started with Experts Exchange in 2004 and it's been a mainstay of my professional computing life since. It helped me launch a career as a programmer / Oracle data analyst

William Peck

ASKER CERTIFIED SOLUTION

Chris H

12/4/2017

THIS SOLUTION ONLY AVAILABLE TO MEMBERS.

View this solution by signing up for a free trial.

Members can start a 7-Day free trial and enjoy unlimited access to the platform.