none
[Résolu] Test d'accès Wi-Fi WPA Entreprise avec du PEAP/MS-CHAPv2 sans AD CS

    Question

  • Hi,

    I am trying to setup a lab environment to work on Wireless access with 802.1X authentication based on PEAP/MS-CHAPv2. I want to rely on 3rd party certificate and not on an AD CS environment.

    I have followed the Fondation Network guide : Deploying 802.1X Authenticated Wireless Access with PEAP-MS-CHAP v2 and I do not achieve to make this working.

    Here is my setup :

    - SMO-IN101P ==> Windows 2008 R2 with AD (domain: GRP), DHCP (80% of the subnet  IP range), DNS roles

    - SMO-IN301P ==> Windows 2008 R2 with AD (domain: GRP), DHCP (20% of the subnet  IP range), DNS, NPS (for RADIUS) roles

    - WIFI-PC1 ==> Windows 7 Pro client laptop (already registered in the domain GRP via a wired ethernet access)

    - AP-252 ==> a DLink DI524 Access point setup with WPA2 enterprise authentication. Radius settings are pointing to SMO-IN301P with a pre-shared key

    The GRP domain has :

    - 1 user account : test1, the dialin properties are set to "Control access trough remote access policy"

    - 1 computer account - WIFI-PC1,  the dialin properties are set to "Control access trough remote access policy"

    - 1 security group : Wireless Group which contains test1 and PC1

    I have created a GPO to configure the Wireless settings (WPA2 enterprise with PEAP-MSCHAPv2, etc...) in the settings I have uncheked the server certificate control (as it is just a lab). The Wi-Fi settings is named "My Corporate Wi-Fi"

    The NPS has been registered within the AD. The AP-252 has been added as a RADIUS client with the correct pre-shared key

    To be able to work with the 802.1X seup wizard witin NPS, I have also installed IIS on AD02 and created a self-signed computer certificate which is available in AD02 certificate Library.

    The 802.1X wizard has been setup to use AP-252, to authenticate users & computers against the "Wireless Group". The PEAP-MSCHAPv2 has been enabled to use the self signed certificate (mandatory even if the client is set not to verify this certificate).

    I have connected the WIFI-PC1 thru a wire connection to ensure the GPO is correctly downloaded and installed : I can see the Wi-Fi settings "My Corporate Wi-Fi" enabled into it, with the correct parameters.

    I disconnect the laptop fom the wire and enable the Wi-Fi connection : The authentication fails !

    In the event viewer of the AD02, I can see a message telling me that the dialin properties of both WIFI-PC1 and test1 are not set as "allow" (Code reason 65)

    If I switch this to "Allow", I still get an authentication failure : "The user is trying to use an authentication method that is not enabled on the corresponding network Policy" (code reason 66)

    Could you help me on this ?

    Thanks for your support



    Wednesday, June 13, 2012 10:30 AM

Answers

  • Le serveur NPS a accordé l'accès, donc le problème vient plus probablement de la borne Wifi ou du certificat autosigné, même si j'ai déjà réussi à faire fonctionner un certificat autosigné sans problème. Pour le certificat, avez vous un chemin pour la vérification de la liste de révocation (CRL)? Avez essayer de le placer dans le trusted root du poste client? Si cela fonctionne en le placant dans le trusted root, vous pourrez sans problème basculer vers un certificat publique.

    Voir aussi le journal d'évenement du poste client.

    Thursday, July 05, 2012 6:39 AM
  • Bonjour !

    Je progresse... J'ai tout simplement changé de borne Wi-Fi et cela fonctionne beaucoup mieux !

    J'ai recréé la stratégie avec la condition par défaut à savoir : Type de port NAS = Wireless OU Wireless - IEEE 802.11

    Dans les logs la borne est bien vue comme : Sans-fil - IEEE 802.11 et donc match bien la condition des 2 stratégies.

    Après vérification sur le site de la Wi-Fi Alliance, il semblerait que la DI-524 n'est pas certifiée WPA2 entreprise, elle est certifiée "WPA™ - Enterprise, Personal" avec le support EAP-TLS seulement (pas de PEAP a priori) ==> http://certifications.wi-fi.org/pdf_certificate.php?cid=W001969

    Je vais maintenant régler les GPO et la problématique de certificat wildcard pour voir ce que cela donne... EN grand merci Bruce JDC pour vos nombreux conseils !

    Monday, July 23, 2012 9:14 AM

All replies

  • Hi !

    Is there anybody who could help me ?

    Thanks.

    Friday, June 15, 2012 10:08 AM
  • Bonjour,

    Merci d’avoir contacté les forums TechNet France. La langue utilisée sur ces forums est la langue française, donc s’il vous plaît repostez
    votre question en française, comme on vous demande dans
    l’étiquette sur les forums TechNet France.

    Vu que le nombre des questions en anglaise sur les forums TechNet France a grandi je voudrais vous demander nous donner des détails sur la raison pour laquelle vous n’avez pas posté votre question en français. On veut déterminer s’il y a un problème avec notre plateforme ou comment on peut prévenir ce type de problèmes.

    Merci pour votre compréhension et collaboration.

    Cordialement,

    Dan



    Dan BAJENARU, MSFT    Votez! Appel à la contribution
    Nous vous prions de considérer que dans le cadre de ce forum on n’offre pas de support technique et aucune garantie de la part de Microsoft ne peut être offerte.


    Friday, June 15, 2012 12:05 PM
  • Bonjour,

    Je suis vraiment désolé ! Mon interface étant en anglais, je pensais être sur un forum anglais...

    Voici donc mon pb en français :

    J'essaie de créer une infra d'authentification 802.1X pour un réseau Wi-Fi et je n'y arrive pas !

    J'ai suivi la doc suivante : http://go.microsoft.com/fwlink/?LinkId=105231

     

    Voici mon infra :

    • SMO-IN101P : Serveur Windows 2008 R2, avec les rôles AD DS (domaine : GRP), DHCP (actif, fournissant 80% des IP de l'étendue) et DNS (domaine grp.monentreprise.com)
    • SMO-IN301P : Serveur Windows 2008 R2, avec les rôles AD DS (domaine : GRP), DHCP (standby, fournissant 20% des IP de l'étendue), DNS et NPS (pour la partie RADIUS)
    • AP-252 : Une borne Wi-Fi DLink DI524 compatible WPA2 Enterprise.
    • WIFI-PC1 : un laptop sous Windows 7

    Dans le domaine GRP, il y a:

    • Un compte utilisateur : Test1
    • Un compte ordinateur : WIFI-PC1 (je lui ai fait joindre le domaine via le réseau filaire)
    • Un groupe de sécurtité : Wireless Group qui contient test1 et WIFI-PC1

    Nous possédons un certificat wildcard fournit par notre autorité de certification DigiCert : *.monentreprise.com

    Je l'ai intégré dans le serveur SMO-IN301P via la commande : certreq –accept star_monentreprise_com.crt

    Je le retrouve bien dans la bibliothèque des certificats

    J'ai également créé une GPO pour préconfigurer le réseau Wi-Fi et l'authentification 802.1X associée

    La partie NPS est également configurée (WPA2 Enterprise, PEPAP-MSCHAPv2 certificat *.monentreprise.com, groupe Wireless group, etc...)

    Je reboot WIFI-PC1 en filaire : la GPO est bien chargée et les paramètres sont OK

    Je passe en Wi-Fi, le PC tente de s'y connecter et indique qu'il n'a pas été autorisé à se connecter sur le serveur l'event viewer indique :

    Le serveur NPS a refusé l’accès à un utilisateur.

    Contactez l’administrateur du serveur NPS pour plus d’informations.

    Utilisateur :

    ID de sécurité : GRP\test1

    Nom de compte : GRP\Test1

    Domaine de compte : GRP

    Nom de compte complet : grp.monentreprise.com/Users/Test1 Wi-Fi

    Ordinateur client :

    ID de sécurité : NULL SID

    Nom de compte : -

    Nom de compte complet : -

    Version du système d’exploitation : -

    Identificateur de la station appelée : -

    Identificateur de la station appelante : -

    Serveur NAS :

    Adresse IPv4 du serveur NAS : 10.9.99.252

    Adresse IPv6 du serveur NAS : -

    Identificateur du serveur NAS : -

    Type de port du serveur NAS : -

    Port du serveur NAS : -

    Client RADIUS :

    Nom convivial du client : ap-252.grp.monentreprise.com

    Adresse IP du client : 10.9.99.252

    Informations détaillées sur l’authentification :

    Nom de la stratégie de demande de connexion : Use Windows authentication for all users

    Nom de la stratégie réseau : Connections to other access servers

    Fournisseur d’authentification : Windows

    Serveur d’authentification : SMO-IN301P.grp.monentreprise.com

    Type d’authentification : EAP

    Type EAP : -

    Identificateur de la session du compte : -

    Résultats de la journalisation : Les informations de suivi ont été inscrites dans le fichier journal local.

    Code raison : 65

    Raison : Le paramètre Autorisation d’accès réseau dans les propriétés des appels entrants du compte d’utilisateur dans Active Directory est défini pour refuser l’accès à l’utilisateur. Pour modifier ce paramètre en Autoriser l’accès ou Contrôler l’accès via la stratégie d’accès à distance, accédez aux propriétés du compte d’utilisateur dans Utilisateurs et ordinateurs Active Directory, cliquez sur l’onglet Appel entrant, et modifiez Autorisation d’accès réseau.

    J'ai la même erreur pour l'authentification du WIFI-PC1

    Pourtant dans l'onglet "Appel entrant" de ces 2 objets, j'ai bien coché "Copntroler l'accès via la stratégie d'accès à distance"

    Si je coche "Autoriser" à la place j'ai le message suivant dans l'event viewer :

    Code raison : 66

    Raison : L’utilisateur a essayé d’utiliser une méthode d’authentification qui n’est pas activée sur la stratégie réseau correspondante.

    Pourriez-vous m'aider à solutionner mon problème ?

    Merci beaucoup.

    Friday, June 15, 2012 2:56 PM
  • - L'authentification souhaitée est bien du 802.1X de la forme user / mdp, sans certificat côté client?

    Suivez cet article : http://technet.microsoft.com/en-us/library/cc732256(v=ws.10).aspx

    Sur le client vous avez crée un profil de type : 802.1X / Encryption WEP / Method : PEAP + MSCHAPv2? Vous pouvez aller dans les options avancés coté client, et de cocher "Specify authentication mode" + choisir User Authentication.

    Monday, June 18, 2012 8:59 AM
  • Bonjour,

    Qu'entendez-vous par client ?

    • Si c'est la borne Wi-Fi :
      * au niveau de sa configuration, j'ai : Security : WPA2 Enterprise (AES) / 802.1X Settings, RADIUS Server IP: 10.9.99.2 (IP du NPS) , RADIUS Port : 1812, Radius Shared Key : <Une clé que j'ai définie>
      * au niveau de serveur NPS, dans Gestionnaire du serveur ==> Rôles ==> Service de Stratégie et d'accès réseau ==> NPS (Local) ==>Clients et serveur RADIS ==> Clients RADIUS : j'ai bien la borne Wi-Fi ap-252.grp.monentreprise.com avec les paramètres suivants : Activer ce client RADIUS, son nom convivial (FQDN) et son adresse IP, le secret partagé est bien le même clé que stipulé plus haut, dans l'onglet "Avancé", le nom du fournisseur est bien "RADIUS Standard"
    • Si c'est  PC Wi-Fi sous Windows 7 pro : C'est une GPO qui a été poussée et qui est bien présente sur le poste client avec les paramètres suivants :
      * Authentification: WPA2-Entreprise
      * Chiffrement : AES
      * Méthode d'authentification : Microsoft PEAP (Protected EAP), Propriétés :
           - Connexion à ces serveurs : smo-in301p.grp. monentreprise.com
           - Autorités de certification racine de de confiance : DigiCert High Assurance EV Root CA
           - Mot de passe sécurisé 'EAP-MSCHAPv2) + Utiliser automatiquement mon nom et mon mot de passe Windows d'ouverture de session (et éventuellement le domaine)
           - Activer la reconnexion rapide
      * Mettre en mémoire cache les informations utilisateur pour les futures connexions à ce réseau

    Quels autres éléments dois-je vérifier ?
    • Edited by aheskia Monday, June 18, 2012 9:38 AM
    Monday, June 18, 2012 9:36 AM
  • La stratégie de demande  de connexion et la stratégie de réseau sur le NPS

    - stratégie de connexion : de mémoire, faire une policy qui correspond au type d'accès à traiter, il doit y avoir des paramètres spécifiques à RADIUS et/ou 802.1X. Il s'agit là de spécifier quelles sont les demandes du client Radius à considérer (sans parler encore d'authentification).

    - stratégie de réseau : les paramètres d'authentification et d'autorisation (PEAP / MSCHAPv2)

    Je n'ai pas de client radius sous la main, mais en gros :

    - stratégie de connexon : nouvelle strategié de type "unspecified", choisir la propriété du client radius qui vous convient le mieux (Nom convivial, adresse IP, etc), ou il me semble que vous pouvez aussi choisir le type de port nas en wireless 802.1X. Authentifier les connexions sur ce serveur, mais ne pas surcharger l'authentification

    - stratégie de réseau : authentification PEAP + MSChapv2, il faut fournir aussi une contrainte, vous pouvez mettre un groupe d'utilisateur du domaine par exemple.

    Monday, June 18, 2012 1:21 PM
  • Pour configurer le NPS, j'ai utilisé le wizard "Serveur RADIUS pour les connexions cablées ou sans fil 802.1X"

    J'ai donc bien une stratégie de demande de connexion qui comprend :

    • Etat : activé
    • Type de serveur d'accès réseau : Unspecified
    • Condition : type de port NAS, Valeur : Wireless - Other OU Wireless - IEEE 802.11
    • Méthode d'authentification : rien de cocher
    • Transfert de la demande de connexion - Authentification : Authentifier sur ce serveur
    • Transfert de la demande de connexion - Gestion :  "Transférer les demandes de gestion à ce groupe de serveurs RADIUS distants" non coché
    • Pas de règles sur les attribut du nom de domaine
    • Pas d'attributs RADIUS ni spécifique au fournisseur

    Au niveau de la stratégie réseau :

    • Etat : activé
    • Autorisation : Accorder l'accès si la demande de connexion correspond à cette stratégie
    • Ignorer les propriétés de numérotations des comptes utilisateurs
    • Type de serveur d'accès réseau : Unspecified
    • Conditions : Type de port NAS = Wireless - Other OU Wireless - 802.11  +  Groupe Windows = Wireless Group
    • Contraintes : Méthode d'authentification : Microsoft PEAP (Protected EAP)
              - Certificat délivré à *.macompagnie.com
              - Activer la connexion rapide
              - Mot de passe sécurisé (EAP-MSCHAP vesion 2) - Nombre de nouvelles tentatives  d'authentification : 2 - Autoriser le client à modifier le mot de passe après son expiration
    • Contraintes : Méthode d'authentification moins sécurisée :
               - Authentification chiffrée Microsoft version 2 (MS-CHAP v2)
               - l'utilisateur peut modifier le mot de passe après l'expiration
               - Authentification chiffrée Microsoft (MS-CHAP)
               - l'utilisateur peut modifier le mot de passe après l'expiration
    • Pas de contraintes sur:
               - le délai d'inactivité
               - le délai d'expiration de session
               - ID de la station appelée
               - Restriction relatives aux jours et aux heures
               - type de port NAS
    • Paramètres
               - Attributs Radius standard : Framed-Protocol = PPP et Service-Type = Framed
               - Aucun attributs Radius spécifiques au fournisseur
               - Protection d'accès réseau - Contrainte de mise en conformité NAP : Autoriser un accès complet au réseau
               - Protection d'accès réseau - Etat étendu : <Vide>
               - Routage et accès à distance - Liaisons multiples et protocole BAP : Les paramètres du serveur déterminent l'utilisation de connexions multiples, pas de protocole BAP
               - Routage et accès à distance - pas de filtre IP
               - Routage et accès à distance - chiffrement  : tous les chiffrement sont autorisés (MPPE 40 bits, MPPE 56 bits et MPPE 128 bits et aucun)
               - Routage et accès à distance - Paramètres IP : Les paramètres du serveur déterminent l'attribution des adresses IP

    Tout cela semble donc correspondre à ce que vous indiquez...

    Monday, June 18, 2012 2:42 PM
  • Oui cela semble être les bons paramètres:

    • Nom de la stratégie de demande de connexion : Use Windows authentication for all users
    • Nom de la stratégie réseau : Connections to other access servers

    Ce sont bien les deux stratégies que vous avez crée sur le NPS?

    Sur le poste client (7) essayé de jouer avec l'encryption entre AES et TKIP, et forcé dans les paramètres avancés l'auth Utilisateur pour 802.1X.

    Monday, June 18, 2012 3:09 PM
  • Sur la stratégie de demande de connexion, j'en ai 2 :

    • Connexion sans-fil sécurisées (ordre de traitement 1)
    • Use Windows authentication for all users (ordre de traitement 2)

    Sur la stratégie réseau, j'en ai 3 :

    • Connexion sans-fil sécurisée - ordre de traitement 1 - Type d'accès : Accorder l'accès
    • Connections to Microsoft Routing and Remote Access Server - ordre de traitement 2 - Type d'accès : Refuser l'accès
    • Connections to other access servers - ordre de traitement 3 - Type d'accès : Refuser l'accès

    J'ai modifié la GPO pour les utilisateurs Windows Vista et supérieure comme suit :

    gpo

    Le PC a bien repris en GPO les nouveaux paramètres :

    conf-wifi

    Mais j'ai toujours le code erreur 65 si je n'active pas "Autorisé" dans Appel entrant de l'utilisateur

    ou le code 66 (L’utilisateur a essayé d’utiliser une méthode d’authentification qui n’est pas activée sur la stratégie réseau correspondante.) quand je l'active.

    Monday, June 18, 2012 5:00 PM
  • Si vous avez

    • Nom de la stratégie de demande de connexion : Use Windows authentication for all users
    • Nom de la stratégie réseau : Connections to other access servers

    C'est que vous tombez dans ces stratégies concernant l'accès, donc hors de vos stratégies définies pour le WiFi, qui ne sont donc pas évaluées. Revoir la configuration de la borne et du NPS.

    Tuesday, June 19, 2012 7:37 AM
  • Je ne suis pas sur de bien saisir votre réponse.

    J'ai bien ces 2 stratégie mais leur ordre de traitement indique qu'elles sont a priori traitées après la stratégie Wi-Fi qui à l'ordre n°1, non ?

    Faut-il que je supprime ces 2 policies par défaut ? (ce n'est pas indiqué dans le guide de Microsoft...)

    Tuesday, June 19, 2012 7:58 AM
  • Non, cela signifie que la requete ne tombe pas dans la stratégie Wi-Fi, donc que les conditions de celle-ci l'exclue de l'évaluation. Il y a soit un problème de configuration de la borne WiFi, soit des conditions de la stratégie de demande de connexion.

    Essayer d'enlever les conditions de port NAS, et mettez à la place des conditions RADIUS (nom ou IP du serveur).

    Tuesday, June 19, 2012 9:46 AM
  • La configuration de la borne Wi-Fi est la suivante :

    Tuesday, June 19, 2012 10:38 AM
  • Donc vous me demander de modifier la condition dans la stratégie de demande de connexion ?

    Actuellement la condition est la suivante :

     

    Je la supprime puis je clique sur ajouter et j'ai le choix suivant :

     

    Quelle condition dois-je ajouter ?


    Merci.

    Tuesday, June 19, 2012 10:39 AM
  • Essayer avec "Propriété du client radius" -> "Adresse IPV4 du client", vous mettez l'IP de la borne WiFi.

    L'idée est que les requetes doivent être acceptées par la stratégie de demande de connexion WiFi, si ce n'est pas le cas, c'est que les informations passées par la borne à NPS ne sont pas celles attendues.

    Tuesday, June 19, 2012 12:00 PM
  • Effectivement en changeant la condition (i.e. condition sur l'adresse IP de la borne Wi-Fi) pour les 2 stratégie (stratégie de demande de connexion et stratégie réseau), je vois dans les logs que cette fois-ci ces 2 stratégies sont utilisées lors de la connexion et d'ailleurs dans les logs je vois aussi que le type d’authentification n'est plus EAP mais PEAP.

    On progresse donc ! Maintenant c'est l'authentification de l'utilisateur qui semble rejetée... Mais je vois aussi que mes contrôleurs de domaines ne veulent plus se synchroniser ! J'ai aussi plein d'autres erreurs.

    Je vais remasteriser mes 2 VM et je reposte plus tard dès que mon infra est à nouveau en place pour vous donner les résultats.

    A plus tard...

    Thursday, June 21, 2012 7:35 AM
  • Re bonjour,

    Bien mon infra est de nouveau en place et donc j'ai bien reparamétré les conditions avec l'IP de la borne Wi-Fi et ce sont bien les bonnes policies qui sont maintenant sélectionnées par le NPS. Le code erreur est maintenant 22 ! il semblerait qu'il reste en EAP et ne passe pas en PEAP... Une idée ?

    Le serveur NPS a refusé l’accès à un utilisateur.

    Contactez l’administrateur du serveur NPS pour plus d’informations.

    Utilisateur :

    ID de sécurité : GRP\Test1

    Nom de compte : GRP\Test1

    Domaine de compte : GRP

    Nom de compte complet : GRP\Test1

    Ordinateur client :

    ID de sécurité : NULL SID

    Nom de compte : -

    Nom de compte complet : -

    Version du système d’exploitation : -

    Identificateur de la station appelée : -

    Identificateur de la station appelante : -

    Serveur NAS :

    Adresse IPv4 du serveur NAS : 10.9.99.252

    Adresse IPv6 du serveur NAS : -

    Identificateur du serveur NAS : -

    Type de port du serveur NAS : -

    Port du serveur NAS : -

    Client RADIUS :

    Nom convivial du client : ap-252.grp.monentreprise.com

    Adresse IP du client : 10.9.99.252

    Informations détaillées sur l’authentification :

    Nom de la stratégie de demande de connexion : Connexions sans fil sécurisées

    Nom de la stratégie réseau : Connexions sans fil sécurisées

    Fournisseur d’authentification : Windows

    Serveur d’authentification : SMO-IN301P.grp.monentreprise.com

    Type d’authentification : EAP

    Type EAP : -

    Identificateur de la session du compte : -

    Résultats de la journalisation : Les informations de suivi ont été inscrites dans le fichier journal local.

    Code raison : 22

    Raison : Le client n’a pas pu être authentifié car le protocole EAP (Extensible Authentication Protocol) ne peut pas être traité par le serveur.

    Thursday, June 21, 2012 2:55 PM
  • Dans ce cas c'est probablement un problème de paramètrage côté Client (Wifi), normalement cela devrait être en manuel :

    • NetworkName : votre ID de réseau
    • Security Type : WPA2-Enterprise
    • Encryption Type : AES ou TKIP selon ce qui est configuré sur la borne
    • Editer les propriétés du réseau
    • Network auth method : PEAP
    • PEAP setting : Validate server certificate (vous pouvez forcer le certificat ici ou au contraire l'ignorer)
    • PEAP setting : Authentification Method : EAP-MSCHAPv2
    • Advanced Setting / 802.1X : eventuellement forcer l'auth "user" uniquement
    Thursday, June 21, 2012 3:23 PM
  • Il semble y avoir un bug avec le forum, je n'arrive pas à vous répondre... Je suis donc obligé de me répondre à moi-même (et l'affichage est "tout cassé").

    Je revérifie donc point par point la conf :

    - Borne Wi-Fi : SSID, sécurité : WPA Entreprise, encryption : TKIP, serveur Radius 10.9.99.2 (c'est le serveur NPS), port Radius : 1812, Radius pre-shared key : EoJr39eHU8qa8Ob7S6hZLy

    - Serveur :

          - GPO : la GPO de configuration Wi-Fi est supprimée (je configure le Wi-Fi "à la main" sur WIFI-PC1)

          - NPS : STratégie de réseau basée sur Microsoft PEAP (Protected EAP) founissant le certificat délivré par DigiCert, le type EAP est : Mot de passe sécurisé (EAP-MSCHAP version 2) avec 2 tentatives d'authentification

    - WIFI-PC1 :

          - Configuration Wi-Fi manuelle : SSID, Type de sécurité : WPA Entreprise, chiffrement : TKIP,

          - méthode d'authentification : Microsoft: PEAP (Protected EAP), paramètres :

                    - je décoche "valider le certificat du serveur",

                    - méthode d'authentification : Mot de passe sécurisé (EAP-MSCHAP version 2)

                    - Paramètres avancés 802.1X : spécifier le mode d'authentification : je force à "Authentification de l'utilisateur" (au lieu de : authentification de l'utilisateur ou de l'ordinateur)

    Mais j'ai toujours la même erreur avec code raison 22 !

    Pensez-vous que l'option "Activer la reconnexion rapide" peut avoir un impact ?

    • Edited by aheskia Friday, June 22, 2012 9:49 AM
    Friday, June 22, 2012 9:22 AM
  • L'erreur 22 : Network Policy Server was unable to negotiate the use of an Extensible Authentication Protocol (EAP) type with the client computer.

    Cela pourrait être lié au certificat utilisé, pouvez vous valider les points de cet article : http://technet.microsoft.com/en-us/library/cc731363.aspx 

    Note : Apparament l'utilisation de certificat wildcard sur NPS semble poser problème, il y a plusieurs posts sur les forums anglophone et cisco sur ce sujet.


    Friday, June 22, 2012 10:11 AM
  • Voici un extrait de la commande certutil -dump :

    Objet:
        CN=*.monentreprise.com
        O=Mon Entrreprise SAS
        L=Ville
        S=Region
        C=FR

    Algorithme de clé publique :
        ID d'objet Algorithme: 1.2.840.113549.1.1.1 RSA (RSA_SIGN)
        Paramètres de l'algorithme :
        05 00

        2.5.29.17 : indicateurs = 0, longueur = 5e
        Autre nom de l'objet
            Nom DNS=*.monentreprise.com
            Nom DNS=monentreprise.com
            Nom DNS=smo-in101p.grp.monentreprise.com
            Nom DNS=smo-in301p.grp.monentreprise.com

        2.5.29.15 : indicateurs = 1(Critique), longueur = 4
        Utilisation de la clé
            Signature numérique, Chiffrement de la clé (a0)

        2.5.29.37 : indicateurs = 0, longueur = 16
        Utilisation avancée de la clé
            Authentification du serveur (1.3.6.1.5.5.7.3.1)
            Authentification du client (1.3.6.1.5.5.7.3.2)

    Donc elle répond au prérequis listés de l'article mentionné :

    • clé RSA
    • EKU : Authentification du serveur (1.3.6.1.5.5.7.3.1)
    • Alternate name contenant le FQDN du serveur

    De plus, j'ai explicitement configuré le client pour ne pas vérifier le certificat du serveur !... donc cela devrait aller, non ?

    Tuesday, June 26, 2012 5:46 PM
  • Apparament les problèmes cités sont plutôt dans l'intégration de certificat wildcard dans NPS. EN effet même si le client ne vérifie pas le certificat, c'est celui ci qui sert côté NPS à créer les cannaux sécurisés.

    Idéalement vous pourriez essayer avec un certificat "normal" (un self signed que vous aurez aussi rajouter dans le trusted root d'un client de test)

    Thursday, June 28, 2012 8:19 AM
  • Je vais voir comment DigiCert peut me signer un certificat "de test" (valide 1 ou 2 mois) pour finaliser cette maquette.

    Pour le certificate request je m'appuie sur cette documentation jusqu'à l'étape 7 : http://support.microsoft.com/kb/321051/en-us

    Au niveau de l'EKU dois-je spécifier les 2 OID :  Authentification du serveur (1.3.6.1.5.5.7.3.1) et Authentification du client (1.3.6.1.5.5.7.3.2)

    ou seul 1.3.6.1.5.5.7.3.1 (authentification serveur) est suffisant ?

    Par contre est-ce que la requete request.req créée par la commande certreq -new request.inf request.req peut être considérée comme un certificat auto-signé ?

    Où est la clé privée ?

    Comment puis-je créé un certificat auto-signé en ligne de commande (je ne souhaite pas installé IIS) ?




    • Edited by aheskia Friday, June 29, 2012 2:43 PM
    Friday, June 29, 2012 2:40 PM
  • Authentification du serveur (1.3.6.1.5.5.7.3.1) devrait suffire, par contre certreq ne fait que créer une demande de certificat, il faut un autre outil pour la valider (les outils du rôle AD CS par exemple, ou OpenSSL)

    Techniquement, lorsque vous créez une demande de certificat sur un serveur celui ci stock dans un magasin spécifique les demandes en attente, avec la clé privée. Une vois le fichier de req signé et retourné par une autorité, sur le même serveur, vous allez pouvoir combiner la requête signée et la clé privée stockée localement pour avoir un certificat complet.

    Monday, July 02, 2012 8:15 AM
  • Désolé pour ce retour tardif...

    On progresse :

    1. Je me suis créé une autorité de certification (sous OpenSSL sur une machine séparée) avec un certificat Root que j'ai positionné dans les autorités de confiance des magasins des 2 serveurs (SMO-IN101P et SMO-IN301P) ainsi que le portable sou Windows 7 (WIFI-PC1)
    2. J'ai ensuite créé un certificat signé par cette autorité (je n'ai pas fait de certreq -new.. sur le serveur, j'ai directement généré un certificat machine signé avec sa clé privé sur le serveur OpenSSL (j'ai bien entendu fourni le bon sujet, le bin id EKU, etc...) , j'ai exporté la clé et le certificat .crt et un fichier .pfx que j'ai ensuite importé dans le serveur NPS (SMO-IN301P)
    3. J'ai recréé les stratégie radius sur le NPS basé sur ce nouveau certificat serveur

    Le résultat :

    • dans les logs du NPS : j'ai bien les 2 messages qui indiquent "Le serveur NPS a accordé l’accès à un utilisateur" et "Le serveur NPS a accordé l’accès total à un utilisateur car l’hôte répond aux critères définis par la stratégie d’intégrité." et je vois que ça a bien basculé en PEAP (et non EAP)

    Nom de la stratégie réseau : Connexions sans fil sécurisées

    Fournisseur d’authentification : Windows

    Serveur d’authentification : SMO-IN301P.grp.monentreprise.com

    Type d’authentification : PEAP

    Type EAP : Microsoft: Mot de passe sécurisé (EAP-MSCHAP version 2)

    • Mais sur le PC : quand je lance la connexion sur le SSID, cela prend très longtemps et au bout d'un certain temps j'ai un message "Windows n'a pas pu se connecter à CORP-WIFI" !!! je n'ai plus de GPO, j'ai créé cet accès "à la main" en désactivant la validation du certificat serveur dans les paramètres PEAP.

    Que se passe-t-il ?

    Wednesday, July 04, 2012 5:26 PM
  • Le serveur NPS a accordé l'accès, donc le problème vient plus probablement de la borne Wifi ou du certificat autosigné, même si j'ai déjà réussi à faire fonctionner un certificat autosigné sans problème. Pour le certificat, avez vous un chemin pour la vérification de la liste de révocation (CRL)? Avez essayer de le placer dans le trusted root du poste client? Si cela fonctionne en le placant dans le trusted root, vous pourrez sans problème basculer vers un certificat publique.

    Voir aussi le journal d'évenement du poste client.

    Thursday, July 05, 2012 6:39 AM
  • Je n'y arrive toujours pas.

    J'ai essayé d'ajouter le RootCA dans le magasin NTAuth sur le poste client avec la commande

    certutil -enterprise -addstore NTAuth CA_CertFilename.cer

    où CA_CertFilenalme.cer est l'export de mon autorité de certification qui a signé le certificat. Je n'ai plus le message d'erreur sur le client sur la partie certificat. Mais la connexion reste 'limitée', comme si le client n'obtenait pas d'adresse IP du serveur DHCP.

    Je tente un ipconfig /renew ==> Mais il bloque sur la carte Wi-Fi avec le message : Impossible de contacter votre serveur DHCP

    Y a-t-il un pré-requis pour que le serveur DHCP soit sur le même server que le RADIUS/NPS ?

    J'ai regardé l'observateur d'évènement du client, mais je ne trouve pas de message d'erreur sur la partie Wi-Fi. Quel journal dois-je regarder en particulier ?

    Merci.

    Monday, July 09, 2012 11:28 AM
  • Je viens de faire un test et de me connecter avec un iPhone (en acceptant le certificat proposé par le serveur) et ça n'a pas l'air de mieux marcher :

    Sur les logs du serveur, je vois bien que la connexion est autorisée (d'ailleurs je vois plein de demandes de connexions)

    mais sur l'iphone ça mouline après m'avoir demandé les credentials, mais ça ne semble pas vouloir se connecter...

    Qu'est-ce qui peut bien bloquer comme ça ?

    Monday, July 09, 2012 1:39 PM
  • Bonjour !

    Je progresse... J'ai tout simplement changé de borne Wi-Fi et cela fonctionne beaucoup mieux !

    J'ai recréé la stratégie avec la condition par défaut à savoir : Type de port NAS = Wireless OU Wireless - IEEE 802.11

    Dans les logs la borne est bien vue comme : Sans-fil - IEEE 802.11 et donc match bien la condition des 2 stratégies.

    Après vérification sur le site de la Wi-Fi Alliance, il semblerait que la DI-524 n'est pas certifiée WPA2 entreprise, elle est certifiée "WPA™ - Enterprise, Personal" avec le support EAP-TLS seulement (pas de PEAP a priori) ==> http://certifications.wi-fi.org/pdf_certificate.php?cid=W001969

    Je vais maintenant régler les GPO et la problématique de certificat wildcard pour voir ce que cela donne... EN grand merci Bruce JDC pour vos nombreux conseils !

    Monday, July 23, 2012 9:14 AM