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" a écrit dans le message de news:
>
> > 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,
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" a écrit dans le message de news:
>
> > 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" a écrit dans le message de news:
>
> > 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" a écrit dans le message de news:
> >>
> >> > 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" wrote in message
> >> >> news:
> >> >> > 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é.
> >> >> >
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é.
> >> >> >
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" a écrit dans le message de news:
>
> > 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" a écrit dans le message de news:
> >>
> >> > 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" wrote in message
> >> >> news:
> >> >> > 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é.
> >> >> >
Bonjour,
Je ne comprend pas lorsque tu dis :
"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à."
Tu fais un deny pour l'utilisateur sur les objets adéquats
Tu donnes les droits à l'application role sur les objets adéquats
Si tu ne connais pas le mot de passe de l'application role ou si tu ne
l'active pas via ton ou tes applications ton utilisateur n'a pas les droits
sur les objets adéquats.
Cordialement,
LionelP
"AB" a écrit :
> 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" a écrit dans le message de news:
> >
> > > 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,
Je ne comprend pas lorsque tu dis :
"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à."
Tu fais un deny pour l'utilisateur sur les objets adéquats
Tu donnes les droits à l'application role sur les objets adéquats
Si tu ne connais pas le mot de passe de l'application role ou si tu ne
l'active pas via ton ou tes applications ton utilisateur n'a pas les droits
sur les objets adéquats.
Cordialement,
LionelP
"AB" a écrit :
> 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,
Je ne comprend pas lorsque tu dis :
"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à."
Tu fais un deny pour l'utilisateur sur les objets adéquats
Tu donnes les droits à l'application role sur les objets adéquats
Si tu ne connais pas le mot de passe de l'application role ou si tu ne
l'active pas via ton ou tes applications ton utilisateur n'a pas les droits
sur les objets adéquats.
Cordialement,
LionelP
"AB" a écrit :
> 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" a écrit dans le message de news:
> >
> > > 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,
Théoriquement cela devait marcher. i.e. l'utilisateur devrait être rejeté
par sql server puisqu'il n'a pas activé le role application et n'a pas le
de passe de ce dernier. Passant par tous les frontaux vb, l'utilisateur
rejeté si le rôle n'est pas activé.
Lorsque le rôle est activé, l'utilisateur accède à la bd mais le select
une table en particulier lui est refusé.
Sur la même bd, alors que l'utilisateur est en denyreader denywriter et
activé le rôle application, l'accès lui est autorisé lorsqu'il ouvre la
via Access en tant que table liée.
Normalement, il ne le devrait pas puisqu'il n'a pas activé le rôle
application. Non seulement il y arrive à y accéder mais il peut modifier
données de la table sur laquelle il est refusé en select. Le role
à aucun moment n'est activé ou saisi par l'utilisateur.
Le test a été refait en lançant l'application vb et le fichier Access en
même temps.
pour l'application VB, le refus est manifesté dans un message d'erreur.
contre pour la table liée ouverte sur la table en question. Le refus n'est
pas opéré.
J'ai bien vérifié que j'attaquais la bonne table dans la bonne bd sur
laquelle j'étais en refus total(pas de select ni insert ni update).
Accès toujours en full modification sur cette table via Access table liée.
Merci
Cordialement
AB
"" a écrit :
> Bonjour,
>
> Je ne comprend pas lorsque tu dis :
> "Si l'activation est oubliée le rôle application n'a aucune utilité
> la bd peut être intérrogée sans aucun problème. Et le problème se trouve
>
> Tu fais un deny pour l'utilisateur sur les objets adéquats
> Tu donnes les droits à l'application role sur les objets adéquats
> Si tu ne connais pas le mot de passe de l'application role ou si tu ne
> l'active pas via ton ou tes applications ton utilisateur n'a pas les
> sur les objets adéquats.
>
> Cordialement,
> LionelP
>
>
> "AB" a écrit :
>
> > 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
> > contexte d'exécution propre à une application.
> > De façon shématique, on crée un rôle application au niveau sql.
> > niveau application, l'application se connecte. Ensuite, faire un
> > sp_setapprole pour activé le rôle via le code applicatif juste après
> > connecté. Si l'activation est oubliée le rôle application n'a aucune
> > puisque la bd peut être intérrogée sans aucun problème. Et le problème
> > trouve là.
> > Lorsqu'une personne utilise access brut (bd vide) pour liée des
> > 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
> > contraire aurait été le bienvenue. Le fonctinnement suivant aurait été
> > 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
> > alors le role application doit être associé à une application au
> > serveur sql. Et lorsqu'une application se connecte si elle ne fait pas
> > 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" a écrit dans le message de news:
> > >
> > > > Bonjour à tous,
> > > >
> > > > Est-ce quelqu'un sait comment limiter les accès d'une application,
> > > > access d'accèder via odbc.
> > > > Voici le contexte. Les utilisateurs travaillent avec des applis vb
> > > > aspnet. L'accès aux serverus se fait via les logins windows.
> > > > utilisateur a accès en lecture ecriture sur les bases de données.
> > > > là.
> > > > Tout est sécrurisé. Aucun utilisateur n'accède directement à la
> > > > Puisque
> > > > le frontal VB 6 ou aspnet permet ce verrouillage. Par contre, dans
> > > > l'entreprise certains utilisateurs ont access d'installé sur leur
> > > > save manipuler les DSN, en créent et accèdent directement aux
> > > > à
> > > > l'autentification intégrée windows. Pas de mot passe à tapper, un
> > > > lien
> > > > odbc et l'accès est possible aux bases de productions. Il est
> > > > de
> > > > leur supprimer access de leur machine pour des raisons
> > > > L'object de ce post est comment faire pour refuser l'accès aux
> > > > productions à cet utilisateur lorsqu'il vient d'une base access
> > > > lui
> > > > laissant l'accès via les applis vb6 et aspnet.
> > > > Passer tout en autentification sql n'est pas possible car les
> > > > et
> > > > aspnet gèrent des rôles applicatifs basés sur le login windows.
> > > > mémoire
> > > > un rôle applicatif est rôle qui permet l'accès ou pas à certaines
> > > > de
> > > > l'appli pour un utilisateur donné. Le rôle applicatif est
> > > > rôle
> > > > base de donnée qui,lui, a pour fonction de gérer les objects bd.
> > > > rôles sont compléméntaires.
> > > >
> > > > l'idéal serait d'associer le nom d'une application à un rôle db.
> > > > façon lorsque la personne se connecte via une appli bv6, elle y
> > > > autorisée. Par contre si elle se connecte avec access l'accès lui
> > > > 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
> > > > permet de vérifier les connexions? Je sais cela pourrait
> > > > système mais fait d'une façon réfléchie cela ne poserait aucun
> > > > Le scénario serait le suivant:
> > > > Pour un rôle donné appartenant à une db lui associer un ou
> > > > d'applications. Lorsque l'utilisateur se connecte, en supposant
> > > > routine de vérification des autorisations puisse être modifiée,
> > > > 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
> > > > question.
> > > >
> > > > Cela serait très utiles dans l'avenir. Avec office 2003,
> > > > peut
> > > > attaquer une une bd très facilement. L'autentification windows et
> > > > rôles
> > > > bd + rôle applicatifs ne sont plus suffisant. Gérer la sécurité
> > > > 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
> > > > d'une application cliente à un rôle bd palierait à ce problème.
> > > >
> > > > Cela fait beaucoup de questions, merci pour vos réponses et pour
> > > > patience.
> > > > Juste une dernière question. Si quelqu'un sait quelle est la nom
> > > > procédure système qui permet de checker les roles bd lors de la
> > > > d'une application cliente je lui serais très reconnaissant.
> > > >
> > > > Encore merci
> > > >
> > > > AB
> > >
> > >
> > >
Bonjour,
Théoriquement cela devait marcher. i.e. l'utilisateur devrait être rejeté
par sql server puisqu'il n'a pas activé le role application et n'a pas le
de passe de ce dernier. Passant par tous les frontaux vb, l'utilisateur
rejeté si le rôle n'est pas activé.
Lorsque le rôle est activé, l'utilisateur accède à la bd mais le select
une table en particulier lui est refusé.
Sur la même bd, alors que l'utilisateur est en denyreader denywriter et
activé le rôle application, l'accès lui est autorisé lorsqu'il ouvre la
via Access en tant que table liée.
Normalement, il ne le devrait pas puisqu'il n'a pas activé le rôle
application. Non seulement il y arrive à y accéder mais il peut modifier
données de la table sur laquelle il est refusé en select. Le role
à aucun moment n'est activé ou saisi par l'utilisateur.
Le test a été refait en lançant l'application vb et le fichier Access en
même temps.
pour l'application VB, le refus est manifesté dans un message d'erreur.
contre pour la table liée ouverte sur la table en question. Le refus n'est
pas opéré.
J'ai bien vérifié que j'attaquais la bonne table dans la bonne bd sur
laquelle j'étais en refus total(pas de select ni insert ni update).
Accès toujours en full modification sur cette table via Access table liée.
Merci
Cordialement
AB
"lionelp@online.microsoft.com" a écrit :
> Bonjour,
>
> Je ne comprend pas lorsque tu dis :
> "Si l'activation est oubliée le rôle application n'a aucune utilité
> la bd peut être intérrogée sans aucun problème. Et le problème se trouve
>
> Tu fais un deny pour l'utilisateur sur les objets adéquats
> Tu donnes les droits à l'application role sur les objets adéquats
> Si tu ne connais pas le mot de passe de l'application role ou si tu ne
> l'active pas via ton ou tes applications ton utilisateur n'a pas les
> sur les objets adéquats.
>
> Cordialement,
> LionelP
>
>
> "AB" a écrit :
>
> > 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
> > contexte d'exécution propre à une application.
> > De façon shématique, on crée un rôle application au niveau sql.
> > niveau application, l'application se connecte. Ensuite, faire un
> > sp_setapprole pour activé le rôle via le code applicatif juste après
> > connecté. Si l'activation est oubliée le rôle application n'a aucune
> > puisque la bd peut être intérrogée sans aucun problème. Et le problème
> > trouve là.
> > Lorsqu'une personne utilise access brut (bd vide) pour liée des
> > 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
> > contraire aurait été le bienvenue. Le fonctinnement suivant aurait été
> > 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
> > alors le role application doit être associé à une application au
> > serveur sql. Et lorsqu'une application se connecte si elle ne fait pas
> > 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,
> > > > access d'accèder via odbc.
> > > > Voici le contexte. Les utilisateurs travaillent avec des applis vb
> > > > aspnet. L'accès aux serverus se fait via les logins windows.
> > > > utilisateur a accès en lecture ecriture sur les bases de données.
> > > > là.
> > > > Tout est sécrurisé. Aucun utilisateur n'accède directement à la
> > > > Puisque
> > > > le frontal VB 6 ou aspnet permet ce verrouillage. Par contre, dans
> > > > l'entreprise certains utilisateurs ont access d'installé sur leur
> > > > save manipuler les DSN, en créent et accèdent directement aux
> > > > à
> > > > l'autentification intégrée windows. Pas de mot passe à tapper, un
> > > > lien
> > > > odbc et l'accès est possible aux bases de productions. Il est
> > > > de
> > > > leur supprimer access de leur machine pour des raisons
> > > > L'object de ce post est comment faire pour refuser l'accès aux
> > > > productions à cet utilisateur lorsqu'il vient d'une base access
> > > > lui
> > > > laissant l'accès via les applis vb6 et aspnet.
> > > > Passer tout en autentification sql n'est pas possible car les
> > > > et
> > > > aspnet gèrent des rôles applicatifs basés sur le login windows.
> > > > mémoire
> > > > un rôle applicatif est rôle qui permet l'accès ou pas à certaines
> > > > de
> > > > l'appli pour un utilisateur donné. Le rôle applicatif est
> > > > rôle
> > > > base de donnée qui,lui, a pour fonction de gérer les objects bd.
> > > > rôles sont compléméntaires.
> > > >
> > > > l'idéal serait d'associer le nom d'une application à un rôle db.
> > > > façon lorsque la personne se connecte via une appli bv6, elle y
> > > > autorisée. Par contre si elle se connecte avec access l'accès lui
> > > > 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
> > > > permet de vérifier les connexions? Je sais cela pourrait
> > > > système mais fait d'une façon réfléchie cela ne poserait aucun
> > > > Le scénario serait le suivant:
> > > > Pour un rôle donné appartenant à une db lui associer un ou
> > > > d'applications. Lorsque l'utilisateur se connecte, en supposant
> > > > routine de vérification des autorisations puisse être modifiée,
> > > > 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
> > > > question.
> > > >
> > > > Cela serait très utiles dans l'avenir. Avec office 2003,
> > > > peut
> > > > attaquer une une bd très facilement. L'autentification windows et
> > > > rôles
> > > > bd + rôle applicatifs ne sont plus suffisant. Gérer la sécurité
> > > > 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
> > > > d'une application cliente à un rôle bd palierait à ce problème.
> > > >
> > > > Cela fait beaucoup de questions, merci pour vos réponses et pour
> > > > patience.
> > > > Juste une dernière question. Si quelqu'un sait quelle est la nom
> > > > procédure système qui permet de checker les roles bd lors de la
> > > > d'une application cliente je lui serais très reconnaissant.
> > > >
> > > > Encore merci
> > > >
> > > > AB
> > >
> > >
> > >
Bonjour,
Théoriquement cela devait marcher. i.e. l'utilisateur devrait être rejeté
par sql server puisqu'il n'a pas activé le role application et n'a pas le
de passe de ce dernier. Passant par tous les frontaux vb, l'utilisateur
rejeté si le rôle n'est pas activé.
Lorsque le rôle est activé, l'utilisateur accède à la bd mais le select
une table en particulier lui est refusé.
Sur la même bd, alors que l'utilisateur est en denyreader denywriter et
activé le rôle application, l'accès lui est autorisé lorsqu'il ouvre la
via Access en tant que table liée.
Normalement, il ne le devrait pas puisqu'il n'a pas activé le rôle
application. Non seulement il y arrive à y accéder mais il peut modifier
données de la table sur laquelle il est refusé en select. Le role
à aucun moment n'est activé ou saisi par l'utilisateur.
Le test a été refait en lançant l'application vb et le fichier Access en
même temps.
pour l'application VB, le refus est manifesté dans un message d'erreur.
contre pour la table liée ouverte sur la table en question. Le refus n'est
pas opéré.
J'ai bien vérifié que j'attaquais la bonne table dans la bonne bd sur
laquelle j'étais en refus total(pas de select ni insert ni update).
Accès toujours en full modification sur cette table via Access table liée.
Merci
Cordialement
AB
"" a écrit :
> Bonjour,
>
> Je ne comprend pas lorsque tu dis :
> "Si l'activation est oubliée le rôle application n'a aucune utilité
> la bd peut être intérrogée sans aucun problème. Et le problème se trouve
>
> Tu fais un deny pour l'utilisateur sur les objets adéquats
> Tu donnes les droits à l'application role sur les objets adéquats
> Si tu ne connais pas le mot de passe de l'application role ou si tu ne
> l'active pas via ton ou tes applications ton utilisateur n'a pas les
> sur les objets adéquats.
>
> Cordialement,
> LionelP
>
>
> "AB" a écrit :
>
> > 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
> > contexte d'exécution propre à une application.
> > De façon shématique, on crée un rôle application au niveau sql.
> > niveau application, l'application se connecte. Ensuite, faire un
> > sp_setapprole pour activé le rôle via le code applicatif juste après
> > connecté. Si l'activation est oubliée le rôle application n'a aucune
> > puisque la bd peut être intérrogée sans aucun problème. Et le problème
> > trouve là.
> > Lorsqu'une personne utilise access brut (bd vide) pour liée des
> > 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
> > contraire aurait été le bienvenue. Le fonctinnement suivant aurait été
> > 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
> > alors le role application doit être associé à une application au
> > serveur sql. Et lorsqu'une application se connecte si elle ne fait pas
> > 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" a écrit dans le message de news:
> > >
> > > > Bonjour à tous,
> > > >
> > > > Est-ce quelqu'un sait comment limiter les accès d'une application,
> > > > access d'accèder via odbc.
> > > > Voici le contexte. Les utilisateurs travaillent avec des applis vb
> > > > aspnet. L'accès aux serverus se fait via les logins windows.
> > > > utilisateur a accès en lecture ecriture sur les bases de données.
> > > > là.
> > > > Tout est sécrurisé. Aucun utilisateur n'accède directement à la
> > > > Puisque
> > > > le frontal VB 6 ou aspnet permet ce verrouillage. Par contre, dans
> > > > l'entreprise certains utilisateurs ont access d'installé sur leur
> > > > save manipuler les DSN, en créent et accèdent directement aux
> > > > à
> > > > l'autentification intégrée windows. Pas de mot passe à tapper, un
> > > > lien
> > > > odbc et l'accès est possible aux bases de productions. Il est
> > > > de
> > > > leur supprimer access de leur machine pour des raisons
> > > > L'object de ce post est comment faire pour refuser l'accès aux
> > > > productions à cet utilisateur lorsqu'il vient d'une base access
> > > > lui
> > > > laissant l'accès via les applis vb6 et aspnet.
> > > > Passer tout en autentification sql n'est pas possible car les
> > > > et
> > > > aspnet gèrent des rôles applicatifs basés sur le login windows.
> > > > mémoire
> > > > un rôle applicatif est rôle qui permet l'accès ou pas à certaines
> > > > de
> > > > l'appli pour un utilisateur donné. Le rôle applicatif est
> > > > rôle
> > > > base de donnée qui,lui, a pour fonction de gérer les objects bd.
> > > > rôles sont compléméntaires.
> > > >
> > > > l'idéal serait d'associer le nom d'une application à un rôle db.
> > > > façon lorsque la personne se connecte via une appli bv6, elle y
> > > > autorisée. Par contre si elle se connecte avec access l'accès lui
> > > > 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
> > > > permet de vérifier les connexions? Je sais cela pourrait
> > > > système mais fait d'une façon réfléchie cela ne poserait aucun
> > > > Le scénario serait le suivant:
> > > > Pour un rôle donné appartenant à une db lui associer un ou
> > > > d'applications. Lorsque l'utilisateur se connecte, en supposant
> > > > routine de vérification des autorisations puisse être modifiée,
> > > > 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
> > > > question.
> > > >
> > > > Cela serait très utiles dans l'avenir. Avec office 2003,
> > > > peut
> > > > attaquer une une bd très facilement. L'autentification windows et
> > > > rôles
> > > > bd + rôle applicatifs ne sont plus suffisant. Gérer la sécurité
> > > > 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
> > > > d'une application cliente à un rôle bd palierait à ce problème.
> > > >
> > > > Cela fait beaucoup de questions, merci pour vos réponses et pour
> > > > patience.
> > > > Juste une dernière question. Si quelqu'un sait quelle est la nom
> > > > procédure système qui permet de checker les roles bd lors de la
> > > > d'une application cliente je lui serais très reconnaissant.
> > > >
> > > > Encore merci
> > > >
> > > > AB
> > >
> > >
> > >
donc:
Sous quel compte Access se connecte à SQL Server ? Pour t'en assurer lance
un profiler et vois ce qui se passe, tu trouveras alors la réponse à ton
problème.
Cordialement,
LionelP
"AB" wrote in message
news:
> Bonjour,
>
> Théoriquement cela devait marcher. i.e. l'utilisateur devrait être rejeté
> par sql server puisqu'il n'a pas activé le role application et n'a pas le
mot
> de passe de ce dernier. Passant par tous les frontaux vb, l'utilisateur
est
> rejeté si le rôle n'est pas activé.
> Lorsque le rôle est activé, l'utilisateur accède à la bd mais le select
sur
> une table en particulier lui est refusé.
> Sur la même bd, alors que l'utilisateur est en denyreader denywriter et
doit
> activé le rôle application, l'accès lui est autorisé lorsqu'il ouvre la
table
> via Access en tant que table liée.
> Normalement, il ne le devrait pas puisqu'il n'a pas activé le rôle
> application. Non seulement il y arrive à y accéder mais il peut modifier
les
> données de la table sur laquelle il est refusé en select. Le role
application
> à aucun moment n'est activé ou saisi par l'utilisateur.
> Le test a été refait en lançant l'application vb et le fichier Access en
> même temps.
> pour l'application VB, le refus est manifesté dans un message d'erreur.
Par
> contre pour la table liée ouverte sur la table en question. Le refus n'est
> pas opéré.
> J'ai bien vérifié que j'attaquais la bonne table dans la bonne bd sur
> laquelle j'étais en refus total(pas de select ni insert ni update).
> Accès toujours en full modification sur cette table via Access table liée.
>
> Merci
>
> Cordialement
> AB
>
> "" a écrit :
>
> > Bonjour,
> >
> > Je ne comprend pas lorsque tu dis :
> > "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à."
> >
> > Tu fais un deny pour l'utilisateur sur les objets adéquats
> > Tu donnes les droits à l'application role sur les objets adéquats
> > Si tu ne connais pas le mot de passe de l'application role ou si tu ne
> > l'active pas via ton ou tes applications ton utilisateur n'a pas les
droits
> > sur les objets adéquats.
> >
> > Cordialement,
> > LionelP
> >
> >
> > "AB" a écrit :
> >
> > > 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" a écrit dans le message de news:
> > > >
> > > > > 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
> > > >
> > > >
> > > >
donc:
Sous quel compte Access se connecte à SQL Server ? Pour t'en assurer lance
un profiler et vois ce qui se passe, tu trouveras alors la réponse à ton
problème.
Cordialement,
LionelP
"AB" <AB@discussions.microsoft.com> wrote in message
news:6BA94926-4D21-4793-B878-39348A7155D8@microsoft.com...
> Bonjour,
>
> Théoriquement cela devait marcher. i.e. l'utilisateur devrait être rejeté
> par sql server puisqu'il n'a pas activé le role application et n'a pas le
mot
> de passe de ce dernier. Passant par tous les frontaux vb, l'utilisateur
est
> rejeté si le rôle n'est pas activé.
> Lorsque le rôle est activé, l'utilisateur accède à la bd mais le select
sur
> une table en particulier lui est refusé.
> Sur la même bd, alors que l'utilisateur est en denyreader denywriter et
doit
> activé le rôle application, l'accès lui est autorisé lorsqu'il ouvre la
table
> via Access en tant que table liée.
> Normalement, il ne le devrait pas puisqu'il n'a pas activé le rôle
> application. Non seulement il y arrive à y accéder mais il peut modifier
les
> données de la table sur laquelle il est refusé en select. Le role
application
> à aucun moment n'est activé ou saisi par l'utilisateur.
> Le test a été refait en lançant l'application vb et le fichier Access en
> même temps.
> pour l'application VB, le refus est manifesté dans un message d'erreur.
Par
> contre pour la table liée ouverte sur la table en question. Le refus n'est
> pas opéré.
> J'ai bien vérifié que j'attaquais la bonne table dans la bonne bd sur
> laquelle j'étais en refus total(pas de select ni insert ni update).
> Accès toujours en full modification sur cette table via Access table liée.
>
> Merci
>
> Cordialement
> AB
>
> "lionelp@online.microsoft.com" a écrit :
>
> > Bonjour,
> >
> > Je ne comprend pas lorsque tu dis :
> > "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à."
> >
> > Tu fais un deny pour l'utilisateur sur les objets adéquats
> > Tu donnes les droits à l'application role sur les objets adéquats
> > Si tu ne connais pas le mot de passe de l'application role ou si tu ne
> > l'active pas via ton ou tes applications ton utilisateur n'a pas les
droits
> > sur les objets adéquats.
> >
> > Cordialement,
> > LionelP
> >
> >
> > "AB" a écrit :
> >
> > > 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
> > > >
> > > >
> > > >
donc:
Sous quel compte Access se connecte à SQL Server ? Pour t'en assurer lance
un profiler et vois ce qui se passe, tu trouveras alors la réponse à ton
problème.
Cordialement,
LionelP
"AB" wrote in message
news:
> Bonjour,
>
> Théoriquement cela devait marcher. i.e. l'utilisateur devrait être rejeté
> par sql server puisqu'il n'a pas activé le role application et n'a pas le
mot
> de passe de ce dernier. Passant par tous les frontaux vb, l'utilisateur
est
> rejeté si le rôle n'est pas activé.
> Lorsque le rôle est activé, l'utilisateur accède à la bd mais le select
sur
> une table en particulier lui est refusé.
> Sur la même bd, alors que l'utilisateur est en denyreader denywriter et
doit
> activé le rôle application, l'accès lui est autorisé lorsqu'il ouvre la
table
> via Access en tant que table liée.
> Normalement, il ne le devrait pas puisqu'il n'a pas activé le rôle
> application. Non seulement il y arrive à y accéder mais il peut modifier
les
> données de la table sur laquelle il est refusé en select. Le role
application
> à aucun moment n'est activé ou saisi par l'utilisateur.
> Le test a été refait en lançant l'application vb et le fichier Access en
> même temps.
> pour l'application VB, le refus est manifesté dans un message d'erreur.
Par
> contre pour la table liée ouverte sur la table en question. Le refus n'est
> pas opéré.
> J'ai bien vérifié que j'attaquais la bonne table dans la bonne bd sur
> laquelle j'étais en refus total(pas de select ni insert ni update).
> Accès toujours en full modification sur cette table via Access table liée.
>
> Merci
>
> Cordialement
> AB
>
> "" a écrit :
>
> > Bonjour,
> >
> > Je ne comprend pas lorsque tu dis :
> > "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à."
> >
> > Tu fais un deny pour l'utilisateur sur les objets adéquats
> > Tu donnes les droits à l'application role sur les objets adéquats
> > Si tu ne connais pas le mot de passe de l'application role ou si tu ne
> > l'active pas via ton ou tes applications ton utilisateur n'a pas les
droits
> > sur les objets adéquats.
> >
> > Cordialement,
> > LionelP
> >
> >
> > "AB" a écrit :
> >
> > > 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" a écrit dans le message de news:
> > > >
> > > > > 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,
C'est le même compte qui utilise les deux applications. Un même compte
windows.
Au niveau du profiler, on constate que c'est le m^me compte qui est
par les deux applications.
Les infos récupérées par le profiler sont les suivantes:
Nom du serveur sql
Nom de la bd
Compte utilisateur
Les requetes exécutés.
Tout est identique. Le profiler montre bien le refus d'autorisation
vient de l'appli VB. Lorsqu'on vient de la bd access(table liée) aucun
n'est observé. le select se passe bien et la modification d'une donnée est
autorisée.
J'en arrive à la consclusion suivante: Passant par Access, en ouvrant
directement un table liée, les roles applications ne remplissent pas leur
rôle.
Merci pour vos réponses.
AB
"lionelp" a écrit :
> donc:
> Sous quel compte Access se connecte à SQL Server ? Pour t'en assurer
> un profiler et vois ce qui se passe, tu trouveras alors la réponse à ton
> problème.
>
> Cordialement,
> LionelP
>
> "AB" wrote in message
> news:
> > Bonjour,
> >
> > Théoriquement cela devait marcher. i.e. l'utilisateur devrait être
> > par sql server puisqu'il n'a pas activé le role application et n'a pas
> mot
> > de passe de ce dernier. Passant par tous les frontaux vb,
> est
> > rejeté si le rôle n'est pas activé.
> > Lorsque le rôle est activé, l'utilisateur accède à la bd mais le
> sur
> > une table en particulier lui est refusé.
> > Sur la même bd, alors que l'utilisateur est en denyreader denywriter
> doit
> > activé le rôle application, l'accès lui est autorisé lorsqu'il ouvre
> table
> > via Access en tant que table liée.
> > Normalement, il ne le devrait pas puisqu'il n'a pas activé le rôle
> > application. Non seulement il y arrive à y accéder mais il peut
> les
> > données de la table sur laquelle il est refusé en select. Le role
> application
> > à aucun moment n'est activé ou saisi par l'utilisateur.
> > Le test a été refait en lançant l'application vb et le fichier Access
> > même temps.
> > pour l'application VB, le refus est manifesté dans un message
> Par
> > contre pour la table liée ouverte sur la table en question. Le refus
> > pas opéré.
> > J'ai bien vérifié que j'attaquais la bonne table dans la bonne bd sur
> > laquelle j'étais en refus total(pas de select ni insert ni update).
> > Accès toujours en full modification sur cette table via Access table
> >
> > Merci
> >
> > Cordialement
> > AB
> >
> > "" a écrit :
> >
> > > Bonjour,
> > >
> > > Je ne comprend pas lorsque tu dis :
> > > "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
> là."
> > >
> > > Tu fais un deny pour l'utilisateur sur les objets adéquats
> > > Tu donnes les droits à l'application role sur les objets adéquats
> > > Si tu ne connais pas le mot de passe de l'application role ou si tu
> > > l'active pas via ton ou tes applications ton utilisateur n'a pas les
> droits
> > > sur les objets adéquats.
> > >
> > > Cordialement,
> > > LionelP
> > >
> > >
> > > "AB" a écrit :
> > >
> > > > 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
> 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
> s'être
> > > > connecté. Si l'activation est oubliée le rôle application n'a
> utilité
> > > > puisque la bd peut être intérrogée sans aucun problème. Et le
> 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
> > > > efficacité. Il n'empêche en rien les gens de se connecter. Alors
> le
> > > > contraire aurait été le bienvenue. Le fonctinnement suivant aurait
> plus
> > > > efficace. Lorsqu'il y a un role applicatif. Aucune application ne
> > > > intérroger la bd sauf celles qui activent le role application via
> 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
> 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" a écrit dans le message de
> > > > >
> > > > > > Bonjour à tous,
> > > > > >
> > > > > > Est-ce quelqu'un sait comment limiter les accès d'une
> type
> > > > > > access d'accèder via odbc.
> > > > > > Voici le contexte. Les utilisateurs travaillent avec des
> 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
> Jusqu'à
> > > > > > là.
> > > > > > Tout est sécrurisé. Aucun utilisateur n'accède directement à
> BD.
> > > > > > Puisque
> > > > > > le frontal VB 6 ou aspnet permet ce verrouillage. Par contre,
> > > > > > l'entreprise certains utilisateurs ont access d'installé sur
> 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,
> 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
> 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
> Pour
> > > > > > mémoire
> > > > > > un rôle applicatif est rôle qui permet l'accès ou pas à
> 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
> Ces deux
> > > > > > rôles sont compléméntaires.
> > > > > >
> > > > > > l'idéal serait d'associer le nom d'une application à un rôle
> De cette
> > > > > > façon lorsque la personne se connecte via une appli bv6, elle
> sera
> > > > > > autorisée. Par contre si elle se connecte avec access l'accès
> 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
> que la
> > > > > > routine de vérification des autorisations puisse être
> lorsque
> > > > > > sql
> > > > > > vérifie les autorisations d'accès aux objects au préalable il
> > > > > > vérifier
> > > > > > sil'application est autorisé ou pas à accèder à la base de
> 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
> les
> > > > > > rôles
> > > > > > bd + rôle applicatifs ne sont plus suffisant. Gérer la
> avec des
> > > > > > outils qui permettent un accès très facile aux bds n'est plus
> > > > > > efficace
> > > > > > lorsque nous utilisons l'autentification windows. Pouvoir
> le nom
> > > > > > d'une application cliente à un rôle bd palierait à ce
> > > > > >
> > > > > > Cela fait beaucoup de questions, merci pour vos réponses et
> votre
> > > > > > patience.
> > > > > > Juste une dernière question. Si quelqu'un sait quelle est la
> de la
> > > > > > procédure système qui permet de checker les roles bd lors de
> connexion
> > > > > > d'une application cliente je lui serais très reconnaissant.
> > > > > >
> > > > > > Encore merci
> > > > > >
> > > > > > AB
> > > > >
> > > > >
> > > > >
>
>
>
Bonjour,
C'est le même compte qui utilise les deux applications. Un même compte
windows.
Au niveau du profiler, on constate que c'est le m^me compte qui est
par les deux applications.
Les infos récupérées par le profiler sont les suivantes:
Nom du serveur sql
Nom de la bd
Compte utilisateur
Les requetes exécutés.
Tout est identique. Le profiler montre bien le refus d'autorisation
vient de l'appli VB. Lorsqu'on vient de la bd access(table liée) aucun
n'est observé. le select se passe bien et la modification d'une donnée est
autorisée.
J'en arrive à la consclusion suivante: Passant par Access, en ouvrant
directement un table liée, les roles applications ne remplissent pas leur
rôle.
Merci pour vos réponses.
AB
"lionelp" a écrit :
> donc:
> Sous quel compte Access se connecte à SQL Server ? Pour t'en assurer
> un profiler et vois ce qui se passe, tu trouveras alors la réponse à ton
> problème.
>
> Cordialement,
> LionelP
>
> "AB" <AB@discussions.microsoft.com> wrote in message
> news:6BA94926-4D21-4793-B878-39348A7155D8@microsoft.com...
> > Bonjour,
> >
> > Théoriquement cela devait marcher. i.e. l'utilisateur devrait être
> > par sql server puisqu'il n'a pas activé le role application et n'a pas
> mot
> > de passe de ce dernier. Passant par tous les frontaux vb,
> est
> > rejeté si le rôle n'est pas activé.
> > Lorsque le rôle est activé, l'utilisateur accède à la bd mais le
> sur
> > une table en particulier lui est refusé.
> > Sur la même bd, alors que l'utilisateur est en denyreader denywriter
> doit
> > activé le rôle application, l'accès lui est autorisé lorsqu'il ouvre
> table
> > via Access en tant que table liée.
> > Normalement, il ne le devrait pas puisqu'il n'a pas activé le rôle
> > application. Non seulement il y arrive à y accéder mais il peut
> les
> > données de la table sur laquelle il est refusé en select. Le role
> application
> > à aucun moment n'est activé ou saisi par l'utilisateur.
> > Le test a été refait en lançant l'application vb et le fichier Access
> > même temps.
> > pour l'application VB, le refus est manifesté dans un message
> Par
> > contre pour la table liée ouverte sur la table en question. Le refus
> > pas opéré.
> > J'ai bien vérifié que j'attaquais la bonne table dans la bonne bd sur
> > laquelle j'étais en refus total(pas de select ni insert ni update).
> > Accès toujours en full modification sur cette table via Access table
> >
> > Merci
> >
> > Cordialement
> > AB
> >
> > "lionelp@online.microsoft.com" a écrit :
> >
> > > Bonjour,
> > >
> > > Je ne comprend pas lorsque tu dis :
> > > "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
> là."
> > >
> > > Tu fais un deny pour l'utilisateur sur les objets adéquats
> > > Tu donnes les droits à l'application role sur les objets adéquats
> > > Si tu ne connais pas le mot de passe de l'application role ou si tu
> > > l'active pas via ton ou tes applications ton utilisateur n'a pas les
> droits
> > > sur les objets adéquats.
> > >
> > > Cordialement,
> > > LionelP
> > >
> > >
> > > "AB" a écrit :
> > >
> > > > 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
> 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
> s'être
> > > > connecté. Si l'activation est oubliée le rôle application n'a
> utilité
> > > > puisque la bd peut être intérrogée sans aucun problème. Et le
> 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
> > > > efficacité. Il n'empêche en rien les gens de se connecter. Alors
> le
> > > > contraire aurait été le bienvenue. Le fonctinnement suivant aurait
> plus
> > > > efficace. Lorsqu'il y a un role applicatif. Aucune application ne
> > > > intérroger la bd sauf celles qui activent le role application via
> 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
> 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
> > > > > F8586490-78D0-4832-8C2E-0DC92B852C78@microsoft.com...
> > > > > > Bonjour à tous,
> > > > > >
> > > > > > Est-ce quelqu'un sait comment limiter les accès d'une
> type
> > > > > > access d'accèder via odbc.
> > > > > > Voici le contexte. Les utilisateurs travaillent avec des
> 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
> Jusqu'à
> > > > > > là.
> > > > > > Tout est sécrurisé. Aucun utilisateur n'accède directement à
> BD.
> > > > > > Puisque
> > > > > > le frontal VB 6 ou aspnet permet ce verrouillage. Par contre,
> > > > > > l'entreprise certains utilisateurs ont access d'installé sur
> 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,
> 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
> 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
> Pour
> > > > > > mémoire
> > > > > > un rôle applicatif est rôle qui permet l'accès ou pas à
> 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
> Ces deux
> > > > > > rôles sont compléméntaires.
> > > > > >
> > > > > > l'idéal serait d'associer le nom d'une application à un rôle
> De cette
> > > > > > façon lorsque la personne se connecte via une appli bv6, elle
> sera
> > > > > > autorisée. Par contre si elle se connecte avec access l'accès
> 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
> que la
> > > > > > routine de vérification des autorisations puisse être
> lorsque
> > > > > > sql
> > > > > > vérifie les autorisations d'accès aux objects au préalable il
> > > > > > vérifier
> > > > > > sil'application est autorisé ou pas à accèder à la base de
> 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
> les
> > > > > > rôles
> > > > > > bd + rôle applicatifs ne sont plus suffisant. Gérer la
> avec des
> > > > > > outils qui permettent un accès très facile aux bds n'est plus
> > > > > > efficace
> > > > > > lorsque nous utilisons l'autentification windows. Pouvoir
> le nom
> > > > > > d'une application cliente à un rôle bd palierait à ce
> > > > > >
> > > > > > Cela fait beaucoup de questions, merci pour vos réponses et
> votre
> > > > > > patience.
> > > > > > Juste une dernière question. Si quelqu'un sait quelle est la
> de la
> > > > > > procédure système qui permet de checker les roles bd lors de
> connexion
> > > > > > d'une application cliente je lui serais très reconnaissant.
> > > > > >
> > > > > > Encore merci
> > > > > >
> > > > > > AB
> > > > >
> > > > >
> > > > >
>
>
>
Bonjour,
C'est le même compte qui utilise les deux applications. Un même compte
windows.
Au niveau du profiler, on constate que c'est le m^me compte qui est
par les deux applications.
Les infos récupérées par le profiler sont les suivantes:
Nom du serveur sql
Nom de la bd
Compte utilisateur
Les requetes exécutés.
Tout est identique. Le profiler montre bien le refus d'autorisation
vient de l'appli VB. Lorsqu'on vient de la bd access(table liée) aucun
n'est observé. le select se passe bien et la modification d'une donnée est
autorisée.
J'en arrive à la consclusion suivante: Passant par Access, en ouvrant
directement un table liée, les roles applications ne remplissent pas leur
rôle.
Merci pour vos réponses.
AB
"lionelp" a écrit :
> donc:
> Sous quel compte Access se connecte à SQL Server ? Pour t'en assurer
> un profiler et vois ce qui se passe, tu trouveras alors la réponse à ton
> problème.
>
> Cordialement,
> LionelP
>
> "AB" wrote in message
> news:
> > Bonjour,
> >
> > Théoriquement cela devait marcher. i.e. l'utilisateur devrait être
> > par sql server puisqu'il n'a pas activé le role application et n'a pas
> mot
> > de passe de ce dernier. Passant par tous les frontaux vb,
> est
> > rejeté si le rôle n'est pas activé.
> > Lorsque le rôle est activé, l'utilisateur accède à la bd mais le
> sur
> > une table en particulier lui est refusé.
> > Sur la même bd, alors que l'utilisateur est en denyreader denywriter
> doit
> > activé le rôle application, l'accès lui est autorisé lorsqu'il ouvre
> table
> > via Access en tant que table liée.
> > Normalement, il ne le devrait pas puisqu'il n'a pas activé le rôle
> > application. Non seulement il y arrive à y accéder mais il peut
> les
> > données de la table sur laquelle il est refusé en select. Le role
> application
> > à aucun moment n'est activé ou saisi par l'utilisateur.
> > Le test a été refait en lançant l'application vb et le fichier Access
> > même temps.
> > pour l'application VB, le refus est manifesté dans un message
> Par
> > contre pour la table liée ouverte sur la table en question. Le refus
> > pas opéré.
> > J'ai bien vérifié que j'attaquais la bonne table dans la bonne bd sur
> > laquelle j'étais en refus total(pas de select ni insert ni update).
> > Accès toujours en full modification sur cette table via Access table
> >
> > Merci
> >
> > Cordialement
> > AB
> >
> > "" a écrit :
> >
> > > Bonjour,
> > >
> > > Je ne comprend pas lorsque tu dis :
> > > "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
> là."
> > >
> > > Tu fais un deny pour l'utilisateur sur les objets adéquats
> > > Tu donnes les droits à l'application role sur les objets adéquats
> > > Si tu ne connais pas le mot de passe de l'application role ou si tu
> > > l'active pas via ton ou tes applications ton utilisateur n'a pas les
> droits
> > > sur les objets adéquats.
> > >
> > > Cordialement,
> > > LionelP
> > >
> > >
> > > "AB" a écrit :
> > >
> > > > 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
> 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
> s'être
> > > > connecté. Si l'activation est oubliée le rôle application n'a
> utilité
> > > > puisque la bd peut être intérrogée sans aucun problème. Et le
> 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
> > > > efficacité. Il n'empêche en rien les gens de se connecter. Alors
> le
> > > > contraire aurait été le bienvenue. Le fonctinnement suivant aurait
> plus
> > > > efficace. Lorsqu'il y a un role applicatif. Aucune application ne
> > > > intérroger la bd sauf celles qui activent le role application via
> 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
> 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" a écrit dans le message de
> > > > >
> > > > > > Bonjour à tous,
> > > > > >
> > > > > > Est-ce quelqu'un sait comment limiter les accès d'une
> type
> > > > > > access d'accèder via odbc.
> > > > > > Voici le contexte. Les utilisateurs travaillent avec des
> 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
> Jusqu'à
> > > > > > là.
> > > > > > Tout est sécrurisé. Aucun utilisateur n'accède directement à
> BD.
> > > > > > Puisque
> > > > > > le frontal VB 6 ou aspnet permet ce verrouillage. Par contre,
> > > > > > l'entreprise certains utilisateurs ont access d'installé sur
> 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,
> 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
> 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
> Pour
> > > > > > mémoire
> > > > > > un rôle applicatif est rôle qui permet l'accès ou pas à
> 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
> Ces deux
> > > > > > rôles sont compléméntaires.
> > > > > >
> > > > > > l'idéal serait d'associer le nom d'une application à un rôle
> De cette
> > > > > > façon lorsque la personne se connecte via une appli bv6, elle
> sera
> > > > > > autorisée. Par contre si elle se connecte avec access l'accès
> 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
> que la
> > > > > > routine de vérification des autorisations puisse être
> lorsque
> > > > > > sql
> > > > > > vérifie les autorisations d'accès aux objects au préalable il
> > > > > > vérifier
> > > > > > sil'application est autorisé ou pas à accèder à la base de
> 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
> les
> > > > > > rôles
> > > > > > bd + rôle applicatifs ne sont plus suffisant. Gérer la
> avec des
> > > > > > outils qui permettent un accès très facile aux bds n'est plus
> > > > > > efficace
> > > > > > lorsque nous utilisons l'autentification windows. Pouvoir
> le nom
> > > > > > d'une application cliente à un rôle bd palierait à ce
> > > > > >
> > > > > > Cela fait beaucoup de questions, merci pour vos réponses et
> votre
> > > > > > patience.
> > > > > > Juste une dernière question. Si quelqu'un sait quelle est la
> de la
> > > > > > procédure système qui permet de checker les roles bd lors de
> connexion
> > > > > > d'une application cliente je lui serais très reconnaissant.
> > > > > >
> > > > > > Encore merci
> > > > > >
> > > > > > AB
> > > > >
> > > > >
> > > > >
>
>
>
Bonjour,
Il y a nécessairement une différence, SQL Server ne fait pas de distinction
entre des applications clientes. Soit le compte d'Access est différent ou
peut-êter maintient-il un curseur insensitif ouvert sur la table.
Cordialement,
LionelP
"Bela" wrote in message
news:
> Bonjour,
> C'est le même compte qui utilise les deux applications. Un même compte
> windows.
> Au niveau du profiler, on constate que c'est le m^me compte qui est
utilisé
> par les deux applications.
> Les infos récupérées par le profiler sont les suivantes:
> Nom du serveur sql
> Nom de la bd
> Compte utilisateur
> Les requetes exécutés.
>
> Tout est identique. Le profiler montre bien le refus d'autorisation
lorsq'on
> vient de l'appli VB. Lorsqu'on vient de la bd access(table liée) aucun
refus
> n'est observé. le select se passe bien et la modification d'une donnée est
> autorisée.
>
> J'en arrive à la consclusion suivante: Passant par Access, en ouvrant
> directement un table liée, les roles applications ne remplissent pas leur
> rôle.
>
> Merci pour vos réponses.
>
> AB
>
>
>
> "lionelp" a écrit :
>
> > donc:
> > Sous quel compte Access se connecte à SQL Server ? Pour t'en assurer
lance
> > un profiler et vois ce qui se passe, tu trouveras alors la réponse à ton
> > problème.
> >
> > Cordialement,
> > LionelP
> >
> > "AB" wrote in message
> > news:
> > > Bonjour,
> > >
> > > Théoriquement cela devait marcher. i.e. l'utilisateur devrait être
rejeté
> > > par sql server puisqu'il n'a pas activé le role application et n'a pas
le
> > mot
> > > de passe de ce dernier. Passant par tous les frontaux vb,
l'utilisateur
> > est
> > > rejeté si le rôle n'est pas activé.
> > > Lorsque le rôle est activé, l'utilisateur accède à la bd mais le
select
> > sur
> > > une table en particulier lui est refusé.
> > > Sur la même bd, alors que l'utilisateur est en denyreader denywriter
et
> > doit
> > > activé le rôle application, l'accès lui est autorisé lorsqu'il ouvre
la
> > table
> > > via Access en tant que table liée.
> > > Normalement, il ne le devrait pas puisqu'il n'a pas activé le rôle
> > > application. Non seulement il y arrive à y accéder mais il peut
modifier
> > les
> > > données de la table sur laquelle il est refusé en select. Le role
> > application
> > > à aucun moment n'est activé ou saisi par l'utilisateur.
> > > Le test a été refait en lançant l'application vb et le fichier Access
en
> > > même temps.
> > > pour l'application VB, le refus est manifesté dans un message
d'erreur.
> > Par
> > > contre pour la table liée ouverte sur la table en question. Le refus
n'est
> > > pas opéré.
> > > J'ai bien vérifié que j'attaquais la bonne table dans la bonne bd sur
> > > laquelle j'étais en refus total(pas de select ni insert ni update).
> > > Accès toujours en full modification sur cette table via Access table
liée.
> > >
> > > Merci
> > >
> > > Cordialement
> > > AB
> > >
> > > "" a écrit :
> > >
> > > > Bonjour,
> > > >
> > > > Je ne comprend pas lorsque tu dis :
> > > > "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à."
> > > >
> > > > Tu fais un deny pour l'utilisateur sur les objets adéquats
> > > > Tu donnes les droits à l'application role sur les objets adéquats
> > > > Si tu ne connais pas le mot de passe de l'application role ou si tu
ne
> > > > l'active pas via ton ou tes applications ton utilisateur n'a pas les
> > droits
> > > > sur les objets adéquats.
> > > >
> > > > Cordialement,
> > > > LionelP
> > > >
> > > >
> > > > "AB" a écrit :
> > > >
> > > > > 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" a écrit dans le message de
news:
> > > > > >
> > > > > > > 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
Bonjour,
Il y a nécessairement une différence, SQL Server ne fait pas de distinction
entre des applications clientes. Soit le compte d'Access est différent ou
peut-êter maintient-il un curseur insensitif ouvert sur la table.
Cordialement,
LionelP
"Bela" <Bela@discussions.microsoft.com> wrote in message
news:69AAB5AE-E896-4470-AAD0-CE0BF8B4E505@microsoft.com...
> Bonjour,
> C'est le même compte qui utilise les deux applications. Un même compte
> windows.
> Au niveau du profiler, on constate que c'est le m^me compte qui est
utilisé
> par les deux applications.
> Les infos récupérées par le profiler sont les suivantes:
> Nom du serveur sql
> Nom de la bd
> Compte utilisateur
> Les requetes exécutés.
>
> Tout est identique. Le profiler montre bien le refus d'autorisation
lorsq'on
> vient de l'appli VB. Lorsqu'on vient de la bd access(table liée) aucun
refus
> n'est observé. le select se passe bien et la modification d'une donnée est
> autorisée.
>
> J'en arrive à la consclusion suivante: Passant par Access, en ouvrant
> directement un table liée, les roles applications ne remplissent pas leur
> rôle.
>
> Merci pour vos réponses.
>
> AB
>
>
>
> "lionelp" a écrit :
>
> > donc:
> > Sous quel compte Access se connecte à SQL Server ? Pour t'en assurer
lance
> > un profiler et vois ce qui se passe, tu trouveras alors la réponse à ton
> > problème.
> >
> > Cordialement,
> > LionelP
> >
> > "AB" <AB@discussions.microsoft.com> wrote in message
> > news:6BA94926-4D21-4793-B878-39348A7155D8@microsoft.com...
> > > Bonjour,
> > >
> > > Théoriquement cela devait marcher. i.e. l'utilisateur devrait être
rejeté
> > > par sql server puisqu'il n'a pas activé le role application et n'a pas
le
> > mot
> > > de passe de ce dernier. Passant par tous les frontaux vb,
l'utilisateur
> > est
> > > rejeté si le rôle n'est pas activé.
> > > Lorsque le rôle est activé, l'utilisateur accède à la bd mais le
select
> > sur
> > > une table en particulier lui est refusé.
> > > Sur la même bd, alors que l'utilisateur est en denyreader denywriter
et
> > doit
> > > activé le rôle application, l'accès lui est autorisé lorsqu'il ouvre
la
> > table
> > > via Access en tant que table liée.
> > > Normalement, il ne le devrait pas puisqu'il n'a pas activé le rôle
> > > application. Non seulement il y arrive à y accéder mais il peut
modifier
> > les
> > > données de la table sur laquelle il est refusé en select. Le role
> > application
> > > à aucun moment n'est activé ou saisi par l'utilisateur.
> > > Le test a été refait en lançant l'application vb et le fichier Access
en
> > > même temps.
> > > pour l'application VB, le refus est manifesté dans un message
d'erreur.
> > Par
> > > contre pour la table liée ouverte sur la table en question. Le refus
n'est
> > > pas opéré.
> > > J'ai bien vérifié que j'attaquais la bonne table dans la bonne bd sur
> > > laquelle j'étais en refus total(pas de select ni insert ni update).
> > > Accès toujours en full modification sur cette table via Access table
liée.
> > >
> > > Merci
> > >
> > > Cordialement
> > > AB
> > >
> > > "lionelp@online.microsoft.com" a écrit :
> > >
> > > > Bonjour,
> > > >
> > > > Je ne comprend pas lorsque tu dis :
> > > > "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à."
> > > >
> > > > Tu fais un deny pour l'utilisateur sur les objets adéquats
> > > > Tu donnes les droits à l'application role sur les objets adéquats
> > > > Si tu ne connais pas le mot de passe de l'application role ou si tu
ne
> > > > l'active pas via ton ou tes applications ton utilisateur n'a pas les
> > droits
> > > > sur les objets adéquats.
> > > >
> > > > Cordialement,
> > > > LionelP
> > > >
> > > >
> > > > "AB" a écrit :
> > > >
> > > > > 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
Bonjour,
Il y a nécessairement une différence, SQL Server ne fait pas de distinction
entre des applications clientes. Soit le compte d'Access est différent ou
peut-êter maintient-il un curseur insensitif ouvert sur la table.
Cordialement,
LionelP
"Bela" wrote in message
news:
> Bonjour,
> C'est le même compte qui utilise les deux applications. Un même compte
> windows.
> Au niveau du profiler, on constate que c'est le m^me compte qui est
utilisé
> par les deux applications.
> Les infos récupérées par le profiler sont les suivantes:
> Nom du serveur sql
> Nom de la bd
> Compte utilisateur
> Les requetes exécutés.
>
> Tout est identique. Le profiler montre bien le refus d'autorisation
lorsq'on
> vient de l'appli VB. Lorsqu'on vient de la bd access(table liée) aucun
refus
> n'est observé. le select se passe bien et la modification d'une donnée est
> autorisée.
>
> J'en arrive à la consclusion suivante: Passant par Access, en ouvrant
> directement un table liée, les roles applications ne remplissent pas leur
> rôle.
>
> Merci pour vos réponses.
>
> AB
>
>
>
> "lionelp" a écrit :
>
> > donc:
> > Sous quel compte Access se connecte à SQL Server ? Pour t'en assurer
lance
> > un profiler et vois ce qui se passe, tu trouveras alors la réponse à ton
> > problème.
> >
> > Cordialement,
> > LionelP
> >
> > "AB" wrote in message
> > news:
> > > Bonjour,
> > >
> > > Théoriquement cela devait marcher. i.e. l'utilisateur devrait être
rejeté
> > > par sql server puisqu'il n'a pas activé le role application et n'a pas
le
> > mot
> > > de passe de ce dernier. Passant par tous les frontaux vb,
l'utilisateur
> > est
> > > rejeté si le rôle n'est pas activé.
> > > Lorsque le rôle est activé, l'utilisateur accède à la bd mais le
select
> > sur
> > > une table en particulier lui est refusé.
> > > Sur la même bd, alors que l'utilisateur est en denyreader denywriter
et
> > doit
> > > activé le rôle application, l'accès lui est autorisé lorsqu'il ouvre
la
> > table
> > > via Access en tant que table liée.
> > > Normalement, il ne le devrait pas puisqu'il n'a pas activé le rôle
> > > application. Non seulement il y arrive à y accéder mais il peut
modifier
> > les
> > > données de la table sur laquelle il est refusé en select. Le role
> > application
> > > à aucun moment n'est activé ou saisi par l'utilisateur.
> > > Le test a été refait en lançant l'application vb et le fichier Access
en
> > > même temps.
> > > pour l'application VB, le refus est manifesté dans un message
d'erreur.
> > Par
> > > contre pour la table liée ouverte sur la table en question. Le refus
n'est
> > > pas opéré.
> > > J'ai bien vérifié que j'attaquais la bonne table dans la bonne bd sur
> > > laquelle j'étais en refus total(pas de select ni insert ni update).
> > > Accès toujours en full modification sur cette table via Access table
liée.
> > >
> > > Merci
> > >
> > > Cordialement
> > > AB
> > >
> > > "" a écrit :
> > >
> > > > Bonjour,
> > > >
> > > > Je ne comprend pas lorsque tu dis :
> > > > "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à."
> > > >
> > > > Tu fais un deny pour l'utilisateur sur les objets adéquats
> > > > Tu donnes les droits à l'application role sur les objets adéquats
> > > > Si tu ne connais pas le mot de passe de l'application role ou si tu
ne
> > > > l'active pas via ton ou tes applications ton utilisateur n'a pas les
> > droits
> > > > sur les objets adéquats.
> > > >
> > > > Cordialement,
> > > > LionelP
> > > >
> > > >
> > > > "AB" a écrit :
> > > >
> > > > > 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" a écrit dans le message de
news:
> > > > > >
> > > > > > > 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
