Link to home
Start Free TrialLog in
Avatar of jbla9028
jbla9028Flag for United States of America

asked on

the account name is invalid or does not exist, or the password is invalid for the account name specified

I am trying to figure out an issue with my computers here at my main site. I have a service account that has Domain Admin credentials. I can't set any services to start using the service until I log into the server as that account. I go to enter the service in and I get:

the account name is invalid or does not exist, or the password is invalid for the account name specified
I type in

and I KNOW the password is correct.

Any ideas what this could be? I have 4 domain controllers, 2 are local and 2 are remote.
Avatar of kloux
Flag of United States of America image

Have you logged in as this user at this site before?  Could there be an AD replication issue between your sites?

Avatar of jbla9028


I have logged in using this service on machines. If I log into the machine I can then use the account to start the service. If I do not log in though, It gives me the error.
Avatar of Fingo11

Just for claification you have to log into the server (DC) before the services will start on the local computers?  Or you need to log into the local computers with the service account before the services will start?
log into the local computer I'm trying to start the service as. I have done some research within AD all my FSMO roles are at the 2nd site but I should have access to all DCs from this computer.
Are any of the DCs Read-Only?  If they are you may have problems since the admin accounts do not get cached on them.

It almost sounds like the local SAM is looking to the local database to authenticate the user rather than contacting a DC.  Any issues logging into those computers with a brand new user that has never logged in before?
No I just tried logging into the server using another Admin account that hasn't logged into the server before without an issue. All the DCs are RW. windows 2000 domain controllers at this site. windows 2003 DCs at 2nd site.
 Have you checked your dns settings. The other issue may be with the computer object. Have you tried to remove the computer from the domain, then join it back in to reset the computer object. Or better use netdom to reset the
secure channel. Sounds like it can't find a valid dc.
wouldn't there be event log entries saying that though? I don't see anything in the event log regarding failing connectivity. I have removed/added back to the domain with no luck. I've also tried "Prestiging" the computer by manually adding the computer into an OU prior to joining it to a domain with no luck,
what's the netdom command you speak of?
Netdom is a great built in tool for domain management from the command line. Similar to netsh but for different use
Is this PC getting a DHCP address and getting the correct DNS suffix of your internal domain?
I can't see anywhere what OS you're running for the domain? 2k3, 2k8 etc?
Apologies, I now see that you're using 2000 and 2003 DCs.

Just wondering whether you're referring to a 'Service Account' as just a normal user account that you intend to use for services, or whether you meant an actual literal service account...
Firstly, have you tried using a different account than the one you're having problems with?

What I'd suggest, to try and narrow down where the problem may be:

Create a new domain account (test or whatever), RDP to this server, and edit the local policy (gpedit.msc), and go to Comp Config > Windows Settings > Security Settings > Local Policies > USer Rights Assignments and locate the setting for 'Log on as a service'.

Double click it and add the test domain account that you just created as a user to the list of users granted the right to log on as a service.

Probably worth logging off/on again (or restarting) just to be thorough, and then try configuring that test account as the account to start the service with, and see what happens?


running on a windows 2000 level domain. I have a mix of 2k and 2k3 DCs. I can not get the service to accept the username unless I actually logon to the server as that username first. It's crazy. The first time I try to start the service using the account I just logged in as. I get the message saying "domainname\useraccount has been granted access to login as a service.)

the account "type" doesn't matter. Doesn't matter if it's an administrator's user account or a "service" account. No account will login as a service until I log in as that service account first.

I tried your suggestion Pete by going to gpedit etc. I get to the logon as a service box and this is what I see (see screenshot.) Why are the SIDs showing up instead of usernames? This seems to be giving me the impression of what the actual issue is. The last accountt hat actually shows my domain name and username is my login that I logged in with and successfully was able to login as a service.

 User generated image
FYI just to be sure. I formatted and reinstalled windows 2008 R2 Enterprise on this box just to be sure it wasn't an OS configuration issue. I ran all windows updates and have statically assigned the IP address. No luck. My next try will be to move this server to the datacenter where my RID master is to see if it's a problem with the server not being able ot reach the RID master.
So I just moved this server to our Datacenter where I have all the FSMO roles at and I was able to use any account to log in as a service. Seems to be something related to the domain controllers at one of my sites. any ideas where to start looking?
Hmmm, first off, I'd look at whether all the necessary ports are open between the subnet that your server normally sits in, and the subnet that your FSMO role holder sits in... You can find a list of required AD ports here:

Test from the member server using portqry or something over the relevant ports direct to the FSMO role holder DC...

Do you have a domain controller on-site with the member server, or is the FSMO role holder your only DC? I'm not 100% on how the FSMO role holders are located when needed (it may just be a referral from one DC to another rather than a client trying to contact the role holders directly), however as it only takes a couple of seconds it may also be worth pointing your member server directly to the FSMO role holder for DNS as well, i.e. change the network adapter settings to look at the role holders IP address (assuming it's running DNS!).

Do you see any other instances (e.g. in file/folder ACLs) where sIDs are not resolving to common names for objects in AD?

When I look on the servers at folder permissions all users and group names are showing up instead of their SIDs. I am going through server by server and checking to make sure all the ports listed in the link are open between each server. I will let you know how I make out shortly.
I am noticing the following errors on my DCs

The File Replication Service is having trouble enabling replication from NAVDC4 to DC1 for c:\winnt\sysvol\domain using the DNS name FRS will keep retrying.
 Following are some of the reasons you would see this warning.
 [1] FRS can not correctly resolve the DNS name from this computer.
 [2] FRS is not running on
 [3] The topology information in the Active Directory for this replica has not yet replicated to all the Domain Controllers.

1.) the server can resolve the IP Address/Name of all domain controllers
2.) I do a netstat and I see port 138 available but I'm unable to telnet to that port? I'm assuming since it's UDP I can't.  I can't even do this locally. How can I verify that this is working right?
3.) how can I check if the topology info in AD has "fully" replicated?  
One little thing to check that often gets looked over is the time synchronization between replication partners.  If its off by more than 5 min or so there will be odd errors.(Check time zones as well)  Try clearing the dns cache on all servers and restart any relpication services on each machine.

Looking at previous posts I am wondering in your different sites you have at least one Global Catalog server.  If not you could see some of the issues you have related.

On your servers having trouble with replication try disabling NetBios over TCP on the nics and see what happens or if they are disabled enable it.  

Give those a try and report back.  Good luck!

There is a reg hack to enable a non-authoritative restore of the SYSVOL folder on a specific DC, if it's struggling to replicate with the other DCs.

You'll find the details here - Remember, you want D2 - NON-Authoritative, and you only want to do this on the DC that is having problems replicating...

Though ideally we'll do a bit more troubleshooting first, in case it's not just corruption but some other reason that this DC isn't able to replicate (in which case the restore would probably have no affect, except to remove whatever's in that DCs SYSVOL at the mo, without refilling it from the other DCs!!).

If you make a normal change on the problem DC (like, create a test user), does that user replicate round to all other DCs successfully?
I tried running the following command based on a MSTechnet Article

ERROR - Cannot RPC to computer,; 000006d9 (1753)

C:\>ntfrsutl version
NtFrsApi Version Information
   NtFrsApi Major      : 0
   NtFrsApi Minor      : 0
   NtFrsApi Compiled on: Feb 16 2007 20:01:19
ERROR - Cannot bind w/authentication to computer,; 000006ba (
ERROR - Cannot RPC to computer,; 000006d9 (1753)

I only get this 1 direction, if I use the same pair of DCs just run the command from the other site, it works. it seems like a firewall issue but I have all the ports open. I'm reading something about RPC ports being special though. I believe I have explicitly allowed the following ports all the way through the firewalls both TCP and UDP.


Is there any way that just for troubleshooting purposes you can open the firewall completely, then retest, just to prove beyond any shadow of a doubt that this is a firewall issue? It certainly looks that way, but never hurts to be sure...

Also, have a look through this technet article on AD ports. There are 2 sections, 1 about configuring firewalls for dynamic RPC, the other for static RPC (which requires additional config in actually specifying which port RPC will use)


I'm going to try to use the static port registry entry next week to see if that helps replication, I don't like how it uses random ports. Seems very insecure since you have to allow all the ports to be opened.
Ok I restricted RPC this morning to 5555 and 5556. The FRS replication is no longer giving me the error. I'm still getting the same initial error when trying to setup a service to use a domain service account. I must be missing something. Does the client machine have to talk to directly to the server with one of the FSMO roles in order to complete the request? Its definitely something with windows 7/2008 though. I just tried to make the change on a win2k3 R2 server and I was able to do it. Very quirky
In all honesty, I don't know if the client needs to contact the FSMO role holder itself, or whether it's just a referral from the nearest DC.

Is there any way you can prove simply whether this is a firewall issue at all, by opening all ports from client to DC for a couple of minutes, just to test if that makes the problem go away?

After all this, we could somehow be barking up the wrong tree entirely... It'd be nice to know whether that's the case or not!

Well.... I just opened up all the ip traffic to and from the FSMO role holder and I'm still having the issue. i'm confirming with Cisco that I didn't mess anything up but it looks like it's not a network issue.
Avatar of PeteJThomas
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
wow you got it! haha. that posting had a hotfix at the end. I just ran it on my windows 7 machine and it appears it's working. The workstation allowed me to use a AD username to start the service. What a crazy problem. Thanks for your hard work and sorry it took so long to get this working
Phew, I was starting to think we may never get to the bottom of that one! We hadn't talked about Win 7 before, hence I didn't think the fix would apply!

For anyone who looks at this in the future, just in case the above link breaks, here is the post that contains it:

Posted by 'Joson Zhou'

Hi all,

The fix for this issue has been released. Please check the KB article below:

Error 1789 when you use the LookupAccountName function on a computer that is running Windows 7 or Windows Server 2008 R2


As always, glad we could be of help! :)