Sécurité.

As tu investigué les roles d'application.
Regarde sp_addapprole dans l'Aide En Ligne

--
Bien cordialement
Med Bouchenafa

"AB" <AB@discussions.microsoft.com> a écrit dans le message de news:
F8586490-78D0-4832-8C2E-0DC92B852C78@microsoft.com...

Bonjour à tous,

Est-ce quelqu'un sait comment limiter les accès d'une application, type
access d'accèder via odbc.
Voici le contexte. Les utilisateurs travaillent avec des applis vb 6 et
aspnet. L'accès aux serverus se fait via les logins windows. Chaque
utilisateur a accès en lecture ecriture sur les bases de données. Jusqu'à
là.
Tout est sécrurisé. Aucun utilisateur n'accède directement à la BD.
Puisque
le frontal VB 6 ou aspnet permet ce verrouillage. Par contre, dans
l'entreprise certains utilisateurs ont access d'installé sur leur machine,
save manipuler les DSN, en créent et accèdent directement aux bases grâce
à
l'autentification intégrée windows. Pas de mot passe à tapper, un seul
lien
odbc et l'accès est possible aux bases de productions. Il est impossible
de
leur supprimer access de leur machine pour des raisons d'exploitations.
L'object de ce post est comment faire pour refuser l'accès aux bases de
productions à cet utilisateur lorsqu'il vient d'une base access tout en
lui
laissant l'accès via les applis vb6 et aspnet.
Passer tout en autentification sql n'est pas possible car les applis vb6
et
aspnet gèrent des rôles applicatifs basés sur le login windows. Pour
mémoire
un rôle applicatif est rôle qui permet l'accès ou pas à certaines régions
de
l'appli pour un utilisateur donné. Le rôle applicatif est différent du
rôle
base de donnée qui,lui, a pour fonction de gérer les objects bd. Ces deux
rôles sont compléméntaires.

l'idéal serait d'associer le nom d'une application à un rôle db. De cette
façon lorsque la personne se connecte via une appli bv6, elle y sera
autorisée. Par contre si elle se connecte avec access l'accès lui sera
refusée.
Je ne pense pas que cela est possible dans la version sql2k.

Parcontre, y'a-t-il une possibilité de modifier la procédure systeme qui
permet de vérifier les connexions? Je sais cela pourrait destabiliser le
système mais fait d'une façon réfléchie cela ne poserait aucun problème.
Le scénario serait le suivant:
Pour un rôle donné appartenant à une db lui associer un ou plusieurs noms
d'applications. Lorsque l'utilisateur se connecte, en supposant que la
routine de vérification des autorisations puisse être modifiée, lorsque
sql
vérifie les autorisations d'accès aux objects au préalable il doit
vérifier
sil'application est autorisé ou pas à accèder à la base de données en
question.

Cela serait très utiles dans l'avenir. Avec office 2003, l'utilisateur
peut
attaquer une une bd très facilement. L'autentification windows et les
rôles
bd + rôle applicatifs ne sont plus suffisant. Gérer la sécurité avec des
outils qui permettent un accès très facile aux bds n'est plus très
efficace
lorsque nous utilisons l'autentification windows. Pouvoir associer le nom
d'une application cliente à un rôle bd palierait à ce problème.

Cela fait beaucoup de questions, merci pour vos réponses et pour votre
patience.
Juste une dernière question. Si quelqu'un sait quelle est la nom de la
procédure système qui permet de checker les roles bd lors de la connexion
d'une application cliente je lui serais très reconnaissant.

Encore merci

AB

Bonjour,
Merci pour ta réponse. Mais cela ne me convient pas.
Le sp_addapprole n'est efficace que lorsqu'il est activé par code et dans un
contexte d'exécution propre à une application.
De façon shématique, on crée un rôle application au niveau sql. Ensuite, au
niveau application, l'application se connecte. Ensuite, faire un
sp_setapprole pour activé le rôle via le code applicatif juste après s'être
connecté. Si l'activation est oubliée le rôle application n'a aucune utilité
puisque la bd peut être intérrogée sans aucun problème. Et le problème se
trouve là.
Lorsqu'une personne utilise access brut (bd vide) pour liée des tables. Elle
peut se connecter sans aucun problème. Le rôle applicatif n'a aucune
efficacité. Il n'empêche en rien les gens de se connecter. Alors que le
contraire aurait été le bienvenue. Le fonctinnement suivant aurait été plus
efficace. Lorsqu'il y a un role applicatif. Aucune application ne peut
intérroger la bd sauf celles qui activent le role application via le code. ou
alors le role application doit être associé à une application au niveau du
serveur sql. Et lorsqu'une application se connecte si elle ne fait pas partie
de ce role l'autorisation lui ait refusé.


Le problème reste ouvert!
Merci pour vos réponses.

AB

"Med Bouchenafa" a écrit :

As tu investigué les roles d'application.
Regarde sp_addapprole dans l'Aide En Ligne

--
Bien cordialement
Med Bouchenafa

"AB" <AB@discussions.microsoft.com> a écrit dans le message de news:
F8586490-78D0-4832-8C2E-0DC92B852C78@microsoft.com...
> Bonjour à tous,
>
> Est-ce quelqu'un sait comment limiter les accès d'une application, type
> access d'accèder via odbc.
> Voici le contexte. Les utilisateurs travaillent avec des applis vb 6 et
> aspnet. L'accès aux serverus se fait via les logins windows. Chaque
> utilisateur a accès en lecture ecriture sur les bases de données. Jusqu'à
> là.
> Tout est sécrurisé. Aucun utilisateur n'accède directement à la BD.
> Puisque
> le frontal VB 6 ou aspnet permet ce verrouillage. Par contre, dans
> l'entreprise certains utilisateurs ont access d'installé sur leur machine,
> save manipuler les DSN, en créent et accèdent directement aux bases grâce
> à
> l'autentification intégrée windows. Pas de mot passe à tapper, un seul
> lien
> odbc et l'accès est possible aux bases de productions. Il est impossible
> de
> leur supprimer access de leur machine pour des raisons d'exploitations.
> L'object de ce post est comment faire pour refuser l'accès aux bases de
> productions à cet utilisateur lorsqu'il vient d'une base access tout en
> lui
> laissant l'accès via les applis vb6 et aspnet.
> Passer tout en autentification sql n'est pas possible car les applis vb6
> et
> aspnet gèrent des rôles applicatifs basés sur le login windows. Pour
> mémoire
> un rôle applicatif est rôle qui permet l'accès ou pas à certaines régions
> de
> l'appli pour un utilisateur donné. Le rôle applicatif est différent du
> rôle
> base de donnée qui,lui, a pour fonction de gérer les objects bd. Ces deux
> rôles sont compléméntaires.
>
> l'idéal serait d'associer le nom d'une application à un rôle db. De cette
> façon lorsque la personne se connecte via une appli bv6, elle y sera
> autorisée. Par contre si elle se connecte avec access l'accès lui sera
> refusée.
> Je ne pense pas que cela est possible dans la version sql2k.
>
> Parcontre, y'a-t-il une possibilité de modifier la procédure systeme qui
> permet de vérifier les connexions? Je sais cela pourrait destabiliser le
> système mais fait d'une façon réfléchie cela ne poserait aucun problème.
> Le scénario serait le suivant:
> Pour un rôle donné appartenant à une db lui associer un ou plusieurs noms
> d'applications. Lorsque l'utilisateur se connecte, en supposant que la
> routine de vérification des autorisations puisse être modifiée, lorsque
> sql
> vérifie les autorisations d'accès aux objects au préalable il doit
> vérifier
> sil'application est autorisé ou pas à accèder à la base de données en
> question.
>
> Cela serait très utiles dans l'avenir. Avec office 2003, l'utilisateur
> peut
> attaquer une une bd très facilement. L'autentification windows et les
> rôles
> bd + rôle applicatifs ne sont plus suffisant. Gérer la sécurité avec des
> outils qui permettent un accès très facile aux bds n'est plus très
> efficace
> lorsque nous utilisons l'autentification windows. Pouvoir associer le nom
> d'une application cliente à un rôle bd palierait à ce problème.
>
> Cela fait beaucoup de questions, merci pour vos réponses et pour votre
> patience.
> Juste une dernière question. Si quelqu'un sait quelle est la nom de la
> procédure système qui permet de checker les roles bd lors de la connexion
> d'une application cliente je lui serais très reconnaissant.
>
> Encore merci
>
> AB

Bonjour,
Il y a peut-être une autre façon de voir les choses ...
Le profil windows de l'utilisateur sert à gérer les actions qu'au niveau de
l'application pas au niveau de la manipulation des données de la base
(l'accès aux données de la base se fait via le client VB ou ASP donc par un
clic sur un bouton ou un lien qui exécute du code). Du coup, la gestion de la
sécurté doit pouvoir se faire comme suit :
1) Passer en mixte
2) Interdir l'accès aux compte windows
3) Créer un compte SQL avec juste un droit en lecture sur la base avec accès
à la table (ou au droit d'exécution d'une proc) qui donne les droits
applicatifs des profils utilisateurs. Bien sûr si ces droits sont gérés en
base sinon cette étape est inutile.
4) Ensuite créer un compte SQL générique qui est utilisé par les applicatifs
VB et
ASP pour se connecter à la base et qui a le droit d'effectuer les ordres de
manipulation de données (et d'exec de procédure).

Le seul bémol à cette solution est que plusieurs connexions applicatives
apparaîtront avec le même user SQL. La différence se fera au niveau de
l'information HOTE.

Espérant vous avoir aidé.


"AB" a écrit :

Bonjour à tous,

Est-ce quelqu'un sait comment limiter les accès d'une application, type
access d'accèder via odbc.
Voici le contexte. Les utilisateurs travaillent avec des applis vb 6 et
aspnet. L'accès aux serverus se fait via les logins windows. Chaque
utilisateur a accès en lecture ecriture sur les bases de données. Jusqu'à là.
Tout est sécrurisé. Aucun utilisateur n'accède directement à la BD. Puisque
le frontal VB 6 ou aspnet permet ce verrouillage. Par contre, dans
l'entreprise certains utilisateurs ont access d'installé sur leur machine,
save manipuler les DSN, en créent et accèdent directement aux bases grâce à
l'autentification intégrée windows. Pas de mot passe à tapper, un seul lien
odbc et l'accès est possible aux bases de productions. Il est impossible de
leur supprimer access de leur machine pour des raisons d'exploitations.
L'object de ce post est comment faire pour refuser l'accès aux bases de
productions à cet utilisateur lorsqu'il vient d'une base access tout en lui
laissant l'accès via les applis vb6 et aspnet.
Passer tout en autentification sql n'est pas possible car les applis vb6 et
aspnet gèrent des rôles applicatifs basés sur le login windows. Pour mémoire
un rôle applicatif est rôle qui permet l'accès ou pas à certaines régions de
l'appli pour un utilisateur donné. Le rôle applicatif est différent du rôle
base de donnée qui,lui, a pour fonction de gérer les objects bd. Ces deux
rôles sont compléméntaires.

l'idéal serait d'associer le nom d'une application à un rôle db. De cette
façon lorsque la personne se connecte via une appli bv6, elle y sera
autorisée. Par contre si elle se connecte avec access l'accès lui sera
refusée.
Je ne pense pas que cela est possible dans la version sql2k.

Parcontre, y'a-t-il une possibilité de modifier la procédure systeme qui
permet de vérifier les connexions? Je sais cela pourrait destabiliser le
système mais fait d'une façon réfléchie cela ne poserait aucun problème.
Le scénario serait le suivant:
Pour un rôle donné appartenant à une db lui associer un ou plusieurs noms
d'applications. Lorsque l'utilisateur se connecte, en supposant que la
routine de vérification des autorisations puisse être modifiée, lorsque sql
vérifie les autorisations d'accès aux objects au préalable il doit vérifier
sil'application est autorisé ou pas à accèder à la base de données en
question.

Cela serait très utiles dans l'avenir. Avec office 2003, l'utilisateur peut
attaquer une une bd très facilement. L'autentification windows et les rôles
bd + rôle applicatifs ne sont plus suffisant. Gérer la sécurité avec des
outils qui permettent un accès très facile aux bds n'est plus très efficace
lorsque nous utilisons l'autentification windows. Pouvoir associer le nom
d'une application cliente à un rôle bd palierait à ce problème.

Cela fait beaucoup de questions, merci pour vos réponses et pour votre
patience.
Juste une dernière question. Si quelqu'un sait quelle est la nom de la
procédure système qui permet de checker les roles bd lors de la connexion
d'une application cliente je lui serais très reconnaissant.

Encore merci

AB

Bonjour et merci pur ta réponse.
Cette solution n'est pas viable dans mon contexte.
Avec une vigntaine d'applications et autant de db, cela devient ingérable.
Sans compter que la gestion de la sécurité pour l'ensemble des applications
n'est pas homogènes.
Au niveau des bds, des rôles bd sont utilisés. au minimum , il y a 2 rôles
par bd.
Le principe de gestion de sécurité utilisé est le suivant:
Auniveau bd:
- Utilisation de rôles bd avec autentification windows (Groupes NT)
Au niveau interface utilisateur:
- Profils stockées en base de données. Ceci permet ou nom l'accès à des
écrans
confidentiels

Modifier tout cela coûterait cher.

Mon souci ce n'est pas tellement les applications en prods. Si nous avions
que cela il n'y aurai aucun problème.
Le souci est que certains utilisateurs expérimentés avec Access savent créer
des DSN sur une bd (sql ou .mdb). Comme ils ont accès aux bds via les
applications Vb et aspnet, di facto ils ont les droits necessaires pour
interroger les bds via une table liée dans Access.

Comme l'autentificaton ne peut être changée pour des raisons diverses,
l'interdiction aux bds de prods ne peut se faire pour une catégorie de
personnes.

En tout cas merci pour tout et merci à ceux qui participent pour la
résolution des problèmes que nous rencontrons.

Mes encouragements.

AB

Avec une vingtaine de bd, cela m'amènerait à 40 compte sql à génrer


"TLE91" a écrit :

Bonjour,
Il y a peut-être une autre façon de voir les choses ...
Le profil windows de l'utilisateur sert à gérer les actions qu'au niveau de
l'application pas au niveau de la manipulation des données de la base
(l'accès aux données de la base se fait via le client VB ou ASP donc par un
clic sur un bouton ou un lien qui exécute du code). Du coup, la gestion de la
sécurté doit pouvoir se faire comme suit :
1) Passer en mixte
2) Interdir l'accès aux compte windows
3) Créer un compte SQL avec juste un droit en lecture sur la base avec accès
à la table (ou au droit d'exécution d'une proc) qui donne les droits
applicatifs des profils utilisateurs. Bien sûr si ces droits sont gérés en
base sinon cette étape est inutile.
4) Ensuite créer un compte SQL générique qui est utilisé par les applicatifs
VB et
ASP pour se connecter à la base et qui a le droit d'effectuer les ordres de
manipulation de données (et d'exec de procédure).

Le seul bémol à cette solution est que plusieurs connexions applicatives
apparaîtront avec le même user SQL. La différence se fera au niveau de
l'information HOTE.

Espérant vous avoir aidé.


"AB" a écrit :

> Bonjour à tous,
>
> Est-ce quelqu'un sait comment limiter les accès d'une application, type
> access d'accèder via odbc.
> Voici le contexte. Les utilisateurs travaillent avec des applis vb 6 et
> aspnet. L'accès aux serverus se fait via les logins windows. Chaque
> utilisateur a accès en lecture ecriture sur les bases de données. Jusqu'à là.
> Tout est sécrurisé. Aucun utilisateur n'accède directement à la BD. Puisque
> le frontal VB 6 ou aspnet permet ce verrouillage. Par contre, dans
> l'entreprise certains utilisateurs ont access d'installé sur leur machine,
> save manipuler les DSN, en créent et accèdent directement aux bases grâce à
> l'autentification intégrée windows. Pas de mot passe à tapper, un seul lien
> odbc et l'accès est possible aux bases de productions. Il est impossible de
> leur supprimer access de leur machine pour des raisons d'exploitations.
> L'object de ce post est comment faire pour refuser l'accès aux bases de
> productions à cet utilisateur lorsqu'il vient d'une base access tout en lui
> laissant l'accès via les applis vb6 et aspnet.
> Passer tout en autentification sql n'est pas possible car les applis vb6 et
> aspnet gèrent des rôles applicatifs basés sur le login windows. Pour mémoire
> un rôle applicatif est rôle qui permet l'accès ou pas à certaines régions de
> l'appli pour un utilisateur donné. Le rôle applicatif est différent du rôle
> base de donnée qui,lui, a pour fonction de gérer les objects bd. Ces deux
> rôles sont compléméntaires.
>
> l'idéal serait d'associer le nom d'une application à un rôle db. De cette
> façon lorsque la personne se connecte via une appli bv6, elle y sera
> autorisée. Par contre si elle se connecte avec access l'accès lui sera
> refusée.
> Je ne pense pas que cela est possible dans la version sql2k.
>
> Parcontre, y'a-t-il une possibilité de modifier la procédure systeme qui
> permet de vérifier les connexions? Je sais cela pourrait destabiliser le
> système mais fait d'une façon réfléchie cela ne poserait aucun problème.
> Le scénario serait le suivant:
> Pour un rôle donné appartenant à une db lui associer un ou plusieurs noms
> d'applications. Lorsque l'utilisateur se connecte, en supposant que la
> routine de vérification des autorisations puisse être modifiée, lorsque sql
> vérifie les autorisations d'accès aux objects au préalable il doit vérifier
> sil'application est autorisé ou pas à accèder à la base de données en
> question.
>
> Cela serait très utiles dans l'avenir. Avec office 2003, l'utilisateur peut
> attaquer une une bd très facilement. L'autentification windows et les rôles
> bd + rôle applicatifs ne sont plus suffisant. Gérer la sécurité avec des
> outils qui permettent un accès très facile aux bds n'est plus très efficace
> lorsque nous utilisons l'autentification windows. Pouvoir associer le nom
> d'une application cliente à un rôle bd palierait à ce problème.
>
> Cela fait beaucoup de questions, merci pour vos réponses et pour votre
> patience.
> Juste une dernière question. Si quelqu'un sait quelle est la nom de la
> procédure système qui permet de checker les roles bd lors de la connexion
> d'une application cliente je lui serais très reconnaissant.
>
> Encore merci
>
> AB

Je ne suis pas sur que ça aide, mais si l'utilisateur n'a aucun droit et que
le role applicatif a les droits, l'utilisateur ne pourra accéder que par
l'appli, et si le role n'a pas été activé, l'utilisateur se trouve sans
droits, ça oblige a maintenir l'appli à jour.

br

"AB" <AB@discussions.microsoft.com> wrote in message
news:0148BA31-CFDA-477F-8136-95554471E65F@microsoft.com...

Bonjour,
Merci pour ta réponse. Mais cela ne me convient pas.
Le sp_addapprole n'est efficace que lorsqu'il est activé par code et dans
un
contexte d'exécution propre à une application.
De façon shématique, on crée un rôle application au niveau sql. Ensuite,
au
niveau application, l'application se connecte. Ensuite, faire un
sp_setapprole pour activé le rôle via le code applicatif juste après
s'être
connecté. Si l'activation est oubliée le rôle application n'a aucune
utilité
puisque la bd peut être intérrogée sans aucun problème. Et le problème se
trouve là.
Lorsqu'une personne utilise access brut (bd vide) pour liée des tables.
Elle
peut se connecter sans aucun problème. Le rôle applicatif n'a aucune
efficacité. Il n'empêche en rien les gens de se connecter. Alors que le
contraire aurait été le bienvenue. Le fonctinnement suivant aurait été
plus
efficace. Lorsqu'il y a un role applicatif. Aucune application ne peut
intérroger la bd sauf celles qui activent le role application via le code.
ou
alors le role application doit être associé à une application au niveau du
serveur sql. Et lorsqu'une application se connecte si elle ne fait pas
partie
de ce role l'autorisation lui ait refusé.


Le problème reste ouvert!
Merci pour vos réponses.

AB

"Med Bouchenafa" a écrit :

As tu investigué les roles d'application.
Regarde sp_addapprole dans l'Aide En Ligne

--
Bien cordialement
Med Bouchenafa

"AB" <AB@discussions.microsoft.com> a écrit dans le message de news:
F8586490-78D0-4832-8C2E-0DC92B852C78@microsoft.com...
> Bonjour à tous,
>
> Est-ce quelqu'un sait comment limiter les accès d'une application, type
> access d'accèder via odbc.
> Voici le contexte. Les utilisateurs travaillent avec des applis vb 6 et
> aspnet. L'accès aux serverus se fait via les logins windows. Chaque
> utilisateur a accès en lecture ecriture sur les bases de données.
> Jusqu'à
> là.
> Tout est sécrurisé. Aucun utilisateur n'accède directement à la BD.
> Puisque
> le frontal VB 6 ou aspnet permet ce verrouillage. Par contre, dans
> l'entreprise certains utilisateurs ont access d'installé sur leur
> machine,
> save manipuler les DSN, en créent et accèdent directement aux bases
> grâce
> à
> l'autentification intégrée windows. Pas de mot passe à tapper, un seul
> lien
> odbc et l'accès est possible aux bases de productions. Il est
> impossible
> de
> leur supprimer access de leur machine pour des raisons d'exploitations.
> L'object de ce post est comment faire pour refuser l'accès aux bases de
> productions à cet utilisateur lorsqu'il vient d'une base access tout en
> lui
> laissant l'accès via les applis vb6 et aspnet.
> Passer tout en autentification sql n'est pas possible car les applis
> vb6
> et
> aspnet gèrent des rôles applicatifs basés sur le login windows. Pour
> mémoire
> un rôle applicatif est rôle qui permet l'accès ou pas à certaines
> régions
> de
> l'appli pour un utilisateur donné. Le rôle applicatif est différent du
> rôle
> base de donnée qui,lui, a pour fonction de gérer les objects bd. Ces
> deux
> rôles sont compléméntaires.
>
> l'idéal serait d'associer le nom d'une application à un rôle db. De
> cette
> façon lorsque la personne se connecte via une appli bv6, elle y sera
> autorisée. Par contre si elle se connecte avec access l'accès lui sera
> refusée.
> Je ne pense pas que cela est possible dans la version sql2k.
>
> Parcontre, y'a-t-il une possibilité de modifier la procédure systeme
> qui
> permet de vérifier les connexions? Je sais cela pourrait destabiliser
> le
> système mais fait d'une façon réfléchie cela ne poserait aucun
> problème.
> Le scénario serait le suivant:
> Pour un rôle donné appartenant à une db lui associer un ou plusieurs
> noms
> d'applications. Lorsque l'utilisateur se connecte, en supposant que la
> routine de vérification des autorisations puisse être modifiée, lorsque
> sql
> vérifie les autorisations d'accès aux objects au préalable il doit
> vérifier
> sil'application est autorisé ou pas à accèder à la base de données en
> question.
>
> Cela serait très utiles dans l'avenir. Avec office 2003, l'utilisateur
> peut
> attaquer une une bd très facilement. L'autentification windows et les
> rôles
> bd + rôle applicatifs ne sont plus suffisant. Gérer la sécurité avec
> des
> outils qui permettent un accès très facile aux bds n'est plus très
> efficace
> lorsque nous utilisons l'autentification windows. Pouvoir associer le
> nom
> d'une application cliente à un rôle bd palierait à ce problème.
>
> Cela fait beaucoup de questions, merci pour vos réponses et pour votre
> patience.
> Juste une dernière question. Si quelqu'un sait quelle est la nom de la
> procédure système qui permet de checker les roles bd lors de la
> connexion
> d'une application cliente je lui serais très reconnaissant.
>
> Encore merci
>
> AB

Bonjour,

L'utilisation du role applicatif ne peut se faire sans une connection au
préalable.
Il faut d'abord se connecter et ensuite réduire ou étendre les droits avec
le rôle applicatif.
Sans connexion l'activation du rôle applicatif ne peut se faire via
l'interface utilisateur.
Comme, il est dit dans un de mes posts, ce n'est pas tellement mes
applications VB qui posent problème. C'est Access. Une même personne qui
accède via une appli Vb, l'accès doit lui pouvoir être refusé pour une autre
application pour une même base.
Avec l'autentification windows, l'interdiction ne peut se faire lorsque
cette personne utilise Access (Au niveau d'accès je n'ai pas d'applis, juste
une base de données et des tables liées). Le rôle application n'est utile que
lorsqu'il peut être activé via le code. Comme aucun code ne peut être activé
via Access, aucun rôle applicatif n'est actif. Laisser l'accès à un
utilisateur expérimenté, le droit de voir les données de production à partir
d'une table Access, C'est extrêment dangereux. Une erreur de manipulation est
vite arrivée.

L'avantage avec une autentification windows, c'est qu'il y a qu'un seul
compte (SSO = Single Sign On) Une autentification unique pour toutes les
applis. Le désavantage:
Il n'y a pas de distinction, au niveau gestion de la sécurité bd, entre
deux applications qui utilise un même login.
Qu'on vient d'une application VB ou d'une application ASP.NET, si
l'utilisateur à un même login, le serveur sql ne sait pas faire la différence
ou la distinction entre ces deux applications. Pour Sql Server, ce sont des
reqûtes qui viennent du même login.
En fait il sait faire la difference entre les applications mais la gestion
de la sécurité n'est pas gérée aussi finiment qu'on le voudrait. Cela ne
remet pas en cause le principe de fonctionnement de Sql Server. Il réponds à
pas mal de problèmatique. Mais dans mon contexte, et je pense dans le
contexte d'autres entreprises, cela devient urgent de pourvoir gérer un vrai
rôle applicatif au niveau du serveur qui serait basé sur le principe suivant:
Grâce à un role applicatif server(qui serait à créer), pour un même compte,
en fonction d l'application, autoriser ou pas le compte à accéder à la même
bd.

Qui s'est peut être que Microsoft l'a prévu pour sql2005 ou en prendra en
compte dans ces prochains SP pour sql2k et sql2005

En tous cas cela faciliterait bien les choses à pas mal de développeur et DBA

Merci à tous.
AB

"bruno reiter [MVP]" a écrit :

Je ne suis pas sur que ça aide, mais si l'utilisateur n'a aucun droit et que
le role applicatif a les droits, l'utilisateur ne pourra accéder que par
l'appli, et si le role n'a pas été activé, l'utilisateur se trouve sans
droits, ça oblige a maintenir l'appli à jour.

br

"AB" <AB@discussions.microsoft.com> wrote in message
news:0148BA31-CFDA-477F-8136-95554471E65F@microsoft.com...
> Bonjour,
> Merci pour ta réponse. Mais cela ne me convient pas.
> Le sp_addapprole n'est efficace que lorsqu'il est activé par code et dans
> un
> contexte d'exécution propre à une application.
> De façon shématique, on crée un rôle application au niveau sql. Ensuite,
> au
> niveau application, l'application se connecte. Ensuite, faire un
> sp_setapprole pour activé le rôle via le code applicatif juste après
> s'être
> connecté. Si l'activation est oubliée le rôle application n'a aucune
> utilité
> puisque la bd peut être intérrogée sans aucun problème. Et le problème se
> trouve là.
> Lorsqu'une personne utilise access brut (bd vide) pour liée des tables.
> Elle
> peut se connecter sans aucun problème. Le rôle applicatif n'a aucune
> efficacité. Il n'empêche en rien les gens de se connecter. Alors que le
> contraire aurait été le bienvenue. Le fonctinnement suivant aurait été
> plus
> efficace. Lorsqu'il y a un role applicatif. Aucune application ne peut
> intérroger la bd sauf celles qui activent le role application via le code.
> ou
> alors le role application doit être associé à une application au niveau du
> serveur sql. Et lorsqu'une application se connecte si elle ne fait pas
> partie
> de ce role l'autorisation lui ait refusé.
>
>
> Le problème reste ouvert!
> Merci pour vos réponses.
>
> AB
>
> "Med Bouchenafa" a écrit :
>
>> As tu investigué les roles d'application.
>> Regarde sp_addapprole dans l'Aide En Ligne
>>
>> --
>> Bien cordialement
>> Med Bouchenafa
>>
>> "AB" <AB@discussions.microsoft.com> a écrit dans le message de news:
>> F8586490-78D0-4832-8C2E-0DC92B852C78@microsoft.com...
>> > Bonjour à tous,
>> >
>> > Est-ce quelqu'un sait comment limiter les accès d'une application, type
>> > access d'accèder via odbc.
>> > Voici le contexte. Les utilisateurs travaillent avec des applis vb 6 et
>> > aspnet. L'accès aux serverus se fait via les logins windows. Chaque
>> > utilisateur a accès en lecture ecriture sur les bases de données.
>> > Jusqu'à
>> > là.
>> > Tout est sécrurisé. Aucun utilisateur n'accède directement à la BD.
>> > Puisque
>> > le frontal VB 6 ou aspnet permet ce verrouillage. Par contre, dans
>> > l'entreprise certains utilisateurs ont access d'installé sur leur
>> > machine,
>> > save manipuler les DSN, en créent et accèdent directement aux bases
>> > grâce
>> > à
>> > l'autentification intégrée windows. Pas de mot passe à tapper, un seul
>> > lien
>> > odbc et l'accès est possible aux bases de productions. Il est
>> > impossible
>> > de
>> > leur supprimer access de leur machine pour des raisons d'exploitations.
>> > L'object de ce post est comment faire pour refuser l'accès aux bases de
>> > productions à cet utilisateur lorsqu'il vient d'une base access tout en
>> > lui
>> > laissant l'accès via les applis vb6 et aspnet.
>> > Passer tout en autentification sql n'est pas possible car les applis
>> > vb6
>> > et
>> > aspnet gèrent des rôles applicatifs basés sur le login windows. Pour
>> > mémoire
>> > un rôle applicatif est rôle qui permet l'accès ou pas à certaines
>> > régions
>> > de
>> > l'appli pour un utilisateur donné. Le rôle applicatif est différent du
>> > rôle
>> > base de donnée qui,lui, a pour fonction de gérer les objects bd. Ces
>> > deux
>> > rôles sont compléméntaires.
>> >
>> > l'idéal serait d'associer le nom d'une application à un rôle db. De
>> > cette
>> > façon lorsque la personne se connecte via une appli bv6, elle y sera
>> > autorisée. Par contre si elle se connecte avec access l'accès lui sera
>> > refusée.
>> > Je ne pense pas que cela est possible dans la version sql2k.
>> >
>> > Parcontre, y'a-t-il une possibilité de modifier la procédure systeme
>> > qui
>> > permet de vérifier les connexions? Je sais cela pourrait destabiliser
>> > le
>> > système mais fait d'une façon réfléchie cela ne poserait aucun
>> > problème.
>> > Le scénario serait le suivant:
>> > Pour un rôle donné appartenant à une db lui associer un ou plusieurs
>> > noms
>> > d'applications. Lorsque l'utilisateur se connecte, en supposant que la
>> > routine de vérification des autorisations puisse être modifiée, lorsque
>> > sql
>> > vérifie les autorisations d'accès aux objects au préalable il doit
>> > vérifier
>> > sil'application est autorisé ou pas à accèder à la base de données en
>> > question.
>> >
>> > Cela serait très utiles dans l'avenir. Avec office 2003, l'utilisateur
>> > peut
>> > attaquer une une bd très facilement. L'autentification windows et les
>> > rôles
>> > bd + rôle applicatifs ne sont plus suffisant. Gérer la sécurité avec
>> > des
>> > outils qui permettent un accès très facile aux bds n'est plus très
>> > efficace
>> > lorsque nous utilisons l'autentification windows. Pouvoir associer le
>> > nom
>> > d'une application cliente à un rôle bd palierait à ce problème.
>> >
>> > Cela fait beaucoup de questions, merci pour vos réponses et pour votre
>> > patience.
>> > Juste une dernière question. Si quelqu'un sait quelle est la nom de la
>> > procédure système qui permet de checker les roles bd lors de la
>> > connexion
>> > d'une application cliente je lui serais très reconnaissant.
>> >
>> > Encore merci
>> >
>> > AB
>>
>>
>>

Le rôle d'application a été créé pour répondre exactement à ta problématique
et il est inutile d'attendre SQL Server 2005 pour le résoudre
Il faut distinguer entre compte login et compte utilisateur
Le premier permet d'acceder à SQL Server et le second permet d'acceder à une
base de données

On peut avoir un login (Windows ou SQL Server) et ne pas pouvoir utiliser
une base de données si l'on a pas de compte utilisateur associé.
Pour pouvoir utiliser une base, il faut que le login possède un compte
d'utilisateur dans la base.
Si tes utlisateurs n'ont pas de comptes utilisateurs dans cette base, ils ne
pourront pas l'utiliser même s'ils possèdent un login le permettant une
authentification Windows
Qu'ils utilisent ACCESS ou n'importe quel autre outil, il ne feront que se
connecter au serveur et ne pourront jamais faire quoi que ce soit sur ta
base sauf par l'intermédiaire d'un rôle d'application que tu auras créé au
préalable


--
Bien cordialement
Med Bouchenafa



"AB" <AB@discussions.microsoft.com> a écrit dans le message de news:
C3785FF7-D7D4-43CD-B5BC-0F297161ADA0@microsoft.com...

Bonjour,

L'utilisation du role applicatif ne peut se faire sans une connection au
préalable.
Il faut d'abord se connecter et ensuite réduire ou étendre les droits avec
le rôle applicatif.
Sans connexion l'activation du rôle applicatif ne peut se faire via
l'interface utilisateur.
Comme, il est dit dans un de mes posts, ce n'est pas tellement mes
applications VB qui posent problème. C'est Access. Une même personne qui
accède via une appli Vb, l'accès doit lui pouvoir être refusé pour une
autre
application pour une même base.
Avec l'autentification windows, l'interdiction ne peut se faire lorsque
cette personne utilise Access (Au niveau d'accès je n'ai pas d'applis,
juste
une base de données et des tables liées). Le rôle application n'est utile
que
lorsqu'il peut être activé via le code. Comme aucun code ne peut être
activé
via Access, aucun rôle applicatif n'est actif. Laisser l'accès à un
utilisateur expérimenté, le droit de voir les données de production à
partir
d'une table Access, C'est extrêment dangereux. Une erreur de manipulation
est
vite arrivée.

L'avantage avec une autentification windows, c'est qu'il y a qu'un seul
compte (SSO = Single Sign On) Une autentification unique pour toutes les
applis. Le désavantage:
Il n'y a pas de distinction, au niveau gestion de la sécurité bd, entre
deux applications qui utilise un même login.
Qu'on vient d'une application VB ou d'une application ASP.NET, si
l'utilisateur à un même login, le serveur sql ne sait pas faire la
différence
ou la distinction entre ces deux applications. Pour Sql Server, ce sont
des
reqûtes qui viennent du même login.
En fait il sait faire la difference entre les applications mais la gestion
de la sécurité n'est pas gérée aussi finiment qu'on le voudrait. Cela ne
remet pas en cause le principe de fonctionnement de Sql Server. Il réponds
à
pas mal de problèmatique. Mais dans mon contexte, et je pense dans le
contexte d'autres entreprises, cela devient urgent de pourvoir gérer un
vrai
rôle applicatif au niveau du serveur qui serait basé sur le principe
suivant:
Grâce à un role applicatif server(qui serait à créer), pour un même
compte,
en fonction d l'application, autoriser ou pas le compte à accéder à la
même
bd.

Qui s'est peut être que Microsoft l'a prévu pour sql2005 ou en prendra en
compte dans ces prochains SP pour sql2k et sql2005

En tous cas cela faciliterait bien les choses à pas mal de développeur et
DBA

Merci à tous.
AB

"bruno reiter [MVP]" a écrit :

Je ne suis pas sur que ça aide, mais si l'utilisateur n'a aucun droit et
que
le role applicatif a les droits, l'utilisateur ne pourra accéder que par
l'appli, et si le role n'a pas été activé, l'utilisateur se trouve sans
droits, ça oblige a maintenir l'appli à jour.

br

"AB" <AB@discussions.microsoft.com> wrote in message
news:0148BA31-CFDA-477F-8136-95554471E65F@microsoft.com...
> Bonjour,
> Merci pour ta réponse. Mais cela ne me convient pas.
> Le sp_addapprole n'est efficace que lorsqu'il est activé par code et
> dans
> un
> contexte d'exécution propre à une application.
> De façon shématique, on crée un rôle application au niveau sql.
> Ensuite,
> au
> niveau application, l'application se connecte. Ensuite, faire un
> sp_setapprole pour activé le rôle via le code applicatif juste après
> s'être
> connecté. Si l'activation est oubliée le rôle application n'a aucune
> utilité
> puisque la bd peut être intérrogée sans aucun problème. Et le problème
> se
> trouve là.
> Lorsqu'une personne utilise access brut (bd vide) pour liée des tables.
> Elle
> peut se connecter sans aucun problème. Le rôle applicatif n'a aucune
> efficacité. Il n'empêche en rien les gens de se connecter. Alors que le
> contraire aurait été le bienvenue. Le fonctinnement suivant aurait été
> plus
> efficace. Lorsqu'il y a un role applicatif. Aucune application ne peut
> intérroger la bd sauf celles qui activent le role application via le
> code.
> ou
> alors le role application doit être associé à une application au niveau
> du
> serveur sql. Et lorsqu'une application se connecte si elle ne fait pas
> partie
> de ce role l'autorisation lui ait refusé.
>
>
> Le problème reste ouvert!
> Merci pour vos réponses.
>
> AB
>
> "Med Bouchenafa" a écrit :
>
>> As tu investigué les roles d'application.
>> Regarde sp_addapprole dans l'Aide En Ligne
>>
>> --
>> Bien cordialement
>> Med Bouchenafa
>>
>> "AB" <AB@discussions.microsoft.com> a écrit dans le message de news:
>> F8586490-78D0-4832-8C2E-0DC92B852C78@microsoft.com...
>> > Bonjour à tous,
>> >
>> > Est-ce quelqu'un sait comment limiter les accès d'une application,
>> > type
>> > access d'accèder via odbc.
>> > Voici le contexte. Les utilisateurs travaillent avec des applis vb 6
>> > et
>> > aspnet. L'accès aux serverus se fait via les logins windows. Chaque
>> > utilisateur a accès en lecture ecriture sur les bases de données.
>> > Jusqu'à
>> > là.
>> > Tout est sécrurisé. Aucun utilisateur n'accède directement à la BD.
>> > Puisque
>> > le frontal VB 6 ou aspnet permet ce verrouillage. Par contre, dans
>> > l'entreprise certains utilisateurs ont access d'installé sur leur
>> > machine,
>> > save manipuler les DSN, en créent et accèdent directement aux bases
>> > grâce
>> > à
>> > l'autentification intégrée windows. Pas de mot passe à tapper, un
>> > seul
>> > lien
>> > odbc et l'accès est possible aux bases de productions. Il est
>> > impossible
>> > de
>> > leur supprimer access de leur machine pour des raisons
>> > d'exploitations.
>> > L'object de ce post est comment faire pour refuser l'accès aux bases
>> > de
>> > productions à cet utilisateur lorsqu'il vient d'une base access tout
>> > en
>> > lui
>> > laissant l'accès via les applis vb6 et aspnet.
>> > Passer tout en autentification sql n'est pas possible car les applis
>> > vb6
>> > et
>> > aspnet gèrent des rôles applicatifs basés sur le login windows. Pour
>> > mémoire
>> > un rôle applicatif est rôle qui permet l'accès ou pas à certaines
>> > régions
>> > de
>> > l'appli pour un utilisateur donné. Le rôle applicatif est différent
>> > du
>> > rôle
>> > base de donnée qui,lui, a pour fonction de gérer les objects bd. Ces
>> > deux
>> > rôles sont compléméntaires.
>> >
>> > l'idéal serait d'associer le nom d'une application à un rôle db. De
>> > cette
>> > façon lorsque la personne se connecte via une appli bv6, elle y sera
>> > autorisée. Par contre si elle se connecte avec access l'accès lui
>> > sera
>> > refusée.
>> > Je ne pense pas que cela est possible dans la version sql2k.
>> >
>> > Parcontre, y'a-t-il une possibilité de modifier la procédure systeme
>> > qui
>> > permet de vérifier les connexions? Je sais cela pourrait
>> > destabiliser
>> > le
>> > système mais fait d'une façon réfléchie cela ne poserait aucun
>> > problème.
>> > Le scénario serait le suivant:
>> > Pour un rôle donné appartenant à une db lui associer un ou plusieurs
>> > noms
>> > d'applications. Lorsque l'utilisateur se connecte, en supposant que
>> > la
>> > routine de vérification des autorisations puisse être modifiée,
>> > lorsque
>> > sql
>> > vérifie les autorisations d'accès aux objects au préalable il doit
>> > vérifier
>> > sil'application est autorisé ou pas à accèder à la base de données
>> > en
>> > question.
>> >
>> > Cela serait très utiles dans l'avenir. Avec office 2003,
>> > l'utilisateur
>> > peut
>> > attaquer une une bd très facilement. L'autentification windows et
>> > les
>> > rôles
>> > bd + rôle applicatifs ne sont plus suffisant. Gérer la sécurité avec
>> > des
>> > outils qui permettent un accès très facile aux bds n'est plus très
>> > efficace
>> > lorsque nous utilisons l'autentification windows. Pouvoir associer
>> > le
>> > nom
>> > d'une application cliente à un rôle bd palierait à ce problème.
>> >
>> > Cela fait beaucoup de questions, merci pour vos réponses et pour
>> > votre
>> > patience.
>> > Juste une dernière question. Si quelqu'un sait quelle est la nom de
>> > la
>> > procédure système qui permet de checker les roles bd lors de la
>> > connexion
>> > d'une application cliente je lui serais très reconnaissant.
>> >
>> > Encore merci
>> >
>> > AB
>>
>>
>>

Non il ne répond pas du tout à ma problématique.
Je pense que, premiè-rement ma problématique n'est pas comprise et secondo
tu confonds le principe de fonctionnement d'un rôle applicatifs avec un rôle
avec le role bd.
Au niveau de sql server, nous avons 3 type de roles:
1 - Roles serveur (Rôle fixe : db_ower, etc..)
2 - Rôle bd ( autorisations au niveau de l'object) Rôle que tu associe à ta
connexion sql server.
3 - Rôle application (Rôle avec un mot de passe: Droit également sur les
objets)

tu es obligé d'activer le rôle applicatif pour une connexion pour qu'il soit
valide sinon il n'est pas pris en compte.

Voici le test à effectuer si tru veux en avoir le coeur net.

J'ai fais le test suivant:

J'ai un utilisateur A qui est en datareader datawriter sur un serveur sql
réseau,
un rôle applicatif RLE avec son mot de passe XXX. le Role RLE interdit le
select sur la table authors dans la bd Pubs
une appli vb.net. Son fonctionnement est simple je me connecte à la bd je
fais un select et je l'affiche dans un grille.

plusieurs scénarii:
1 - connexion à la base B
2 - Pas d'activation de Rôle application avec sp_setapprole
3 - select table authors dans pubs
4- récup résultats et affichage
5 - Tout est ok affichage du résultat. Aucune restriction. LE role n'est
même pas intervenu dans mon fragement de code ni a été déclaenché par sql
server.
Et c'est puisque nous l'avons pas activé avec sp_setapprole.

Ce scébnarion fonctionne, le rôle application le serveur s'en fiche. Il ne
sait même pas à quel compte l'associer et en plus il n'est pas actif.

scénarion II
1 - connexion à la base B
2 - Activation du Rôle applicatif "RLE" avec sp_setapprole
3 - select table authors dans pubs
==> Et la erreur: Pas le droit select sur la base.
Ce role ne remplit son role que dans un contexte de connexion client et que
lorsqu'il est activé sinon cela ne fonctinne pas.

Je suis toujours l'utilisateur A
maintenant je lance Access, je crée un DSN sur ma Base B ( pour mémoire le
compte y est déclaré puisque je fait des select sur ma table authors. Je suis
toujours avec le Role RLE qui interdit le select sur authors de la BD Pubs.
J'arrive sans aucun problème à lier des tables et à enter en modification
des données.

Le problème du Role application c'est que tant que il n'est pas activé pour
une connexion donnée, il ne sont pas valide. Il n'est pas pris en compte par
Sql server

Fait un autre test:
prend scénario II. Cette fois-ci tu laisses la connexion ouverte et tu en
ouvre une autre pour faire un select sur la même table (authors). Je te
laisse deviner les choses.
Et bien ça passe. On peut faitre un select sur la table authors lorsqu'on
passe par une autre connexion. dans le même code.
Il est noté en clair dans la doc de microsoft que ce rôle n'est valable que
pour une connexion ouverte ayant activé le rôle sinon walow. le rôle
applicatif n'est pas déclenché. A chaque fois qu'une connexion est ouverte tu
DOIS faire un sp_setapprole si tu veux que ton role soit pris en compte par
ton serveur tu n'as aucun choix que de faire un sp_setapprole après chaque
ouverture de connexion sinon ton rôle ne sera jamais déclenché et aucune
restriction ne sera effective. Tu pour faire des selects autant que tu veux
sur les objets de ta bb ça passera. Sauf si tu as un rôle server.

Juste pour conclure, lorsque c'est une application maison, on peut toujours
restreindre les droits au niveau interface utilisateur avec dans rôle stocks
dans une bd sql pour affiner les droits d'accès. Mais lorsque c'est une
application tierce( Access ou Excel). L'accès bd ne peut pas être géré
lorsqu'un utilisateur a déjà accès à cette même bd.

Ce rôle que je demande, il est utile et sera utile. Avec des outils aussi
ouverts que ceux de MSSoft, le besoin s'en fait sentir.
Nous, développeurs, voulons pourvoir controller l'accès à une bd en fonction
du type client.
Le problème ne vient pas de ce que nous codons. Mais il vient du fait que
les applis MS n'offrent pas certains possibilités pour mieux restreindre les
droits dans ce type de contexte. Non pas qu'elles ne sont pas sécurisées.
Maisdans un certain contexte on se heurte à la problématique que j'ai
expliqué un peu plus haut.
Pour palier à ce problème, il faut qu'on ait la possibilité de gérer la
sécurité en associant un rôle à une application donnée.
Le test a été également effecté avec des roles dans une table sql pour
afficner les droits cela répond pas à ma problèmetque. Dans mon cas précis
cela ne fonctionne pas! Mon problème c'est toujours Access.

Espérant avoir été assez clair.
Merci pour ta réponse et j'espère ne pas avoir été trop long dans ce post.

AB



"Med Bouchenafa" a écrit :

Le rôle d'application a été créé pour répondre exactement à ta problématique
et il est inutile d'attendre SQL Server 2005 pour le résoudre
Il faut distinguer entre compte login et compte utilisateur
Le premier permet d'acceder à SQL Server et le second permet d'acceder à une
base de données

On peut avoir un login (Windows ou SQL Server) et ne pas pouvoir utiliser
une base de données si l'on a pas de compte utilisateur associé.
Pour pouvoir utiliser une base, il faut que le login possède un compte
d'utilisateur dans la base.
Si tes utlisateurs n'ont pas de comptes utilisateurs dans cette base, ils ne
pourront pas l'utiliser même s'ils possèdent un login le permettant une
authentification Windows
Qu'ils utilisent ACCESS ou n'importe quel autre outil, il ne feront que se
connecter au serveur et ne pourront jamais faire quoi que ce soit sur ta
base sauf par l'intermédiaire d'un rôle d'application que tu auras créé au
préalable


--
Bien cordialement
Med Bouchenafa



"AB" <AB@discussions.microsoft.com> a écrit dans le message de news:
C3785FF7-D7D4-43CD-B5BC-0F297161ADA0@microsoft.com...
> Bonjour,
>
> L'utilisation du role applicatif ne peut se faire sans une connection au
> préalable.
> Il faut d'abord se connecter et ensuite réduire ou étendre les droits avec
> le rôle applicatif.
> Sans connexion l'activation du rôle applicatif ne peut se faire via
> l'interface utilisateur.
> Comme, il est dit dans un de mes posts, ce n'est pas tellement mes
> applications VB qui posent problème. C'est Access. Une même personne qui
> accède via une appli Vb, l'accès doit lui pouvoir être refusé pour une
> autre
> application pour une même base.
> Avec l'autentification windows, l'interdiction ne peut se faire lorsque
> cette personne utilise Access (Au niveau d'accès je n'ai pas d'applis,
> juste
> une base de données et des tables liées). Le rôle application n'est utile
> que
> lorsqu'il peut être activé via le code. Comme aucun code ne peut être
> activé
> via Access, aucun rôle applicatif n'est actif. Laisser l'accès à un
> utilisateur expérimenté, le droit de voir les données de production à
> partir
> d'une table Access, C'est extrêment dangereux. Une erreur de manipulation
> est
> vite arrivée.
>
> L'avantage avec une autentification windows, c'est qu'il y a qu'un seul
> compte (SSO = Single Sign On) Une autentification unique pour toutes les
> applis. Le désavantage:
> Il n'y a pas de distinction, au niveau gestion de la sécurité bd, entre
> deux applications qui utilise un même login.
> Qu'on vient d'une application VB ou d'une application ASP.NET, si
> l'utilisateur à un même login, le serveur sql ne sait pas faire la
> différence
> ou la distinction entre ces deux applications. Pour Sql Server, ce sont
> des
> reqûtes qui viennent du même login.
> En fait il sait faire la difference entre les applications mais la gestion
> de la sécurité n'est pas gérée aussi finiment qu'on le voudrait. Cela ne
> remet pas en cause le principe de fonctionnement de Sql Server. Il réponds
> à
> pas mal de problèmatique. Mais dans mon contexte, et je pense dans le
> contexte d'autres entreprises, cela devient urgent de pourvoir gérer un
> vrai
> rôle applicatif au niveau du serveur qui serait basé sur le principe
> suivant:
> Grâce à un role applicatif server(qui serait à créer), pour un même
> compte,
> en fonction d l'application, autoriser ou pas le compte à accéder à la
> même
> bd.
>
> Qui s'est peut être que Microsoft l'a prévu pour sql2005 ou en prendra en
> compte dans ces prochains SP pour sql2k et sql2005
>
> En tous cas cela faciliterait bien les choses à pas mal de développeur et
> DBA
>
> Merci à tous.
> AB
>
> "bruno reiter [MVP]" a écrit :
>
>> Je ne suis pas sur que ça aide, mais si l'utilisateur n'a aucun droit et
>> que
>> le role applicatif a les droits, l'utilisateur ne pourra accéder que par
>> l'appli, et si le role n'a pas été activé, l'utilisateur se trouve sans
>> droits, ça oblige a maintenir l'appli à jour.
>>
>> br
>>
>> "AB" <AB@discussions.microsoft.com> wrote in message
>> news:0148BA31-CFDA-477F-8136-95554471E65F@microsoft.com...
>> > Bonjour,
>> > Merci pour ta réponse. Mais cela ne me convient pas.
>> > Le sp_addapprole n'est efficace que lorsqu'il est activé par code et
>> > dans
>> > un
>> > contexte d'exécution propre à une application.
>> > De façon shématique, on crée un rôle application au niveau sql.
>> > Ensuite,
>> > au
>> > niveau application, l'application se connecte. Ensuite, faire un
>> > sp_setapprole pour activé le rôle via le code applicatif juste après
>> > s'être
>> > connecté. Si l'activation est oubliée le rôle application n'a aucune
>> > utilité
>> > puisque la bd peut être intérrogée sans aucun problème. Et le problème
>> > se
>> > trouve là.
>> > Lorsqu'une personne utilise access brut (bd vide) pour liée des tables.
>> > Elle
>> > peut se connecter sans aucun problème. Le rôle applicatif n'a aucune
>> > efficacité. Il n'empêche en rien les gens de se connecter. Alors que le
>> > contraire aurait été le bienvenue. Le fonctinnement suivant aurait été
>> > plus
>> > efficace. Lorsqu'il y a un role applicatif. Aucune application ne peut
>> > intérroger la bd sauf celles qui activent le role application via le
>> > code.
>> > ou
>> > alors le role application doit être associé à une application au niveau
>> > du
>> > serveur sql. Et lorsqu'une application se connecte si elle ne fait pas
>> > partie
>> > de ce role l'autorisation lui ait refusé.
>> >
>> >
>> > Le problème reste ouvert!
>> > Merci pour vos réponses.
>> >
>> > AB
>> >
>> > "Med Bouchenafa" a écrit :
>> >
>> >> As tu investigué les roles d'application.
>> >> Regarde sp_addapprole dans l'Aide En Ligne
>> >>
>> >> --
>> >> Bien cordialement
>> >> Med Bouchenafa
>> >>
>> >> "AB" <AB@discussions.microsoft.com> a écrit dans le message de news:
>> >> F8586490-78D0-4832-8C2E-0DC92B852C78@microsoft.com...
>> >> > Bonjour à tous,
>> >> >
>> >> > Est-ce quelqu'un sait comment limiter les accès d'une application,
>> >> > type
>> >> > access d'accèder via odbc.
>> >> > Voici le contexte. Les utilisateurs travaillent avec des applis vb 6
>> >> > et
>> >> > aspnet. L'accès aux serverus se fait via les logins windows. Chaque
>> >> > utilisateur a accès en lecture ecriture sur les bases de données.
>> >> > Jusqu'à
>> >> > là.
>> >> > Tout est sécrurisé. Aucun utilisateur n'accède directement à la BD.
>> >> > Puisque
>> >> > le frontal VB 6 ou aspnet permet ce verrouillage. Par contre, dans
>> >> > l'entreprise certains utilisateurs ont access d'installé sur leur
>> >> > machine,
>> >> > save manipuler les DSN, en créent et accèdent directement aux bases
>> >> > grâce
>> >> > à
>> >> > l'autentification intégrée windows. Pas de mot passe à tapper, un
>> >> > seul
>> >> > lien
>> >> > odbc et l'accès est possible aux bases de productions. Il est
>> >> > impossible
>> >> > de
>> >> > leur supprimer access de leur machine pour des raisons
>> >> > d'exploitations.
>> >> > L'object de ce post est comment faire pour refuser l'accès aux bases
>> >> > de
>> >> > productions à cet utilisateur lorsqu'il vient d'une base access tout
>> >> > en
>> >> > lui
>> >> > laissant l'accès via les applis vb6 et aspnet.
>> >> > Passer tout en autentification sql n'est pas possible car les applis
>> >> > vb6
>> >> > et
>> >> > aspnet gèrent des rôles applicatifs basés sur le login windows. Pour
>> >> > mémoire
>> >> > un rôle applicatif est rôle qui permet l'accès ou pas à certaines
>> >> > régions
>> >> > de
>> >> > l'appli pour un utilisateur donné. Le rôle applicatif est différent
>> >> > du
>> >> > rôle
>> >> > base de donnée qui,lui, a pour fonction de gérer les objects bd. Ces
>> >> > deux
>> >> > rôles sont compléméntaires.
>> >> >
>> >> > l'idéal serait d'associer le nom d'une application à un rôle db. De
>> >> > cette
>> >> > façon lorsque la personne se connecte via une appli bv6, elle y sera
>> >> > autorisée. Par contre si elle se connecte avec access l'accès lui
>> >> > sera
>> >> > refusée.
>> >> > Je ne pense pas que cela est possible dans la version sql2k.
>> >> >
>> >> > Parcontre, y'a-t-il une possibilité de modifier la procédure systeme
>> >> > qui
>> >> > permet de vérifier les connexions? Je sais cela pourrait
>> >> > destabiliser
>> >> > le
>> >> > système mais fait d'une façon réfléchie cela ne poserait aucun
>> >> > problème.
>> >> > Le scénario serait le suivant:
>> >> > Pour un rôle donné appartenant à une db lui associer un ou plusieurs
>> >> > noms
>> >> > d'applications. Lorsque l'utilisateur se connecte, en supposant que
>> >> > la
>> >> > routine de vérification des autorisations puisse être modifiée,
>> >> > lorsque
>> >> > sql
>> >> > vérifie les autorisations d'accès aux objects au préalable il doit
>> >> > vérifier
>> >> > sil'application est autorisé ou pas à accèder à la base de données
>> >> > en
>> >> > question.
>> >> >
>> >> > Cela serait très utiles dans l'avenir. Avec office 2003,
>> >> > l'utilisateur
>> >> > peut
>> >> > attaquer une une bd très facilement. L'autentification windows et
>> >> > les
>> >> > rôles
>> >> > bd + rôle applicatifs ne sont plus suffisant. Gérer la sécurité avec
>> >> > des
>> >> > outils qui permettent un accès très facile aux bds n'est plus très
>> >> > efficace
>> >> > lorsque nous utilisons l'autentification windows. Pouvoir associer
>> >> > le
>> >> > nom
>> >> > d'une application cliente à un rôle bd palierait à ce problème.
>> >> >
>> >> > Cela fait beaucoup de questions, merci pour vos réponses et pour
>> >> > votre
>> >> > patience.
>> >> > Juste une dernière question. Si quelqu'un sait quelle est la nom de
>> >> > la
>> >> > procédure système qui permet de checker les roles bd lors de la
>> >> > connexion
>> >> > d'une application cliente je lui serais très reconnaissant.
>> >> >
>> >> > Encore merci
>> >> >
>> >> > AB
>> >>
>> >>
>> >>
>>
>>
>>

Ok, allons-y pas à pas et on va voir où ça coince

Prenons la cas de ton utisateurA
Ajoute le dans les roles db_denydatareader et db_denydatawriter
Met ton role RLE dans les roles db_datareader et db_datawriter
Refais tes tests

Que ce soit ACCESS ou ton application, ton utilisateurA n'a plus aucun droit
de lecture/Ecriture
Il faut qu'il active le rôle d'application RLE pour le faire.
Est ce que c'est ce que tu veux?

--
Bien cordialement
Med Bouchenafa




"AB" <AB@discussions.microsoft.com> a écrit dans le message de news:
89753743-3BA7-472F-A105-8BAEA99DACD6@microsoft.com...

Non il ne répond pas du tout à ma problématique.
Je pense que, premiè-rement ma problématique n'est pas comprise et secondo
tu confonds le principe de fonctionnement d'un rôle applicatifs avec un
rôle
avec le role bd.
Au niveau de sql server, nous avons 3 type de roles:
1 - Roles serveur (Rôle fixe : db_ower, etc..)
2 - Rôle bd ( autorisations au niveau de l'object) Rôle que tu associe à
ta
connexion sql server.
3 - Rôle application (Rôle avec un mot de passe: Droit également sur les
objets)

tu es obligé d'activer le rôle applicatif pour une connexion pour qu'il
soit
valide sinon il n'est pas pris en compte.

Voici le test à effectuer si tru veux en avoir le coeur net.

J'ai fais le test suivant:

J'ai un utilisateur A qui est en datareader datawriter sur un serveur sql
réseau,
un rôle applicatif RLE avec son mot de passe XXX. le Role RLE interdit le
select sur la table authors dans la bd Pubs
une appli vb.net. Son fonctionnement est simple je me connecte à la bd je
fais un select et je l'affiche dans un grille.

plusieurs scénarii:
1 - connexion à la base B
2 - Pas d'activation de Rôle application avec sp_setapprole
3 - select table authors dans pubs
4- récup résultats et affichage
5 - Tout est ok affichage du résultat. Aucune restriction. LE role n'est
même pas intervenu dans mon fragement de code ni a été déclaenché par sql
server.
Et c'est puisque nous l'avons pas activé avec sp_setapprole.

Ce scébnarion fonctionne, le rôle application le serveur s'en fiche. Il ne
sait même pas à quel compte l'associer et en plus il n'est pas actif.

scénarion II
1 - connexion à la base B
2 - Activation du Rôle applicatif "RLE" avec sp_setapprole
3 - select table authors dans pubs
==> Et la erreur: Pas le droit select sur la base.
Ce role ne remplit son role que dans un contexte de connexion client et
que
lorsqu'il est activé sinon cela ne fonctinne pas.

Je suis toujours l'utilisateur A
maintenant je lance Access, je crée un DSN sur ma Base B ( pour mémoire le
compte y est déclaré puisque je fait des select sur ma table authors. Je
suis
toujours avec le Role RLE qui interdit le select sur authors de la BD
Pubs.
J'arrive sans aucun problème à lier des tables et à enter en modification
des données.

Le problème du Role application c'est que tant que il n'est pas activé
pour
une connexion donnée, il ne sont pas valide. Il n'est pas pris en compte
par
Sql server

Fait un autre test:
prend scénario II. Cette fois-ci tu laisses la connexion ouverte et tu en
ouvre une autre pour faire un select sur la même table (authors). Je te
laisse deviner les choses.
Et bien ça passe. On peut faitre un select sur la table authors lorsqu'on
passe par une autre connexion. dans le même code.
Il est noté en clair dans la doc de microsoft que ce rôle n'est valable
que
pour une connexion ouverte ayant activé le rôle sinon walow. le rôle
applicatif n'est pas déclenché. A chaque fois qu'une connexion est ouverte
tu
DOIS faire un sp_setapprole si tu veux que ton role soit pris en compte
par
ton serveur tu n'as aucun choix que de faire un sp_setapprole après chaque
ouverture de connexion sinon ton rôle ne sera jamais déclenché et aucune
restriction ne sera effective. Tu pour faire des selects autant que tu
veux
sur les objets de ta bb ça passera. Sauf si tu as un rôle server.

Juste pour conclure, lorsque c'est une application maison, on peut
toujours
restreindre les droits au niveau interface utilisateur avec dans rôle
stocks
dans une bd sql pour affiner les droits d'accès. Mais lorsque c'est une
application tierce( Access ou Excel). L'accès bd ne peut pas être géré
lorsqu'un utilisateur a déjà accès à cette même bd.

Ce rôle que je demande, il est utile et sera utile. Avec des outils aussi
ouverts que ceux de MSSoft, le besoin s'en fait sentir.
Nous, développeurs, voulons pourvoir controller l'accès à une bd en
fonction
du type client.
Le problème ne vient pas de ce que nous codons. Mais il vient du fait que
les applis MS n'offrent pas certains possibilités pour mieux restreindre
les
droits dans ce type de contexte. Non pas qu'elles ne sont pas sécurisées.
Maisdans un certain contexte on se heurte à la problématique que j'ai
expliqué un peu plus haut.
Pour palier à ce problème, il faut qu'on ait la possibilité de gérer la
sécurité en associant un rôle à une application donnée.
Le test a été également effecté avec des roles dans une table sql pour
afficner les droits cela répond pas à ma problèmetque. Dans mon cas précis
cela ne fonctionne pas! Mon problème c'est toujours Access.

Espérant avoir été assez clair.
Merci pour ta réponse et j'espère ne pas avoir été trop long dans ce post.

AB



"Med Bouchenafa" a écrit :

Le rôle d'application a été créé pour répondre exactement à ta
problématique
et il est inutile d'attendre SQL Server 2005 pour le résoudre
Il faut distinguer entre compte login et compte utilisateur
Le premier permet d'acceder à SQL Server et le second permet d'acceder à
une
base de données

On peut avoir un login (Windows ou SQL Server) et ne pas pouvoir utiliser
une base de données si l'on a pas de compte utilisateur associé.
Pour pouvoir utiliser une base, il faut que le login possède un compte
d'utilisateur dans la base.
Si tes utlisateurs n'ont pas de comptes utilisateurs dans cette base, ils
ne
pourront pas l'utiliser même s'ils possèdent un login le permettant une
authentification Windows
Qu'ils utilisent ACCESS ou n'importe quel autre outil, il ne feront que
se
connecter au serveur et ne pourront jamais faire quoi que ce soit sur ta
base sauf par l'intermédiaire d'un rôle d'application que tu auras créé
au
préalable


--
Bien cordialement
Med Bouchenafa



"AB" <AB@discussions.microsoft.com> a écrit dans le message de news:
C3785FF7-D7D4-43CD-B5BC-0F297161ADA0@microsoft.com...
> Bonjour,
>
> L'utilisation du role applicatif ne peut se faire sans une connection
> au
> préalable.
> Il faut d'abord se connecter et ensuite réduire ou étendre les droits
> avec
> le rôle applicatif.
> Sans connexion l'activation du rôle applicatif ne peut se faire via
> l'interface utilisateur.
> Comme, il est dit dans un de mes posts, ce n'est pas tellement mes
> applications VB qui posent problème. C'est Access. Une même personne
> qui
> accède via une appli Vb, l'accès doit lui pouvoir être refusé pour une
> autre
> application pour une même base.
> Avec l'autentification windows, l'interdiction ne peut se faire lorsque
> cette personne utilise Access (Au niveau d'accès je n'ai pas d'applis,
> juste
> une base de données et des tables liées). Le rôle application n'est
> utile
> que
> lorsqu'il peut être activé via le code. Comme aucun code ne peut être
> activé
> via Access, aucun rôle applicatif n'est actif. Laisser l'accès à un
> utilisateur expérimenté, le droit de voir les données de production à
> partir
> d'une table Access, C'est extrêment dangereux. Une erreur de
> manipulation
> est
> vite arrivée.
>
> L'avantage avec une autentification windows, c'est qu'il y a qu'un seul
> compte (SSO = Single Sign On) Une autentification unique pour toutes
> les
> applis. Le désavantage:
> Il n'y a pas de distinction, au niveau gestion de la sécurité bd,
> entre
> deux applications qui utilise un même login.
> Qu'on vient d'une application VB ou d'une application ASP.NET, si
> l'utilisateur à un même login, le serveur sql ne sait pas faire la
> différence
> ou la distinction entre ces deux applications. Pour Sql Server, ce sont
> des
> reqûtes qui viennent du même login.
> En fait il sait faire la difference entre les applications mais la
> gestion
> de la sécurité n'est pas gérée aussi finiment qu'on le voudrait. Cela
> ne
> remet pas en cause le principe de fonctionnement de Sql Server. Il
> réponds
> à
> pas mal de problèmatique. Mais dans mon contexte, et je pense dans le
> contexte d'autres entreprises, cela devient urgent de pourvoir gérer un
> vrai
> rôle applicatif au niveau du serveur qui serait basé sur le principe
> suivant:
> Grâce à un role applicatif server(qui serait à créer), pour un même
> compte,
> en fonction d l'application, autoriser ou pas le compte à accéder à la
> même
> bd.
>
> Qui s'est peut être que Microsoft l'a prévu pour sql2005 ou en prendra
> en
> compte dans ces prochains SP pour sql2k et sql2005
>
> En tous cas cela faciliterait bien les choses à pas mal de développeur
> et
> DBA
>
> Merci à tous.
> AB
>
> "bruno reiter [MVP]" a écrit :
>
>> Je ne suis pas sur que ça aide, mais si l'utilisateur n'a aucun droit
>> et
>> que
>> le role applicatif a les droits, l'utilisateur ne pourra accéder que
>> par
>> l'appli, et si le role n'a pas été activé, l'utilisateur se trouve
>> sans
>> droits, ça oblige a maintenir l'appli à jour.
>>
>> br
>>
>> "AB" <AB@discussions.microsoft.com> wrote in message
>> news:0148BA31-CFDA-477F-8136-95554471E65F@microsoft.com...
>> > Bonjour,
>> > Merci pour ta réponse. Mais cela ne me convient pas.
>> > Le sp_addapprole n'est efficace que lorsqu'il est activé par code et
>> > dans
>> > un
>> > contexte d'exécution propre à une application.
>> > De façon shématique, on crée un rôle application au niveau sql.
>> > Ensuite,
>> > au
>> > niveau application, l'application se connecte. Ensuite, faire un
>> > sp_setapprole pour activé le rôle via le code applicatif juste après
>> > s'être
>> > connecté. Si l'activation est oubliée le rôle application n'a aucune
>> > utilité
>> > puisque la bd peut être intérrogée sans aucun problème. Et le
>> > problème
>> > se
>> > trouve là.
>> > Lorsqu'une personne utilise access brut (bd vide) pour liée des
>> > tables.
>> > Elle
>> > peut se connecter sans aucun problème. Le rôle applicatif n'a aucune
>> > efficacité. Il n'empêche en rien les gens de se connecter. Alors que
>> > le
>> > contraire aurait été le bienvenue. Le fonctinnement suivant aurait
>> > été
>> > plus
>> > efficace. Lorsqu'il y a un role applicatif. Aucune application ne
>> > peut
>> > intérroger la bd sauf celles qui activent le role application via le
>> > code.
>> > ou
>> > alors le role application doit être associé à une application au
>> > niveau
>> > du
>> > serveur sql. Et lorsqu'une application se connecte si elle ne fait
>> > pas
>> > partie
>> > de ce role l'autorisation lui ait refusé.
>> >
>> >
>> > Le problème reste ouvert!
>> > Merci pour vos réponses.
>> >
>> > AB
>> >
>> > "Med Bouchenafa" a écrit :
>> >
>> >> As tu investigué les roles d'application.
>> >> Regarde sp_addapprole dans l'Aide En Ligne
>> >>
>> >> --
>> >> Bien cordialement
>> >> Med Bouchenafa
>> >>
>> >> "AB" <AB@discussions.microsoft.com> a écrit dans le message de
>> >> news:
>> >> F8586490-78D0-4832-8C2E-0DC92B852C78@microsoft.com...
>> >> > Bonjour à tous,
>> >> >
>> >> > Est-ce quelqu'un sait comment limiter les accès d'une
>> >> > application,
>> >> > type
>> >> > access d'accèder via odbc.
>> >> > Voici le contexte. Les utilisateurs travaillent avec des applis
>> >> > vb 6
>> >> > et
>> >> > aspnet. L'accès aux serverus se fait via les logins windows.
>> >> > Chaque
>> >> > utilisateur a accès en lecture ecriture sur les bases de données.
>> >> > Jusqu'à
>> >> > là.
>> >> > Tout est sécrurisé. Aucun utilisateur n'accède directement à la
>> >> > BD.
>> >> > Puisque
>> >> > le frontal VB 6 ou aspnet permet ce verrouillage. Par contre,
>> >> > dans
>> >> > l'entreprise certains utilisateurs ont access d'installé sur leur
>> >> > machine,
>> >> > save manipuler les DSN, en créent et accèdent directement aux
>> >> > bases
>> >> > grâce
>> >> > à
>> >> > l'autentification intégrée windows. Pas de mot passe à tapper, un
>> >> > seul
>> >> > lien
>> >> > odbc et l'accès est possible aux bases de productions. Il est
>> >> > impossible
>> >> > de
>> >> > leur supprimer access de leur machine pour des raisons
>> >> > d'exploitations.
>> >> > L'object de ce post est comment faire pour refuser l'accès aux
>> >> > bases
>> >> > de
>> >> > productions à cet utilisateur lorsqu'il vient d'une base access
>> >> > tout
>> >> > en
>> >> > lui
>> >> > laissant l'accès via les applis vb6 et aspnet.
>> >> > Passer tout en autentification sql n'est pas possible car les
>> >> > applis
>> >> > vb6
>> >> > et
>> >> > aspnet gèrent des rôles applicatifs basés sur le login windows.
>> >> > Pour
>> >> > mémoire
>> >> > un rôle applicatif est rôle qui permet l'accès ou pas à certaines
>> >> > régions
>> >> > de
>> >> > l'appli pour un utilisateur donné. Le rôle applicatif est
>> >> > différent
>> >> > du
>> >> > rôle
>> >> > base de donnée qui,lui, a pour fonction de gérer les objects bd.
>> >> > Ces
>> >> > deux
>> >> > rôles sont compléméntaires.
>> >> >
>> >> > l'idéal serait d'associer le nom d'une application à un rôle db.
>> >> > De
>> >> > cette
>> >> > façon lorsque la personne se connecte via une appli bv6, elle y
>> >> > sera
>> >> > autorisée. Par contre si elle se connecte avec access l'accès lui
>> >> > sera
>> >> > refusée.
>> >> > Je ne pense pas que cela est possible dans la version sql2k.
>> >> >
>> >> > Parcontre, y'a-t-il une possibilité de modifier la procédure
>> >> > systeme
>> >> > qui
>> >> > permet de vérifier les connexions? Je sais cela pourrait
>> >> > destabiliser
>> >> > le
>> >> > système mais fait d'une façon réfléchie cela ne poserait aucun
>> >> > problème.
>> >> > Le scénario serait le suivant:
>> >> > Pour un rôle donné appartenant à une db lui associer un ou
>> >> > plusieurs
>> >> > noms
>> >> > d'applications. Lorsque l'utilisateur se connecte, en supposant
>> >> > que
>> >> > la
>> >> > routine de vérification des autorisations puisse être modifiée,
>> >> > lorsque
>> >> > sql
>> >> > vérifie les autorisations d'accès aux objects au préalable il
>> >> > doit
>> >> > vérifier
>> >> > sil'application est autorisé ou pas à accèder à la base de
>> >> > données
>> >> > en
>> >> > question.
>> >> >
>> >> > Cela serait très utiles dans l'avenir. Avec office 2003,
>> >> > l'utilisateur
>> >> > peut
>> >> > attaquer une une bd très facilement. L'autentification windows et
>> >> > les
>> >> > rôles
>> >> > bd + rôle applicatifs ne sont plus suffisant. Gérer la sécurité
>> >> > avec
>> >> > des
>> >> > outils qui permettent un accès très facile aux bds n'est plus
>> >> > très
>> >> > efficace
>> >> > lorsque nous utilisons l'autentification windows. Pouvoir
>> >> > associer
>> >> > le
>> >> > nom
>> >> > d'une application cliente à un rôle bd palierait à ce problème.
>> >> >
>> >> > Cela fait beaucoup de questions, merci pour vos réponses et pour
>> >> > votre
>> >> > patience.
>> >> > Juste une dernière question. Si quelqu'un sait quelle est la nom
>> >> > de
>> >> > la
>> >> > procédure système qui permet de checker les roles bd lors de la
>> >> > connexion
>> >> > d'une application cliente je lui serais très reconnaissant.
>> >> >
>> >> > Encore merci
>> >> >
>> >> > AB
>> >>
>> >>
>> >>
>>
>>
>>

Bonjour,
J'ai suivi méthodiquement ce que tu me préconises.
J'ai même changé de serveur pour refaire mes tests car sur ma machine j'y
avais toujours accès avec Access et avec mon application.
Une chose que tu as bien remarqué. Elle concerne les rôles db_denydatareader
et db_denydatawriter. Il est vrai qu'ilsn'ont pas été ajouté à l'utilisateur
A.

Sur le serveur Sql réseau, les droits de mon compte ont été supprimés.
Ensuite, Une connexion pour mon compte à été ajoutée. Les rôles suivants ont
été affectés db_denydatareader et db_denydatawriter. Un rôle applicatif RLE a
été créé. Les rôles db_denydatareader et db_denydatawriter lui ont été
affectés. Ce Rôle RLE n'a pas l'autorisation de faire un select sur la table
catégories de Northwind.
L'appli vb.net se connecte au serveur sql réseau, active le rôle RLE.
Résulat: Message d'erreur :"Autorisation Select refusée sur l'objet
'Catégories', bd Northwind. Propriétaire 'dbo'. Jusque là Ok! L'activation du
rôle a bien fonctionné!
Lançant Access, créant un DSN vers Northwind se trouvant sur le serveur sql
réseau. Gardant les même restrictions: Liant la table 'catégories'.
Résultat: La table 'catégories' est liée et est accessible en lecture
ecriture.
Modifiant une donnée dans cette table. Chose faite.Les modifications de
données ont été acceptées. Avec l'appli vb.net, refaire un select et là
toujours le même message "Autorisation select refusé ..."
Continuant les tests.
Je ressors de l'application, le sp_addapprole est commenté i.e. qu'il ne
sera pas exécuté par l'application vb.net. On refait le test dans les mêmes
conditions rien n'a été changé sauf le role RLE qui n'est plus activé.
Resultat: Et bien je récupère bien les données de la tables 'catégories' et
je récupère bien les données qui ont été modifiées alors que je suis en
denyreader et denywriter et mon role RLE est interdit de select sur la table
catégories. D'accord il n'est pas activé mais le db_denydatareader et
db_denydatawriter aurait, théoriquement joués leur rôle.

Voici la configuration machine cliente et serveur
Cleint:
Win XP + VS. NET2003 + access 2002
Serveur:
Win Server 2003 + Sql2k + SP3a

Même si cette solution marcherait, visiblement ce n'est pas le cas
puisqu'elle autorise Access à se connecter à la bd et en plus on peut faire
des modifications, l'investissement pour modifier toutes les applications se
chiffre en mois. Donc cette solution n'est viable du tout. Même si sur le
principe elle pourrait fonctionner.

Mon problème reste entier puique Access y accède toujours à la bd en
modification.

Merci pour ton aide et ta patience.
Cordialement
AB



"Med Bouchenafa" a écrit :

Ok, allons-y pas à pas et on va voir où ça coince

Prenons la cas de ton utisateurA
Ajoute le dans les roles db_denydatareader et db_denydatawriter
Met ton role RLE dans les roles db_datareader et db_datawriter
Refais tes tests

Que ce soit ACCESS ou ton application, ton utilisateurA n'a plus aucun droit
de lecture/Ecriture
Il faut qu'il active le rôle d'application RLE pour le faire.
Est ce que c'est ce que tu veux?

--
Bien cordialement
Med Bouchenafa




"AB" <AB@discussions.microsoft.com> a écrit dans le message de news:
89753743-3BA7-472F-A105-8BAEA99DACD6@microsoft.com...
> Non il ne répond pas du tout à ma problématique.
> Je pense que, premiè-rement ma problématique n'est pas comprise et secondo
> tu confonds le principe de fonctionnement d'un rôle applicatifs avec un
> rôle
> avec le role bd.
> Au niveau de sql server, nous avons 3 type de roles:
> 1 - Roles serveur (Rôle fixe : db_ower, etc..)
> 2 - Rôle bd ( autorisations au niveau de l'object) Rôle que tu associe à
> ta
> connexion sql server.
> 3 - Rôle application (Rôle avec un mot de passe: Droit également sur les
> objets)
>
> tu es obligé d'activer le rôle applicatif pour une connexion pour qu'il
> soit
> valide sinon il n'est pas pris en compte.
>
> Voici le test à effectuer si tru veux en avoir le coeur net.
>
> J'ai fais le test suivant:
>
> J'ai un utilisateur A qui est en datareader datawriter sur un serveur sql
> réseau,
> un rôle applicatif RLE avec son mot de passe XXX. le Role RLE interdit le
> select sur la table authors dans la bd Pubs
> une appli vb.net. Son fonctionnement est simple je me connecte à la bd je
> fais un select et je l'affiche dans un grille.
>
> plusieurs scénarii:
> 1 - connexion à la base B
> 2 - Pas d'activation de Rôle application avec sp_setapprole
> 3 - select table authors dans pubs
> 4- récup résultats et affichage
> 5 - Tout est ok affichage du résultat. Aucune restriction. LE role n'est
> même pas intervenu dans mon fragement de code ni a été déclaenché par sql
> server.
> Et c'est puisque nous l'avons pas activé avec sp_setapprole.
>
> Ce scébnarion fonctionne, le rôle application le serveur s'en fiche. Il ne
> sait même pas à quel compte l'associer et en plus il n'est pas actif.
>
> scénarion II
> 1 - connexion à la base B
> 2 - Activation du Rôle applicatif "RLE" avec sp_setapprole
> 3 - select table authors dans pubs
> ==> Et la erreur: Pas le droit select sur la base.
> Ce role ne remplit son role que dans un contexte de connexion client et
> que
> lorsqu'il est activé sinon cela ne fonctinne pas.
>
> Je suis toujours l'utilisateur A
> maintenant je lance Access, je crée un DSN sur ma Base B ( pour mémoire le
> compte y est déclaré puisque je fait des select sur ma table authors. Je
> suis
> toujours avec le Role RLE qui interdit le select sur authors de la BD
> Pubs.
> J'arrive sans aucun problème à lier des tables et à enter en modification
> des données.
>
> Le problème du Role application c'est que tant que il n'est pas activé
> pour
> une connexion donnée, il ne sont pas valide. Il n'est pas pris en compte
> par
> Sql server
>
> Fait un autre test:
> prend scénario II. Cette fois-ci tu laisses la connexion ouverte et tu en
> ouvre une autre pour faire un select sur la même table (authors). Je te
> laisse deviner les choses.
> Et bien ça passe. On peut faitre un select sur la table authors lorsqu'on
> passe par une autre connexion. dans le même code.
> Il est noté en clair dans la doc de microsoft que ce rôle n'est valable
> que
> pour une connexion ouverte ayant activé le rôle sinon walow. le rôle
> applicatif n'est pas déclenché. A chaque fois qu'une connexion est ouverte
> tu
> DOIS faire un sp_setapprole si tu veux que ton role soit pris en compte
> par
> ton serveur tu n'as aucun choix que de faire un sp_setapprole après chaque
> ouverture de connexion sinon ton rôle ne sera jamais déclenché et aucune
> restriction ne sera effective. Tu pour faire des selects autant que tu
> veux
> sur les objets de ta bb ça passera. Sauf si tu as un rôle server.
>
> Juste pour conclure, lorsque c'est une application maison, on peut
> toujours
> restreindre les droits au niveau interface utilisateur avec dans rôle
> stocks
> dans une bd sql pour affiner les droits d'accès. Mais lorsque c'est une
> application tierce( Access ou Excel). L'accès bd ne peut pas être géré
> lorsqu'un utilisateur a déjà accès à cette même bd.
>
> Ce rôle que je demande, il est utile et sera utile. Avec des outils aussi
> ouverts que ceux de MSSoft, le besoin s'en fait sentir.
> Nous, développeurs, voulons pourvoir controller l'accès à une bd en
> fonction
> du type client.
> Le problème ne vient pas de ce que nous codons. Mais il vient du fait que
> les applis MS n'offrent pas certains possibilités pour mieux restreindre
> les
> droits dans ce type de contexte. Non pas qu'elles ne sont pas sécurisées.
> Maisdans un certain contexte on se heurte à la problématique que j'ai
> expliqué un peu plus haut.
> Pour palier à ce problème, il faut qu'on ait la possibilité de gérer la
> sécurité en associant un rôle à une application donnée.
> Le test a été également effecté avec des roles dans une table sql pour
> afficner les droits cela répond pas à ma problèmetque. Dans mon cas précis
> cela ne fonctionne pas! Mon problème c'est toujours Access.
>
> Espérant avoir été assez clair.
> Merci pour ta réponse et j'espère ne pas avoir été trop long dans ce post.
>
> AB
>
>
>
> "Med Bouchenafa" a écrit :
>
>> Le rôle d'application a été créé pour répondre exactement à ta
>> problématique
>> et il est inutile d'attendre SQL Server 2005 pour le résoudre
>> Il faut distinguer entre compte login et compte utilisateur
>> Le premier permet d'acceder à SQL Server et le second permet d'acceder à
>> une
>> base de données
>>
>> On peut avoir un login (Windows ou SQL Server) et ne pas pouvoir utiliser
>> une base de données si l'on a pas de compte utilisateur associé.
>> Pour pouvoir utiliser une base, il faut que le login possède un compte
>> d'utilisateur dans la base.
>> Si tes utlisateurs n'ont pas de comptes utilisateurs dans cette base, ils
>> ne
>> pourront pas l'utiliser même s'ils possèdent un login le permettant une
>> authentification Windows
>> Qu'ils utilisent ACCESS ou n'importe quel autre outil, il ne feront que
>> se
>> connecter au serveur et ne pourront jamais faire quoi que ce soit sur ta
>> base sauf par l'intermédiaire d'un rôle d'application que tu auras créé
>> au
>> préalable
>>
>>
>> --
>> Bien cordialement
>> Med Bouchenafa
>>
>>
>>
>> "AB" <AB@discussions.microsoft.com> a écrit dans le message de news:
>> C3785FF7-D7D4-43CD-B5BC-0F297161ADA0@microsoft.com...
>> > Bonjour,
>> >
>> > L'utilisation du role applicatif ne peut se faire sans une connection
>> > au
>> > préalable.
>> > Il faut d'abord se connecter et ensuite réduire ou étendre les droits
>> > avec
>> > le rôle applicatif.
>> > Sans connexion l'activation du rôle applicatif ne peut se faire via
>> > l'interface utilisateur.
>> > Comme, il est dit dans un de mes posts, ce n'est pas tellement mes
>> > applications VB qui posent problème. C'est Access. Une même personne
>> > qui
>> > accède via une appli Vb, l'accès doit lui pouvoir être refusé pour une
>> > autre
>> > application pour une même base.
>> > Avec l'autentification windows, l'interdiction ne peut se faire lorsque
>> > cette personne utilise Access (Au niveau d'accès je n'ai pas d'applis,
>> > juste
>> > une base de données et des tables liées). Le rôle application n'est
>> > utile
>> > que
>> > lorsqu'il peut être activé via le code. Comme aucun code ne peut être
>> > activé
>> > via Access, aucun rôle applicatif n'est actif. Laisser l'accès à un
>> > utilisateur expérimenté, le droit de voir les données de production à
>> > partir
>> > d'une table Access, C'est extrêment dangereux. Une erreur de
>> > manipulation
>> > est
>> > vite arrivée.
>> >
>> > L'avantage avec une autentification windows, c'est qu'il y a qu'un seul
>> > compte (SSO = Single Sign On) Une autentification unique pour toutes
>> > les
>> > applis. Le désavantage:
>> > Il n'y a pas de distinction, au niveau gestion de la sécurité bd,
>> > entre
>> > deux applications qui utilise un même login.
>> > Qu'on vient d'une application VB ou d'une application ASP.NET, si
>> > l'utilisateur à un même login, le serveur sql ne sait pas faire la
>> > différence
>> > ou la distinction entre ces deux applications. Pour Sql Server, ce sont
>> > des
>> > reqûtes qui viennent du même login.
>> > En fait il sait faire la difference entre les applications mais la
>> > gestion
>> > de la sécurité n'est pas gérée aussi finiment qu'on le voudrait. Cela
>> > ne
>> > remet pas en cause le principe de fonctionnement de Sql Server. Il
>> > réponds
>> > à
>> > pas mal de problèmatique. Mais dans mon contexte, et je pense dans le
>> > contexte d'autres entreprises, cela devient urgent de pourvoir gérer un
>> > vrai
>> > rôle applicatif au niveau du serveur qui serait basé sur le principe
>> > suivant:
>> > Grâce à un role applicatif server(qui serait à créer), pour un même
>> > compte,
>> > en fonction d l'application, autoriser ou pas le compte à accéder à la
>> > même
>> > bd.
>> >
>> > Qui s'est peut être que Microsoft l'a prévu pour sql2005 ou en prendra
>> > en
>> > compte dans ces prochains SP pour sql2k et sql2005
>> >
>> > En tous cas cela faciliterait bien les choses à pas mal de développeur
>> > et
>> > DBA
>> >
>> > Merci à tous.
>> > AB
>> >
>> > "bruno reiter [MVP]" a écrit :
>> >
>> >> Je ne suis pas sur que ça aide, mais si l'utilisateur n'a aucun droit
>> >> et
>> >> que
>> >> le role applicatif a les droits, l'utilisateur ne pourra accéder que
>> >> par
>> >> l'appli, et si le role n'a pas été activé, l'utilisateur se trouve
>> >> sans
>> >> droits, ça oblige a maintenir l'appli à jour.
>> >>
>> >> br
>> >>
>> >> "AB" <AB@discussions.microsoft.com> wrote in message
>> >> news:0148BA31-CFDA-477F-8136-95554471E65F@microsoft.com...
>> >> > Bonjour,
>> >> > Merci pour ta réponse. Mais cela ne me convient pas.
>> >> > Le sp_addapprole n'est efficace que lorsqu'il est activé par code et
>> >> > dans
>> >> > un
>> >> > contexte d'exécution propre à une application.
>> >> > De façon shématique, on crée un rôle application au niveau sql.
>> >> > Ensuite,
>> >> > au
>> >> > niveau application, l'application se connecte. Ensuite, faire un
>> >> > sp_setapprole pour activé le rôle via le code applicatif juste après
>> >> > s'être
>> >> > connecté. Si l'activation est oubliée le rôle application n'a aucune
>> >> > utilité
>> >> > puisque la bd peut être intérrogée sans aucun problème. Et le
>> >> > problème
>> >> > se
>> >> > trouve là.
>> >> > Lorsqu'une personne utilise access brut (bd vide) pour liée des
>> >> > tables.
>> >> > Elle
>> >> > peut se connecter sans aucun problème. Le rôle applicatif n'a aucune
>> >> > efficacité. Il n'empêche en rien les gens de se connecter. Alors que
>> >> > le
>> >> > contraire aurait été le bienvenue. Le fonctinnement suivant aurait
>> >> > été
>> >> > plus
>> >> > efficace. Lorsqu'il y a un role applicatif. Aucune application ne
>> >> > peut
>> >> > intérroger la bd sauf celles qui activent le role application via le
>> >> > code.
>> >> > ou
>> >> > alors le role application doit être associé à une application au
>> >> > niveau
>> >> > du
>> >> > serveur sql. Et lorsqu'une application se connecte si elle ne fait
>> >> > pas
>> >> > partie
>> >> > de ce role l'autorisation lui ait refusé.
>> >> >