Влизания в SQL сървър между домейни с помощта на удостоверяване на Windows

Както беше споменато в моята актуализация на въпроса, промяна на акаунта на услугата да бъде в Domain2 реши проблема. И така, какво се случваше?

Проблемът – обяснено

Доколкото мога да кажа (също с помощта на представител на Microsoft), тъй като акаунтът на услугата първоначално беше Domain1 потребител, не може да определи в кои локални групи на домейна членува свързващият се потребител, когато потребителят се удостоверява чрез Kerberos. Основната причина, че това е проблем с Kerberos, беше, когато успешно се свързах с помощта на „Named Pipes“, тъй като това използва NTLM удостоверяване.

Цялостно решение

За да обедините всичко, за да добавите успешно потребители от Domain1 и Domain3 като членове на групи в Domain2 за да могат групите да се използват като данни за вход в SQL Server с удостоверяване на Windows, ето списък с изисквания (или поне силно се препоръчва):

1. Установени отношения на доверие между домейните
   1. Най-малко трябва да се настроят еднопосочни тръстове, така че Domain2 се доверява на Domain1 и Domain3
2. Групи в Domain2 трябва да бъде с обхват "Domain Local"
   1. Това е за да можете да добавяте потребители и групи от Domain1 и Domain3
   2. Вижте тук за повече информация
3. Използвайте SQL Server Configuration Manager, за да посочите неадминистративен Domain2 потребител като самоличност на акаунта за услуга
   1. MSDN документира защо използването на потребителски акаунт на домейн може да бъде предпочитано
   2. Въпреки че мениджърът на конфигурацията трябва да добавя потребители към локални SQL Server 2005 специфични групи вместо вас (т.е. SQLServer2005MSSQLUser$MY_MACHINE$MY_INSTANCE), попаднах на няколко случая, в които това не беше така. Затова просто проверете местните си групи, за да се уверите, че са актуализирани по подходящ начин с вашия Domain2 потребителски акаунт.
   3. Въпреки че настройката на SQL Server трябва автоматично да присвоява подходящи разрешения за техните локални групи, отново се натъкнах на няколко случая, когато това не беше така. Ако това се случи с вас, можете да направите справка с тази статия в MSDN заедно със споменатата по-рано статия за изискванията за разрешение.
4. Конфигурирайте име на принципала на услугата (SPN) за хоста на екземпляра на SQL Server (включително всички псевдоними) и Domain2 сервизен акаунт
   1. SPN е необходим за взаимно удостоверяване между клиента и хоста на сървъра
   2. Вижте тази статия в TechNet за повече информация
5. В зависимост от това как възнамерявате да използвате представянето под чужда самоличност, може да искате да активирате Domain2 сервизен акаунт, който да бъде доверен за делегиране
   1. Вижте тази статия в TechNet за повече информация
6. Активиране на отдалечени връзки за екземпляра на SQL услуга
7. Накрая създайте данни за вход за желания Domain2 групи и всеки Domain1 или Domain3 членовете трябва да могат да се свързват дистанционно!

Забележка

Както винаги при всяка отдалечена мрежова дейност, проверете защитните си стени, за да се уверите, че портовете на SQL Server не са блокирани. Въпреки че портът по подразбиране е 1433, проверете дали портът ви е чист.