Forum Discussion

justletmelogin50's avatar
justletmelogin50
Brass Contributor
Jun 23, 2026

Event 4768 for one user

Hi all,

We have two domain controllers running server 2019 with Domain Functional Level 2016.

We have one user who has been with us for almost a year, and they were suddenly getting a message in the last week that username or password were incorrect even though we confimed they were not.  They were able to initally switch to another user and re-enter their username and log in, but now it won't allow that.

On the domain controller I see events for the user Audit Failure 4768 with Result Code 0x6.  This result suggests the username doesn't exist which isn't true.  The account isn't being locked.

Has anyone seen this before and know what the issue might be?

thanks

jm

Active Directory

2 Replies

  • Jamony's avatar
    Jamony
    MCT
    Jul 07, 2026

    Hi, if this is isolated to one user, I would look at that account and the device they are signing in from before assuming the domain controllers are the problem.

     

    Good checks:

     

    1. Confirm whether the failures come from one workstation, one app, or many systems.

    2. Check the 4768 failure code and client address in the event details.

    3. Clear stored credentials on the user's device, including Credential Manager, mapped drives, mobile mail apps, and old RDP sessions.

    4. Confirm the account is not locked, expired, or recently changed in a way that old credentials are still being reused.

    5. If the user recently changed password, check services or scheduled tasks running under that user account.

     

    The client address and failure code should point you toward whether this is a stale password, time/Kerberos issue, or one device repeatedly trying bad credentials.

  • kyazaferr's avatar
    kyazaferr
    MCT
    Jun 25, 2026

    Event ID 4768 with Result Code 0x6 (KDC_ERR_C_PRINCIPAL_UNKNOWN) indicates that the Key Distribution Center (KDC) could not locate the client principal specified in the Kerberos AS-REQ. Although this often means "user not found", it can also occur when the account exists but Kerberos is receiving an unexpected or incorrect identity.

     

    Since the user was able to log on previously and this started only recently, I would check the following:

     

    Verify the account actually exists on the DC processing the request

    Get-ADUser username

     

    Also verify:

     

    Account is enabled

    Account has not expired

    UserPrincipalName (UPN) is correct

    sAMAccountName hasn't been modified

    Check which Domain Controller is handling the authentication

     

    If only one DC returns Event 4768 with 0x6, compare AD replication:

     

    repadmin /replsummary

    repadmin /showrepl

    dcdiag /test:Advertising

     

    A replication issue could cause one DC to have stale directory information.

     

    Verify the workstation is using only AD DNS servers

     

    Incorrect DNS (public DNS, stale records, VPN DNS, etc.) can cause the client to contact the wrong KDC.

     

    ipconfig /all

    nltest /dsgetdc:<domain>

    Look at the 4768 event details

     

    Pay particular attention to:

     

    Client Address

    Target User Name

    Supplied Realm Name

    Certificate Information (if Smart Card authentication is used)

     

    Sometimes the client is actually sending an incorrect UPN or realm.

     

    Check for duplicate UPNs

     

    A duplicate UPN can also cause Kerberos lookup issues.

     

    Get-ADUser -Filter * -Properties UserPrincipalName |

    Group-Object UserPrincipalName |

    Where-Object Count -gt 1

    Test with another workstation

     

    If the user can authenticate from another computer, the problem is likely local to the original workstation (cached credentials, Kerberos cache, DNS, or machine secure channel).

     

    You can also clear the Kerberos cache:

     

    klist purge

     

    or verify the secure channel:

     

    Test-ComputerSecureChannel -Verbose