none
Utilisateurs ne peuvent pas se loger sur leur portable en dehors de leur réseau (hors domaine 2016) RRS feed

  • Discussion générale

  • Bonjour,

    Dans un tout nouveau domaine basé sur un serveur 2016 comme DC, les utilisateurs de laptop, en l'absence de connexion au réseau, ne peuvent pas se connecter sur leur session Windows. Lors de la tentative de login, le message suivant apparaît à l'écran:

    "Nous n'avons pas pu vous connecter avec ces informations d'identification, car votre domaine n'est pas disponible. Vérifiez que votre appareil est connecté au réseau de votre organisation, puis réessayez. Si vous vous connectiez sur cet appareil avec d'autres informations d'identification auparavant, vous pouvez utiliser celles-ci pour vous connecter"

    Par défaut, un PC client (Windows 10 en l'occurrence) doit copier ses "credentials" en local lors de son premier login/logoff d'un utilisateur. Ensuite, il devient utilisable hors connexion réseau en l'absence de son contrôleur de domaine. Ici impossible.

    Pour être plus précis, si je supprime le profil et que je le recrée par un nouveau login/logoff, je peux quelques fois me loger sous le nom de cet utilisateur hors connexion et ensuite de manière, semblerait-il aléatoire, un moment, après plusieurs tentatives réussies, le message bloquant (ci-dessus) revient et empêche toute accès à la session. Le PC (laptop) est alors inutilisable hors du domaine. Ce problème est actuellement le même sur les 10 PCs clients du domaine (PC fixe ou portable).

    Je n'ai jamais eu cela sur les versions précédentes de Windows (serveur ou client).

    Les versions utilisées:
    DC: Windows Server 2016 standard (Version 1607) tous les updates sont faits
    Clients: Windows 10 Pro 64 bits (Version 1703) tous les updates sont faits

    Deux OU on été crées pour les "users" et les "computers" avec des GPO toutes simples:
    GPO pour les utilisateurs:
    1. Map drives
    2. Print mount
    GPO pour les PCs:
    1. activation d'accès RDP (pour l'instant désactivée dans les tests en cours de ce problème)

    Donc la config est très simple actuellement mais je suis très embêté car les utilisateurs ne peuvent pas sortir du réseau avec leur laptop. Pas d'utilisation possible ni à domicile, ni en clientèle pour eux!

    C'est un tout nouveau réseau mais déjà en production. Tout le reste fonctionne parfaitement bien.

    Qui pourrait m'aider sur ce problème ?

    Merci d'avance.

    mercredi 26 juillet 2017 22:30

Toutes les réponses

  • Bonjour,

    Si l'utilisateur n'a jamais ouvert une session sur la machine en question , pour la première ouverture de session, il faut que la machine soit connectée à un DC.

    Si l'utilisateur a déjà ouvert une session , il est capable de rouvrir une session sans être connecté à un DC, vue que les informations d'identification  sont en cache, par défaut une machine Windows est capable de garder entre 10 et 25  utilisateurs en cache en fonction de la version de l'OS.

    Par contre, il est possible de modifier le nombre de compte en cache autorisé ou bien désactiver le cache via GPO ou la clé de register.

    Pour votre cas, vérifiez que l'utilisateur a déjà ouvert une session sur sa machine.

    Et au niveau la clé de register vérifiez que la valeur de la clé CachedLogonsCount est supérier à 0, cette clé est sous:

    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\Winlogon\

    Au niveau de la GPO vérifiez également que le paramètre Number of previous logon to cache sous:


    Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\:

    Pour  désactiver le cache via la clé de registre il faut mettre 


    Please don't forget to mark the correct answer, to help others who have the same issue. Thameur BOURBITA MCSE | MCSA My Blog : http://bourbitathameur.blogspot.fr/

    jeudi 27 juillet 2017 10:24
    Modérateur
  • Merci pour votre réponse. Tout cela est bien correct mais cela avait déjà été contrôlé.

    1. minimum 1 login sur le PC client concerné par l'utilisateur concerné avait bien été fait.

    2. Le check dans la base de registration pour s'assurer que la valeur est bien différente de 0 a bien été effectuée aussi. En fait, la valeur peut être de 0 à 50 et par défaut sur Windows 10, elle est à 10. Je me suis donc assuré que, le problème survenant, cette valeur n'avait pas été modifiée. Et effectivement, non, elle est toujours bien à 10.

    3. Quant à appliquer une GPO spécifique, pour forcer une valeur différente de 0, je ne l'ai effectivement pas testée. A priori, je n'en vois pas l'intérêt puisque ma valeur base de registre reste bien sur 10 mais, par acquis de conscience, je vais quand même tester cela.

    vendredi 28 juillet 2017 13:57
  • 3. Quant à appliquer une GPO spécifique, pour forcer une valeur différente de 0, je ne l'ai effectivement pas testée. A priori, je n'en vois pas l'intérêt puisque ma valeur base de registre reste bien sur 10 mais, par acquis de conscience, je vais quand même tester cela.

    Je viens à l'instant d'en faire le test et cela ne change rien
    vendredi 28 juillet 2017 14:06
  • Je suis assez surpris de cette règle car j'ai déjà eu dans des domaines précédents de simples "users" qui pouvaient s'authentifier hors domaine. Quoi qu'il en soit, cette fois, la question ne se pose même pas car les utilisateurs concernés sont bien tous admin local de leur propre PC.

    (et effectivement, comme dit plus haut, les utilisateurs concernés ont bien ouvert une fois une session en connexion avec le domaine)

    vendredi 28 juillet 2017 14:48

  • Si vous exécutez la commande suivante, voyez-vous les credentials locaux ?

    control /name Microsoft.CredentialManager

    Si vous les voyez, supprimez les et demandez à l'utilisateur de se reconnecter sur le domaine, puis faites à nouveau un test.


    Claude Couderc Consultant IIS, SharePoint, Exchange http://coudr.com

    vendredi 28 juillet 2017 14:54
  • Je ne vois rien qui corresponde à des credentials du domaine.

    Je n'ai des informations que dans la rubrique "Informations d'identifications génériques"
    Et celles-ci ne correspondent en rien au credential du domaine. Principalement ce sont des credential outlook sur des comptes O365.

    Est-ce normal de ne rien voir dans ce panel au niveau des credential domaine ?

    Est-il possible de forcer à nouveau les "credential" (la copie) locales sans supprimer le profil local sur la machine ? Ceci afin de devoir éviter de reconfigurer l'ensemble du profil de l'utilisateur. Existe-t-il une commande pour cela ? Personnellement, je n'en connais pas.
    samedi 29 juillet 2017 18:33
  • Je ne vois rien qui corresponde à des credentials du domaine.

    Je n'ai des informations que dans la rubrique "Informations d'identifications génériques"
    Et celles-ci ne correspondent en rien au credential du domaine. Principalement ce sont des credential outlook sur des comptes O365.

    Est-ce normal de ne rien voir dans ce panel au niveau des credential domaine ?

    Est-il possible de forcer à nouveau les "credential" (la copie) locales sans supprimer le profil local sur la machine ? Ceci afin de devoir éviter de reconfigurer l'ensemble du profil de l'utilisateur. Existe-t-il une commande pour cela ? Personnellement, je n'en connais pas.
    Vous pouvez essayer désactiver le cache ensuite réactiver via la clé de register.

    Please don't forget to mark the correct answer, to help others who have the same issue. Thameur BOURBITA MCSE | MCSA My Blog : http://bourbitathameur.blogspot.fr/

    samedi 29 juillet 2017 19:16
    Modérateur
  • Vous pouvez essayer désactiver le cache ensuite réactiver via la clé de register.

    Je suppose que vous parlez de cette clé:
    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\Winlogon\
    CachedLogonsCount

    La mettre à 0 puis la réactiver en remettant une valeur 10 par exemple ?

    samedi 29 juillet 2017 22:37

  • Claude Couderc Consultant IIS, SharePoint, Exchange http://coudr.com

    dimanche 30 juillet 2017 08:39
  • Vous pouvez essayer désactiver le cache ensuite réactiver via la clé de register.

    Je suppose que vous parlez de cette clé:
    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\Winlogon\
    CachedLogonsCount

    La mettre à 0 puis la réactiver en remettant une valeur 10 par exemple ?

    Oui ....

    Please don't forget to mark the correct answer, to help others who have the same issue. Thameur BOURBITA MCSE | MCSA My Blog : http://bourbitathameur.blogspot.fr/

    dimanche 30 juillet 2017 12:11
    Modérateur
  • Vous pouvez essayer désactiver le cache ensuite réactiver via la clé de register.


    Testé ce matin. Toujours pas de solution de cette manière.

    Pour forcer la solution, j'ai supprimé le profil de l'utilisateur sur l'un des PCs puis recréé (en connexion domaine évidemment) et là, par la suite, je peux enfin me connecter hors domaine. J'aurais préféré ne pas devoir systématiquement supprimer le profil dans la mesure où cela requiert de devoir tout refaire pour les profils de chaque utilisateur.

    1. Si quelqu'un a une idée autre que les solutions proposées ci-dessus (et toutes testées scrupuleusement) pour arriver à reforcer les credentials sans supprimer le profil... Il est vrai que la source du problème n'étant toujours pas trouvée, c'est un peu chercher en aveugle.

    2. Effectivement, d'où aurait pu surgir ce problème. Il est toujours intéressant de connaître la source pour éviter à l'avenir de retomber devant le même problème.

    lundi 31 juillet 2017 09:40

  • Réponse ci-dessus (en référence à "Vous pouvez essayer désactiver le cache ensuite réactiver via la clé de register"), mais cela ne fonctionne toujours pas
    lundi 31 juillet 2017 09:43

  • Claude Couderc Consultant IIS, SharePoint, Exchange http://coudr.com


    Il n'y a rien dans cette rubrique
    lundi 31 juillet 2017 09:46
  • Il faut cliquer sur Ajouter des informations d'identification Windows

    Puis renseigner les valeurs demandées : domaine, nom utilisateur puis mot de passe.

    Ensuite, vous cliquez sur le bouton OK.


    Claude Couderc Consultant IIS, SharePoint, Exchange http://coudr.com


    lundi 31 juillet 2017 10:24