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.

Hmmm, weird.. when you log on to a domain you are not logging onto a member server, (the member server does not have a copy of the active directory database) you are contacting a *domain controller* for authentication.

To me it seems your member servers aren't communicating properly and you could be using cached credentials on the member servers, which are out of date

It smacks of improperly configured DNS, as it's DNS SRV records that point logins to the correct DC

 

I do, but does everybody else do to? Most off my students don't realise that the password they provide for the administrator account during the DCPromo process is in fact the password for the newly created local administrator, the password you need to have when you need to perform a AD restore some 20 months later when the domain admin password has allready been changed a number of times and have to recall what the password was 6 changes ago. Most students just tend to give the password for the domain admin at that time. Microsoft is helping a lot there by using just 1 password for all accounts in their courses.

 

This is a single domain on a single site, the school has three DC's, one of which has all of the FSMO Roles, all the DC's are configured ac GC's. The first two DC's also run as DNS servers.

Yep, this is the same place that I had to mess about with the policies a few weeks ago. To be honest this school has had that many problems with security and policies not applying that this password issue is way down the list of priorities!

You are right though, it could definately be some wierd problem, but how can restoring policies back to their default setting cause something like this?

Sparky is correct its only the domain admin account that has the problem. This is at least as far as I am aware I did ask the NM about it and he seems to think this is the case but I have not yet confirmed this myself.

 

Is it just the original built-in domain admin account or other accounts that have been added to the domain admins group?

 

Call me old fashioned if you will but i find that hard to believe

 

I think you definetly need to confirm this.

 

Well, it's hard enough to diagnose a problem when you are the person actually gathering the important pieces of information that helps lead to a successful diagnosis.. When all you have to go on is 'hearsay', it is best to ignore most of it until you have confirmed for yourself that the reported symptoms are actually as described.

This is my take on relevant facts so far..

We have a problem with a user password change not being processed properly. the user belongs to the domain admins group.

Password changes are handled by the DC holding the PDC Emulator role (depending on the mode of the forest).

Durin login, Universal Group membership is checked out by a GC server.

Only GPOs set at the domain level can affect "account policies". (lockout, complexity etc).

So, when logging in at a member server, which is not a DC or a PDC emulator or a GC holder.. you really must have connectivity with servers that are. I'm assuming that the member servers are working ok, and have no obvious connectivity issues.

Therefore, i conclude that the problem stems from being unable to locate the PDC/GC/DC on the network.

As i said, DNS is where *i* would look first.

 

Well I'll be damned!

It seems that I've got to the bottom of this one today, Nothing to do with DNS, or anything complcated, but perhaps something to do with when the Default Domain Policy was restored.

What's going on is that the Administrator, and other members of the Domain Admins group passwords haven't been changed since the default domain policy was restored a number of weeks ago and when we have come to change them we have been using special characters such as @%$, etc in the new passwords. Use a simple password and it all works correctly.

This probably explains why it was working with normal users as they don't tend to have complex passwords.

The Network Manager is now going to use passphrases rather than complex passwords.

The strange thing is that the DC allows me to change the password to something using special characters in ADUC, accepts it when loggin into the DC's, but not member servers?

 

Strange. We use complex passwords with characters like those and never had a problem. Is there somewhere an older OS in play?