Création nom ds groupe admin

Alors:

- Le groupe utilisateurs contient toujours tous les
utilisateurs de ton fichier groupe de travail. En fait
quel que soit le fichier mdw auquel tu es joint, le compte
logué est toujours inscrit dans le groupe utilisateurs. Du
coup, si tu laisses des droits à ce groupe, tu laisses ces
droits à tous les utilisateurs d'Access

- Le compte administrateur par défaut ne peut pas être
supprimé. Si tu veux lui retirer tous ses droits, tu dois
le supprimer de tous les groupes ce qui le laissera membre
de utilisateurs. Evidemment tu dois retirer les droits à
ce groupe pour que la sécurisation prenne effet.

Ah et sinon pour qu'une base soit réellement sécurisée,
elle doit être créée par ton propre compte administrateur.
En effet le créateur d'une base (ou d'un objet) devient
son propriétaire, et il à tous les droits sur sa propriété.
On peut changer le propriétaire de tous les objets, mais
pas d'une base. Du coup, une base créée par le compte
admin par défaut est accessible à tout le monde.

Bon et si tu veux plus d'infos sur ce modèle complexe, vas
voir la FAQ :
http://support.microsoft.com/support/access/content/secfaq.
asp
et il ya une bonne desxcription du modèle et du systeme de
comptes ici:
http://msdn.microsoft.com/library/default.asp?
url=/library/en-
us/odeopg/html/deovrrunninguserlevelsecuritywizard.asp

-----Message d'origine-----
Hello à tous !

Je suis en train de suivre une procédure pas à pas
trouvée

dans les archives google pour appliquer correctement la
sécurité utilisateur.
Par contre je bute sur un point. Quand je créé
l'utilisateur qui deviendra l'administrateur, il me le
met

par défaut dans le groupe utilisateurs. Et après, même si
je l'inscris dans "Administrateur", il ne veut pas me
supprimer le compte adminitrateur par défaut.
Comment faire ??

Merci beaucoup d'avance :o)

Arnaud
.

Je te remercie beaucoup pour ta réponse.
Effectivement je l'ai simplement retiré et ca fonctionne !
Pour le reste oui, pas de pb, j'ai créé une nouvelle base
et tout importé.
Merci !! :o)

-----Message d'origine-----
Alors:

- Le groupe utilisateurs contient toujours tous les
utilisateurs de ton fichier groupe de travail. En fait
quel que soit le fichier mdw auquel tu es joint, le
compte

logué est toujours inscrit dans le groupe utilisateurs.
Du

coup, si tu laisses des droits à ce groupe, tu laisses
ces

droits à tous les utilisateurs d'Access

- Le compte administrateur par défaut ne peut pas être
supprimé. Si tu veux lui retirer tous ses droits, tu dois
le supprimer de tous les groupes ce qui le laissera
membre

de utilisateurs. Evidemment tu dois retirer les droits à
ce groupe pour que la sécurisation prenne effet.

Ah et sinon pour qu'une base soit réellement sécurisée,
elle doit être créée par ton propre compte
administrateur.

En effet le créateur d'une base (ou d'un objet) devient
son propriétaire, et il à tous les droits sur sa
propriété.

On peut changer le propriétaire de tous les objets, mais
pas d'une base. Du coup, une base créée par le compte
admin par défaut est accessible à tout le monde.

Bon et si tu veux plus d'infos sur ce modèle complexe,
vas

voir la FAQ :
http://support.microsoft.com/support/access/content/secfaq
.

asp
et il ya une bonne desxcription du modèle et du systeme
de

comptes ici:
http://msdn.microsoft.com/library/default.asp?
url=/library/en-
us/odeopg/html/deovrrunninguserlevelsecuritywizard.asp

-----Message d'origine-----
Hello à tous !

Je suis en train de suivre une procédure pas à pas
trouvée

dans les archives google pour appliquer correctement la
sécurité utilisateur.
Par contre je bute sur un point. Quand je créé
l'utilisateur qui deviendra l'administrateur, il me le
met

par défaut dans le groupe utilisateurs. Et après, même
si

je l'inscris dans "Administrateur", il ne veut pas me
supprimer le compte adminitrateur par défaut.
Comment faire ??

Merci beaucoup d'avance :o)

Arnaud
.

.

J'ai un autre problème avec la sécurité, du moins je me
pose une question :
J'ai une base qui vient attaquer la base que j'ai
sécurisée, et je ne voudrais pas que dans ce process
apparaisse une demande de mot de passe.
Qu'en sera-t-il ?

Merci !

-----Message d'origine-----
Alors:

- Le groupe utilisateurs contient toujours tous les
utilisateurs de ton fichier groupe de travail. En fait
quel que soit le fichier mdw auquel tu es joint, le
compte

logué est toujours inscrit dans le groupe utilisateurs.
Du

coup, si tu laisses des droits à ce groupe, tu laisses
ces

droits à tous les utilisateurs d'Access

- Le compte administrateur par défaut ne peut pas être
supprimé. Si tu veux lui retirer tous ses droits, tu dois
le supprimer de tous les groupes ce qui le laissera
membre

de utilisateurs. Evidemment tu dois retirer les droits à
ce groupe pour que la sécurisation prenne effet.

Ah et sinon pour qu'une base soit réellement sécurisée,
elle doit être créée par ton propre compte
administrateur.

En effet le créateur d'une base (ou d'un objet) devient
son propriétaire, et il à tous les droits sur sa
propriété.

On peut changer le propriétaire de tous les objets, mais
pas d'une base. Du coup, une base créée par le compte
admin par défaut est accessible à tout le monde.

Bon et si tu veux plus d'infos sur ce modèle complexe,
vas

voir la FAQ :
http://support.microsoft.com/support/access/content/secfaq
.

asp
et il ya une bonne desxcription du modèle et du systeme
de

comptes ici:
http://msdn.microsoft.com/library/default.asp?
url=/library/en-
us/odeopg/html/deovrrunninguserlevelsecuritywizard.asp

-----Message d'origine-----
Hello à tous !

Je suis en train de suivre une procédure pas à pas
trouvée

dans les archives google pour appliquer correctement la
sécurité utilisateur.
Par contre je bute sur un point. Quand je créé
l'utilisateur qui deviendra l'administrateur, il me le
met

par défaut dans le groupe utilisateurs. Et après, même
si

je l'inscris dans "Administrateur", il ne veut pas me
supprimer le compte adminitrateur par défaut.
Comment faire ??

Merci beaucoup d'avance :o)

Arnaud
.

.

Re,

Difficile d'attaquer une base securisée.
Par DAO, tu peux le faire normalement du moment que tu
ouvres la base "attaquante" avec le bon fichier mdw, et
logué sous un utilisateur ayant le droit d'ouvrir et
d'attaquer l'autre base.
J'imagine que c'est pareil en ADo mais je n'ai jamais fait.

Si tu veux automatiser la base, apparemment le seul moyen
est de la lancer par Shell en spécifiant le workgroup,
login et mot de passe, puis de récupérer le process par
GetObject (,"Access.Application")
Personnellement je n'ai jamais réussi a récupérer le shell
par Getobject, mais bon c'est ce qui est marqué partout.

J

-----Message d'origine-----
J'ai un autre problème avec la sécurité, du moins je me
pose une question :
J'ai une base qui vient attaquer la base que j'ai
sécurisée, et je ne voudrais pas que dans ce process
apparaisse une demande de mot de passe.
Qu'en sera-t-il ?

Merci !

-----Message d'origine-----
Alors:

- Le groupe utilisateurs contient toujours tous les
utilisateurs de ton fichier groupe de travail. En fait
quel que soit le fichier mdw auquel tu es joint, le
compte

logué est toujours inscrit dans le groupe utilisateurs.
Du

coup, si tu laisses des droits à ce groupe, tu laisses
ces

droits à tous les utilisateurs d'Access

- Le compte administrateur par défaut ne peut pas être
supprimé. Si tu veux lui retirer tous ses droits, tu
dois

le supprimer de tous les groupes ce qui le laissera
membre

de utilisateurs. Evidemment tu dois retirer les droits à
ce groupe pour que la sécurisation prenne effet.

Ah et sinon pour qu'une base soit réellement sécurisée,
elle doit être créée par ton propre compte
administrateur.

En effet le créateur d'une base (ou d'un objet) devient
son propriétaire, et il à tous les droits sur sa
propriété.

On peut changer le propriétaire de tous les objets, mais
pas d'une base. Du coup, une base créée par le compte
admin par défaut est accessible à tout le monde.

Bon et si tu veux plus d'infos sur ce modèle complexe,
vas

voir la FAQ :
http://support.microsoft.com/support/access/content/secfa
q

..

asp
et il ya une bonne desxcription du modèle et du systeme
de

comptes ici:
http://msdn.microsoft.com/library/default.asp?
url=/library/en-
us/odeopg/html/deovrrunninguserlevelsecuritywizard.asp

-----Message d'origine-----
Hello à tous !

Je suis en train de suivre une procédure pas à pas
trouvée

dans les archives google pour appliquer correctement la
sécurité utilisateur.
Par contre je bute sur un point. Quand je créé
l'utilisateur qui deviendra l'administrateur, il me le
met

par défaut dans le groupe utilisateurs. Et après, même
si

je l'inscris dans "Administrateur", il ne veut pas me
supprimer le compte adminitrateur par défaut.
Comment faire ??

Merci beaucoup d'avance :o)

Arnaud
.

.

.

re, :)

automatiser une base signifie que tu vas pouvoir effectuer
des actions du style ouvrir un état, un formulaire, etc.
Ceci nécessite un objet Application, et la procédure du
Shell lorsqu'il s'agit d'une base sécurisée.

Si tu veux simplement effectuer des opérations sur les
données (des requêtes) tu peux accéder à une base distante
en DAO

Par contre je ne comprends pas trop ton architecture.
Quelle est la base qui contient les formulaires et les
requêtes de mise à jour? La base sécurisée?

Quoi qu'il en soit le principe est simple. Lorsque tu
essaie de passer une requete sur une table, le moteur Jet
regarde ton identité, regarde les permissions
correspondantes pour la table, et dit oui ou non suivant
ce qu'il trouve. Il faut donc que tu sois logué avec un
compte valide pour modifier une table, que ce soit par DAO
ou qu'il s'agisse d'une table liée.
Tu peux lancer ton application interface en chargant le
fichier mdw sécurisé, te loguer, et là tu pourras mettre à
jour les données sur les bases sécurisées. Le seul moyen
de n'avoir absolument aucune invite de login/mot de passe
est, il me semble, de passer par le Shell.

J.

-----Message d'origine-----
Un nouveau merci pour ta réponse.
Qu'entends-tu par automatiser la base ?
En fait la structure est la suivante :
- Une base avec quelques tables et des requêtes
- Une base non sécurisée avec de nombreuses tables
- La base que je sécurise.
En fait un service lance via un formulaire des requêtes
qui vont mettre à jour les données des deux autres bases.
Les tables de celles-ci sont liées dans la première.
J'aurai donc bien malheureusement l'apparition d'une
boîte

de dialogue avec login/pass lorsqu'ils déclencheront le
process depuis la première base ?

Merci encore

-----Message d'origine-----
Re,

Difficile d'attaquer une base securisée.
Par DAO, tu peux le faire normalement du moment que tu
ouvres la base "attaquante" avec le bon fichier mdw, et
logué sous un utilisateur ayant le droit d'ouvrir et
d'attaquer l'autre base.
J'imagine que c'est pareil en ADo mais je n'ai jamais
fait.

Si tu veux automatiser la base, apparemment le seul
moyen

est de la lancer par Shell en spécifiant le workgroup,
login et mot de passe, puis de récupérer le process par
GetObject (,"Access.Application")
Personnellement je n'ai jamais réussi a récupérer le
shell

par Getobject, mais bon c'est ce qui est marqué partout.

J

-----Message d'origine-----
J'ai un autre problème avec la sécurité, du moins je me
pose une question :
J'ai une base qui vient attaquer la base que j'ai
sécurisée, et je ne voudrais pas que dans ce process
apparaisse une demande de mot de passe.
Qu'en sera-t-il ?

Merci !

-----Message d'origine-----
Alors:

- Le groupe utilisateurs contient toujours tous les
utilisateurs de ton fichier groupe de travail. En fait
quel que soit le fichier mdw auquel tu es joint, le
compte

logué est toujours inscrit dans le groupe
utilisateurs.

Du

coup, si tu laisses des droits à ce groupe, tu laisses
ces

droits à tous les utilisateurs d'Access

- Le compte administrateur par défaut ne peut pas être
supprimé. Si tu veux lui retirer tous ses droits, tu
dois

le supprimer de tous les groupes ce qui le laissera
membre

de utilisateurs. Evidemment tu dois retirer les droits
à

ce groupe pour que la sécurisation prenne effet.

Ah et sinon pour qu'une base soit réellement
sécurisée,

elle doit être créée par ton propre compte
administrateur.

En effet le créateur d'une base (ou d'un objet)
devient

son propriétaire, et il à tous les droits sur sa
propriété.

On peut changer le propriétaire de tous les objets,
mais

pas d'une base. Du coup, une base créée par le compte
admin par défaut est accessible à tout le monde.

Bon et si tu veux plus d'infos sur ce modèle complexe,
vas

voir la FAQ :
http://support.microsoft.com/support/access/content/sec
f

a

q

..

asp
et il ya une bonne desxcription du modèle et du
systeme

de

comptes ici:
http://msdn.microsoft.com/library/default.asp?
url=/library/en-
us/odeopg/html/deovrrunninguserlevelsecuritywizard.asp

-----Message d'origine-----
Hello à tous !

Je suis en train de suivre une procédure pas à pas
trouvée

dans les archives google pour appliquer correctement
la

sécurité utilisateur.
Par contre je bute sur un point. Quand je créé
l'utilisateur qui deviendra l'administrateur, il me
le

met

par défaut dans le groupe utilisateurs. Et après,
même

si

je l'inscris dans "Administrateur", il ne veut pas me
supprimer le compte adminitrateur par défaut.
Comment faire ??

Merci beaucoup d'avance :o)

Arnaud
.

.

.

.

.

rerere :)

En fait l'architecture est celle du client, je n'ai pas la
main dessus, et les formulaires se trouvent dans toutes
les bases, il n'y a pas de notion front/back. En fait, il
y a une base qui peut éventuellement etre considéré comme
front c'est la première.
Je sais que via un reccourci windows, on peut ouvrir une
base en mettant dans le raccourci login et pass. N'y a-t-
il pas un moyen de passer ces mêmes paramètres aux
requêtes qui vont taper dans la sécurisée ?

-----Message d'origine-----
re, :)

automatiser une base signifie que tu vas pouvoir
effectuer

des actions du style ouvrir un état, un formulaire, etc.
Ceci nécessite un objet Application, et la procédure du
Shell lorsqu'il s'agit d'une base sécurisée.

Si tu veux simplement effectuer des opérations sur les
données (des requêtes) tu peux accéder à une base
distante

en DAO

Par contre je ne comprends pas trop ton architecture.
Quelle est la base qui contient les formulaires et les
requêtes de mise à jour? La base sécurisée?

Quoi qu'il en soit le principe est simple. Lorsque tu
essaie de passer une requete sur une table, le moteur Jet
regarde ton identité, regarde les permissions
correspondantes pour la table, et dit oui ou non suivant
ce qu'il trouve. Il faut donc que tu sois logué avec un
compte valide pour modifier une table, que ce soit par
DAO

ou qu'il s'agisse d'une table liée.
Tu peux lancer ton application interface en chargant le
fichier mdw sécurisé, te loguer, et là tu pourras mettre
à

jour les données sur les bases sécurisées. Le seul moyen
de n'avoir absolument aucune invite de login/mot de passe
est, il me semble, de passer par le Shell.

J.

-----Message d'origine-----
Un nouveau merci pour ta réponse.
Qu'entends-tu par automatiser la base ?
En fait la structure est la suivante :
- Une base avec quelques tables et des requêtes
- Une base non sécurisée avec de nombreuses tables
- La base que je sécurise.
En fait un service lance via un formulaire des requêtes
qui vont mettre à jour les données des deux autres
bases.

Les tables de celles-ci sont liées dans la première.
J'aurai donc bien malheureusement l'apparition d'une
boîte

de dialogue avec login/pass lorsqu'ils déclencheront le
process depuis la première base ?

Merci encore

-----Message d'origine-----
Re,

Difficile d'attaquer une base securisée.
Par DAO, tu peux le faire normalement du moment que tu
ouvres la base "attaquante" avec le bon fichier mdw, et
logué sous un utilisateur ayant le droit d'ouvrir et
d'attaquer l'autre base.
J'imagine que c'est pareil en ADo mais je n'ai jamais
fait.

Si tu veux automatiser la base, apparemment le seul
moyen

est de la lancer par Shell en spécifiant le workgroup,
login et mot de passe, puis de récupérer le process par
GetObject (,"Access.Application")
Personnellement je n'ai jamais réussi a récupérer le
shell

par Getobject, mais bon c'est ce qui est marqué partout.

J

-----Message d'origine-----
J'ai un autre problème avec la sécurité, du moins je
me

pose une question :
J'ai une base qui vient attaquer la base que j'ai
sécurisée, et je ne voudrais pas que dans ce process
apparaisse une demande de mot de passe.
Qu'en sera-t-il ?

Merci !

-----Message d'origine-----
Alors:

- Le groupe utilisateurs contient toujours tous les
utilisateurs de ton fichier groupe de travail. En
fait

quel que soit le fichier mdw auquel tu es joint, le
compte

logué est toujours inscrit dans le groupe
utilisateurs.

Du

coup, si tu laisses des droits à ce groupe, tu
laisses

ces

droits à tous les utilisateurs d'Access

- Le compte administrateur par défaut ne peut pas
être

supprimé. Si tu veux lui retirer tous ses droits, tu
dois

le supprimer de tous les groupes ce qui le laissera
membre

de utilisateurs. Evidemment tu dois retirer les
droits

à

ce groupe pour que la sécurisation prenne effet.

Ah et sinon pour qu'une base soit réellement
sécurisée,

elle doit être créée par ton propre compte
administrateur.

En effet le créateur d'une base (ou d'un objet)
devient

son propriétaire, et il à tous les droits sur sa
propriété.

On peut changer le propriétaire de tous les objets,
mais

pas d'une base. Du coup, une base créée par le compte
admin par défaut est accessible à tout le monde.

Bon et si tu veux plus d'infos sur ce modèle
complexe,

vas

voir la FAQ :
http://support.microsoft.com/support/access/content/se
c

f

a

q

..

asp
et il ya une bonne desxcription du modèle et du
systeme

de

comptes ici:
http://msdn.microsoft.com/library/default.asp?
url=/library/en-
us/odeopg/html/deovrrunninguserlevelsecuritywizard.asp

-----Message d'origine-----
Hello à tous !

Je suis en train de suivre une procédure pas à pas
trouvée

dans les archives google pour appliquer correctement
la

sécurité utilisateur.
Par contre je bute sur un point. Quand je créé
l'utilisateur qui deviendra l'administrateur, il me
le

met

par défaut dans le groupe utilisateurs. Et après,
même

si

je l'inscris dans "Administrateur", il ne veut pas
me

supprimer le compte adminitrateur par défaut.
Comment faire ??

Merci beaucoup d'avance :o)

Arnaud
.

.

.

.

.

.

Franchement je crois pas...

Les noms d'utilisateurs et groupes sont chargés au
démarrage d'access. Tu peux démarrer Access avec un
parametre spécial par un raccourci windows, en effet.
C'est le principe qu'on utilise dans le Shell. A partir
d'une appli non sécurisée, on execute une autre instance
d'Access, mais sécurisée.

Le seul moyen de charger le bon fichier mdw, et donc
d'avoir la bonne identité, est de lancer access en le
spécifiant. Impossible de prendre une autre identité le
temps d'une requête, en tout cas j'en ai jamais entendu
parler...

Mais là tu conçois le systeme de sécurité ou il existe
déjà et tu veux t'y adapter??
J

-----Message d'origine-----
rerere :)

En fait l'architecture est celle du client, je n'ai pas
la

main dessus, et les formulaires se trouvent dans toutes
les bases, il n'y a pas de notion front/back. En fait, il
y a une base qui peut éventuellement etre considéré comme
front c'est la première.
Je sais que via un reccourci windows, on peut ouvrir une
base en mettant dans le raccourci login et pass. N'y a-t-
il pas un moyen de passer ces mêmes paramètres aux
requêtes qui vont taper dans la sécurisée ?

-----Message d'origine-----
re, :)

automatiser une base signifie que tu vas pouvoir
effectuer

des actions du style ouvrir un état, un formulaire, etc.
Ceci nécessite un objet Application, et la procédure du
Shell lorsqu'il s'agit d'une base sécurisée.

Si tu veux simplement effectuer des opérations sur les
données (des requêtes) tu peux accéder à une base
distante

en DAO

Par contre je ne comprends pas trop ton architecture.
Quelle est la base qui contient les formulaires et les
requêtes de mise à jour? La base sécurisée?

Quoi qu'il en soit le principe est simple. Lorsque tu
essaie de passer une requete sur une table, le moteur
Jet

regarde ton identité, regarde les permissions
correspondantes pour la table, et dit oui ou non suivant
ce qu'il trouve. Il faut donc que tu sois logué avec un
compte valide pour modifier une table, que ce soit par
DAO

ou qu'il s'agisse d'une table liée.
Tu peux lancer ton application interface en chargant le
fichier mdw sécurisé, te loguer, et là tu pourras mettre
à

jour les données sur les bases sécurisées. Le seul moyen
de n'avoir absolument aucune invite de login/mot de
passe

est, il me semble, de passer par le Shell.

J.

-----Message d'origine-----
Un nouveau merci pour ta réponse.
Qu'entends-tu par automatiser la base ?
En fait la structure est la suivante :
- Une base avec quelques tables et des requêtes
- Une base non sécurisée avec de nombreuses tables
- La base que je sécurise.
En fait un service lance via un formulaire des requêtes
qui vont mettre à jour les données des deux autres
bases.

Les tables de celles-ci sont liées dans la première.
J'aurai donc bien malheureusement l'apparition d'une
boîte

de dialogue avec login/pass lorsqu'ils déclencheront le
process depuis la première base ?

Merci encore

-----Message d'origine-----
Re,

Difficile d'attaquer une base securisée.
Par DAO, tu peux le faire normalement du moment que tu
ouvres la base "attaquante" avec le bon fichier mdw,
et

logué sous un utilisateur ayant le droit d'ouvrir et
d'attaquer l'autre base.
J'imagine que c'est pareil en ADo mais je n'ai jamais
fait.

Si tu veux automatiser la base, apparemment le seul
moyen

est de la lancer par Shell en spécifiant le workgroup,
login et mot de passe, puis de récupérer le process
par

GetObject (,"Access.Application")
Personnellement je n'ai jamais réussi a récupérer le
shell

par Getobject, mais bon c'est ce qui est marqué
partout.

J

-----Message d'origine-----
J'ai un autre problème avec la sécurité, du moins je
me

pose une question :
J'ai une base qui vient attaquer la base que j'ai
sécurisée, et je ne voudrais pas que dans ce process
apparaisse une demande de mot de passe.
Qu'en sera-t-il ?

Merci !

-----Message d'origine-----
Alors:

- Le groupe utilisateurs contient toujours tous les
utilisateurs de ton fichier groupe de travail. En
fait

quel que soit le fichier mdw auquel tu es joint, le
compte

logué est toujours inscrit dans le groupe
utilisateurs.

Du

coup, si tu laisses des droits à ce groupe, tu
laisses

ces

droits à tous les utilisateurs d'Access

- Le compte administrateur par défaut ne peut pas
être

supprimé. Si tu veux lui retirer tous ses droits, tu
dois

le supprimer de tous les groupes ce qui le laissera
membre

de utilisateurs. Evidemment tu dois retirer les
droits

à

ce groupe pour que la sécurisation prenne effet.

Ah et sinon pour qu'une base soit réellement
sécurisée,

elle doit être créée par ton propre compte
administrateur.

En effet le créateur d'une base (ou d'un objet)
devient

son propriétaire, et il à tous les droits sur sa
propriété.

On peut changer le propriétaire de tous les objets,
mais

pas d'une base. Du coup, une base créée par le
compte

admin par défaut est accessible à tout le monde.

Bon et si tu veux plus d'infos sur ce modèle
complexe,

vas

voir la FAQ :
http://support.microsoft.com/support/access/content/s
e

c

f

a

q

..

asp
et il ya une bonne desxcription du modèle et du
systeme

de

comptes ici:
http://msdn.microsoft.com/library/default.asp?
url=/library/en-
us/odeopg/html/deovrrunninguserlevelsecuritywizard.as
p

-----Message d'origine-----
Hello à tous !

Je suis en train de suivre une procédure pas à pas
trouvée

dans les archives google pour appliquer
correctement

la

sécurité utilisateur.
Par contre je bute sur un point. Quand je créé
l'utilisateur qui deviendra l'administrateur, il me
le

met

par défaut dans le groupe utilisateurs. Et après,
même

si

je l'inscris dans "Administrateur", il ne veut pas
me

supprimer le compte adminitrateur par défaut.
Comment faire ??

Merci beaucoup d'avance :o)

Arnaud
.

.

.

.

.

.

.

Là je suis en train de mettre en place la sécurité sur une
base, car rien n'est sécurisé actuellement.
Mais je ne connais pas cette histoire de shell par contre.

-----Message d'origine-----
Franchement je crois pas...

Les noms d'utilisateurs et groupes sont chargés au
démarrage d'access. Tu peux démarrer Access avec un
parametre spécial par un raccourci windows, en effet.
C'est le principe qu'on utilise dans le Shell. A partir
d'une appli non sécurisée, on execute une autre instance
d'Access, mais sécurisée.

Le seul moyen de charger le bon fichier mdw, et donc
d'avoir la bonne identité, est de lancer access en le
spécifiant. Impossible de prendre une autre identité le
temps d'une requête, en tout cas j'en ai jamais entendu
parler...

Mais là tu conçois le systeme de sécurité ou il existe
déjà et tu veux t'y adapter??
J

-----Message d'origine-----
rerere :)

En fait l'architecture est celle du client, je n'ai pas
la

main dessus, et les formulaires se trouvent dans toutes
les bases, il n'y a pas de notion front/back. En fait,
il

y a une base qui peut éventuellement etre considéré
comme

front c'est la première.
Je sais que via un reccourci windows, on peut ouvrir une
base en mettant dans le raccourci login et pass. N'y a-t-
il pas un moyen de passer ces mêmes paramètres aux
requêtes qui vont taper dans la sécurisée ?

-----Message d'origine-----
re, :)

automatiser une base signifie que tu vas pouvoir
effectuer

des actions du style ouvrir un état, un formulaire,
etc.

Ceci nécessite un objet Application, et la procédure du
Shell lorsqu'il s'agit d'une base sécurisée.

Si tu veux simplement effectuer des opérations sur les
données (des requêtes) tu peux accéder à une base
distante

en DAO

Par contre je ne comprends pas trop ton architecture.
Quelle est la base qui contient les formulaires et les
requêtes de mise à jour? La base sécurisée?

Quoi qu'il en soit le principe est simple. Lorsque tu
essaie de passer une requete sur une table, le moteur
Jet

regarde ton identité, regarde les permissions
correspondantes pour la table, et dit oui ou non
suivant

ce qu'il trouve. Il faut donc que tu sois logué avec un
compte valide pour modifier une table, que ce soit par
DAO

ou qu'il s'agisse d'une table liée.
Tu peux lancer ton application interface en chargant le
fichier mdw sécurisé, te loguer, et là tu pourras
mettre

à

jour les données sur les bases sécurisées. Le seul
moyen

de n'avoir absolument aucune invite de login/mot de
passe

est, il me semble, de passer par le Shell.

J.

-----Message d'origine-----
Un nouveau merci pour ta réponse.
Qu'entends-tu par automatiser la base ?
En fait la structure est la suivante :
- Une base avec quelques tables et des requêtes
- Une base non sécurisée avec de nombreuses tables
- La base que je sécurise.
En fait un service lance via un formulaire des
requêtes

qui vont mettre à jour les données des deux autres
bases.

Les tables de celles-ci sont liées dans la première.
J'aurai donc bien malheureusement l'apparition d'une
boîte

de dialogue avec login/pass lorsqu'ils déclencheront
le

process depuis la première base ?

Merci encore

-----Message d'origine-----
Re,

Difficile d'attaquer une base securisée.
Par DAO, tu peux le faire normalement du moment que
tu

ouvres la base "attaquante" avec le bon fichier mdw,
et

logué sous un utilisateur ayant le droit d'ouvrir et
d'attaquer l'autre base.
J'imagine que c'est pareil en ADo mais je n'ai jamais
fait.

Si tu veux automatiser la base, apparemment le seul
moyen

est de la lancer par Shell en spécifiant le
workgroup,

login et mot de passe, puis de récupérer le process
par

GetObject (,"Access.Application")
Personnellement je n'ai jamais réussi a récupérer le
shell

par Getobject, mais bon c'est ce qui est marqué
partout.

J

-----Message d'origine-----
J'ai un autre problème avec la sécurité, du moins je
me

pose une question :
J'ai une base qui vient attaquer la base que j'ai
sécurisée, et je ne voudrais pas que dans ce process
apparaisse une demande de mot de passe.
Qu'en sera-t-il ?

Merci !

-----Message d'origine-----
Alors:

- Le groupe utilisateurs contient toujours tous les
utilisateurs de ton fichier groupe de travail. En
fait

quel que soit le fichier mdw auquel tu es joint, le
compte

logué est toujours inscrit dans le groupe
utilisateurs.

Du

coup, si tu laisses des droits à ce groupe, tu
laisses

ces

droits à tous les utilisateurs d'Access

- Le compte administrateur par défaut ne peut pas
être

supprimé. Si tu veux lui retirer tous ses droits,
tu

dois

le supprimer de tous les groupes ce qui le laissera
membre

de utilisateurs. Evidemment tu dois retirer les
droits

à

ce groupe pour que la sécurisation prenne effet.

Ah et sinon pour qu'une base soit réellement
sécurisée,

elle doit être créée par ton propre compte
administrateur.

En effet le créateur d'une base (ou d'un objet)
devient

son propriétaire, et il à tous les droits sur sa
propriété.

On peut changer le propriétaire de tous les objets,
mais

pas d'une base. Du coup, une base créée par le
compte

admin par défaut est accessible à tout le monde.

Bon et si tu veux plus d'infos sur ce modèle
complexe,

vas

voir la FAQ :
http://support.microsoft.com/support/access/content/
s

e

c

f

a

q

..

asp
et il ya une bonne desxcription du modèle et du
systeme

de

comptes ici:
http://msdn.microsoft.com/library/default.asp?
url=/library/en-
us/odeopg/html/deovrrunninguserlevelsecuritywizard.a
s

p

-----Message d'origine-----
Hello à tous !

Je suis en train de suivre une procédure pas à pas
trouvée

dans les archives google pour appliquer
correctement

la

sécurité utilisateur.
Par contre je bute sur un point. Quand je créé
l'utilisateur qui deviendra l'administrateur, il
me

le

met

par défaut dans le groupe utilisateurs. Et après,
même

si

je l'inscris dans "Administrateur", il ne veut pas
me

supprimer le compte adminitrateur par défaut.
Comment faire ??

Merci beaucoup d'avance :o)

Arnaud
.

.

.

.

.

.

.

.