Wielodomenowe logowanie do serwera SQL przy użyciu uwierzytelniania systemu Windows

Jak wspomniałem w aktualizacji mojego pytania, zmiana konta usługi na Domain2 rozwiązał problem. Więc co się dzieje?

Problem – wyjaśniony

Z tego co mogę powiedzieć (również z pomocą przedstawiciela Microsoft), ponieważ konto usługi było pierwotnie Domain1 użytkownika, nie można było określić, do jakich grup lokalnych domeny należy łączący się użytkownik, gdy użytkownik uwierzytelnia się za pomocą protokołu Kerberos. Głównym tropem, że był to problem Kerberos, był fakt, że udało mi się połączyć za pomocą „Potoków nazwanych”, ponieważ używa to uwierzytelniania NTLM.

Ogólne rozwiązanie

Aby zebrać to wszystko razem, pomyślnie dodać użytkowników z Domain1 i Domain3 jako członkowie grup w Domain2 aby grupy mogły być używane jako loginy SQL Server z uwierzytelnianiem Windows, oto lista wymagań (lub przynajmniej zdecydowanie zalecanych):

1. Ustalone relacje zaufania między domenami
   1. Należy skonfigurować co najmniej jednokierunkowe zaufanie, aby Domain2 ufa Domain1 i Domain3
2. Grupy w Domain2 musi mieć zakres „Domena lokalna”
   1. Dzięki temu możesz dodawać użytkowników i grupy z Domain1 i Domain3
   2. Zobacz tutaj, aby uzyskać więcej informacji
3. Użyj programu SQL Server Configuration Manager, aby wyznaczyć nieadministracyjną Domain2 użytkownik jako tożsamość konta usługi
   1. Dokumenty MSDN, dlaczego korzystanie z konta użytkownika domeny może być preferowane
   2. Mimo że menedżer konfiguracji powinien dodawać użytkowników do lokalnych grup SQL Server 2005 za Ciebie (np. SQLServer2005MSSQLUser$MY_MACHINE$MY_INSTANCE), natknąłem się na kilka przypadków, w których tak nie było. Więc po prostu sprawdź swoje lokalne grupy, aby upewnić się, że zostały odpowiednio zaktualizowane za pomocą Twojej Domain2 konto użytkownika.
   3. Chociaż konfiguracja SQL Server powinna automatycznie przypisywać odpowiednie uprawnienia do ich grup lokalnych, ponownie natknąłem się na kilka przypadków, w których tak nie było. Jeśli tak się stanie, możesz odwołać się do tego artykułu MSDN wraz z wcześniej wspomnianym artykułem, aby uzyskać informacje o wymaganiach dotyczących uprawnień.
4. Skonfiguruj główną nazwę usługi (SPN) dla hosta wystąpienia programu SQL Server (w tym wszelkie aliasy) i Domain2 konto usługi
   1. Stan SPN jest wymagany do wzajemnego uwierzytelnienia między klientem a hostem serwera
   2. Zobacz ten artykuł w TechNet, aby uzyskać więcej informacji
5. W zależności od tego, jak zamierzasz używać personifikacji, możesz włączyć Domain2 konto usługi, które ma być zaufane do delegowania
   1. Zobacz ten artykuł w TechNet, aby uzyskać więcej informacji
6. Włącz połączenia zdalne dla instancji usługi SQL
7. Na koniec utwórz loginy dla wybranej Domain2 grupy i dowolna Domain1 lub Domain3 członkowie powinni mieć możliwość łączenia się zdalnie!

Uwaga

Jak zawsze w przypadku każdej zdalnej aktywności sieciowej, sprawdź zapory sieciowe, aby upewnić się, że porty SQL Server nie są blokowane. Chociaż domyślnym portem jest 1433, upewnij się, że twój port jest czysty.