Comment changer le mot de passe du domaine Windows via VPN en ligne de commande lorsque la synchronisation du mot de passe forcé est activée

Scénario :

Connecté en tant qu’utilisateur de domaine à un poste de travail.
L’utilisateur n’est pas administrateur du poste.
Un compte de domaine est créé avec les droits administrateur local.
Ce compte n’a jamais été utilisé pour se connecter au poste.
L’utilisateur reçoit le mot de passe du compte administrateur de son ordinateur.

Problème :
La politique de changement de mot de passe forcé est activée et le compte administrateur n’est pas mis en cache sur la machine. Étant connecté via VPN, l’utilisateur ne peut pas se connecter et recevoir l’invite de changement de mot de passe.

Comment l’utilisateur peut-il se connecter avec le compte administrateur et changer son mot de passe ?

Si le poste était connecté au réseau local (LAN) pouvant atteindre le contrôleur de domaine, le mot de passe aurait pu être modifié.

Mais via VPN, lorsqu’il est connecté en tant qu’utilisateur non administrateur, cela semble impossible. Lorsqu’on tente d’exécuter une commande ‘run as’ pour cmd.exe en tant qu’administrateur local et avec ‘net use /domain nom_utilisateur *’, cela ne fonctionne pas. La demande de changement de mot de passe forcé ne peut pas apparaître.

Cela fonctionnerait si la modification de mot de passe forcé n’était pas activée.

Des idées ou y a-t-il déjà rencontré cette situation ?

Ne pouvez-vous pas désactiver la nécessité de changer le mot de passe, permettre à l’utilisateur de se connecter une fois en tant qu’administrateur, puis définir le drapeau de changement de mot de passe.

L’ordinateur est-il chiffré ? Sinon, vous pouvez leur demander de changer le mot de passe de l’administrateur local, lol.

Peut-être que cela fonctionne dans mon environnement :

  • Se connecter en tant qu’utilisateur de domaine > se connecter via VPN en tant que cet utilisateur.

  • Passer au profil utilisateur réel. Étant donné qu’il a une connexion VPN active, cela pourrait leur permettre de changer le mot de passe maintenant. Ou se connecter et utiliser Ctrl+Alt+Suppr pour définir un nouveau mot de passe, qui sera synchronisé via le VPN et respectera l’exigence de changement de mot de passe.

  • Cela suppose cependant que l’utilisateur peut encore se connecter avec l’ancien mot de passe. Ou qu’il est autorisé à ‘basculer entre profils utilisateur’ au lieu de se déconnecter.

Vous avez dit que l’utilisateur RDP dans un ‘serveur de changement de mot de passe’ sur votre réseau. Vous avez configuré le serveur pour qu’une déconnexion soit initiée lors du démarrage en utilisant les clés HKLM Run, mais avant cela, l’utilisateur serait invité à changer son mot de passe. Il serait déconnecté juste après le changement, mais cet utilisateur pourrait maintenant utiliser ce compte tant qu’il est connecté au VPN et que le domaine est accessible via le VPN, car il ne possède plus le drapeau de changement de mot de passe forcé.

Avec Cisco AnyConnect, vous pouvez VPN avant la connexion. Nos collègues travaillant à domicile utilisent cela lorsqu’ils reçoivent un nouvel ordinateur portable à leur domicile. Cela leur permet de créer et mettre en cache leur profil Windows pour la première fois.

Une ligne de commande pour changer le mot de passe de quelqu’un d’autre, en connaissant l’ancien mot de passe :

([ADSI]‘LDAP://CN=user02,OU=Users,OU=MALLAB,DC=mallab,DC=local’).ChangePassword(‘OldPwd123-!’,‘ANewPwd123-!’)

Réinitialiser le mot de passe efface également le drapeau ‘changer le mot de passe lors de la prochaine connexion’.

J’ai vu un commentaire disant d’utiliser le mot de passe LAPs.
Pour ce scénario, le mot de passe LAPs n’est pas une option mais bonne suggestion.

Mec, regarde plutôt l’utilisation des points.

Pour ce scénario :
Ce qui n’est pas une option :
Impossible de désactiver le changement de mot de passe forcé en raison des règles de politique.
Puisque l’utilisateur ne s’est jamais connecté avec le compte de domaine, avec le compte qui est administrateur local de la machine :
Le mot de passe n’est pas mis en cache, car il aurait dû avoir déjà parlé à un contrôleur de domaine pour être mis en cache. Un problème supplémentaire est que la combinaison clavier Windows L pour passer à un autre utilisateur est bloquée par la politique.
Donc, l’utilisateur ne peut pas se connecter via VPN pour tout compte qui n’est pas encore mis en cache.
C’est pourquoi cela ressemble à un dilemme sans issue.

Oui, il est chiffré avec BitLocker et le déchiffrement est contraire à la politique dans ce scénario.

Le problème est que la modification forcée du changement de mot de passe semble ne permettre que de changer le mot de passe via une interface graphique de connexion utilisateur.

L’écran de réinitialisation du mot de passe OWA Exchange ne peut pas être utilisé car un autre compte n’est pas un utilisateur Exchange.

L’écran de réinitialisation du mot de passe Citrix n’est pas une option non plus car l’utilisateur n’est pas non plus un utilisateur Citrix.

Encore une fois, je pense qu’il devrait y avoir une interface Microsoft pour changer le mot de passe via une interface graphique ou autre, mais il semble qu’il n’y en ait pas.
Dans ce scénario, l’utilisateur doit installer un logiciel sur le poste de travail, ce que le compte connecté n’est pas autorisé à faire en tant qu’administrateur local par politique. La machine n’a pas RDP activé ni d’outils à distance.

Encore une situation de dilemme pour trouver une façon pour l’utilisateur d’installer le logiciel via le compte logiciel dédié sur VPN sans venir au bureau et se connecter en tant que réseau local.

Changer de profil avec le raccourci clavier “L” et cmd est bloqué par la GPO. Le profil utilisateur autre n’a jamais été connecté à la machine, donc il n’est pas mis en cache.
Une bonne idée cependant.

C’est ma solution habituelle, si c’est un compte de domaine.

Se connecter via RDP à une machine via VPN ou session Citrix sur laquelle l’autre compte n’a pas de permissions pour se connecter, demandera une réinitialisation.

Je l’utilise pour l’un de nos ADs qui est la source de synchronisation locale pour notre Azure AD, auquel je n’ai aucun privilège élevé. J’essaie de me connecter à l’un des contrôleurs de domaine, cela me permet de faire la réinitialisation, puis dit de partir. Mais, ce qui est crucial, c’est que cela fonctionne également pour que l’accès SSO Azure AD refonctionne. Les utilisateurs normaux ont probablement un service en libre-service, mais ma méthode est plus simple :slight_smile:

C’est une idée intéressante. Y a-t-il des articles à ce sujet ?