Accessi tra domini SQL Server utilizzando l'autenticazione di Windows

Come menzionato nell'aggiornamento della mia domanda, la modifica dell'account del servizio in Domain2 risolto il problema. Allora cosa stava succedendo?

Il problema - Spiegazione

Da quello che posso dire (anche con l'aiuto di un rappresentante Microsoft), perché l'account di servizio era originariamente un Domain1 utente, non è stato possibile determinare a quali gruppi locali di dominio è membro l'utente che si connette quando l'utente esegue l'autenticazione tramite Kerberos. Il motivo principale che si trattava di un problema di Kerberos è stato quando mi sono connesso correttamente utilizzando "Named Pipes" poiché utilizza l'autenticazione NTLM.

Soluzione generale

Per riunire tutto, aggiungere correttamente utenti da Domain1 e Domain3 come membri di gruppi in Domain2 in modo che i gruppi possano essere utilizzati come accessi a SQL Server con l'autenticazione di Windows, ecco un elenco di requisiti (o almeno fortemente incoraggiati):

1. Relazioni di fiducia stabilite tra i domini
   1. Come minimo, i trust a una via devono essere impostati in modo che Domain2 si fida di Domain1 e Domain3
2. Gruppi in Domain2 deve avere l'ambito "Dominio locale"
   1. In questo modo puoi aggiungere utenti e gruppi da Domain1 e Domain3
   2. Vedi qui per maggiori informazioni
3. Utilizzare Gestione configurazione SQL Server per designare un Domain2 non amministrativo utente come identità dell'account di servizio
   1. MSDN documenta il motivo per cui potrebbe essere preferibile utilizzare un account utente di dominio
   2. Anche se il gestore di configurazione dovrebbe aggiungere utenti a gruppi specifici di SQL Server 2005 locali per te (ad esempio SQLServer2005MSSQLUser$MY_MACHINE$MY_INSTANCE), mi sono imbattuto in alcuni casi in cui non era il caso. Quindi controlla i tuoi gruppi locali per assicurarti che siano stati aggiornati in modo appropriato con il tuo Domain2 account utente.
   3. Anche se la configurazione di SQL Server dovrebbe assegnare automaticamente le autorizzazioni appropriate per i loro gruppi locali, mi sono imbattuto in alcuni casi in cui non era così. In questo caso, puoi fare riferimento a questo articolo MSDN insieme all'articolo menzionato in precedenza per i requisiti di autorizzazione.
4. Configura un nome dell'entità servizio (SPN) per l'host dell'istanza di SQL Server (inclusi eventuali alias) e il Domain2 conto di servizio
   1. L'SPN è richiesto per l'autenticazione reciproca tra il client e l'host del server
   2. Vedi questo articolo di TechNet per maggiori informazioni
5. A seconda di come intendi utilizzare la rappresentazione, potresti voler abilitare il Domain2 account di servizio da considerare attendibile per la delega
   1. Vedi questo articolo di TechNet per maggiori informazioni
6. Abilita connessioni remote per l'istanza di SQL Service
7. Infine, crea gli accessi per il Domain2 desiderato gruppi e qualsiasi Domain1 o Domain3 i membri dovrebbero essere in grado di connettersi da remoto!

Nota

Come sempre con qualsiasi attività di rete remota, controlla i firewall per assicurarti che le porte di SQL Server non siano bloccate. Sebbene la porta predefinita sia 1433, assicurati che la tua porta sia in chiaro.