Agent SQL Server - Message de domaine non approuvé

Question

Exécution de SQL Server 2016. Vous disposez actuellement d'une solution hébergée dans un domaine et, bien sûr, notre point d'accès se trouve dans une autre. nous devons extraire les données de manière automatisée.

Nous avons ajouté des informations d'identification Windows avec le gestionnaire des informations d'identification qui collecte les informations de point de terminaison et un ensemble d'informations d'identification.

par exemple.

• Internet ou NETWORKADDRESS: mydatabase.remotedomain.com
• Nom d'utilisateur: remotedomain \ Nom d'utilisateur Mot de passe
• : Mot de passe

Cette solution fonctionne avec de nombreux outils, Excel, SSMS requête directe, Visual Studio . L'utilisateur entre le point de terminaison (URL du serveur ou IP/port) et utilise la sécurité intégrée de Windows. la connexion est établie et le magasin d'informations d'identification fait l'affaire et l'utilisateur est authentifié.

SSMS exemple

• Nom du serveur: mydatabase.remotedomain.com
• Authentification: l'authentification Windows

Mon défi est SSIS et Agent SQL. Le package SSIS s'exécute dans VS2015. déployer le package dans le catalogue Integration Services - mettre le package en surbrillance, l'exécuter et l'exécuter.

Créer un Agent SQL Server et d'exécuter le travail et je reçois ce cadeau .....

Connexion Échec: La connexion est d'un domaine non sécurisé et ne peut pas être utilisé avec l'authentification Windows

J'ai créé un droit d'accès SQL, créé un proxy (exécution de package SSIS), créé un travail qui utilise l'exécution en tant que la référence mais qui se termine par le même résultat. Les informations d'identification doivent être dans mon domaine local ou le travail ne sera pas exécuté .... et bien sûr localdomain \ nom d'utilisateur ne s'authentifie pas sur la connexion de données à distance. Donc, Proxy n'aide pas la situation.

Ce que je me attendais est que le gestionnaire de fenêtres de lettres de créance échangerait les informations d'identification comme lorsque le travail est exécuté manuellement ou par Excel ou plusieurs d'autres moyens ...

Answer 1

Votre compte d'informations d'identification de la fenêtre doit être un compte d'utilisateur AD qui est dans un groupe avec une portée soit globale ou universelle. Les groupes universels sont utiles lorsque vous avez plusieurs domaines.

Le processus s'exécutera dans le contexte dans lequel il est appelé (c'est-à-dire par vous, l'agent SQL ou le compte proxy). Il ne change pas le contexte exécutable car il appelle différents processus, sauf si vous le faites de façon pragmatique, et c'est une mauvaise idée de toute façon ...

A eu un problème similaire et c'était un cauchemar à résoudre! Appris beaucoup de trucs de configuration AD amusants en cours de route.

Understanding User and Group Accounts déclare ce qui suit:

Les groupes peuvent avoir différents champs d'application domaine local, intégré local, global et universel. Autrement dit, les groupes ont différents domaines dans lesquels ils sont valides.

groupes mondiaux:

groupes qui sont utilisés pour accorder des autorisations à des objets dans un domaine dans l'arborescence de domaine ou de la forêt. Les membres de groupes globaux peuvent uniquement inclure des comptes et des groupes du domaine dans lequel ils sont définis.

groupes universels:

groupes qui sont utilisés pour accorder des autorisations sur une large échelle dans un arbre de domaine ou de la forêt. Les membres de groupes globaux incluent des comptes et des groupes de n'importe quel domaine de l'arborescence de domaine ou de la forêt.

EDIT

Si c'est juste une traction de données d'un domaine à l'autre, les données peuvent être d'abord exporté vers un csv dans le domaine non approuvé et SFTP'd dans votre environnement où la TL (Transformer et Load) du processus ETL (Extract-Transform-Load) pourrait avoir lieu? SSIS serait un bon outil pour cela, mais C# et Powershell pourraient également être utilisés.

Answer 2

Désolé, le changement de groupe pour Global ou Universel pour le compte AD local n'a aucun effet. Je suis un peu perdu sur comment faire une modification sur le compte local en cours d'utilisation pour SQL Agent fera toute différence. La solution fonctionne dans tous les outils par substitution de compte local avec la configuration de compte à distance dans Credential Manager. Si je l'ai manqué, et que cette modification devrait fonctionner, veuillez fournir un exemple de configuration si possible.

Encore une fois, il apparaît que ce processus n'est pas exécuté/suivi par l'Agent SQL Server car il fonctionne partout ailleurs mais pas dans un travail exécuté par l'Agent.

alors encore une fois mon espoir est que quelqu'un a déjà vu quelque chose comme ça et a une solution.

Mon objectif final est de simplement automatiser l'extraction de données à partir d'un serveur SQL distant sans confiance. J'espérais que la solution proxy fonctionnerait, mais lorsque vous définissez les informations d'identification sur le domaine distant \ nom d'utilisateur, le travail ne sera même pas exécuté.

Existe-t-il un moyen de configurer ma connexion dans le package SSIS pour définir explicitement les informations d'identification sur le domaine distant \ nom_utilisateur \ pwd. J'ai pris un coup à ça et je ne pouvais pas avoir ça pour voler non plus. si c'est le cas, un exemple est inestimable pour moi.

Je ne me inquiète comment je reçois à la ligne de but, il faut juste ... merci à tous pour l'aide

Answer 3

J'ai ouvert un ticket avec Microsoft et a travaillé avec l'un de leurs ressources supérieurs à ce sujet.

cela semble être un bogue dans SQL Agent. Il n'existe aucune raison ou problème connu qui empêche l'Agent SQL de récupérer les informations d'identification distantes dans le Windows Credential Store, mais ce n'est pas le cas.

Une alternative de travail consistait à utiliser l'utilitaire de ligne de commande DTEXEC. une légère modification du projet SSIS pour s'assurer que tous les gestionnaires de connexions se trouvent au niveau du package au lieu du projet (création d'un problème de référence).

cette solution n'est pas idéale, mais cela a fonctionné et DTEXEC a permis à SSIS de récupérer les informations d'identification requises dans le magasin et de les exécuter sans problème.

Je ferai un suivi une fois que Microsoft aura terminé ses recherches et reviendra vers moi, le ticket est toujours ouvert.