Petite question:
Un partage est en CT pour "Tout le monde". Si pour une raison donnée, le DC
se retrouve offline et ne peut plus valider les authentifications d'accès à
ce partage, un UserA serait il considéré comme un Anonymous User s'il
tentait d'accéder au partage ??? En gros, si je veux pouvoir autoriser
l'accès à un partage meme sans DC pour valider l'authentification, le fait
de donner un CT pour "Anonymous User" me permettrait il d'y parvenir ?
(je precise, partition en FAT32 donc pas de permissions NTFS en sus des
permissions de partage)
Petite question: Un partage est en CT pour "Tout le monde". Si pour une raison donnée, le DC se retrouve offline et ne peut plus valider les authentifications d'accès à ce partage, un UserA serait il considéré comme un Anonymous User s'il tentait d'accéder au partage ??? En gros, si je veux pouvoir autoriser l'accès à un partage meme sans DC pour valider l'authentification, le fait de donner un CT pour "Anonymous User" me permettrait il d'y parvenir ?
(je precise, partition en FAT32 donc pas de permissions NTFS en sus des permissions de partage)
Merci à vous !!
il faudrait en plus activer le compte "invité", ce qui est très mal d'un
point de vue sécurité
"Dom" <laurentPASdomSPAM@libre.fr> wrote in message
news:46f42370$0$9005$426a34cc@news.free.fr...
Bonsoir à tous,
Petite question:
Un partage est en CT pour "Tout le monde". Si pour une raison donnée, le
DC se retrouve offline et ne peut plus valider les authentifications
d'accès à ce partage, un UserA serait il considéré comme un Anonymous User
s'il tentait d'accéder au partage ??? En gros, si je veux pouvoir
autoriser l'accès à un partage meme sans DC pour valider
l'authentification, le fait de donner un CT pour "Anonymous User" me
permettrait il d'y parvenir ?
(je precise, partition en FAT32 donc pas de permissions NTFS en sus des
permissions de partage)
Petite question: Un partage est en CT pour "Tout le monde". Si pour une raison donnée, le DC se retrouve offline et ne peut plus valider les authentifications d'accès à ce partage, un UserA serait il considéré comme un Anonymous User s'il tentait d'accéder au partage ??? En gros, si je veux pouvoir autoriser l'accès à un partage meme sans DC pour valider l'authentification, le fait de donner un CT pour "Anonymous User" me permettrait il d'y parvenir ?
(je precise, partition en FAT32 donc pas de permissions NTFS en sus des permissions de partage)
Merci à vous !!
Jacques Barathon [MS]
"Dom" wrote in message news:46f42370$0$9005$
Bonsoir à tous,
Petite question: Un partage est en CT pour "Tout le monde". Si pour une raison donnée, le DC se retrouve offline et ne peut plus valider les authentifications d'accès à ce partage, un UserA serait il considéré comme un Anonymous User s'il tentait d'accéder au partage ??? En gros, si je veux pouvoir autoriser l'accès à un partage meme sans DC pour valider l'authentification, le fait de donner un CT pour "Anonymous User" me permettrait il d'y parvenir ?
Si je me souviens bien, dans un environnement AD un client doit pouvoir continuer à se connecter aux ressources partagées en l'absence de DC, tant que le ticket Kerberos fourni par le poste client reste valide. Je ne me rappelle pas la durée de validité standard d'un ticket mais elle doit être au moins de quelques heures. De plus, une connexion déjà établie avec un serveur n'expire pas tant que la connexion reste ouverte, même si le ticket lui-même a expiré.
Quant à ouvrir les accès aux utilisateurs anonymes ou à tout le monde, c'est une mauvaise idée, comme déjà souligné par Mathieu.
Jacques
"Dom" <laurentPASdomSPAM@libre.fr> wrote in message
news:46f42370$0$9005$426a34cc@news.free.fr...
Bonsoir à tous,
Petite question:
Un partage est en CT pour "Tout le monde". Si pour une raison donnée, le
DC se retrouve offline et ne peut plus valider les authentifications
d'accès à ce partage, un UserA serait il considéré comme un Anonymous User
s'il tentait d'accéder au partage ??? En gros, si je veux pouvoir
autoriser l'accès à un partage meme sans DC pour valider
l'authentification, le fait de donner un CT pour "Anonymous User" me
permettrait il d'y parvenir ?
Si je me souviens bien, dans un environnement AD un client doit pouvoir
continuer à se connecter aux ressources partagées en l'absence de DC, tant
que le ticket Kerberos fourni par le poste client reste valide. Je ne me
rappelle pas la durée de validité standard d'un ticket mais elle doit être
au moins de quelques heures. De plus, une connexion déjà établie avec un
serveur n'expire pas tant que la connexion reste ouverte, même si le ticket
lui-même a expiré.
Quant à ouvrir les accès aux utilisateurs anonymes ou à tout le monde, c'est
une mauvaise idée, comme déjà souligné par Mathieu.
Petite question: Un partage est en CT pour "Tout le monde". Si pour une raison donnée, le DC se retrouve offline et ne peut plus valider les authentifications d'accès à ce partage, un UserA serait il considéré comme un Anonymous User s'il tentait d'accéder au partage ??? En gros, si je veux pouvoir autoriser l'accès à un partage meme sans DC pour valider l'authentification, le fait de donner un CT pour "Anonymous User" me permettrait il d'y parvenir ?
Si je me souviens bien, dans un environnement AD un client doit pouvoir continuer à se connecter aux ressources partagées en l'absence de DC, tant que le ticket Kerberos fourni par le poste client reste valide. Je ne me rappelle pas la durée de validité standard d'un ticket mais elle doit être au moins de quelques heures. De plus, une connexion déjà établie avec un serveur n'expire pas tant que la connexion reste ouverte, même si le ticket lui-même a expiré.
Quant à ouvrir les accès aux utilisateurs anonymes ou à tout le monde, c'est une mauvaise idée, comme déjà souligné par Mathieu.
Petite question: Un partage est en CT pour "Tout le monde". Si pour une raison donnée, le DC se retrouve offline et ne peut plus valider les authentifications d'accès à ce partage, un UserA serait il considéré comme un Anonymous User s'il tentait d'accéder au partage ??? En gros, si je veux pouvoir autoriser l'accès à un partage meme sans DC pour valider l'authentification, le fait de donner un CT pour "Anonymous User" me permettrait il d'y parvenir ?
Si je me souviens bien, dans un environnement AD un client doit pouvoir continuer à se connecter aux ressources partagées en l'absence de DC, tant que le ticket Kerberos fourni par le poste client reste valide. Je ne me rappelle pas la durée de validité standard d'un ticket mais elle doit être au moins de quelques heures. De plus, une connexion déjà établie avec un serveur n'expire pas tant que la connexion reste ouverte, même si le ticket lui-même a expiré.
Quant à ouvrir les accès aux utilisateurs anonymes ou à tout le monde, c'est une mauvaise idée, comme déjà souligné par Mathieu.
"Jacques Barathon [MS]" <jbaratho@online.microsoft.com> wrote in message
news:%23jH4ztEAIHA.1208@TK2MSFTNGP03.phx.gbl...
"Dom" <laurentPASdomSPAM@libre.fr> wrote in message
news:46f42370$0$9005$426a34cc@news.free.fr...
Bonsoir à tous,
Petite question:
Un partage est en CT pour "Tout le monde". Si pour une raison donnée, le
DC se retrouve offline et ne peut plus valider les authentifications
d'accès à ce partage, un UserA serait il considéré comme un Anonymous
User s'il tentait d'accéder au partage ??? En gros, si je veux pouvoir
autoriser l'accès à un partage meme sans DC pour valider
l'authentification, le fait de donner un CT pour "Anonymous User" me
permettrait il d'y parvenir ?
Si je me souviens bien, dans un environnement AD un client doit pouvoir
continuer à se connecter aux ressources partagées en l'absence de DC, tant
que le ticket Kerberos fourni par le poste client reste valide. Je ne me
rappelle pas la durée de validité standard d'un ticket mais elle doit être
au moins de quelques heures. De plus, une connexion déjà établie avec un
serveur n'expire pas tant que la connexion reste ouverte, même si le
ticket lui-même a expiré.
Quant à ouvrir les accès aux utilisateurs anonymes ou à tout le monde,
c'est une mauvaise idée, comme déjà souligné par Mathieu.
Petite question: Un partage est en CT pour "Tout le monde". Si pour une raison donnée, le DC se retrouve offline et ne peut plus valider les authentifications d'accès à ce partage, un UserA serait il considéré comme un Anonymous User s'il tentait d'accéder au partage ??? En gros, si je veux pouvoir autoriser l'accès à un partage meme sans DC pour valider l'authentification, le fait de donner un CT pour "Anonymous User" me permettrait il d'y parvenir ?
Si je me souviens bien, dans un environnement AD un client doit pouvoir continuer à se connecter aux ressources partagées en l'absence de DC, tant que le ticket Kerberos fourni par le poste client reste valide. Je ne me rappelle pas la durée de validité standard d'un ticket mais elle doit être au moins de quelques heures. De plus, une connexion déjà établie avec un serveur n'expire pas tant que la connexion reste ouverte, même si le ticket lui-même a expiré.
Quant à ouvrir les accès aux utilisateurs anonymes ou à tout le monde, c'est une mauvaise idée, comme déjà souligné par Mathieu.
Jacques
Dom
Merci à vous 2 de vos réponses. Hélas, le pb reste entier pour moi. En effet, les DCs st sur un site distant avec un lien WAN pour relier le serveur en magasin et les DCs. Il est déjà arrivé que le lien WAN tombe pdt plusieurs jours .... D'ou mon soucis de continuité de service ... sur la durée.
Merci à vous 2 de vos réponses.
Hélas, le pb reste entier pour moi. En effet, les DCs st sur un site distant
avec un lien WAN pour relier le serveur en magasin et les DCs. Il est déjà
arrivé que le lien WAN tombe pdt plusieurs jours .... D'ou mon soucis de
continuité de service ... sur la durée.
Merci à vous 2 de vos réponses. Hélas, le pb reste entier pour moi. En effet, les DCs st sur un site distant avec un lien WAN pour relier le serveur en magasin et les DCs. Il est déjà arrivé que le lien WAN tombe pdt plusieurs jours .... D'ou mon soucis de continuité de service ... sur la durée.
Mathieu CHATEAU
Si vous avez un serveur sur place, ne pourrait-il pas être DC ? A quoi sert ce partage ? il y a sûrement des solutions de contournement
Merci à vous 2 de vos réponses. Hélas, le pb reste entier pour moi. En effet, les DCs st sur un site distant avec un lien WAN pour relier le serveur en magasin et les DCs. Il est déjà arrivé que le lien WAN tombe pdt plusieurs jours .... D'ou mon soucis de continuité de service ... sur la durée.
Si vous avez un serveur sur place, ne pourrait-il pas être DC ?
A quoi sert ce partage ? il y a sûrement des solutions de contournement
"Dom" <laurentPASdomSPAM@libre.fr> wrote in message
news:46fac340$0$22552$426a74cc@news.free.fr...
Merci à vous 2 de vos réponses.
Hélas, le pb reste entier pour moi. En effet, les DCs st sur un site
distant avec un lien WAN pour relier le serveur en magasin et les DCs. Il
est déjà arrivé que le lien WAN tombe pdt plusieurs jours .... D'ou mon
soucis de continuité de service ... sur la durée.
Merci à vous 2 de vos réponses. Hélas, le pb reste entier pour moi. En effet, les DCs st sur un site distant avec un lien WAN pour relier le serveur en magasin et les DCs. Il est déjà arrivé que le lien WAN tombe pdt plusieurs jours .... D'ou mon soucis de continuité de service ... sur la durée.
Dom
Disons que le cas se presente sur plusieurs 100aines de sites (1 magasin = 1 cas) !!! D'ou ma volonté de ne pas voir arriver qq 100aines de DCs supplémentaires à gerer .... La problématique est du au fait qu'une appli d'encaissement sur les stations de travail (caisses) fait appel à un fichier ini se trouvant sur le serveur pour se lancer. Et ce fichier ini est sur le fameux partage ..... Pas de possibilité de modifier le prog d'encaissement pour lui dire d'aller chercher ailleurs le fameux fichier ..... (pour etre totalement exact ds mon descriptif, j'ajoute que mon "serveur" magasin est en fait un 2000 pro car il n'y a jamais plus de 10 caisses par magasin...).
"Mathieu CHATEAU" a écrit dans le message de news:
Si vous avez un serveur sur place, ne pourrait-il pas être DC ? A quoi sert ce partage ? il y a sûrement des solutions de contournement
Merci à vous 2 de vos réponses. Hélas, le pb reste entier pour moi. En effet, les DCs st sur un site distant avec un lien WAN pour relier le serveur en magasin et les DCs. Il est déjà arrivé que le lien WAN tombe pdt plusieurs jours .... D'ou mon soucis de continuité de service ... sur la durée.
Disons que le cas se presente sur plusieurs 100aines de sites (1 magasin = 1
cas) !!! D'ou ma volonté de ne pas voir arriver qq 100aines de DCs
supplémentaires à gerer ....
La problématique est du au fait qu'une appli d'encaissement sur les stations
de travail (caisses) fait appel à un fichier ini se trouvant sur le serveur
pour se lancer. Et ce fichier ini est sur le fameux partage .....
Pas de possibilité de modifier le prog d'encaissement pour lui dire d'aller
chercher ailleurs le fameux fichier .....
(pour etre totalement exact ds mon descriptif, j'ajoute que mon "serveur"
magasin est en fait un 2000 pro car il n'y a jamais plus de 10 caisses par
magasin...).
"Mathieu CHATEAU" <gollum123@free.fr> a écrit dans le message de news:
utkBC5HAIHA.1208@TK2MSFTNGP05.phx.gbl...
Si vous avez un serveur sur place, ne pourrait-il pas être DC ?
A quoi sert ce partage ? il y a sûrement des solutions de contournement
"Dom" <laurentPASdomSPAM@libre.fr> wrote in message
news:46fac340$0$22552$426a74cc@news.free.fr...
Merci à vous 2 de vos réponses.
Hélas, le pb reste entier pour moi. En effet, les DCs st sur un site
distant avec un lien WAN pour relier le serveur en magasin et les DCs. Il
est déjà arrivé que le lien WAN tombe pdt plusieurs jours .... D'ou mon
soucis de continuité de service ... sur la durée.
Disons que le cas se presente sur plusieurs 100aines de sites (1 magasin = 1 cas) !!! D'ou ma volonté de ne pas voir arriver qq 100aines de DCs supplémentaires à gerer .... La problématique est du au fait qu'une appli d'encaissement sur les stations de travail (caisses) fait appel à un fichier ini se trouvant sur le serveur pour se lancer. Et ce fichier ini est sur le fameux partage ..... Pas de possibilité de modifier le prog d'encaissement pour lui dire d'aller chercher ailleurs le fameux fichier ..... (pour etre totalement exact ds mon descriptif, j'ajoute que mon "serveur" magasin est en fait un 2000 pro car il n'y a jamais plus de 10 caisses par magasin...).
"Mathieu CHATEAU" a écrit dans le message de news:
Si vous avez un serveur sur place, ne pourrait-il pas être DC ? A quoi sert ce partage ? il y a sûrement des solutions de contournement
Merci à vous 2 de vos réponses. Hélas, le pb reste entier pour moi. En effet, les DCs st sur un site distant avec un lien WAN pour relier le serveur en magasin et les DCs. Il est déjà arrivé que le lien WAN tombe pdt plusieurs jours .... D'ou mon soucis de continuité de service ... sur la durée.
Mathieu CHATEAU
Pourquoi ne pas faire l'inverse ? le serveur copie en local sur chaque station le fichier ini ? tant qu'il est up, il rafraichit le fichier sur les 10 pc. S'il n'est plus là, ils ont encore le dernier fichier valide.
Quand un pc démarre (s'ils sont arrêtés), une tâche planifiée collecte le fichier ini tout de suite
Disons que le cas se presente sur plusieurs 100aines de sites (1 magasin = 1 cas) !!! D'ou ma volonté de ne pas voir arriver qq 100aines de DCs supplémentaires à gerer .... La problématique est du au fait qu'une appli d'encaissement sur les stations de travail (caisses) fait appel à un fichier ini se trouvant sur le serveur pour se lancer. Et ce fichier ini est sur le fameux partage ..... Pas de possibilité de modifier le prog d'encaissement pour lui dire d'aller chercher ailleurs le fameux fichier ..... (pour etre totalement exact ds mon descriptif, j'ajoute que mon "serveur" magasin est en fait un 2000 pro car il n'y a jamais plus de 10 caisses par magasin...).
"Mathieu CHATEAU" a écrit dans le message de news:
Si vous avez un serveur sur place, ne pourrait-il pas être DC ? A quoi sert ce partage ? il y a sûrement des solutions de contournement
Merci à vous 2 de vos réponses. Hélas, le pb reste entier pour moi. En effet, les DCs st sur un site distant avec un lien WAN pour relier le serveur en magasin et les DCs. Il est déjà arrivé que le lien WAN tombe pdt plusieurs jours .... D'ou mon soucis de continuité de service ... sur la durée.
Pourquoi ne pas faire l'inverse ?
le serveur copie en local sur chaque station le fichier ini ?
tant qu'il est up, il rafraichit le fichier sur les 10 pc.
S'il n'est plus là, ils ont encore le dernier fichier valide.
Quand un pc démarre (s'ils sont arrêtés), une tâche planifiée collecte le
fichier ini tout de suite
"Dom" <laurentPASdomSPAM@libre.fr> wrote in message
news:46fad5ce$0$7072$426a74cc@news.free.fr...
Disons que le cas se presente sur plusieurs 100aines de sites (1 magasin =
1 cas) !!! D'ou ma volonté de ne pas voir arriver qq 100aines de DCs
supplémentaires à gerer ....
La problématique est du au fait qu'une appli d'encaissement sur les
stations de travail (caisses) fait appel à un fichier ini se trouvant sur
le serveur pour se lancer. Et ce fichier ini est sur le fameux partage
.....
Pas de possibilité de modifier le prog d'encaissement pour lui dire
d'aller chercher ailleurs le fameux fichier .....
(pour etre totalement exact ds mon descriptif, j'ajoute que mon "serveur"
magasin est en fait un 2000 pro car il n'y a jamais plus de 10 caisses par
magasin...).
"Mathieu CHATEAU" <gollum123@free.fr> a écrit dans le message de news:
utkBC5HAIHA.1208@TK2MSFTNGP05.phx.gbl...
Si vous avez un serveur sur place, ne pourrait-il pas être DC ?
A quoi sert ce partage ? il y a sûrement des solutions de contournement
"Dom" <laurentPASdomSPAM@libre.fr> wrote in message
news:46fac340$0$22552$426a74cc@news.free.fr...
Merci à vous 2 de vos réponses.
Hélas, le pb reste entier pour moi. En effet, les DCs st sur un site
distant avec un lien WAN pour relier le serveur en magasin et les DCs.
Il est déjà arrivé que le lien WAN tombe pdt plusieurs jours .... D'ou
mon soucis de continuité de service ... sur la durée.
Pourquoi ne pas faire l'inverse ? le serveur copie en local sur chaque station le fichier ini ? tant qu'il est up, il rafraichit le fichier sur les 10 pc. S'il n'est plus là, ils ont encore le dernier fichier valide.
Quand un pc démarre (s'ils sont arrêtés), une tâche planifiée collecte le fichier ini tout de suite
Disons que le cas se presente sur plusieurs 100aines de sites (1 magasin = 1 cas) !!! D'ou ma volonté de ne pas voir arriver qq 100aines de DCs supplémentaires à gerer .... La problématique est du au fait qu'une appli d'encaissement sur les stations de travail (caisses) fait appel à un fichier ini se trouvant sur le serveur pour se lancer. Et ce fichier ini est sur le fameux partage ..... Pas de possibilité de modifier le prog d'encaissement pour lui dire d'aller chercher ailleurs le fameux fichier ..... (pour etre totalement exact ds mon descriptif, j'ajoute que mon "serveur" magasin est en fait un 2000 pro car il n'y a jamais plus de 10 caisses par magasin...).
"Mathieu CHATEAU" a écrit dans le message de news:
Si vous avez un serveur sur place, ne pourrait-il pas être DC ? A quoi sert ce partage ? il y a sûrement des solutions de contournement
Merci à vous 2 de vos réponses. Hélas, le pb reste entier pour moi. En effet, les DCs st sur un site distant avec un lien WAN pour relier le serveur en magasin et les DCs. Il est déjà arrivé que le lien WAN tombe pdt plusieurs jours .... D'ou mon soucis de continuité de service ... sur la durée.
Mathieu CHATEAU
une autre solution est d'activer le compte "invité", ce qui est très mal d'un point de vue sécurité
Disons que le cas se presente sur plusieurs 100aines de sites (1 magasin = 1 cas) !!! D'ou ma volonté de ne pas voir arriver qq 100aines de DCs supplémentaires à gerer .... La problématique est du au fait qu'une appli d'encaissement sur les stations de travail (caisses) fait appel à un fichier ini se trouvant sur le serveur pour se lancer. Et ce fichier ini est sur le fameux partage ..... Pas de possibilité de modifier le prog d'encaissement pour lui dire d'aller chercher ailleurs le fameux fichier ..... (pour etre totalement exact ds mon descriptif, j'ajoute que mon "serveur" magasin est en fait un 2000 pro car il n'y a jamais plus de 10 caisses par magasin...).
"Mathieu CHATEAU" a écrit dans le message de news:
Si vous avez un serveur sur place, ne pourrait-il pas être DC ? A quoi sert ce partage ? il y a sûrement des solutions de contournement
Merci à vous 2 de vos réponses. Hélas, le pb reste entier pour moi. En effet, les DCs st sur un site distant avec un lien WAN pour relier le serveur en magasin et les DCs. Il est déjà arrivé que le lien WAN tombe pdt plusieurs jours .... D'ou mon soucis de continuité de service ... sur la durée.
une autre solution est d'activer le compte "invité", ce qui est très mal
d'un point de vue sécurité
"Dom" <laurentPASdomSPAM@libre.fr> wrote in message
news:46fad5ce$0$7072$426a74cc@news.free.fr...
Disons que le cas se presente sur plusieurs 100aines de sites (1 magasin =
1 cas) !!! D'ou ma volonté de ne pas voir arriver qq 100aines de DCs
supplémentaires à gerer ....
La problématique est du au fait qu'une appli d'encaissement sur les
stations de travail (caisses) fait appel à un fichier ini se trouvant sur
le serveur pour se lancer. Et ce fichier ini est sur le fameux partage
.....
Pas de possibilité de modifier le prog d'encaissement pour lui dire
d'aller chercher ailleurs le fameux fichier .....
(pour etre totalement exact ds mon descriptif, j'ajoute que mon "serveur"
magasin est en fait un 2000 pro car il n'y a jamais plus de 10 caisses par
magasin...).
"Mathieu CHATEAU" <gollum123@free.fr> a écrit dans le message de news:
utkBC5HAIHA.1208@TK2MSFTNGP05.phx.gbl...
Si vous avez un serveur sur place, ne pourrait-il pas être DC ?
A quoi sert ce partage ? il y a sûrement des solutions de contournement
"Dom" <laurentPASdomSPAM@libre.fr> wrote in message
news:46fac340$0$22552$426a74cc@news.free.fr...
Merci à vous 2 de vos réponses.
Hélas, le pb reste entier pour moi. En effet, les DCs st sur un site
distant avec un lien WAN pour relier le serveur en magasin et les DCs.
Il est déjà arrivé que le lien WAN tombe pdt plusieurs jours .... D'ou
mon soucis de continuité de service ... sur la durée.
Disons que le cas se presente sur plusieurs 100aines de sites (1 magasin = 1 cas) !!! D'ou ma volonté de ne pas voir arriver qq 100aines de DCs supplémentaires à gerer .... La problématique est du au fait qu'une appli d'encaissement sur les stations de travail (caisses) fait appel à un fichier ini se trouvant sur le serveur pour se lancer. Et ce fichier ini est sur le fameux partage ..... Pas de possibilité de modifier le prog d'encaissement pour lui dire d'aller chercher ailleurs le fameux fichier ..... (pour etre totalement exact ds mon descriptif, j'ajoute que mon "serveur" magasin est en fait un 2000 pro car il n'y a jamais plus de 10 caisses par magasin...).
"Mathieu CHATEAU" a écrit dans le message de news:
Si vous avez un serveur sur place, ne pourrait-il pas être DC ? A quoi sert ce partage ? il y a sûrement des solutions de contournement
Merci à vous 2 de vos réponses. Hélas, le pb reste entier pour moi. En effet, les DCs st sur un site distant avec un lien WAN pour relier le serveur en magasin et les DCs. Il est déjà arrivé que le lien WAN tombe pdt plusieurs jours .... D'ou mon soucis de continuité de service ... sur la durée.
Dom
Finalement, je suis parvenu à trouver une solution: Il existe sur les caisses et le serveur du magasin un compte PowerUser nommé UserA. Si dès l'ouverture de session AD de l'utilisateur je mappe via un batch avec net use un lecteur quelconque sur le partage du serveur (via le menu demarrer --> programme --> demarrage) en m'appuyant sur les infos d'autentification du compte local USerA, il semble bien que l'accès au partage se fait ensuite en s'appuyant sur ces infos là et non pas sur les infos d'autentification du compte ayant ouvert la session sur le PC ....
Finalement, je suis parvenu à trouver une solution:
Il existe sur les caisses et le serveur du magasin un compte PowerUser nommé
UserA.
Si dès l'ouverture de session AD de l'utilisateur je mappe via un batch avec
net use un lecteur quelconque sur le partage du serveur (via le menu
demarrer --> programme --> demarrage) en m'appuyant sur les infos
d'autentification du compte local USerA, il semble bien que l'accès au
partage se fait ensuite en s'appuyant sur ces infos là et non pas sur les
infos d'autentification du compte ayant ouvert la session sur le PC ....
Finalement, je suis parvenu à trouver une solution: Il existe sur les caisses et le serveur du magasin un compte PowerUser nommé UserA. Si dès l'ouverture de session AD de l'utilisateur je mappe via un batch avec net use un lecteur quelconque sur le partage du serveur (via le menu demarrer --> programme --> demarrage) en m'appuyant sur les infos d'autentification du compte local USerA, il semble bien que l'accès au partage se fait ensuite en s'appuyant sur ces infos là et non pas sur les infos d'autentification du compte ayant ouvert la session sur le PC ....
Jacques Barathon [MS]
"Dom" wrote in message news:46fbd316$0$22337$
Finalement, je suis parvenu à trouver une solution: Il existe sur les caisses et le serveur du magasin un compte PowerUser nommé UserA. Si dès l'ouverture de session AD de l'utilisateur je mappe via un batch avec net use un lecteur quelconque sur le partage du serveur (via le menu demarrer --> programme --> demarrage) en m'appuyant sur les infos d'autentification du compte local USerA, il semble bien que l'accès au partage se fait ensuite en s'appuyant sur ces infos là et non pas sur les infos d'autentification du compte ayant ouvert la session sur le PC ....
C'est effectivement une solution de contournement valable. Bien vu.
Sinon, question peut-être idiote, mais n'y aurait-il pas moyen de remplacer l'infrastructure WAN qui vous fournit un si mauvais niveau de service? Avec le développement de l'ADSL il serait possible d'installer des petits routeurs ADSL qui feraient en même temps client VPN (ou à défaut, la fonction de client VPN/routeur pour les postes locaux pourrait également être prise en charge par le serveur en 2000 Pro).
Jacques
"Dom" <laurentPASdomSPAM@libre.fr> wrote in message
news:46fbd316$0$22337$426a74cc@news.free.fr...
Finalement, je suis parvenu à trouver une solution:
Il existe sur les caisses et le serveur du magasin un compte PowerUser
nommé UserA.
Si dès l'ouverture de session AD de l'utilisateur je mappe via un batch
avec net use un lecteur quelconque sur le partage du serveur (via le menu
demarrer --> programme --> demarrage) en m'appuyant sur les infos
d'autentification du compte local USerA, il semble bien que l'accès au
partage se fait ensuite en s'appuyant sur ces infos là et non pas sur les
infos d'autentification du compte ayant ouvert la session sur le PC ....
C'est effectivement une solution de contournement valable. Bien vu.
Sinon, question peut-être idiote, mais n'y aurait-il pas moyen de remplacer
l'infrastructure WAN qui vous fournit un si mauvais niveau de service? Avec
le développement de l'ADSL il serait possible d'installer des petits
routeurs ADSL qui feraient en même temps client VPN (ou à défaut, la
fonction de client VPN/routeur pour les postes locaux pourrait également
être prise en charge par le serveur en 2000 Pro).
Finalement, je suis parvenu à trouver une solution: Il existe sur les caisses et le serveur du magasin un compte PowerUser nommé UserA. Si dès l'ouverture de session AD de l'utilisateur je mappe via un batch avec net use un lecteur quelconque sur le partage du serveur (via le menu demarrer --> programme --> demarrage) en m'appuyant sur les infos d'autentification du compte local USerA, il semble bien que l'accès au partage se fait ensuite en s'appuyant sur ces infos là et non pas sur les infos d'autentification du compte ayant ouvert la session sur le PC ....
C'est effectivement une solution de contournement valable. Bien vu.
Sinon, question peut-être idiote, mais n'y aurait-il pas moyen de remplacer l'infrastructure WAN qui vous fournit un si mauvais niveau de service? Avec le développement de l'ADSL il serait possible d'installer des petits routeurs ADSL qui feraient en même temps client VPN (ou à défaut, la fonction de client VPN/routeur pour les postes locaux pourrait également être prise en charge par le serveur en 2000 Pro).
