Changing the Administrator Password

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

We changed 'the' domain Administrator accounts password the other week and successfully logged into the DC's with the new password, however when you try to log into any member servers or clients you cannot log on with the new password.

I changed the password again on monday (so that I could see the problem for myself) and it was all working correctly, you could log in everywhere using the administrator account, including through Remote desktop sessions. This worked until around about 2pm yesterday when we tried to log into a member server and it would not accept the password. The DC's take it no problem, but not the member servers or clients.

Unable to figure out what was causing the issue I copied another admin's account, made sure that it had all of the same group memberships as 'the' administrator account. set its password and tested it. I could log in everywhere without any problems.

I then changed the password on my new admin account and tested it, again I could log in to DC's, Member servers, clients, etc.

This morning when the new admin account has been tried out the password again will not work on the member servers or clients. Fine on the DC's, but not anywhere else?

Anyone got any ideas?

 

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

What is the exact error message when trying to login to a Server or Client?

Have you checked the Security Event Logs to see what information they give?

 

The error that is given is the standard 'The system could not log you on....please check that you have typed your password....'

 

hmmm, having just spoken to a colleague about this he says that he has seen it before. he changed passwords, spent ages banging his head against a wall trying to figure out what was going on and they suddenly just sprung into life.

he seems to think that it was just replication taking its time, however there were no replication errors in his case, neither are there any in this one either.

:hhhmmm:hhhmmm

 

Weird. I've often seen domain admin password changes cause havoc (usually when someone has stuck the account in as a service account somewhere and not told anyone) but never seen it only affect non-DCs. Certainly seems, on the face of it, as though there's an issue replicating the password changes around - is your PDC Emulator online and functioning correctly? That's the FSMO role that deals with centralisation of passwiord changes - though I suspect you would have noticed before if there was something wrong with it!

Anything in the event viewer related to account logon/logoff events on the servers affected? Try setting the event logging level up a couple of notches to see if it records anything more helpful than the usual 'logon attempt failed' message

 

Set the admin password to NEVER EXPIRES. hope that will do the trick.....

 

Niiiiiice and secure...

 

The password was changed on the DC that has all of the FSMO roles. All are working correctly and I am seeing no replication errors in event viewer on any of the DC's.

I don't have access to the servers at the minute, but I'll ask the schools network manager to change the logging.

The strange thing about it possibly being replication is why did it work for three days then refuse to work anymore?

The regional settings are definately set to the UK, I know I set them up myself. We've tired simple passwords and its still no different.

It's not a problem if you create an account with a complicated password and never want to change it!!

Also, this is only affecting Administrators, normal users can change passwords as normal?

Possibility of the system being hijacked by a rootkit perhaps???

:hhhmmm

 

If that's the case, you're in a world of hurt... with it being DCs, the phrase 'keys to the kingdom' springs to mind I wouldn't suspect something that drastic at the moment though. Can you run a network trace with ethereal when trying to log on? Maybe by plumbing the box into a mirror port on a switch (or even temporarily routing it through a 10Mb repeating hub) you could sniff and see what happens when you try to log on - this may give you more information on where the process is going wrong.

Getting a trace on network activity may help you if you have to put a call into PSS - they'll ask you to set the diagnostic logging level for security events (which logs hideous amounts of data) and may well ask you to run a capture as well. If you can do that and are willing to PM me the .cap file I can take a look at it for you - but I fully understand if you can't because of confidentiality reasons

 

Might you accidentally be logging in as the local admin on the member servers? The DCs don't have local accounts, but the member servers do...

 

I think (I could be wrong of course) that Ethereal no longer exists. I think it's now "Wireshark".

 

LOL - pedant!

Old habits die hard... it'll ALWAYS be Ethereal to me

You're quite right though, it is called Wireshark now

 

We old-school techs often use the old-school names.

You know, sometime after Alzehimers sets in...

 

Come on Michael! Thats basic troubleshooting!

 

Well, they do have local accounts, but these are inactive when the active directory is running. If they did not have a local account, how would you then do a AD restore?

Do the servers where the logon fails have access to the Global Catalog at that time?

 

Yep. Infact one of the member servers is a Virtual Server that sits on the GC server.

 

Hmmm - following up from Tinus' mail - how is your AD set up? Do you have a single domain or multiple. Recommended GC placement in a single domain environment is for ALL DCs to be GCs as well. However, if you're running multiple domains in your forest then you should ensure that the Infrastructure Master for each domain is NOT also a GC server - this can cause problems with Security Principals.

I've never come across the exact issue you're describing, but I HAVE seen slightly similar ones in multi-domain environments before which were resolved by removing the GC from the IM in each domain.

 

Well... you know what I mean.

 

Sometimes the simplest things are overlooked.

Have you rebooted? Sorry! Couldn't resist!!!

EDIT: I'll literally die laughing if that fixes it!!!