après de nombreuses recherches, je me trouve coincé sur un problème assez bizarre...
Je suis en train de mettre en place une salle info avec un serveur sous debian avec samba/ldap et une vingtaine de poste sous Windows XP Pro.
Tout fonctionne à merveille, les profils itinérants se chargent bien, les partages se montent, etc
Cependant, lors de la connexion d'un utilisateur pour la première fois, il doit créer son mot de passe. Et là, le profil itinérant ne se créé pas, mais un profil local se charge à la place. Ce n'est seulement lorsque ce dernier se connectera sur une autre machine qu'il pourra avoir accès à son profil...
J'ai compris ceci après avoir regardé les logs de smbd.
Ici l'utilisateur n'a pas eu besoin de changer son mot de passe. On voit bien les différents services se charger :
[2010/02/09 16:36:08, 1] smbd/service.c:make_connection_snum(1198)
pc-etu (::ffff:192.168.10.21) connect to service profiles initially as user test6 (uid=1047, gid=513) (pid 6392)
[2010/02/09 16:36:08, 1] smbd/service.c:make_connection_snum(1198)
pc-etu (::ffff:192.168.10.21) connect to service profiles initially as user test6 (uid=1047, gid=513) (pid 6392)
[2010/02/09 16:36:09, 1] smbd/service.c:make_connection_snum(1198)
pc-etu (::ffff:192.168.10.21) connect to service netlogon initially as user test6 (uid=1047, gid=513) (pid 6392)
[2010/02/09 16:36:13, 1] smbd/service.c:make_connection_snum(1198)
pc-etu (::ffff:192.168.10.21) connect to service test6 initially as user test6 (uid=1047, gid=513) (pid 6392)
Alors que là, le changement de mot de passe d'opère, mais pas tout les services se chargent :
[2010/02/09 16:40:01, 1] auth/auth_sam.c:sam_account_ok(172)
sam_account_ok: Account for user 'test6' password must change!.
[2010/02/09 16:40:10, 1] smbd/service.c:make_connection_snum(1198)
pc-etu (::ffff:192.168.10.21) connect to service netlogon initially as user test6 (uid=1047, gid=513) (pid 6434)
[2010/02/09 16:40:15, 1] smbd/service.c:make_connection_snum(1198)
pc-etu (::ffff:192.168.10.21) connect to service test6 initially as user test6 (uid=1047, gid=513) (pid 6434)
Si quelqu'un a une idée pour "forcer" le service profiles à se lancer même en cas de changement de mot de passe, je suis preneur.
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
yan23
yan23 a écrit le 09/02/2010 à 20h04 :
Bonjour,
après de nombreuses recherches, je me trouve coincé sur un problème assez bizarre...
Je suis en train de mettre en place une salle info avec un serveur sous debian avec samba/ldap et une vingtaine de poste sous Windows XP Pro.
Tout fonctionne à merveille, les profils itinérants se chargent bien, les partages se montent, etc
Cependant, lors de la connexion d'un utilisateur pour la première fois, il doit créer son mot de passe. Et là, le profil itinérant ne se créé pas, mais un profil local se charge à la place. Ce n'est seulement lorsque ce dernier se connectera sur une autre machine qu'il pourra avoir accès à son profil...
J'ai compris ceci après avoir regardé les logs de smbd.
Ici l'utilisateur n'a pas eu besoin de changer son mot de passe. On voit bien les différents services se charger :
[2010/02/09 16:36:08, 1] smbd/service.c:make_connection_snum(1198) pc-etu (::ffff:192.168.10.21) connect to service profiles initially as user test6 (uid47, gidQ3) (pid 6392) [2010/02/09 16:36:08, 1] smbd/service.c:make_connection_snum(1198) pc-etu (::ffff:192.168.10.21) connect to service profiles initially as user test6 (uid47, gidQ3) (pid 6392) [2010/02/09 16:36:09, 1] smbd/service.c:make_connection_snum(1198) pc-etu (::ffff:192.168.10.21) connect to service netlogon initially as user test6 (uid47, gidQ3) (pid 6392) [2010/02/09 16:36:13, 1] smbd/service.c:make_connection_snum(1198) pc-etu (::ffff:192.168.10.21) connect to service test6 initially as user test6 (uid47, gidQ3) (pid 6392)
Alors que là, le changement de mot de passe d'opère, mais pas tout les services se chargent : [2010/02/09 16:40:01, 1] auth/auth_sam.c:sam_account_ok(172) sam_account_ok: Account for user 'test6' password must change!. [2010/02/09 16:40:10, 1] smbd/service.c:make_connection_snum(1198) pc-etu (::ffff:192.168.10.21) connect to service netlogon initially as user test6 (uid47, gidQ3) (pid 6434) [2010/02/09 16:40:15, 1] smbd/service.c:make_connection_snum(1198) pc-etu (::ffff:192.168.10.21) connect to service test6 initially as user test6 (uid47, gidQ3) (pid 6434)
Si quelqu'un a une idée pour "forcer" le service profiles à se lancer même en cas de changement de mot de passe, je suis preneur.
Merci pour votre aide, YaN
Re,
J'ai résolu mon problème!!! Il s'agit d'un bug de chez Microsoft suite au passage du SP3... Pas facile de trouver les informations mais à force de recherche :P
Si ça peut intéresser quelqu'un voici le lien de Microsoft qui propose le correctif : http://support.microsoft.com/kb/958058
Ce problème a été corrigé sous Vista et donc Seven je suppose. Il s'agit juste d'un bug sur une dll... 2 jours de galère mais ça marche enfin!!!
Bonne journée, YaN
yan23 a écrit le 09/02/2010 à 20h04 :
Bonjour,
après de nombreuses recherches, je me trouve coincé sur un
problème assez bizarre...
Je suis en train de mettre en place une salle info avec un serveur sous debian
avec samba/ldap et une vingtaine de poste sous Windows XP Pro.
Tout fonctionne à merveille, les profils itinérants se chargent
bien, les partages se montent, etc
Cependant, lors de la connexion d'un utilisateur pour la première fois,
il doit créer son mot de passe. Et là, le profil itinérant
ne se créé pas, mais un profil local se charge à la place.
Ce n'est seulement lorsque ce dernier se connectera sur une autre machine qu'il
pourra avoir accès à son profil...
J'ai compris ceci après avoir regardé les logs de smbd.
Ici l'utilisateur n'a pas eu besoin de changer son mot de passe. On voit bien
les différents services se charger :
[2010/02/09 16:36:08, 1] smbd/service.c:make_connection_snum(1198)
pc-etu (::ffff:192.168.10.21) connect to service profiles initially as user
test6 (uid=1047, gid=513) (pid 6392)
[2010/02/09 16:36:08, 1] smbd/service.c:make_connection_snum(1198)
pc-etu (::ffff:192.168.10.21) connect to service profiles initially as user
test6 (uid=1047, gid=513) (pid 6392)
[2010/02/09 16:36:09, 1] smbd/service.c:make_connection_snum(1198)
pc-etu (::ffff:192.168.10.21) connect to service netlogon initially as user
test6 (uid=1047, gid=513) (pid 6392)
[2010/02/09 16:36:13, 1] smbd/service.c:make_connection_snum(1198)
pc-etu (::ffff:192.168.10.21) connect to service test6 initially as user
test6 (uid=1047, gid=513) (pid 6392)
Alors que là, le changement de mot de passe d'opère, mais pas
tout les services se chargent :
[2010/02/09 16:40:01, 1] auth/auth_sam.c:sam_account_ok(172)
sam_account_ok: Account for user 'test6' password must change!.
[2010/02/09 16:40:10, 1] smbd/service.c:make_connection_snum(1198)
pc-etu (::ffff:192.168.10.21) connect to service netlogon initially as user
test6 (uid=1047, gid=513) (pid 6434)
[2010/02/09 16:40:15, 1] smbd/service.c:make_connection_snum(1198)
pc-etu (::ffff:192.168.10.21) connect to service test6 initially as user
test6 (uid=1047, gid=513) (pid 6434)
Si quelqu'un a une idée pour "forcer" le service profiles
à se lancer même en cas de changement de mot de passe, je suis
preneur.
Merci pour votre aide,
YaN
Re,
J'ai résolu mon problème!!! Il s'agit d'un bug de chez Microsoft suite au passage du SP3... Pas facile de trouver les informations mais à force de recherche :P
Si ça peut intéresser quelqu'un voici le lien de Microsoft qui propose le correctif :
http://support.microsoft.com/kb/958058
Ce problème a été corrigé sous Vista et donc Seven je suppose. Il s'agit juste d'un bug sur une dll... 2 jours de galère mais ça marche enfin!!!
après de nombreuses recherches, je me trouve coincé sur un problème assez bizarre...
Je suis en train de mettre en place une salle info avec un serveur sous debian avec samba/ldap et une vingtaine de poste sous Windows XP Pro.
Tout fonctionne à merveille, les profils itinérants se chargent bien, les partages se montent, etc
Cependant, lors de la connexion d'un utilisateur pour la première fois, il doit créer son mot de passe. Et là, le profil itinérant ne se créé pas, mais un profil local se charge à la place. Ce n'est seulement lorsque ce dernier se connectera sur une autre machine qu'il pourra avoir accès à son profil...
J'ai compris ceci après avoir regardé les logs de smbd.
Ici l'utilisateur n'a pas eu besoin de changer son mot de passe. On voit bien les différents services se charger :
[2010/02/09 16:36:08, 1] smbd/service.c:make_connection_snum(1198) pc-etu (::ffff:192.168.10.21) connect to service profiles initially as user test6 (uid47, gidQ3) (pid 6392) [2010/02/09 16:36:08, 1] smbd/service.c:make_connection_snum(1198) pc-etu (::ffff:192.168.10.21) connect to service profiles initially as user test6 (uid47, gidQ3) (pid 6392) [2010/02/09 16:36:09, 1] smbd/service.c:make_connection_snum(1198) pc-etu (::ffff:192.168.10.21) connect to service netlogon initially as user test6 (uid47, gidQ3) (pid 6392) [2010/02/09 16:36:13, 1] smbd/service.c:make_connection_snum(1198) pc-etu (::ffff:192.168.10.21) connect to service test6 initially as user test6 (uid47, gidQ3) (pid 6392)
Alors que là, le changement de mot de passe d'opère, mais pas tout les services se chargent : [2010/02/09 16:40:01, 1] auth/auth_sam.c:sam_account_ok(172) sam_account_ok: Account for user 'test6' password must change!. [2010/02/09 16:40:10, 1] smbd/service.c:make_connection_snum(1198) pc-etu (::ffff:192.168.10.21) connect to service netlogon initially as user test6 (uid47, gidQ3) (pid 6434) [2010/02/09 16:40:15, 1] smbd/service.c:make_connection_snum(1198) pc-etu (::ffff:192.168.10.21) connect to service test6 initially as user test6 (uid47, gidQ3) (pid 6434)
Si quelqu'un a une idée pour "forcer" le service profiles à se lancer même en cas de changement de mot de passe, je suis preneur.
Merci pour votre aide, YaN
Re,
J'ai résolu mon problème!!! Il s'agit d'un bug de chez Microsoft suite au passage du SP3... Pas facile de trouver les informations mais à force de recherche :P
Si ça peut intéresser quelqu'un voici le lien de Microsoft qui propose le correctif : http://support.microsoft.com/kb/958058
Ce problème a été corrigé sous Vista et donc Seven je suppose. Il s'agit juste d'un bug sur une dll... 2 jours de galère mais ça marche enfin!!!
