Sqlserver
 sql >> Base de données >  >> RDS >> Sqlserver

Connexions SQL Server entre domaines à l'aide de l'authentification Windows

Comme mentionné dans ma mise à jour de la question, changer le compte de service pour qu'il soit dans Domain2 résolu le problème. Alors que se passait-il ?

Le problème - Expliqué

D'après ce que je peux dire (également avec l'aide d'un représentant Microsoft), car le compte de service était à l'origine un Domain1 utilisateur, il n'a pas pu déterminer à quels groupes locaux de domaine l'utilisateur qui se connecte est membre lorsque l'utilisateur s'authentifie via Kerberos. La principale piste indiquant qu'il s'agissait d'un problème Kerberos était lorsque je me suis connecté avec succès à l'aide de "Named Pipes" car cela utilise l'authentification NTLM.

Solution globale

Pour tout rassembler, ajouter avec succès des utilisateurs de Domain1 et Domain3 en tant que membres de groupes dans Domain2 afin que les groupes puissent être utilisés comme connexions SQL Server avec authentification Windows, voici une liste d'exigences (ou du moins fortement encouragées) :

  1. Relations de confiance établies entre les domaines
    1. Au minimum, des approbations unidirectionnelles doivent être configurées afin que Domain2 fait confiance au Domain1 et Domain3
  2. Groupes dans Domain2 doit être étendu "Domaine Local"
    1. Cela vous permet d'ajouter des utilisateurs et des groupes à partir de Domain1 et Domain3
    2. Voir ici pour plus d'informations
  3. Utilisez SQL Server Configuration Manager pour désigner un Domain2 non administratif utilisateur en tant qu'identité du compte de service
    1. MSDN explique pourquoi l'utilisation d'un compte d'utilisateur de domaine peut être préférable
    2. Même si le gestionnaire de configuration est censé ajouter des utilisateurs à des groupes locaux spécifiques à SQL Server 2005 pour vous (c'est-à-dire SQLServer2005MSSQLUser$MY_MACHINE$MY_INSTANCE), j'ai rencontré quelques cas où ce n'était pas le cas. Il vous suffit donc de vérifier vos groupes locaux pour vous assurer qu'ils ont été correctement mis à jour avec votre Domain2 compte utilisateur.
    3. Bien que la configuration de SQL Server doive automatiquement attribuer les autorisations appropriées pour leurs groupes locaux, encore une fois, j'ai rencontré quelques cas où ce n'était pas le cas. Si cela vous arrive, vous pouvez référencer cet article MSDN avec l'article mentionné précédemment pour les exigences d'autorisation.
  4. Configurer un nom principal de service (SPN) pour l'hôte de l'instance SQL Server (y compris les alias) et le Domain2 compte de service
    1. Le SPN est requis pour l'authentification mutuelle entre le client et l'hôte du serveur
    2. Consultez cet article TechNet pour plus d'informations
  5. Selon la façon dont vous avez l'intention d'utiliser l'emprunt d'identité, vous pouvez activer le Domain2 compte de service à approuver pour la délégation
    1. Consultez cet article TechNet pour plus d'informations
  6. Activer les connexions à distance pour l'instance SQL Service
  7. Enfin, créez des identifiants pour le Domain2 souhaité groupes et tout Domain1 ou Domain3 les membres doivent pouvoir se connecter à distance !

Remarque

Comme toujours pour toute activité réseau à distance, vérifiez vos pare-feu pour vous assurer que vos ports SQL Server ne sont pas bloqués. Bien que le port par défaut soit 1433, vérifiez que votre port est en clair.