désolé pour le cross-postage...
FU2 : microsoft.public.fr.windows.server.active_directory
Bonjour à tous,
Sur notre contrôleur AD windows 2003 serveur, nous avons établi une relation
de confiance avec un realm Kerberos extérieur (Heimdal KDC sur un serveur
Unix). Jusque là, tout va bien. Nos utilisateurs ouvrent une session sur
les postes du domaine en utilisant le realm kerberos et accèdent à toutes
les ressources du domaine en utilisant la relation de confiance. Le mapping
des comptes utilisateurs de l'AD vers le principal Kerberos correspondant
fonctionne aussi sans problème.
Par contre, nous avons un problème avec le fonctionnement des profils sur
les postes XP. Quand un utilisateurs ouvre une session sur un poste XP en
utilisant le realm Kerberos, son profil n'est pas mis à jour. S'il n'y a
pas de version cache locale du profil, un nouveau profil vierge est crée.
Si une version locale existe, elle est utilisée sans être mise à jour
depuis le serveur, même si ce n'est pas la dernière version du profil. A la
fermeture de session par contre, les modifications du profil sont
enregistrées sur le serveur, même si le profil n'est pas à jour et
éventuellement en écrasant des modifications existantes sur le serveur...
Tout cela bien sur sans message d'erreur ni avertissement à l'utilisateur !
Inutile de dire que ce comportement est dangereux et pourrait facilement
causer des pertes de données très dommageables pour les utilisateurs...
A noter que sur les postes Windows 2000, nous ne rencontrons pas le même
problème, les profils sont correctement chargés à l'ouverture de session...
Si quelqu'un ayant une configuration du même type avait des pistes ou même
simplement pouvait indiquer s'il observe le même comportement ou non, ce
serait le très bienvenu...
cordialement,
--
Pascal Levy
Ingénieur réseaux & ressources informatiques
Bibliothèque InterUniversitaire Sainte Geneviève
Bibliothèque InterUniversitaire de Langues Orientales
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
William Marie
"Pascal Levy" a écrit dans le message de news: 46459ff3$0$24809$
Question bête (car évidente, mais des fois, c'est l'évidence qu'on oublie) : est que les profils sont explicitement définis dans les propriétés des utilisateurs ? Il faut donc un dossier (chez moi c'est "Profils itinérants") partagé "Tout le monde" "controle total" et inscrire dans les propriétés à l'onglet profils "Ordi_serveurProfils itinérantsutilisateur". Devraient pas se faire bouloter par le Kador à 3 têtes, en principe. -- =================================== William Marie Attention antiSpam remplacer trapellun.invalid par free.fr Web : http://wmarie.free.fr http://www.pandemonium.dnsalias.org (site expérimental) ====================================
"Pascal Levy" <pascal.levy@univ-paris3.fr> a écrit dans le message de news:
46459ff3$0$24809$426a34cc@news.free.fr...
Question bête (car évidente, mais des fois, c'est l'évidence qu'on oublie) :
est que les profils sont explicitement définis dans les propriétés des
utilisateurs ? Il faut donc un dossier (chez moi c'est "Profils itinérants")
partagé "Tout le monde" "controle total" et inscrire dans les propriétés à
l'onglet profils "\Ordi_serveurProfils itinérantsutilisateur". Devraient
pas se faire bouloter par le Kador à 3 têtes, en principe.
--
=================================== William Marie
Attention antiSpam remplacer trapellun.invalid
par free.fr
Web : http://wmarie.free.fr
http://www.pandemonium.dnsalias.org (site expérimental)
====================================
"Pascal Levy" a écrit dans le message de news: 46459ff3$0$24809$
Question bête (car évidente, mais des fois, c'est l'évidence qu'on oublie) : est que les profils sont explicitement définis dans les propriétés des utilisateurs ? Il faut donc un dossier (chez moi c'est "Profils itinérants") partagé "Tout le monde" "controle total" et inscrire dans les propriétés à l'onglet profils "Ordi_serveurProfils itinérantsutilisateur". Devraient pas se faire bouloter par le Kador à 3 têtes, en principe. -- =================================== William Marie Attention antiSpam remplacer trapellun.invalid par free.fr Web : http://wmarie.free.fr http://www.pandemonium.dnsalias.org (site expérimental) ====================================
David Bonnay
Bonjour, As-tu essayé de mettre en place des scripts d'ouverture de session sur ton AD
Bonjour,
As-tu essayé de mettre en place des scripts d'ouverture de session sur
ton AD
Bonjour, As-tu essayé de mettre en place des scripts d'ouverture de session sur ton AD
Mathieu CHATEAU
Bonjour,
par défaut, XP n'attends pas le réseau pour ouvrir les sessions, ce qui peut poser des pb avec les profiles. Essayez en positionnant la GPO "toujours attendre le réseau"
Vu que ca cause Kerberos, j'imagine que toutes les machines concernées sont toutes à la même heure, à 5mn près au maximum ?
"Pascal Levy" wrote in message news:46459ff3$0$24809$
désolé pour le cross-postage... FU2 : microsoft.public.fr.windows.server.active_directory
Bonjour à tous,
Sur notre contrôleur AD windows 2003 serveur, nous avons établi une relation de confiance avec un realm Kerberos extérieur (Heimdal KDC sur un serveur Unix). Jusque là, tout va bien. Nos utilisateurs ouvrent une session sur les postes du domaine en utilisant le realm kerberos et accèdent à toutes les ressources du domaine en utilisant la relation de confiance. Le mapping des comptes utilisateurs de l'AD vers le principal Kerberos correspondant fonctionne aussi sans problème.
Par contre, nous avons un problème avec le fonctionnement des profils sur les postes XP. Quand un utilisateurs ouvre une session sur un poste XP en utilisant le realm Kerberos, son profil n'est pas mis à jour. S'il n'y a pas de version cache locale du profil, un nouveau profil vierge est crée. Si une version locale existe, elle est utilisée sans être mise à jour depuis le serveur, même si ce n'est pas la dernière version du profil. A la fermeture de session par contre, les modifications du profil sont enregistrées sur le serveur, même si le profil n'est pas à jour et éventuellement en écrasant des modifications existantes sur le serveur... Tout cela bien sur sans message d'erreur ni avertissement à l'utilisateur ! Inutile de dire que ce comportement est dangereux et pourrait facilement causer des pertes de données très dommageables pour les utilisateurs...
A noter que sur les postes Windows 2000, nous ne rencontrons pas le même problème, les profils sont correctement chargés à l'ouverture de session...
Si quelqu'un ayant une configuration du même type avait des pistes ou même simplement pouvait indiquer s'il observe le même comportement ou non, ce serait le très bienvenu...
cordialement,
-- Pascal Levy Ingénieur réseaux & ressources informatiques
Bibliothèque InterUniversitaire Sainte Geneviève Bibliothèque InterUniversitaire de Langues Orientales
Bonjour,
par défaut, XP n'attends pas le réseau pour ouvrir les sessions, ce qui peut
poser des pb avec les profiles.
Essayez en positionnant la GPO "toujours attendre le réseau"
Vu que ca cause Kerberos, j'imagine que toutes les machines concernées sont
toutes à la même heure, à 5mn près au maximum ?
"Pascal Levy" <pascal.levy@univ-paris3.fr> wrote in message
news:46459ff3$0$24809$426a34cc@news.free.fr...
désolé pour le cross-postage...
FU2 : microsoft.public.fr.windows.server.active_directory
Bonjour à tous,
Sur notre contrôleur AD windows 2003 serveur, nous avons établi une
relation
de confiance avec un realm Kerberos extérieur (Heimdal KDC sur un serveur
Unix). Jusque là, tout va bien. Nos utilisateurs ouvrent une session sur
les postes du domaine en utilisant le realm kerberos et accèdent à toutes
les ressources du domaine en utilisant la relation de confiance. Le
mapping
des comptes utilisateurs de l'AD vers le principal Kerberos correspondant
fonctionne aussi sans problème.
Par contre, nous avons un problème avec le fonctionnement des profils sur
les postes XP. Quand un utilisateurs ouvre une session sur un poste XP en
utilisant le realm Kerberos, son profil n'est pas mis à jour. S'il n'y a
pas de version cache locale du profil, un nouveau profil vierge est crée.
Si une version locale existe, elle est utilisée sans être mise à jour
depuis le serveur, même si ce n'est pas la dernière version du profil. A
la
fermeture de session par contre, les modifications du profil sont
enregistrées sur le serveur, même si le profil n'est pas à jour et
éventuellement en écrasant des modifications existantes sur le serveur...
Tout cela bien sur sans message d'erreur ni avertissement à l'utilisateur
!
Inutile de dire que ce comportement est dangereux et pourrait facilement
causer des pertes de données très dommageables pour les utilisateurs...
A noter que sur les postes Windows 2000, nous ne rencontrons pas le même
problème, les profils sont correctement chargés à l'ouverture de
session...
Si quelqu'un ayant une configuration du même type avait des pistes ou même
simplement pouvait indiquer s'il observe le même comportement ou non, ce
serait le très bienvenu...
cordialement,
--
Pascal Levy
Ingénieur réseaux & ressources informatiques
Bibliothèque InterUniversitaire Sainte Geneviève
Bibliothèque InterUniversitaire de Langues Orientales
par défaut, XP n'attends pas le réseau pour ouvrir les sessions, ce qui peut poser des pb avec les profiles. Essayez en positionnant la GPO "toujours attendre le réseau"
Vu que ca cause Kerberos, j'imagine que toutes les machines concernées sont toutes à la même heure, à 5mn près au maximum ?
"Pascal Levy" wrote in message news:46459ff3$0$24809$
désolé pour le cross-postage... FU2 : microsoft.public.fr.windows.server.active_directory
Bonjour à tous,
Sur notre contrôleur AD windows 2003 serveur, nous avons établi une relation de confiance avec un realm Kerberos extérieur (Heimdal KDC sur un serveur Unix). Jusque là, tout va bien. Nos utilisateurs ouvrent une session sur les postes du domaine en utilisant le realm kerberos et accèdent à toutes les ressources du domaine en utilisant la relation de confiance. Le mapping des comptes utilisateurs de l'AD vers le principal Kerberos correspondant fonctionne aussi sans problème.
Par contre, nous avons un problème avec le fonctionnement des profils sur les postes XP. Quand un utilisateurs ouvre une session sur un poste XP en utilisant le realm Kerberos, son profil n'est pas mis à jour. S'il n'y a pas de version cache locale du profil, un nouveau profil vierge est crée. Si une version locale existe, elle est utilisée sans être mise à jour depuis le serveur, même si ce n'est pas la dernière version du profil. A la fermeture de session par contre, les modifications du profil sont enregistrées sur le serveur, même si le profil n'est pas à jour et éventuellement en écrasant des modifications existantes sur le serveur... Tout cela bien sur sans message d'erreur ni avertissement à l'utilisateur ! Inutile de dire que ce comportement est dangereux et pourrait facilement causer des pertes de données très dommageables pour les utilisateurs...
A noter que sur les postes Windows 2000, nous ne rencontrons pas le même problème, les profils sont correctement chargés à l'ouverture de session...
Si quelqu'un ayant une configuration du même type avait des pistes ou même simplement pouvait indiquer s'il observe le même comportement ou non, ce serait le très bienvenu...
cordialement,
-- Pascal Levy Ingénieur réseaux & ressources informatiques
Bibliothèque InterUniversitaire Sainte Geneviève Bibliothèque InterUniversitaire de Langues Orientales
Pascal Levy
Pascal Levy wrote: (...)
Par contre, nous avons un problème avec le fonctionnement des profils sur les postes XP. Quand un utilisateurs ouvre une session sur un poste XP en utilisant le realm Kerberos, son profil n'est pas mis à jour. S'il n'y a
Comprenne qui peux... Windows XP demande que la GPO "autoriser les profils pour les connections entre forets" (ou quelque chose comme ca, je poste de tete...) soit active.... meme si la relation Kerberos n'est pas dans une foret, meme si le profil est un profil du domaine meme si... mais ca semble comme ca !
en tout cas, le probleme semble regle...
merci pour vos posts,
-- Pascal Levy Ingénieur réseaux & ressources informatiques
Bibliothèque InterUniversitaire Sainte Geneviève Bibliothèque InterUniversitaire de Langues Orientales
Pascal Levy wrote:
(...)
Par contre, nous avons un problème avec le fonctionnement des profils sur
les postes XP. Quand un utilisateurs ouvre une session sur un poste XP en
utilisant le realm Kerberos, son profil n'est pas mis à jour. S'il n'y a
Comprenne qui peux... Windows XP demande que la GPO "autoriser les profils
pour les connections entre forets" (ou quelque chose comme ca, je poste de
tete...) soit active.... meme si la relation Kerberos n'est pas dans une
foret, meme si le profil est un profil du domaine meme si... mais ca semble
comme ca !
en tout cas, le probleme semble regle...
merci pour vos posts,
--
Pascal Levy
Ingénieur réseaux & ressources informatiques
Bibliothèque InterUniversitaire Sainte Geneviève
Bibliothèque InterUniversitaire de Langues Orientales
Par contre, nous avons un problème avec le fonctionnement des profils sur les postes XP. Quand un utilisateurs ouvre une session sur un poste XP en utilisant le realm Kerberos, son profil n'est pas mis à jour. S'il n'y a
Comprenne qui peux... Windows XP demande que la GPO "autoriser les profils pour les connections entre forets" (ou quelque chose comme ca, je poste de tete...) soit active.... meme si la relation Kerberos n'est pas dans une foret, meme si le profil est un profil du domaine meme si... mais ca semble comme ca !
en tout cas, le probleme semble regle...
merci pour vos posts,
-- Pascal Levy Ingénieur réseaux & ressources informatiques
Bibliothèque InterUniversitaire Sainte Geneviève Bibliothèque InterUniversitaire de Langues Orientales
noname
Pascal Levy wrote:
snip
Sur notre contrôleur AD windows 2003 serveur, nous avons établi une relation de confiance avec un snip
Une relation de confiance sous M$ ? Ok je sors.
Pascal Levy wrote:
snip
Sur notre contrôleur AD windows 2003 serveur, nous avons établi une
relation de confiance avec un
snip