• Status: Solved
  • Priority: Low
  • Security: Public
  • Views: 66
  • Last Modified:

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:
      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 H
Chris H
  • 4
1 Solution
Jose Gabriel Ortega CCEO J0rt3g4 Consulting ServicesCommented:
The UPN is unique, indeed in a multidomain environment, you should add the suffix, indeed here's a script for it:

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 HInfrastructure ManagerAuthor Commented:
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?


Chris HInfrastructure ManagerAuthor Commented:
Chris HInfrastructure ManagerAuthor Commented:
I reverted the UPN's back to their original domain.local and populated the email address field under the general tab.  Seems to have fixed the problem and still suffices for the bit titan agent.

Chris HInfrastructure ManagerAuthor Commented:
Fixed myself
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now