Bizarre thin client connection issue

[edlcsre]

Hi all,

You know sometimes you get a particular support call, and, by a process of elimination, eliminate all possible causes of the issue, but its still not working?? Well, this is what we've got. Would be grateful for any ideas or suggestions.

Its a Windows 2000 AD environment, with a Citrix Metaframe XP Server Farm. We've got ThinStar clients.


We have a thin client user at a remote site. He cannot log in to his thin client using his username and password. He can't log in from any of the other thin clients in the office with his username and password. Others can log in from his thin client with their own username and password.

Error message is 'The system could not log you on' Checked the obvious stuff, reset password, etc etc, and still no joy. Its at this point the call is escalated to me (as i do server support, not desktop) I can log in with the id and password without any problems, yet the user on the other end of the phone cannot. We've checked the spelling of the username, the spelling of the password, that the keyboard isn't broken(!), still no luck

Then suspect it could be related to the fact he is using a thin client, so find a thin client to try and connect with, and this also works fine here, but not there for him.

I then decide it has got to be something to do with the site he is based at. It can't be his thin client itself, as everyone else can connect from it, its just his account which cannot. We create a brand new account for him, the the same OU, having deleted his profile and home drive, to make sure its nothing there. The creation of the account creates him a new home drive, and the profile is created when we first log in. I can connect fine from my pc and a thin client, he cannot connect.

His user account is in the same OU as his colleague, who's account he is using as his will not work.

I create a brand new account, just for testing. Once again, we have the exact same issue, he cannot log in using this account either, but it works fine for me!

Having checked through the event log for the Domain Controller, the error code we're getting when it fails to log in is 676. EventID shows this as a login failure due to the userNAME not the user password.

Additionally, error code 6, which is displayed in the event itself, is lised as '6 Client not found in the Kerberos database.'

I'm really struggling to know where to look. It can't be the client itself, as nobody would be able to log into it, it doesn't appear to be the account, as it works fine apart from our user on his thin client at the other site, and it can't be a Group Policy on the OU as it'd affect everyone else, and not just this user.

The fact I've created new accounts in the same ou and a new account in a completely different OU both of which work for me and not for the user mean i'm pretty much out of ideas.

The issue purely seems to be any new account created within the OU for this organisaton, and only when they're connecting via a thin client at this site.

We've been having some strange issues with profiles lately, and its got to the stage where checking the permissions of certain objects (including group policies) will just give a list of SID's, rather than account names. Is it possible we've got AD corruption, and this is why new accounts are not working correctly and old ones work without any issues?

If any of you have seen similar issues, or have any other ideas where I could look to try and find the answer, I'd be really grateful. As it stands, he can log in as the user who is next to him the alphabetical order in his OU, but not with his own account, when permissions, settings, security, etc, are identical, based on the user in question.....

Am out of ideas!!

Chris

 

[ctxuser]

When you say that you can log in, were you saying that you can log in as him or log in with your own account?, Thanks very much for the policies issues you've mentioned. The only thing I haven't heard you say is the entry of this particular user in the 1)Remote desktop Users Group, check that he is in this group.ii) Check also that he is in the RDP and ICA protocol permissions via the Terminal services Configuration.
iii) now I know you've probably tried this before but I'll just say it again. Try login in this user with the UPN convention something like user@domainname.com I hope these measure helps you in any way..

Sometimes, you just have to forget your head and grab your balls ...!

 

[edlcsre]

Hi ctxuser.

Can log in as the user in question.

He's in the correct groups (exactly the same ones as his colleague, who can connect ok) and there are no special permissions on the RDP and ICA protocols on the Citrix boxes; besides, we can connect fine as him.

I've got him to use the FQDN when logging in, and its not made any difference, just the same error messages as before

The plot thickens even more this morning.

We moved his account (which he wasn't able to connect with, and we were) into the root OU for the organisation, and he was able to connect first time. The second time he tried to connect, he could not, the same problem as before) We could still connect with the ID and password without issue

We then copied one of the admin accounts that we use, which was in the IT support OU, and got him to log in with this. He was able to log in and out three times without issue. We moved this to the thin client OU (where his account was to start with) and changed the group membership to be the same as one of his colleagues and it worked a couple of times before failing to work once again. As before, we can connect from here fine.

It seems to me the only possible cause of this would be dodgy replication of AD, as he will be connecting to a different domain controller at his site that we are here. It can't be OU as it works sometimes, and then stops; surely an OU issue would not work at all.

So, it appears that it works for a period of time, and the stops!

Next stop is to look for directory replication issues I guess?

Chris

 

[edlcsre]

update on this one.

Having had a thorough trawl through AD Sites and Services, and done some testing, the problem appears to relate to replication issues within AD....it isn't doing it properly. So, i'm here on site A creating and fiddling with our user's account, and logging in fine, but he, at Site B, is connecting to a different domain controller, and, for some reason, this has his OLD account there. I was able to prove this yesteday as I connected to each domain controller in turn to check his account. I deleted it on my local domain controller, and, an hour later (after 4 lots of replication, the account had been deleted on all domain controllers APART from his local one at site b) So, when he tries to log in, he connects to a 'dead' account, and I'm guessing this is why we get the username invalid error code, the account shouldn't exist.

Further testing allowed us to see that by creating a new account on the bridehead server for our site, this appears to have replicated to his site ok (!). Typically he's not around today to test this, but i'm hopeful.

As an aside on this, within Active Directory Sites and Services, when you expand each site, and select the server, there is a link which shows what I believe to be the configured replication parners for each server, yes? Well, for some servers, the replication servers are shown by name, and for others they are shown as autocreate, and have a long SID for the machine name, despite the fact they should be the same as the machines listed for other servers by name,

Sorry, thats a bit complex, let me explain.

Site A has 3 DC's, Server1, Server2 and Server3
Site B has 1 DC, server4
Sice C has 1 DC, server5, and so on.
and so on.

looking at the partners for server1 gives the following info

Server2, <a really long SID> (Server3), Server4


However, Server2's properties shows Server3 by name, not by the SID.

Is this a sign that we've got corruption at the site replication level, and, if so, what are the potential issues of deleting and re-creating each of the 'corrupt' connections to try and resolve the problem?

Just trying to see if its corruption within AD which is causing the replication not to work properly, or corruption within the replication which is causing AD not to work properly, if you see what I mean.

Any thoughts?

Chris