2 votes

Comment configurer les comptes utilisateurs Windows pour le réseau ODBC avec authentification NT ?

J'essaie de créer une connexion à une base de données SQL Server à partir de l'administrateur de sources de données ODBC en utilisant "l'authentification Windows NT à l'aide de l'ID de connexion réseau". Le serveur et le client fonctionnent tous deux sous Windows XP.

Il semble que tout compte disposant de privilèges d'administrateur puisse ajouter la source de données sur le serveur*, bien que les tentatives de connexion depuis le client donnent lieu à des messages d'erreur qui suggèrent qu'il tente de s'authentifier à l'aide d'un compte invité.

J'ai trouvé une page d'assistance Microsoft qui dit :

Pour SQL Server... : connectez-vous en utilisant le compte utilisateur usurpé.

Mais il ne donne pas de conseils sur comment pour le faire.

Comment puis-je usurper l'identité d'un compte utilisateur sur le serveur ?

ou (puisque cela semble conduire à un écrasement malheureux des privilèges et à une perte de responsabilité) :

Comment donner à un compte sur le client des privilèges sur la base de données du serveur et ensuite s'assurer que le client tente l'authentification avec le compte privilégié et non avec un compte invité ?


Je suis conscient que je fournis des informations plutôt éparses. C'est parce que je suis en territoire inconnu et que je ne sais pas ce qui est pertinent. J'essaierai d'ajouter toute information demandée aussi rapidement que possible.


*J'ai l'intention de resserrer les privilèges dès que j'aurai réussi à les faire fonctionner tels quels.

2voto

Evan Anderson Points 140581

Il semble que vous tireriez profit d'une documentation décrivant les "bases" du système de sécurité de Microsoft SQL Server.

Je jetterais un coup d'œil à ces documents relatifs à directeurs d'école , permissions y securables pour vous faire une idée de la manière dont vous pouvez appliquer les autorisations d'accès aux objets aux utilisateurs/groupes de manière granulaire dans SQL Server.

Ces documents sont un peu abstraits, mais ce sont les détails de base.

En s'éloignant de Microsoft, il y a un très belle "feuille de route". que Robyn Page écrit qui donne un bon aperçu du modèle de sécurité.

Pour une vue à 10 000 pieds, ce que vous cherchez à faire est de créer des groupes Active Directory (dont vous ferez des utilisateurs membres) auxquels vous accorderez diverses permissions sur les ressources ("sécurisables") hébergées par l'ordinateur SQL Server. Les autorisations et sécurités spécifiques dont vous aurez à vous occuper dépendent de votre application spécifique. Si certains utilisateurs ont besoin d'un accès UPDATE à certaines tables, ou de la possibilité d'exécuter certaines procédures stockées, vous utiliserez SQL Management Studio (ou, ugh, Enterprise Manager, si vous êtes sur SQL Server 2000 ou plus ancien) pour accorder les permissions souhaitées.

0voto

Rob Howard Points 636

Le serveur SQL et la station de travail Xp se trouvent-ils dans le même domaine ? S'il s'agit d'une station de travail Xp qui se connecte directement à SQL, elle devrait utiliser les informations d'identification spécifiées (d'un domaine différent) et non celles d'un invité. L'article que vous indiquez parle des services de reporting - c'est une toute autre chose. Les deux facteurs importants sont les suivants

  1. S'assurer que les comptes utilisateurs ont accès à la bonne base de données.
  2. S'assurer que le compte de l'ordinateur du serveur de rapports est approuvé pour la délégation.

Je soupçonne que s'il s'agit d'une question relative au serveur de rapports, le numéro 2 est votre problème. Afin qu'un serveur puisse utiliser les informations d'identification d'un autre serveur, il doit authentification des délégués . Les étapes requises sont les suivantes aquí . Une fois qu'il a obtenu la confiance, un serveur peut alors se faire passer pour un compte utilisateur.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X