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.

  • All 3 AD servers are configured as DNS servers in DHCP. There are also _kerberos and _ldap records under _msdcs.example.com\dc_tcp. The SQL Connection string is "ODBC;DRIVER=SQL Server;SERVER=example-server;DATABASE=DB_Live;Trusted_Connection=Yes;". I wonder if there is some limitation to the "SQL Server" ODBC driver and we should be using a Native SQL Client driver instead? Jul 6 '12 at 7:20
  • @MattyBrown That really shouldn't matter, but to eliminate that as a problem you could easily open a connection to SQL with the standard OLE provider and see if that helps, via DSN. Jul 6 '12 at 12:21
  • Also, make sure you're SQL box has the proper DNS settings as well for all three DCs. Jul 6 '12 at 12:21
  • Our SQL box has the correct DNS server settings. I've coded our application so that if the SQL Server Native Client is available, that's used instead of the SQL Server driver. I suppose I won't be able to see if this has corrected the problem without shutting down or disconnecting one of our AD servers. Jul 6 '12 at 14:54
  • @MattyBrown It's never easy to test AD problems ;) Jul 6 '12 at 15:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.