Status: Solved
Priority: Low
Security: Public
Views: 66
Last Modified: 2017-12-09

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

Chris H

Asked: 2017-11-28

Advertise Here

1 Solution

LVL 17

Jose Gabriel Ortega CCEO J0rt3g4 Consulting ServicesCommented: 2017-11-28

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)

LVL 16

Chris HInfrastructure ManagerAuthor Commented: 2017-11-28

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

LVL 16

Chris HInfrastructure ManagerAuthor Commented: 2017-11-29

bump?

LVL 16

Chris HInfrastructure ManagerAuthor Commented: 2017-12-04

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.

Thanks!

LVL 16

Chris HInfrastructure ManagerAuthor Commented: 2017-12-09

Fixed myself

Question has a verified solution.

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

Random accounts locking after global UPN change

Join & Write a Comment Already a member? Login.

Featured Post