Discussion :

[badack]

Bonjour à tous,

Je suis devant une colle et je dois admettre que la partie système de SQL Server n'est pas ma spécialité.

J'ai créé plusieurs roles (database role) au niveau de ma base de données (RoleA, RoleB, ...)
Ces roles ont comme membres des groupes windows (groupeA, groupeB, ...)
Et bien entendu, chaque groupe windows possède quelques utilisateurs windows également.

Actuellement, je procède de cette manière:
- Je retrouve le groupe windows auquel appartient l'utilisateur (en .net)
- Je retrouve le role auquel appartient le groupe windows (en Sql)

Existe t'il un moyen pour retrouver à quel role est lié un utilisateur windows directement en SQL?

[SQLpro]

Non. Il est d'ailleurs franchement idiot d'utiliser la notion d'utilisateur et de groupe NT au sein d'une base de données. En effet ce ne sont pas des utilisateurs personnes physiques qui se connectent à une base de données, mais des applications. Nous ne sommes plus au temps des SGBD fichiers... Nous sommes au temps des applications client/serveur.

Que ferez vous si votre AD tombe en panne et que votre PDG veut absolument et en urgence les données dans la base ????

Réservez les utilisateurs NT aux DBA de votre entreprise et utilisez des compte de connexion SQL pour les applicatifs.

A +

[badack]

Merci SqlPro pour ta réponse concernant la possibilité ou non de ce que je recherche.

Pour ton analyse, je ne suis pas de ton avis.

Je pense, au contraire, que Active Directory et consort sont justement utilisé dans une optique de centraliser la gestion des identités et des droits.

En utilisant ce repository central, le développeur d'application n'a plus à s'occuper de la gestion de qui peut accéder à quoi.
Il définit ses droits au travers de groupes NT et le reste est laissé au bons soins des équipes de support.
Comment fais tu si ton application utilise une authentification de type Windows?

Et si ton AD se plante, il te reste la possibilité de te connecter en SA .

[SQLpro]

Ce que vous dites n'a aucun sens car en dehors de l'accès au serveur qui est une chose AD n'a strictement aucune visibilité des autorisations sur les fonctions du serveur, les accès aux bases de données ni les autorisations accordées sur les commandes vis à vis des objets des bases de données...

Comme beaucoup, vous confondez données et programmes et c'est navrant !

Je vous plaint le jour ou vous aurez un bon crash système et qu'il vous faudra rendre vos données rapidement accessible dans un système dégradé.

Pensez simplement que votre patron peu être plus intéressé de pouvoir passer une commande dans son SI (donc de rentrer des info dans la base de données), plutôt que d'attendre que vous ayez monté vos serveurs de sécurité.

La conception même de la sécurité c'est avant tout l'urgence vitale des accès aux données, même sans sans aucun contrôle.

Imaginons que vous soyez un accidenté arrivant aux urgence et que le responsable système vous dise, alors que vous êtes quasiment dans le coma, il faut que je remonte le serveur AD pour savoir de quel groupe sanguin vous êtes !!!

Je m'en réjouit d'avance...

A +

[Chtulus]

+1 pour SQLpro

[badack]

Bien évidement que le type de business permet de faire des choix par exemple dans ce niveau.
Et ton exemple justifie tout à fait ce choix.

Mais tout les business n'ont pas les mêmes pré requis.
Tu prends SAP, il s'appuie tout aussi bien sur de l'authentification personnelle que sur n'importe quel LDAP server.
Ce qui veut dire que le choix est ouvert et dans mon cas, c'est l'authentification Windows qui est un pré-requis.

A nouveau, l'accès aux données peut également se faire avec des comptes SQL également, donc je ne m'inquiète pas sur ce point.