En cas d'absence d'un DC ....

Le
Dom
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)

Merci à vous !!
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Mathieu CHATEAU
Le #765849
il faudrait en plus activer le compte "invité", ce qui est très mal d'un
point de vue sécurité

--
Cordialement,
Mathieu CHATEAU
http://lordoftheping.blogspot.com


"Dom" 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 ?

(je precise, partition en FAT32 donc pas de permissions NTFS en sus des
permissions de partage)

Merci à vous !!





Jacques Barathon [MS]
Le #776038
"Dom" 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

Mathieu CHATEAU
Le #775798
Bonjour,

un ticket kerberos dure 10 heures par défaut

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/511.mspx?mfr=true


--
Cordialement,
Mathieu CHATEAU
http://lordoftheping.blogspot.com


"Jacques Barathon [MS]" news:%
"Dom" 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
Le #775797
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
Le #775796
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

--
Cordialement,
Mathieu CHATEAU
http://lordoftheping.blogspot.com


"Dom" news:46fac340$0$22552$
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
Le #775794
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"
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

--
Cordialement,
Mathieu CHATEAU
http://lordoftheping.blogspot.com


"Dom" news:46fac340$0$22552$
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
Le #775793
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



--
Cordialement,
Mathieu CHATEAU
http://lordoftheping.blogspot.com


"Dom" news:46fad5ce$0$7072$
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"
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

--
Cordialement,
Mathieu CHATEAU
http://lordoftheping.blogspot.com


"Dom" news:46fac340$0$22552$
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
Le #775792
une autre solution est d'activer le compte "invité", ce qui est très mal
d'un point de vue sécurité

--
Cordialement,
Mathieu CHATEAU
http://lordoftheping.blogspot.com


"Dom" news:46fad5ce$0$7072$
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"
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

--
Cordialement,
Mathieu CHATEAU
http://lordoftheping.blogspot.com


"Dom" news:46fac340$0$22552$
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
Le #775790
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]
Le #775789
"Dom" 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

Publicité
Poster une réponse
Anonyme