Today, we shut down one of our Active Directory servers during office hours to check the loading on a UPS. Since all the server did was provide Active Directory in a separate building incase the main building caught fire, or whatever, we didn't think it would have any effect on our users.
Seconds after the server was shut down, we had a dozen phone calls from users experiencing this issue:- [Microsoft SQL Server Login] SQLState: '28000' [Microsoft][ODBC SQL Server Driver][SQL Server]Login failed. The login is from an untrusted domain and cannot be used with authentication.
Once we realized what had happened, we quickly rebooted the down Active Directory server. Problem solved.
But why did this happen. And what if one day a server has a breakdown and is offline for hours, or days? Shouldn't the other Active Directory servers in the domain service authentication requests without disruption to users?
We have 3 Windows Server 2003 Standard servers running Active Directory as Domain Controllers with Global Catalogs, all physically located on the same network at Gigabit speeds.
I believe the domain was originally Windows Server 2000, or maybe even NT 4.0. Could the issue be to down to old Group Policies inherited from these old server OS's, or some default setting in Active Directory that needs changing?
It sounds like you may not have your DNS configured properly. You have to make sure that the clients can issue DNS requests to the other DCs. In other words your client DHCP settings should provide the DNS records for all of your DCs (if they run the DNS service). Either way you also need to make sure that all of your DCs are registered in DNS as well.
Clients should automatically fail over for authentication but if your application caches credentials for some reason it may have tried to only go back to the original DC for authentication.