Přihlášení k SQL serveru napříč doménami pomocí ověřování systému Windows

Jak je uvedeno v aktualizaci mé otázky, změna účtu služby tak, aby byl v Domain2 problém vyřešil. Co se tedy dělo?

Problém – vysvětlení

Z toho, co mohu říci (také s pomocí zástupce společnosti Microsoft), protože účet služby byl původně Domain1 Pokud se uživatel autentizuje prostřednictvím protokolu Kerberos, nemohl určit, které lokální skupiny domény je připojující se uživatel členem. Hlavním důvodem, že se jednalo o problém Kerberos, bylo, když jsem se úspěšně připojil pomocí „Named Pipes“, protože to používá ověřování NTLM.

Celkové řešení

Chcete-li to všechno spojit, úspěšně přidat uživatele z Domain1 a Domain3 jako členové skupin v Domain2 aby skupiny mohly být použity jako přihlášení k SQL Serveru s ověřováním Windows, zde je seznam požadavků (nebo alespoň důrazně doporučených):

1. Mezi doménami byly vytvořeny vztahy důvěryhodnosti
   1. Minimálně 1 cesta důvěryhodnosti musí být nastaveny tak, aby Domain2 důvěřuje Domain1 a Domain3
2. Skupiny v Domain2 musí mít rozsah "místní doména"
   1. To proto, abyste mohli přidávat uživatele a skupiny z Domain1 a Domain3
   2. Další informace naleznete zde
3. Pomocí SQL Server Configuration Manager označte Domain2, která není správcem uživatele jako identitu účtu služby
   1. Dokumenty MSDN, proč může být preferováno používání uživatelského účtu domény
   2. Přestože správce konfigurace má za vás přidávat uživatele do místních specifických skupin SQL Server 2005 (tj. SQLServer2005MSSQLUser$MY_MACHINE$MY_INSTANCE), narazil jsem na několik případů, kdy tomu tak nebylo. Zkontrolujte tedy své místní skupiny, abyste se ujistili, že byly náležitě aktualizovány pomocí vaší Domain2 uživatelský účet.
   3. Přestože nastavení SQL Serveru by mělo automaticky přidělovat příslušná oprávnění jejich místním skupinám, opět jsem narazil na několik případů, kdy tomu tak nebylo. Pokud se vám to stane, můžete se podívat na tento článek MSDN spolu s dříve zmíněným článkem ohledně požadavků na oprávnění.
4. Nakonfigurujte hlavní název služby (SPN) pro hostitele instance SQL Server (včetně všech aliasů) a Domain2 servisní účet
   1. SPN je vyžadováno pro vzájemné ověření mezi klientem a hostitelem serveru
   2. Další informace naleznete v tomto článku TechNet
5. V závislosti na tom, jak chcete předstírání jiné identity používat, můžete povolit Domain2 účet služby, který má být důvěryhodný pro delegování
   1. Další informace naleznete v tomto článku TechNet
6. Povolte vzdálená připojení pro instanci služby SQL
7. Nakonec vytvořte přihlašovací údaje pro požadovanou Domain2 skupiny a všechny Domain1 nebo Domain3 členové by měli mít možnost se vzdáleně připojit!

Poznámka

Jako vždy u jakékoli vzdálené síťové aktivity zkontrolujte brány firewall, abyste se ujistili, že porty SQL Serveru nejsou blokovány. Ačkoli výchozí port je 1433, zkontrolujte, zda je váš port v čistém stavu.