7 Responses to Token-based server access validation failed with an infrastructure error

  1. DataGate says:

    I have the same error message but with different cause, my problem is a ghost SID associated with the AD user account

    Background
    An Active Directory (AD) account was created for a user [Domain\UserA]
    A SQL login was created for the account above and then granted access to a number of databases
    The AD account was renamed/modified to [Domain\UserB]
    At this stage the user would encounter an error when connecting to the server
    The sql log show this error message
    Error: 18456, Severity: 14, State: 11.
    Message
    Login failed for user ‘domain\user’. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors. [CLIENT: xxx]

    Action on Server 1 SQL (the one with the problem)
    Dropped the user from the databases
    Re-Created the login from the windows account [Domain\UserB]
    Created the user in the respective databases
    But the user still unable to connect to the server

    Investigation
    On server 1, the SID of the user in SYSUSERS was Matching SYSLOGINS and matches with result of SUSER_SID(Domain\UserA)
    But it does not match the SID in the AD
    The rest of the servers all have the correct SIDs
    When I use SUSER_SNAME(Incorrect-Sid) and SUSER_SNAME(Correct-Sid) on this server they both return [Domain\UserB]

    The problematic server is always returning the incorrect SID when recreating the user login and when using SUSER_SID(Domain\UserA) as if it is cached somewhere.
    I can’t specify the SID when creating the SQL login because it is using the Windows account
    Any idea on how to fix this problem

  2. dbamohsin says:

    Does it work when you bypass token validation by setting the user to have sysadmin?

    have you restarted the instance in between this issues?

    You analysis regarding the ghost sid seems correct – the next question would be how to remove the old sid from the ‘cache’. I would say restart the instance if you have not already tried that – it may be that the orphaned ghost sids are cleaned up on startup.

  3. Suresh says:

    I have the similar issue. It works when I grant the user sysadmin privilege. It is happening only to 2 users and they are good with another instance running on the same server.
    Any ideas?

  4. Suresh says:

    Yes, I tried that as well but no luck.

  5. John J Serna says:

    After validating some solutions posted on other forums, this was the only one that fixed the error. Thanks a lot.

  6. Mike Glenn says:

    Thanks. This is the first solution that worked in our situation other than dropping and recreating the affected Windows accounts. We have a mix of SQL Server 2005 and 2008R2 running on Windows Server 2008 R2 on a cross-domain AND mixed mode network (Windows 2000 (ugh!) on one domain and 2003 R2 AD on the other). This error was encountered when some users tried connecting to SQL Server databases restored from servers on the 2003 AD trusted domain.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: