Honestly, I don't know the first thing about Active Directory. I know how to do the most basic of things inside it, like reset passwords and stuff, how to make users a member of a group, etc.

But when something goes wrong I just don't have enough experience with it to know what to do. Here's my predicament:

I work for a very small office (3-4 people) and they have a Windows Server box with Active Directory running. These people have accounts on the system and their computers are part of a domain.

Recently, though, it seems they've become disconnected from Active Directory. One of the users forgot her password, and I've changed it in the system, but every time she tries to log in it's giving her an error that her username or password is incorrect. The username is correct, so it seems as though it's not talking to the server to get the new password. Any idea what could be going wrong here?

Thanks. Let me know if I can supply any more info. I have remote access to the servers, but not the computer in question. I do have remote access to another machine on the network.

It's been a long time since I've been near Active Directory, but the following may help:

1. Check the event log on both client and server, specifically the security section. This may reveal some hints.

2. Make sure the date and time is set properly on the server and client. If these get too out of sync, authentication can fail.

3. Double check the bindings for the computer(s) in question. On the client, this can be checked in a basic way via the GUI, and on the server, the system should show up as a computer object. You can always try to delete the computer server side, then have the client rejoin the domain.

4. Make sure DNS is working properly. Active Directory relies heavily on DNS, and if people point their system to a normal external server (like Google), the domain is likely to fail. Everyone should be pointed at the Windows Server hosting the domain.

There is much more in depth stuff that can be checked, but this should at least cover the basics.

Thanks for the help, Tom.

1. I'm not exactly sure how to read the security event log for this kind of setup. On the server, I'm seeing nothing but events for this server. On the client, I see a single entry with a computer name that isn't the client or the server...

2. Time/Date appear to match on both.

3. I'm sorry, I'm not sure what you mean by bindings.

4. DNS on the client is pointing to the server's static IP, so that seems to be fine.

Two sets of questions to begin with:

Basic questions:
1. Is it Windows Server 2003 or later, or is it Windows 2000? More precisely, what version of AD/Domain is being used?
2. Are you positive the user is logging on to the domain (or the right one), and not to the local machine?
3. If Windows 2003 and later, what is being entered as a username: "username@domain.name.com" or simply "username". If just "username", back to point 2., can you confirm the third line in the logon screen labeled "Logon To:" is actually showing the proper domain and not local computer?
4. What is the exact wording of the error message?

More advanced:
A. Is the logon failing on one PC only, or on every domain PC?
B. Are other domain users loggin on successfully on those same workstations where this particular user logon is failing?
C. On the Domain Server, checking the properties of the PCs where logon is failing, can you confirm their icon in the AD is not showing a broken connection? It is very unlikely, but it may have happened if you changed the computername without operating in the domain first, for example.
D. Have you re-imaged any of the workstations where the logon is failing?

In general, one way to solve broken domain-workstation link without spending too much time troubleshooting is to remove the workstation from the domain (done at the workstation), then in the domain (on the domain server) - not always needed, but again, it takes 1 second and does not hurt-, then create the workstation again in the domain, the re-join the workstation (at the workstation). Of course, make sure the workstation name you enter in the domain is correct.

The most common problem I've seen with Active Directory (and, equally, back in the days that it was just "domains", before AD was invented), is this:

Not only does a *user* have an account with the AD server, but the computer does, too.

The computer, if it's a member of the domain, has its own account and password. You can see the computer account in the Active Directory Users and Computers applet.

The thing is, no one ever understands this because they never have to type the computer's password. That's negotiated automatically with the AD server when it joins the domain, and at regular intervals thereafter. It's all under the hood.

The problem crops up any time you re-image one of the client machines. Here's how it works:

- You create a client computer.
- You join that client computer to the domain.
- Client computer negotiates, with the AD controller, its machine account password under the hood.
- Client says "Welcome to <domainname>" and asks you to reboot.
- You use the computer and it works for a while.
- You decide to create a backup image of the working system.
- You use that computer for a while. Weeks pass.
- Under the hood, at regular intervals, the client computer is re-negotiating a fresh machine password with the AD controller.
- Weeks later, something goes wrong, and you restore the computer from its imaged backup.
- That imaged backup contains the old machine password and tries to authenticate with that password.
- Server sees the machine attempt to authenticate with the bad machine password and locks out the machine (and thus whatever users are trying to authenticate from that machine).

Only solution is to delete the computer's account in the domain, set the computer to Workgroup, then set the computer back to domain and have it renegotiate a new machine password.

Is there any chance that's what happened to you?

Basic questions:
1. Is it Windows Server 2003 or later, or is it Windows 2000? More precisely, what version of AD/Domain is being used?

It is Server 2003 (the server its self probably isn't much newer than that!). It has Active Directory 5.2.3790.3959.

2. Are you positive the user is logging on to the domain (or the right one), and not to the local machine?

Yes, I'm positive.

3. If Windows 2003 and later, what is being entered as a username: "username@domain.name.com" or simply "username". If just "username", back to point 2., can you confirm the third line in the logon screen labeled "Logon To:" is actually showing the proper domain and not local computer?

They are using just the prefix, not the whole address.

4. What is the exact wording of the error message?

I'll try to get the full error, but at the moment I'm working on these machines remotely, so I don't know if I'll be able to log back in...

More advanced:
A. Is the logon failing on one PC only, or on every domain PC?
B. Are other domain users loggin on successfully on those same workstations where this particular user logon is failing?

Logons aren't failing for everyone, but I'm thinking it might be because others have already logged into those computers and have accounts created locally. Does that make sense? However, I definitely replaced one user's computer recently and was able to log her on (it was a computer already joined to the domain, just one she hadn't logged onto before...

C. On the Domain Server, checking the properties of the PCs where logon is failing, can you confirm their icon in the AD is not showing a broken connection? It is very unlikely, but it may have happened if you changed the computername without operating in the domain first, for example.

I didn't change any computer names that I can think of. I don't see any problem with the icon...

D. Have you re-imaged any of the workstations where the logon is failing?

No, everything is as it was.

In general, one way to solve broken domain-workstation link without spending too much time troubleshooting is to remove the workstation from the domain (done at the workstation), then in the domain (on the domain server) - not always needed, but again, it takes 1 second and does not hurt-, then create the workstation again in the domain, the re-join the workstation (at the workstation). Of course, make sure the workstation name you enter in the domain is correct.


I'll have to see if I can do that. Like I said, I'm remoting these computers, so it might not be possible to remove and re-add the computer without getting kicked off in an unrecoverable way...


Heh, I think I'd remember all that, so no, I don't think that's what happened. I haven't done nearly that much with these peoples' systems.

Ok, so since it is 2003, I would try to logon using "username@domain" just to rule out any possibility there's some issue with locating the proper domain. This is really for peace of mind, and I don't think it is going to help much.


If the domain users you are trying to use remotely are administrators on the local machine (workstations), then you'll be able to logon and therefore to see the error messages. If they are not and you did not enable them to logon remotely, you won't be able to logon. But, in this case, just logon as with your account, go to user manager and make the malfunctioning account part of local computer administrators, and you're done. Or, alternatively, again using your admin account, you may include such malfunctioning user accounts into the list of those who can logon remotely: right-click on My Computer, Properties, Remote.
And actually, if you can do one of the above two things, than you have a proof that the workstation is actually properly connected to the domain. In fact, to add domain users to any local permission group, you need to access the domain through the workstation you're using, which implies that the workstation itself is properly authenticating to the domain (see what Tony explained above).


Partly it does.
If a user already logged on locally and a cache user profile was created locally, you should still get an error message saying that there was some problem authenticating the user in the domain, but then logon process would continue and the user would access to local resources but not to domain resources.
Unless, of course, you deliberately configured the domain or local machine policies to get a different behavior, such as, for example, denying local logon as well when you are not authenticated to the domain; this is a typical safer setup, actually, in "public" places such as computer labs in universities.

IF all users are failing to authenticate to the domain, but are being logged on locally based on a local cached profile, they should not be able to access domain shares on the domain server, for example.n You may want to check that too.
Again unless you deliberately changed the domain and domain server policies to allow anonymous non authenticated access to shares accessible by "everyone", but this is a very unusual setting and I think you would remember fiddling with policies and permissions to do that.


So if by replaced you mean taken from some other place a put on her desk, in other word changing the switch port it is connected to, then the domain server would not even notice.


Yes, it is possible. It is actually being done on a regular basis at work, as we have a group of people who would physically place machines in place, and another who has the needed Domain privilege to join machines to the domain. The latter usually work remotely. Two reboots of the workstations will be needed. One after you remove it from the domain. One after you join it again. Basically
1. Make sure you have the local workstation admin account. RD on the workstation as a local admin. Remove it from Domain. Reboot. You get kicked off of course.
2. While workstation reboots, RD on the Domain Server as a domain admin, and cancel the workstation from the domain. Then Add it again. Logoff.
3. Logon to the workstation which has just rebooted, as a local admin. Join it to the domain providing the domain admin credentials. Reboot it. You get kicked off.
4. Done. Now you may try to RD to the workstation after the second reboot is completed and check if you have any problem.

Ok, here's another thing you may quickly check on the domain server.
Is it possible you "renamed" this person's username on the domain? If so, it can get confusing at times. Display Name, full name, actual logon name may be different, and it is the logon name you should use to logon.
If you think this could have happened, in the Domain Server, open
Active Directory Users and Computers from the Adminisstrative Tools.
Locate the malfuncioning user. Properties. Open the "Account" tab.
Check there what the "logon name" is, as well what the pre-windows 2000 logon name is (if you have it in there). One of those two should be used to logon, and not the full name or the display name or whatever name this user object has in the AD.

Edit:
To explain what I mean here and how confusing this may get, my user account could be

- "Taym" as a <object name> in the AD, and this is what it is shown when you look at the list of users of a specific organizational unit in the Active Directory USers and Computers applet.
when you get into the properties of such AD object (user), though:
- "John" in the <first name> field, "Smith" in the <last name> field, but
- "J. A. Smith" in the <display name> field
** - "john.smith" in the <logon name> field
** - "JOHNS" in the <pre-windows 2000 logon name> field

Only those with the ** would work to log you on the domain.

In rare complex organizational setups, this is actually very versatile. But, it can get a mess also.

Thanks for all the help, Taym. I appreciate it. At the moment there are people using the workstations, so I might try again when they leave.

A weird thing happened towards the end of my troubleshooting, though: I found that my remote software (LogMeIn) did allow me to log out and still maintain control. So, I tried logging in as the user who was having trouble (previously I was logging in as an admin account that currently works on all the systems in the organization). This time I was able to log in successfully. Ugh! There's no computer problem I hate more than one that comes and goes.

Sure, no problem at all.

Now, if logon was successful, I'm thinking of a faulty ethernet cable/port somewhere between the PC and the Domain Server? Do u think this is possible? If logon worked, there's nothing wrong in the DC/Workstation trust relationship.