L'authentification Windows se comporte étrangement lorsque VPN'd

Nous avons quelques applications qui reposent sur l'authentification Windows - quelques applications Web avec l'authentification AD activée et nous nous connectons généralement à nos serveurs SQL avec l'authentification Windows. Cela fonctionne normalement sans accroc. Cela ne fonctionne pas si bien si nous sommes VPN sur un site client.

SSMS

L'ouverture normale de SSMS dans le menu Démarrer, puis la sélection d'un serveur qui accepte normalement l'authentification Windows, entraîne un message disant:

Échec de la connexion. La connexion provient d'un domaine non approuvé et ne peut pas être utilisée avec l'authentification Windows. (Fournisseur de données .Net SqlClient)

Si je passe à une invite de commande et que j'utilise runas /user:domain\userpour lancer SSMS, je peux réussir l'authentification Windows vers nos instances de serveur SQL avec ce processus ssms.

Si je regarde dans le gestionnaire de tâches, les deux copies de ssms.exe (menu Démarrer vs runas) ont le même utilisateur, et je ne vois aucune différence perceptible entre les processus dans procexp.

Sites Web AD Auth

Si j'ouvre IE et que je navigue sur l'un de nos sites Web qui nécessitent un utilisateur Windows authentifié, je reçois l'invite "qui êtes-vous", et cette boîte de dialogue pense que je suis qui que ce soit l'utilisateur VPN. Je peux cependant cliquer sur "Utiliser un autre compte" et m'authentifier de cette façon.

Perspective

Même Outlook demande un nom d'utilisateur lorsque nous sommes VPN'd!

Cela affecte nos machines Win7 et Vista. Cela fait un moment que nous n'avions pas de boîte XP, mais je ne me souviens pas avoir eu ce problème sur XP pour ce qu'il vaut.

Les connexions VPN utilisent simplement les connexions VPN Windows intégrées, ce ne sont pas des VPN Cisco sophistiqués ou quoi que ce soit de cette nature.

Quelqu'un sait-il comment dire à Windows que j'aimerais être mon ancien utilisateur de domaine principal normal plutôt que l'utilisateur VPN lors de l'authentification auprès des ressources de notre domaine? Heck, je serais heureux avec une solution qui m'a incité à dire "qui êtes-vous" si j'essayais d'accéder à l'authentification Windows nécessitant des ressources sur le VPN du client.

Merci!

Toutes mes excuses s'il s'agit plutôt d'une question de superutilisateur, je ne savais pas quel site convenait le mieux. Il s'agit de la mise en réseau et de l'infrastructure et infeste tous nos développeurs ici, donc j'espère que c'est un défaut de serveur Q.

J'avais aussi ce même problème et j'ai trouvé la solution ici:

http://social.technet.microsoft.com/forums/en-US/itprovistanetworking/thread/275599f0-6239-46a5-8245-50a5c13a2713/

Vous devrez localiser votre fichier .pbk de connexions VPN.

Vous pouvez le trouver ici:

C: \ Users \ {WindowsLogin} \ AppData \ Roaming \ Microsoft \ Network \ Connections \ Pbk

Ou si vous l'avez configuré pour permettre à tous les utilisateurs d'utiliser la connexion, vous pouvez le trouver ici:

C: \ ProgramData \ Microsoft \ Network \ Connections \ Pbk

Modifiez-le avec un éditeur de texte et trouvez la ligne qui dit:

UseRasCredentials=1

Désactivez-le en le mettant à 0

UseRasCredentials=0

Nous utilisons le logiciel Cisco VPN pour certains utilisateurs hors site. Le logiciel VPN demande des informations d'identification qui interrogent Active Directory pour garantir que le nom d'utilisateur / mot de passe sont corrects et que l'utilisateur a le droit de se connecter via VPN. Mais une authentification réussie établit uniquement une connexion au réseau. L'accès aux ressources réseau repose sur l'authentification que vous avez fournie au poste de travail lorsque vous vous êtes connecté.

Cela est devenu un problème pour nous car les utilisateurs se connectaient à l'ordinateur portable avec des informations d'identification mises en cache, établissaient une connexion VPN, puis changeaient leur mot de passe. Ils verrouillaient ensuite leurs comptes de domaine car leur jeton d'utilisateur avait leurs anciennes informations d'identification. Nous avons depuis conseillé à ces utilisateurs de verrouiller et déverrouiller leur poste de travail après avoir changé leur mot de passe pendant l'établissement du tunnel VPN. Cela met à jour le jeton utilisateur et leur permet d'accéder aux ressources réseau à l'aide des informations d'identification mises à jour.