How come Windows server cannot change Log On Account of service in Active Directory Domain?
I have a Hybrid Domain with two AD servers managing all windows workstations and servers and a Linux Domain managing linux servers.
The AD servers are Windows Server 2008. The servers are a mix of 2003 and 2008.
I am trying to change a service to start as a specified domain account instead of Local System Account. When I make the change I get an error saying "The specified Domain Either does not exist or could not be contated"
The domain is up and available. I can login ot the system with Domain accounts, I can map and access Domain File Servers, I can browse Domain members .. but I cannot change service account.
The DNS I am using is not the AD it is bind9 .. is this part of the problem? I can't really see why. The servers can see each other.
I have disabled the firewall and AV and still no luck. This behavior can be seen on multiple member servers.
I ran these commands
dcdiag /v /c /d /e /s:dcname >c:\dcdiag.txt
repadmin /showrepl dc* /verbose /all /intersite >c:\repl.txt
and saw no errors (other than smart card certificates which we are not using)
Any help would be greatly appreciated.
Thanks
The AD servers are Windows Server 2008. The servers are a mix of 2003 and 2008.
I am trying to change a service to start as a specified domain account instead of Local System Account. When I make the change I get an error saying "The specified Domain Either does not exist or could not be contated"
The domain is up and available. I can login ot the system with Domain accounts, I can map and access Domain File Servers, I can browse Domain members .. but I cannot change service account.
The DNS I am using is not the AD it is bind9 .. is this part of the problem? I can't really see why. The servers can see each other.
I have disabled the firewall and AV and still no luck. This behavior can be seen on multiple member servers.
I ran these commands
dcdiag /v /c /d /e /s:dcname >c:\dcdiag.txt
repadmin /showrepl dc* /verbose /all /intersite >c:\repl.txt
and saw no errors (other than smart card certificates which we are not using)
Any help would be greatly appreciated.
Thanks
netjgrnaut
Is the BIND9 server acting as a secondary to one of the DNS-enabled DCs? There should be a _msdtc subzone where the service location records exist. These are required for AD operations.
ASKER
These are the AD records I have ( I see no mention of msdtc in the link you referenced.
; SRV RECORDS FOR ACTIVE DIRECTORY DOMAIN CONTROLLER
_ldap._tcp.mydomain.com. SRV 0 0 389 dc
_kerberos._tcp.mydomain.co
_ldap._tcp.dc._msdcs.mydom
_kerberos._tcp.dc._msdcs.m
; SRV RECORDS FOR ACTIVE DIRECTORY DOMAIN CONTROLLER
_ldap._tcp.mydomain.com. SRV 0 0 389 dc
_kerberos._tcp.mydomain.co
_ldap._tcp.dc._msdcs.mydom
_kerberos._tcp.dc._msdcs.m
Sorry - I mean "_msdcs" subzone...
You are running DNS on the DCs, right (that's the default setup for an AD DC)? Even though that's not where you're pointing your clients?
Am I correct in assuming that the service you're editing is on one of the Windows AD member servers (not one of the DCs)?
You could test this idea that DNS is the problem (I suspect it is) by configuring one of the member servers to use the DC for DNS, restarting, and trying to reconfigure the service account as previously attempted.
If it works, then you've got incomplete DNS records in your BIND9 zone - insufficient to fully support your AD member servers.
If it still doesn't work, then you can at least rule out the BIND9 zone as the source of the problem.
_msdcs DNS subdomain
The Microsoft-specific subdomain enables location of domain controllers that have specific roles in the Active Directory domain or forest. Resource records for the DNS root domain of a new Active Directory forest are stored in a _msdcs zone instead of a subdomain, and that zone is stored in the forest-wide application directory partition.
You are running DNS on the DCs, right (that's the default setup for an AD DC)? Even though that's not where you're pointing your clients?
Am I correct in assuming that the service you're editing is on one of the Windows AD member servers (not one of the DCs)?
You could test this idea that DNS is the problem (I suspect it is) by configuring one of the member servers to use the DC for DNS, restarting, and trying to reconfigure the service account as previously attempted.
If it works, then you've got incomplete DNS records in your BIND9 zone - insufficient to fully support your AD member servers.
If it still doesn't work, then you can at least rule out the BIND9 zone as the source of the problem.
...also, if you look at the document I linked to, you will see many more SRV records than what you have indicated.
ASKER
Sorry but that doc link is a bit confusing to me. It doesn't have all the information on it that I need. For example which ports?
Yes You are correct in assuming that I am running DNS on the DCs but pointing clients to another (BIND 9 server)
Correct The service I am editing is on one of the Windows AD member servers
If I change to AD for DNS the problem does indeed go away .
Could you assist in the syntax of the lines I may need to add? Would this be correct? I have no sub domains or sites so would this be sufficient?
_ldap._tcp.mydomain.com. SRV 0 0 389 dc
_kerberos._tcp.mydomain.co
_ldap._tcp.dc._msdcs.mydom
_kerberos._tcp.dc._msdcs.m
NEW LINES
_ldap._tcp.pdc.mydomain.co
_ldap._tcp.gc._msdcs.mydom
_ldap._tcp.pdc._msdcs.mydo
_gc._tcp.mydomain.com. SRV 0 0 3268 dc
Yes You are correct in assuming that I am running DNS on the DCs but pointing clients to another (BIND 9 server)
Correct The service I am editing is on one of the Windows AD member servers
If I change to AD for DNS the problem does indeed go away .
Could you assist in the syntax of the lines I may need to add? Would this be correct? I have no sub domains or sites so would this be sufficient?
_ldap._tcp.mydomain.com. SRV 0 0 389 dc
_kerberos._tcp.mydomain.co
_ldap._tcp.dc._msdcs.mydom
_kerberos._tcp.dc._msdcs.m
NEW LINES
_ldap._tcp.pdc.mydomain.co
_ldap._tcp.gc._msdcs.mydom
_ldap._tcp.pdc._msdcs.mydo
_gc._tcp.mydomain.com. SRV 0 0 3268 dc
Why not just delegate the sub zones back to one of the DCs? This approach will bring you all the records and keep them in sync going forward. You'll get more functionality out of AD that way.
ASKER
Your losing me... What subzone do I have in my main DNS Zone?
Sorry... let me back up a step.
You have a single zone of "mydomain.com" which is being hosted both on AD-enabled DNS DCs *and* on BIND9 Unix hosts. Correct?
For some reason, you've chosen to do the domain administration on BIND9, and point all of your clients there for resolution. Correct?
There are host records that exist in the BIND9 version of the mydomain.com zone that *do not* exist in the AD DNS version. Correct?
Personally, I think the best answer would be to add all of your BIND9-only records to the AD DNS, then reconfigure your BIND9 servers as secondaries to the AD DNS. This would assure that all only one mydomain.com zone exists across your environment. But then you'd have to do your DNS admin going forward on the Windows AD servers. I'm guessing that you don't want to do this (or you wouldn't be trying to run your Windows AD clients against a manually-configured BIND9 DNS server in the first place), right?
The second best answer would be to delegate the AD-specific subzones back to the AD DNS servers. So... if you look at your AD DNS servers, you will see that the AD-specific SRV records are actually held in sub zones under mydomain.com.
Rather than add individual SRV records to the BIND9 zone, you could delegate the four "_" zones back to the AD DNS servers. Generally, you shouldn't need to administer these zones by hand (provided you have secure dynamic updating configured).
A quick overview on how to set up subzone delegation on BIND can be found here...
http://www.zytrax.com/book
If I've made any incorrect assumptions above, please let me know...
You have a single zone of "mydomain.com" which is being hosted both on AD-enabled DNS DCs *and* on BIND9 Unix hosts. Correct?
For some reason, you've chosen to do the domain administration on BIND9, and point all of your clients there for resolution. Correct?
There are host records that exist in the BIND9 version of the mydomain.com zone that *do not* exist in the AD DNS version. Correct?
Personally, I think the best answer would be to add all of your BIND9-only records to the AD DNS, then reconfigure your BIND9 servers as secondaries to the AD DNS. This would assure that all only one mydomain.com zone exists across your environment. But then you'd have to do your DNS admin going forward on the Windows AD servers. I'm guessing that you don't want to do this (or you wouldn't be trying to run your Windows AD clients against a manually-configured BIND9 DNS server in the first place), right?
The second best answer would be to delegate the AD-specific subzones back to the AD DNS servers. So... if you look at your AD DNS servers, you will see that the AD-specific SRV records are actually held in sub zones under mydomain.com.
Rather than add individual SRV records to the BIND9 zone, you could delegate the four "_" zones back to the AD DNS servers. Generally, you shouldn't need to administer these zones by hand (provided you have secure dynamic updating configured).
A quick overview on how to set up subzone delegation on BIND can be found here...
http://www.zytrax.com/book
If I've made any incorrect assumptions above, please let me know...
ASKER
You are correct in your assumptions. The major factor in not using AD DNS is simply that I support both internal and external zone transfer and do not know enough about AD DNS to set this up efficiently
Basically the internal zone resolves to internal IPs and the external zone resolves to public IPs.
Basically the internal zone resolves to internal IPs and the external zone resolves to public IPs.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for helping me work through this issue. I am going to try to finish conversion to AD based DNS server for all internal zones. I will keep BIND running for external requests.
Good choice, IMHO - you'll be happier in the long run. :)