January 27, 2009 at 3:09 am
Can anyone help as I am at a loss with this one.
I am running SQL Server 2000 Standard Edition on a Windows Server 2003 standard edition machine.
The way our in-house developed .NET applications and SQL Server work is simply as follows.
Each application has an Active Directory group created for it, and users that are permitted to access the application are then added to the group.
This AD group is then added into SQL Server, mapped to the appropriate databases, and then either granted permissions on the required objects, or are assigned to a database role that carries the required permissions.
Up until today this has worked like a charm. That was until two users requested access to one of the applications. Both were set up identically and we've double checked everything, however when one of the users attempt to run the application reports that they do not have permissions and the following log is recorded in the SQL Server log.
Login failed for users 'xxx\xxx'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors. [CLIENT: xxx.xxx.xxx.xxx]
Error: 18456, Severity: 14, State: 11
I've tried Googling the problems but what I'm reading makes no sense at all. :crazy:
---------------------------------------
It is by caffeine alone I set my mind in motion.
It is by the Beans of Java that thoughts acquire speed,
the hands acquire shaking, the shaking becomes a warning.
It is by caffeine alone I set my mind in motion.
January 27, 2009 at 7:36 am
Is that one user a member of a lot of Windows groups (including nesting)? Is the user having login issues for any other resources (such as file shares, Exchange, etc.)?
K. Brian Kelley
@kbriankelley
January 27, 2009 at 7:53 am
All users within the company are members of quite numebr of groups as they control all our resources, however we do not allow nesting.
What was peculiar is that other people who can gain access are members set up identially, with exactly the same groups.
However we believe we know what the issue might be, and that is down to replication of the Active Directory as a user who was experiencing similar problems yesterday, even after repeatedly logging in and out of the network for over 2 hours, found they had access this morning.
If this user can gain access to the system tomorrow then this is the most likely cause. However I am still open to other suggestions in case I am wrong.
---------------------------------------
It is by caffeine alone I set my mind in motion.
It is by the Beans of Java that thoughts acquire speed,
the hands acquire shaking, the shaking becomes a warning.
It is by caffeine alone I set my mind in motion.
January 27, 2009 at 8:02 am
Unless you have a lot of sites with multiple site links, it shouldn't normally take that long for security changes to replicate. What may be, though, is that the change was made after the user logged in. When a user logs in, the security token is built based on current memberships (so far as the domain controller knows). If a change is made after that, the security token isn't updated until the user logs in again.
K. Brian Kelley
@kbriankelley
January 27, 2009 at 8:08 am
As soon as a change is made to a group or user, we always ensure that they log out of the network and log back in to ensure that the security token is updated. However I suspect that this may be occuring before replication can take place which will result in the same issue.
We have a considerable number of servers within the domain that are off-site, both in this country and overseas, and I suspect that there is something amiss with its configuration as I sometimes get errors when my Outlook somehow tries to connect to an Exchange server in an branch overseas when sending mail!?!?!? But that is one for the networking department to resolve :Whistling:
---------------------------------------
It is by caffeine alone I set my mind in motion.
It is by the Beans of Java that thoughts acquire speed,
the hands acquire shaking, the shaking becomes a warning.
It is by caffeine alone I set my mind in motion.
January 27, 2009 at 8:35 am
Rayven (1/27/2009)
As soon as a change is made to a group or user, we always ensure that they log out of the network and log back in to ensure that the security token is updated. However I suspect that this may be occuring before replication can take place which will result in the same issue.We have a considerable number of servers within the domain that are off-site, both in this country and overseas, and I suspect that there is something amiss with its configuration as I sometimes get errors when my Outlook somehow tries to connect to an Exchange server in an branch overseas when sending mail!?!?!? But that is one for the networking department to resolve :Whistling:
Exchange configuration doesn't necessarily equal how the rest of the domain is configured. There was advice about putting Exchange in its own sites so that it had dedicated global catalog servers, etc. However, if you're connecting to domain controllers overseas, when there are some locally, then that would indicate an issue. I hope that the physical site topology within AD has been set up correctly and not just as one big default site (which I've seen).
K. Brian Kelley
@kbriankelley
January 27, 2009 at 9:23 am
Erm, having seen the way that the network department configured active directory, it was migrated directory from the original domain, so it is just one huge chunk.:crazy:
Don't ask me why they did it like that, I'm sure they had their reasons.
---------------------------------------
It is by caffeine alone I set my mind in motion.
It is by the Beans of Java that thoughts acquire speed,
the hands acquire shaking, the shaking becomes a warning.
It is by caffeine alone I set my mind in motion.
January 27, 2009 at 9:26 am
Rayven (1/27/2009)
Erm, having seen the way that the network department configured active directory, it was migrated directory from the original domain, so it is just one huge chunk.:crazy:Don't ask me why they did it like that, I'm sure they had their reasons.
Then I'm glad I'm not the directory services administrator there. I'd be pulling my hair out. I took off my directory services admin hat off as of Dec. 31st and I have no real desire to put it back on. So I'll end my comments about AD on this thread here. 🙂
K. Brian Kelley
@kbriankelley
April 6, 2009 at 1:22 pm
So was this an AD replication issue?
I'm getting the same "Token" based error when I add a user from a new domain to an existing domain. I've detailed the problem
http://www.sqlservercentral.com/Forums/Topic690161-146-1.aspx
April 24, 2009 at 12:01 pm
I am also having a very similar issue. Did this ever get resolved?
😎
April 24, 2009 at 12:06 pm
I had to add the user from the new domain to the local users group on the server in the old domain.
April 27, 2009 at 1:19 am
We never did resolve it. Our network department decreased the time between replication of the active directory but it never made a difference. We have just learned to live with the fact that it can take anywhere from a few seconds to 24 hours before a user can access a system if we aren't warned well in advance.
---------------------------------------
It is by caffeine alone I set my mind in motion.
It is by the Beans of Java that thoughts acquire speed,
the hands acquire shaking, the shaking becomes a warning.
It is by caffeine alone I set my mind in motion.
May 1, 2009 at 7:37 pm
In case anyone got here by the same path I did. Migrating database servers from one box to another SQL 2005 to SQL 2008 I received this error after reattaching all my databases and trying to connect via deployed apps. Turns out I skipped a step - transferring the login information. This MS link worked like a charm http://support.microsoft.com/kb/918992/
Hope this helps.
July 14, 2009 at 8:38 am
I Have this issue running SQL Server 2008 and this message was in the log:
"Login failed for user '%'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors"
I could not use any other login except by the login that was used to install SQL Server. So the solution was:
1) Login in the server with the same account used to setup SQL Sever.
2) Open management studio
3) Run -- GRANT CONTROL SERVER TO "my login" for each user that you want to grant rights in the server.
This worked for me.
Bye
Eduardo Pin
July 14, 2009 at 12:43 pm
eduardo.pin (7/14/2009)
3) Run -- GRANT CONTROL SERVER TO "my login" for each user that you want to grant rights in the server.
We have seen this issue when a Windows user was a member of too many Windows group as it causes the token to be too big (known issue... you can either reduce the groups or modify the registry on every system to increase the acceptable token size). But in any case, you probably want to resolve the root cause of this issue. Granting CONTROL SERVER is the equivalent of making everyone a member of the sysadmin fixed server role.
K. Brian Kelley
@kbriankelley
Viewing 15 posts - 1 through 15 (of 30 total)
You must be logged in to reply to this topic. Login to reply