mon problème

AD est installé sur un serveur 2003. PC portable des itinérants sont définis dans le domaine.
Les itinérants se connectent sur le domaine même déconnectés, à condition qu’ils ont été connectés au moins une fois au serveur et dans ce cas ils peuvent consulter leurs messageries.
Mais au bout de 3 à 6 mois lorsque la stratégie de changement de mot de passe se déclenche et les obligeant à changer le mot de passe, ils ne peuvent plus ni accéder au serveur ni de consulter leurs messages.

qui a une solution pour moi

changer la stratégie de mot de passe

*hop déplacer dans la bonne section du forum*

YannB a écrit:

changer la stratégie de mot de passe

Veulent pas changer la stratégie de mot de passe de tout un parc pour 10 pauvres itinérants. Et ils ne veulent pas non plus passer à 2008R2 (qui permet de mettre des stratégies de mot de passe dans les GPO)...
La solution provisoire qui est « Les utilisateurs n'ont pas le droit de changer de mot de passe » ne leur convient pas non plus...

On a même trouvé une solution pour changer le mot de passe sans avoir accès au domaine --- avec IISADMPWD (pensez IIS/AD/modifier PWD pour retenir le sigle ), via une bête page web --- mais vu que les postes n'accèdent pas au contrôleur de domaine, ils gardent eux l'ancien mot de passe. De plus la configuration d'Exchange leur oblige à utiliser leur compte Windows pour se connecter à la messagerie via Outlook (authentification NTLMSSP).

Voilà pour les idées foireuses... Ce qu'il faut trouver c'est un moyen pour les portables de se synchroniser avec le contrôleur sans être sur le réseau.


Et c'est là qu'une idée me vient : encapsuler SMB dans du HTTPS : http://darkmag.net/darkBlog/index.php?2004/08/18/67-tunneling-http ! Ça permettrait de filer un accès sécurisé au contrôleur de domaine à partir de l'extérieur !
Faut voir la faisabilité de la chose avec IIS. Au pire un coup de Samba (4?) ou de Cygwin et on encapsule dans du SSH !
Je ne sais pas pourquoi, mais je sens que dans la pratique ça va se révéler être une mauvaise idée aussi... On en reparle lundi Djafar !

Et une question bete : ils sont sur quel os ?

sur vista et seven dans la gestion des utilisateurs , on peut changer le mot de passe réseau

ça serait pas plus simple?

* pas vraiment a jeun * je dis peut etre de la merde

Mais j'ai eu des utilisateurs qui ont eu ce soucis là, du moins leur vieux mot de passe d'accés au ressources qui reste en place , alors que le mot de passe domaine a été changé

en fait je le décris par une autre façon:

En pratique les nomades utilisent leurs Blackberrys comme modem pour accéder au service de messagerie, et tous les 6 mois, on change leurs mots de passe pour connecter aux serveurs de domaine.
Lorsqu’ils sont au siège tout marche bien, ils se connectent au serveur DNS sans problème. Et lorsqu’ils quittent le siège ils peuvent se connecter encore au siège et même consulter leurs messages sans problème,
En fait, ils connectent à Microsoft Exchange par le déploiement de RPC sur http.
Mais au bout de 6 mois lorsque la stratégie de changement de mot de passe s’impose, et le mot de passe change, ils ne peuvent plus connecter à leurs comptes et à leurs messageries. Comme si il n’y a pas de la synchronisation entre leurs Blackberrys et les serveurs.

Djafar

je suis sur le serveur 2003
ainsi que j'utilise Microsoft Exchange 2003 ou 2007 et outlook 2007
et blacberry comme modem abonné chez orange.

Djafar, tu pourrais donner des nouvelles !

La première solution fut d'utiliser des comptes locaux sur le portable, et leurs comptes de domaines uniquement pour la messagerie, en modifiant le mot de passe via IISADMPWD (qu'on peut même intégrer à OWA).

Mais ça n'a pas plu. C'est donc parti pour un VPN (puis ça permet en plus de récupérer les MaJ de win et de l'antivirus).Et là c'est moi qui m'y colle, vu que je suis déjà dessus pour un autre projet.
Je cherche donc une solution pour automatiser la modification de mot de passe, en faisant un script AutoHotKey (qui est pas mal du tout, en passant), qui lance le client VPN, émule un Ctrl+Alt+Suppr puis un Alt+M pour lancer l'invite de modification de mot de passe.
Problème : la sécurité façon Microsoft : on ne peut pas émuler le Ctrl+Alt+Suppr ! C'est le processus WinLogon qui se charge de reconnaitre directement la frappe au clavier, avant de lancer GINA (Fermer Session, Gestionnaire des tâches, Changer password, toussa), ceci afin d'éviter qu'un processus « pirate » fasse une fausse fenêtre de changement de mot de passe pour le récupérer (c'est aussi pour ça qu'on doit faire Ctrl+Alt+Suppr à l'ouverture de la session). Et donc forcément, pas moyen de changer le mot de passe sans faire ce Ctrl+Alt+Suppr ! Il y a bien la commande net user, mais il faut être admin !
Denis a dit « Une étude qui aboutit à un constat d'impossibilité ou une décision de ne pas faire n'est pas un échec », mais bon, ça me gonfle quand même !

Dernier espoir : trouver le moyen de créer un user qui ait juste le droit de se connecter au domaine et de changer le mot de passe de certains comptes. Ainsi je pourrais utiliser la commande pspasswd (psutils - sysinternals).
Sinon ça va finir en rédaction de procédure et demerdez-vous !

Pourquoi ne pas installé un client VPN (SSL ou Ipsec), gratuit comme "Shrew" sur tous les portables des nomades.

Ensuite le lancer en tâche planifiée à l'ouverture de session.

Qu'il modifie ou pas leur mot de passe, le VPN reste une bonne méthode d'authent.

SI je dis dla merde, greg ...

Ne tiens pas compte du mess précédent, j avais mal lu votre probleme !

Tu connais des gens qui ont utilisé Shrew longtemps chez toi ? Parce qu'il semble mal apprécier les mises à jour de windows (me suis retrouvé sans réseau, j'aurais pas eu de bol pendant tout le stage moi ).

salut greg,

oué oué il est très utilisé chez nous et chez bcp de nos clients !

Je n'ai pas entendu de remontées négatives pour le moment ...

Bah ça doit être ma bécane qui est trop en fin de vie alors (un vieux PIV).

Cependant, l'admin m'a dit qu'il avait eu un problème similaire, du coup ça lui fait un peu peur de mettre ça en place ! On s'est rabattu sur AnyConnect (un client Cisco).

Slt greg
le seul probleme avec anyconnect c qu'il ne support pas les bécanes 64 bits.

Voilà pourquoi on ne l a pas déployé.