Authentification via RADIUS: erreur MSCHAPV2 691
Je travaille sur la configuration de l'authentification dans un paquet ACME Net-Net-Net 3820 (SBC) via un rayon. Le côté de la comptabilité des choses fonctionne bien sans problème. Le côté authentifiant des choses est une autre affaire. Je peux voir à partir d'un paquet capturant que les messages de demande d'accès se produisent en fait au serveur RADIUS à quel point le serveur RADIUS commence à communiquer avec les contrôleurs de domaine. Je vois ensuite la chaîne de communication revenant au RADIUS puis revenait enfin à la SBC. Le problème est que la réponse que je récupère est toujours un message de rejet d'accès avec un code de motif de 16 (l'authentification a échoué en raison d'une inadéquation d'informations d'identification de l'utilisateur. Soit le nom d'utilisateur fourni ne correspond pas à un compte utilisateur existant ou que le mot de passe était incorrect). Ceci est confirmé en examinant les journaux d'événements de sécurité où je peux voir les événements 4625 et 6273. Voir les événements ci-dessous (Remarque: Les noms et IP ont été modifiés pour protéger l'innocent):
ID d'événement: 6273
Network Policy Server denied access to a user.
Contact the Network Policy Server administrator for more information.
User:
Security ID: NULL SID
Account Name: real_username
Account Domain: real_domain
Fully Qualified Account Name: real_domain\real_username
Client Machine:
Security ID: NULL SID
Account Name: -
Fully Qualified Account Name: -
OS-Version: -
Called Station Identifier: -
Calling Station Identifier: -
NAS:
NAS IPv4 Address: 10.0.0.10
NAS IPv6 Address: -
NAS Identifier: radius1.real_domain
NAS Port-Type: -
NAS Port: 101451540
RADIUS Client:
Client Friendly Name: sbc1mgmt
Client IP Address: 10.0.0.10
Authentication Details:
Connection Request Policy Name: SBC Authentication
Network Policy Name: -
Authentication Provider: Windows
Authentication Server: RADIUS1.real_domain
Authentication Type: MS-CHAPv2
EAP Type: -
Account Session Identifier: -
Logging Results: Accounting information was written to the SQL data store and the local log file.
Reason Code: 16
Reason: Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.
ID d'événement: 4625
An account failed to log on.
Subject:
Security ID: SYSTEM
Account Name: RADIUS1$
Account Domain: REAL_DOMAIN
Logon ID: 0x3E7
Logon Type: 3
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: real_username
Account Domain: REAL_DOMAIN
Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xC000006D
Sub Status: 0xC000006A
Process Information:
Caller Process ID: 0x2cc
Caller Process Name: C:\Windows\System32\svchost.exe
Network Information:
Workstation Name:
Source Network Address: -
Source Port: -
Detailed Authentication Information:
Logon Process: IAS
Authentication Package: Microsoft_AUTHENTICATION_PACKAGE_V1_0
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
This event is generated when a logon request fails. It is generated on the computer where access was attempted.
The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).
The Process Information fields indicate which account and process on the system requested the logon.
The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.
The authentication information fields provide detailed information about this specific logon request.
- Transited services indicate which intermediate services have participated in this logon request.
- Package name indicates which sub-protocol was used among the NTLM protocols.
- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
Donc, au premier abord, il semblerait que le problème soit simplement un cas de nom d'utilisateur invalide ou de mot de passe intacté. Ceci est en outre confirmé dans la capture de paquets où je peux voir que la réponse MSCHAPV2 a un code d'erreur de 691 (accès refusé car le nom d'utilisateur ou le mot de passe, ou les deux, ne sont pas valides sur le domaine). La chose est que je sais que j'utilise un nom d'utilisateur valide et j'ai essayé de nombreux noms d'utilisateur, y compris de nouveaux, je n'ai créé que pour le dépannage. Je ne sais pas combien de fois j'ai réinitialisé le mot de passe pour tenter de vous assurer qu'il ne s'agit pas d'un mot de passe d'inadéquation. Je me suis même assuré d'utiliser des mots de passe assez courts et contenant uniquement des lettres pour qu'il n'y ait pas de problèmes de codage de terminal (nous nous connectons à la SBC via des clients SSH). J'ai également fait la même chose avec le secret partagé utilisé lors de la communication entre SBC et le serveur RADIUS. J'ai essayé de préfixer le nom d'utilisateur avec le nom de domaine à la connexion (bien que je ne pense pas que cela devrait être nécessaire). J'ai également essayé d'utiliser l'UPN complet de l'utilisateur pour vous connecter. J'ai essayé plusieurs RADIUS _ tester des clients (ntradping, radiustesest, etc.), mais ils ne prennent pas en charge MSCHAPV2 ou seulement support EAP-MSCHAPV2. J'ai même créé mon propre client avec le module PECL RADIUS de PHP. Néanmoins, il semble toujours échouer avec l'authentification Mschapv2 avec un code d'erreur de 691. Quelqu'un a-t-il des idées sur lesquelles je reçois toujours un nom d'utilisateur ou une réponse de mot de passe invalide lorsque j'ai tout fait pour vous assurer que ce n'est pas le cas?
Voici les spécifications de notre configuration RADIUS:
- Windows Server 2012 R2
- SQL Server 2012 Back Back Based Based pour la comptabilité.
- Le serveur a été autorisé sur le domaine et est membre du groupe "Serveurs RAS et IAS". Pour lequel ce groupe a accès aux comptes que nous testons.
- Les comptes que nous testons avec l'option "Control Access via la stratégie de réseau NPS" vérifiée sous leur "numéro de numérotation".
- Les clients de rayon sont configurés pour simplement correspondre à l'adresse IP que vous pouvez voir sur les événements ci-dessus qu'il applique le nom convivial du client.
- Politique de demande de connexion: la politique "authentification SBC" est appliquée comme indiqué ci-dessus. La seule condition est une expression de regex qui correspond au nom convivial.
- Politique de réseau: comme on le voit dans les événements ci-dessus, aucun ne sera appliqué. Pour des fins de dépannage, j'ai créé une stratégie de réseau définie sur "1" pour la commande de traitement et sa seule condition est une restriction de jour et de temps actuellement définie sur n'importe quel moment, n'importe quel jour.
- La méthode d'authentification est définie sur MSCHAPV2 ou MSCHAPV2 (l'utilisateur peut modifier le mot de passe après avoir expiré). J'ai essayé d'ajouter cela à la politique du réseau et j'ai également essayé de l'ajouter à la stratégie de demande de connexion et de la définir pour remplacer la méthode d'authentification de la stratégie de réseau.
- Nous avons d'autres serveurs RADIUS dans notre domaine qui utilisent Peofe pour authentifier les clients sans fil et ils fonctionnent tous bien. Cependant, nous avons besoin de cela pour travailler avec MSCHAPV2 uniquement (pas de PAE).
- Toutes les autres configurations sont définies sur les valeurs par défaut.
La seule autre chose de note à considérer est le fait que, dans les événements ci-dessus, vous pouvez voir que l'ID de sécurité est "NULL SID". Maintenant, je sais que cela est commun notamment parmi les logons échoués, mais étant donné que cette question indique un nom d'utilisateur invalide ou un mauvais mot de passe, il est peut-être important dans ce cas. En outre, ce serveur a été reconstruit à l'aide du même compte d'ordinateur dans Active Directory. Je ne sais pas si cela aurait travaillé avant la reconstruction. Nous avons essentiellement construit ce serveur et n'auront que l'autorisation du serveur au domaine et l'ajout de SQL lorsque nous avons décidé de séparer le rôle SQL sur un autre serveur. Plutôt que de désinstaller SQL, nous venons de reconstruire la machine. Cependant, avant de réinstaller Windows, je faisais une réinitialisation sur le compte de l'ordinateur. Je ne pense pas que cela soit important, mais je pensais que je le soulignerais s'il y avait une bizarre étrange où la réutilisation du même Sid d'un serveur NPS précédemment autorisé provoquerait un problème.
Dans l'ensemble, il s'agit d'une configuration assez basique et j'espère que j'avais fourni suffisamment d'informations pour que quelqu'un ait une idée de ce qui pourrait se passer. Toutes mes excuses si ma compréhension de cela semble un peu basique, après tout, quand il s'agit de serveurs RADIUS, je suppose que vous pourriez dire que je suis le nouveau gars ici.
Edit 1:
Dans une tentative de dépannage de ce problème, j'ai essayé d'apporter des serveurs supplémentaires pour les tests. Voici les tests supplémentaires que j'ai effectués.
Plusieurs domaines
J'ai maintenant essayé cela dans 3 domaines isolés différents. Nos domaines de test et de production ainsi que mon domaine de maison privé, qui a très peu de personnalisations à part les modifications apportées à l'échange et à la configuration. Tous ont les mêmes résultats décrits ci-dessus.
Service VPN
À l'aide de Windows Server 2012 R2, nous avons soulevé un serveur distinct pour exécuter une configuration VPN standard. L'intention était de voir si nous pouvions utiliser l'authentification RADIUS avec le VPN et si cela a travaillé, nous saurions que le problème est avec les SBCS. Cependant, avant que nous puissions même la configurer pour utiliser RADIUS, nous avons juste tenté de vous assurer qu'il fonctionne avec l'authentification Windows standard sur le serveur VPN local. Fait intéressant, il échoue aussi avec les mêmes événements qui se sont connectés comme des serveurs RADIUS. La machine client étant une station de travail Windows 8.1. Encore une fois, je souligne que nous avons travaillé RADIUS _ serveurs utilisés spécifiquement pour notre environnement sans fil. La seule différence entre ces serveurs RADIUS et celles que je pose des problèmes est que les serveurs sans fil de travail utilisent PEAP au lieu de MSCHAPV2.
freeradius
Maintenant, je ne suis pas de gourou de Linux mais je crois que je l'ai en marche. Je suis capable d'utiliser ntlm_auth pour authentifier les utilisateurs lors de la connexion à la console. Toutefois, lorsque le service RadiusD tente d'utiliser NTLM_Auth pour faire essentiellement la même chose qu'elle échoue et renvoie le même message que je reçois avec le serveur Windows (E = 691). J'ai le service RadiusD en mode de débogage afin que je puisse voir plus de ce qui se passe. Je peux poster les informations de débogage que je reçois si demandé. Les lignes que je constate d'intérêt particulier cependant est la suivante:
(1) ERROR: mschap : Program returned code (1) and output 'Logon failure (0xc000006d)'
(1) mschap : External script failed.
(1) ERROR: mschap : External script says: Logon Failure (0xc000006d)
(1) ERROR: mschap : MS-CHAP2-Response is incorrect
La chose à noter ici est que, même si nous obtenons toujours un message "mauvais mot de passe", le code d'état réel (0xc000006d) est légèrement différent de ce que j'avais sur les serveurs Windows qui étaient (0xc000006a). À partir de ce document, vous pouvez voir ce que ces codes veulent dire: valeurs NTStatus . La bonne chose à propos de ce serveur Freeradius est que je peux voir toutes les réponses du défi lorsqu'il est en mode de débogage. Donc, si je peux envelopper ma tête autour de la manière dont une réponse MSCHAPV2 est calculée, je peux le comparer pour voir s'il s'agit simplement d'une réponse de défis malsompensée. update Il suffit de remarquer que le code 6a est juste le code de sous-état pour le code 6D. Donc, rien de différent des serveurs Windows, je me demande toujours s'il y a une erreur de calcul avec les réponses du défi.
Actuellement, je travaille sur la mise en place d'une instance Windows Server 2008 R2 d'un serveur RADIUS pour voir si cela aide du tout. Cependant, je serais surpris si quelque chose avec le service s'est cassé entre W2K8 R2 et W2K12 R2 sans que personne ne remarque jusqu'à présent. Si cela ne fonctionne pas, je devra peut-être ouvrir un cas avec Microsoft. Mise à jour: mêmes résultats avec W2K8 R2.
update 2
J'ai ouvert un cas avec Microsoft et ils y ont travaillé pendant quelques semaines. La première semaine, j'ai passé mon temps à essayer de les faire comprendre cela n'a rien à sans fil et que le périphérique que nous essayons de vous connecter ne prend pas en charge l'authentification contre un serveur RADIUS utilisant n'importe quelle forme de PAE. Une fois enfin compris que nous essayons de configurer la méthode d'authentification comme seulement Mschapv2 uniquement, sa réaction initiale était simplement "vous ne pouvez pas faire cela". Il a déclaré que, peu importe ce que vous avez toujours besoin de la configuration du PAE ou PEAP dans la case supérieure (même pour les méthodes de PAP et d'autres "Moins sécurisées" dans cette fenêtre de méthode d'authentification). Cela me semblait très peu probable pour moi, alors j'ai demandé une documentation indiquant ceci pour laquelle il modifie ensuite le sujet et n'a fourni aucune documentation. Il est devenu clair que je n'aurais nulle part avec Microsoft quand ils m'ont dit que le problème semble être avec le nom d'utilisateur et le mot de passe. Donc, il leur a fallu 2 semaines pour venir à cette conclusion lorsque la ligne d'objet de ma première ticket avait le code d'erreur E691, ce qui signifie que le nom d'utilisateur et le mot de passe incompatibles et malgré le paragraphe très long que j'ai expliqué que j'ai tout posial pour m'assurer n'est pas un mauvais nom d'utilisateur et mot de passe.
Malheureusement, mon projet de projet ne veut plus gaspiller des heures de support Premiere à ce sujet, nous avons donc fermé le cas. Nous allons probablement faire face à la connexion partagée locale SBC et à configurer une autre façon d'appliquer la responsabilité (seulement 4 d'entre nous auront accès).
Je soulignerai qu'avant d'avoir été dit de laisser tomber le projet, j'ai reçu le serveur Freeradius de travailler à l'aide de MSCHAPV2 uniquement mais n'a pu le faire en utilisant des comptes locaux sur le serveur Freeeradius. Ce sont des mots de passe de texte brut stockés dans un fichier de configuration Freeeradius quelque part. Donc, évidemment, pas une solution, mais cela montre au moins que le SBC communique correctement à un serveur RADIUS via mschapv2. Cela et les autres choses que j'ai mentionnées ci-dessus me conduisent à croire que la question se situe entre le serveur RADIUS et les contrôleurs de domaine. Tandis que l'authentification NTLM fonctionne correctement sur les serveurs Windows RADIUS et freeradius lors de la connexion sur les serveurs localement (peut vous connecter au Windows RADIUS via le compte de test et peut obtenir une authentification réussie sur le freeradius serveur lors de l'utilisation de la commande ntlm_auth avec juste un nom d'utilisateur et un mot de passe), ni RADIUS _ Server semble authentifier via des utilisateurs lorsqu'il est en tant que demande d'accès RADIUS (freeradius utilise la même commande NTLM_AUTH que j'utilise Lorsque vous êtes connecté localement mais au lieu de fournir un nom d'utilisateur et un mot de passe à la commande, il fournit un nom d'utilisateur et un problème de défi).
Je vais donc mettre fin à ce fil ici, mais je garderai un œil sur cela et cela m'informera si quelqu'un pose quelque chose. Si quelqu'un pose une solution ou si des commentaires, je vais répondre.
Solution
Ne le sauriez-vous pas, environ un mois après avoir abandonné cette approche d'utiliser un RADIUS Server pour contrôler l'accès au SBC, nous trouvons une solution possible. Bien sûr à ce stade, nous sommes aussi Occupé avec d'autres projets pour y retourner et essayer cette solution pour que je ne puisse pas dire à 100% si cela résoudrait le problème, mais une fois que je vous expliquerais, vous serez probablement convenir que c'est la réponse.
L'un de mes collègues était dans une conférence Microsoft ayant diverses discussions lorsqu'il est levé sur lui que Mschapv2 s'appuie sur NTLM pour générer des défis et des réponses de mot de passe. MAINTENANT OLD OLD MSCHAP ET MSCHAPV2 (I.E. NOT EAP-MSCHAPV2 ou PEAP) lorsqu'il est utilisé dans Windows RAS Services utilisera NTLMV1 par défaut.
Comme beaucoup d'entre vous ont déjà commencé à attraper, nous, comme de nombreux administrateurs, ont désactivé NTLMV1 sur notre DCS et, en tant que tel, les DCS n'accepteront que les demandes NTLMV2. Cela explique pourquoi l'échec que j'ai continué à obtenir était une erreur "mauvaise mot de passe". Le mot de passe étant envoyé au DCS était au format NTLMV1 et a été ignoré.
Une fois que nous avons compris cela, j'ai pu faire d'autres recherches et j'ai trouvé l'article suivant:
http://support.microsoft.com/kb/2811487
Cet article décrit le même comportement que j'avais connu, y compris le code d'erreur E = 691 que j'ai mentionné. Cet article fournit également une solution de contournement à forcer RAS Services à utiliser NTMLV2 lors de la construction d'une réponse MSCHAPV2. Funny Quelle est facile à trouver ces articles après que vous sachiez précisément le problème.
Encore une fois, je n'ai pas encore vérifié que c'est le problème, car je n'ai pas eu le temps de reconstruire le RADIUS serveurs que j'ai déjà mis hors service, mais je prévois de l'essayer de la sorte si je reçois un Chance. Je voulais juste publier cette solution possible au cas où quelqu'un d'autre trébuche de cette question. Si quelqu'un peut confirmer cela avant de faire s'il vous plaît faites-le-moi savoir.
Modifier - Confirmé
On nous a demandé de prendre un rôle plus important avec ces SBCS et, en tant que tel, nous sommes revenus dans ce projet et avons soulevé une fenêtre Windows RADIUS serveur à nouveau. Cette fois, nous avons appliqué la clé de registre décrite dans le lien ci-dessus. Après avoir pris une capture de paquets de la communication entre le RADIUS Server et les SBCS, je peux en fait maintenant voir "Accès Accepter" les messages se faire tirer sur le SBCS. Donc, je peux maintenant confirmer à moins dans notre scénario que la question que nous ayons eu est comme décrit ci-dessus.
TL; DR
NTLMV1 a été désactivé sur le DCS. Définition d'une clé de registre pour forcer le RADIUS serveur à utiliser NTLMV2 fixe le problème.
De mon expérience, MS NPS vous indique si RADIUS Key pré-partagé ne correspond pas. Quelque chose comme ça:
Event 14: A RADIUS message was received from RADIUS client x.x.x.x with an invalid authenticator. This is typically caused by mismatched shared secrets. Verify the configuration of the shared secret for the RADIUS client in the Network Policy Server snap-in and the configuration of the network access server.
Vous l'obtiendrez dans le journal des événements.
Ce fait que vous voyez l'accès-rejeter dans votre trafic capturé signifie également que les matches clés pré-partagés des deux côtés, sinon NPS ne répondent pas et que vous ne verriez plus non plus RADIUS paquets après la demande d'accès .
Ce qui est également important dans les journaux que vous avez fournis est:
Sub Status: 0xC000006A
Cela signifie que "le nom d'utilisateur est correct mais le mot de passe est faux". C'est assez explicite à mon avis.
Je sais que MS-CHAPV2 n'a pas besoin de stocker le mot de passe à l'aide de cryptage réversible, mais simplement de vérifier cette case pourriez-vous définir cette case pour que le compte utilisateur que vous utilisez, réaffectait son mot de passe après cela et l'essayer à nouveau.
Nous avons eu le même problème avec l'authentification de nos serveurs NPS après avoir ajouté de nouveaux contrôleurs de domaine 2012R2 à un environnement existant 2008R2. Les nouveaux contrôleurs de domaine 2012R2 avaient NTLMV1 désactivé où les contrôleurs de domaine 2008R2 l'avaient activé.
Les serveurs NPS (exécutant 2008R2) où nouaient au hasard l'accès des utilisateurs.
L'événement suivant a été enregistré sur les serveurs NPS: ID d'événement 6273 (journal de sécurité) Server de la stratégie de réseau a refusé l'accès à un utilisateur. Code de la raison: 16 Raison: l'authentification a échoué en raison d'une inadéquation d'informations d'identification de l'utilisateur. Soit le nom d'utilisateur fourni ne correspond pas à un compte utilisateur existant ou que le mot de passe était incorrect.
Lorsque les serveurs NPS sont connectés aux DC de 2008R2, tout a fonctionné comme un charme. Mais sur l'accès de DC 2012R2 a été refusé. Tous parce que NTLMV1 était désactivé sur les nouveaux contrôleurs de domaine 2012R2.
Je peux confirmer que la solution dans l'article de MS KB (- http://support.microsoft.com/kb/2811487 ) fonctionne parfaitement!.
Merci beaucoup pour cet excellent article !!! Cela m'a sauvé une énorme période pour résoudre ce problème; -)
FYI - Après la mise à niveau d'un travail de travail RADIUS + MSCHAP System, je reçois la même erreur.
"\ 000e = 691 r = 1"
Il y avait un changement de samba de quelque sorte qui a rejeté les droits sur la prise WinBind. L'ajout de Freerad au groupe WinBindd_priv a fixé le problème.
/ etc/groupe: winbindd_priv: x: 110: freerad