Question/réponse Windows NT. Avec l'authentification Windows intégrée, le navigateur client se vérifie par rapport au serveur via une communication cryptographique.

L'authentification intégrée Windows prend en charge à la fois le protocole Kerberos v5 et le protocole NTLM (NT LAN Manager) pour l'authentification via le package Négocier. Si Active Directory est disponible et prend en charge le navigateur approprié (IE 5 ou supérieur sur la plateforme Windows 2000), le protocole Kerberos est utilisé, sinon le protocole NTLM est utilisé. Kerberos et NTLM présentent toutes deux certaines limitations. Un fait intéressant est que les avantages de l’un correspondent aux faiblesses de l’autre. Kerberos fonctionne généralement avec des serveurs proxy, mais avec pare-feu son fonctionnement n'est pas aussi efficace. NTLM fonctionne généralement via des pare-feu, mais interagit plutôt médiocrement avec les serveurs proxy.

Quelques mots sur Microsoft Négocier

Microsoft Négocier est un package qui sert d'interface entre différents fournisseurs de support de sécurité. Il peut choisir entre différents packages d'authentification. IIS utilise le package Négocier pour l'authentification, auquel cas le choix est Kerberos ou NTLM. Ce package ajoute également la prise en charge des futurs forfaits d'authentification, ce qui est l'avantage de Négocier. Par défaut, Négocier sélectionne Kerberos comme protocole le plus sécurisé. Si, pour une raison quelconque, le protocole Kerberos n'est pas disponible, Négocier revient à utiliser NTLM.

Authentification NTLM

NTLM est une version améliorée de l'ancien protocole d'authentification LM (LAN Manager). NTLM fonctionne par question/réponse entre le serveur et le client sans transmettre le mot de passe de l'utilisateur sur le réseau en texte clair. Le client doit confirmer qu'il connaît le mot de passe de l'utilisateur en envoyant un hachage crypté.

NTLM fonctionne comme suit.

1. L'utilisateur spécifie un nom d'utilisateur, un mot de passe et un nom de domaine lors de la connexion à l'ordinateur client.
2. Le client crée un hachage mot de passe donné et supprime l'original.
3. Le client envoie le nom d'utilisateur en texte clair au serveur.
4. Le serveur envoie une donnée aléatoire de 16 bits au client.
5. Le client crypte ce fragment, ainsi qu'un hachage du mot de passe de l'utilisateur, et les transmet au serveur.
6. Le serveur transmet le nom d'utilisateur, une donnée aléatoire et la réponse du client au contrôleur de domaine.
7. Le contrôleur de domaine crypte une donnée aléatoire ainsi que son propre hachage du mot de passe de l'utilisateur, puis le compare avec les éléments envoyés par le serveur.
8. Si les valeurs correspondent, le contrôleur de domaine informe le serveur que l'authentification a réussi.
9. Si les valeurs ou le nom d'utilisateur ne correspondent pas, le contrôleur de domaine en informe le serveur, qui envoie un message correspondant au client. Le navigateur client invite ensuite l'utilisateur données d'authentification.

Authentification Kerberos

Dans la mythologie grecque antique, Kerberos est un fabuleux chien à trois têtes qui gardait le monde souterrain des humains. Actuellement, le terme Kerberos fait référence à un protocole d'authentification sécurisé pour accéder aux ressources. Kerberos est basé sur l'authentification par clé privée, dans laquelle le client et le serveur utilisent la même clé pour le cryptage et le déchiffrement. Le client prouve la connaissance de la clé en chiffrant le message, et le serveur prouve la connaissance de la clé en déchiffrant le message. Le serveur récupère ensuite une partie du message, le crypte et l'envoie au client. Si l'intégrité du message est maintenue, le résultat de l'authentification sera positif.

Kerberos s'appuie sur un serveur central appelé Key Distribution Center (KDC) ( Centre de distribution de clés), qui fournit toutes les clés nécessaires. Le KDC émet des TGT (Ticket-Granting Tickets) et les fournit aux clients demandant l'accès à une ressource sur le serveur.

Vous trouverez ci-dessous le processus permettant à un client de recevoir un ticket TGT initial.

1. L'utilisateur se connecte à l'ordinateur client avec un nom d'utilisateur et un mot de passe.
2. Le client crypte le mot de passe et le stocke.
3. Le client envoie un message au KDC demandant les informations d'authentification pour le service TGT, ainsi que le mot de passe crypté de l'utilisateur.
4. Le KDC compare le mot de passe chiffré avec sa copie principale pour vérifier leur identité. L'horodatage joint par le client à la demande est également vérifié pour garantir qu'il correspond à moins de cinq minutes de l'heure du KDC.
5. S'il existe une correspondance complète, le KDC crée le données d'authentification pour le service TGT en générant clé de session connectez-vous et cryptez-le avec une clé utilisateur.
6. KDC crée un autre fragment données d'authentification par cryptage clé de session login et utilisateur TGT avec sa propre clé principale.
7. KDC envoie les deux fragments données d'authentification au client.
8. Le client déchiffre la clé de session de connexion à partir du premier segment données d'authentificationà l'aide d'un mot de passe crypté et stocke cette clé de connexion de session dans son cache de tickets.
9. Le client stocke également le TGT dans son cache de tickets.

Le client dispose désormais du TGT et peut l'utiliser pour obtenir des tickets d'accès aux ressources. Voici comment cela se passe.

1. Le client demande un ticket au KDC pour accéder aux ressources sur le serveur. Le client fournit son TGT au KDC ainsi que le nom de la ressource souhaitée et un message d'authentification chiffré avec la clé de session de connexion.

Récemment, j'ai rencontré ce problème : FireFox, Chrome, Opéra je ne veux pas passer Autorisation NTLM. Le seul qui a réussi était celui-ci C.-à-D.. J'ai oublié de dire que ce problème se produit sur Windows7. Les méthodes de dépannage de ces problèmes seront décrites ci-dessous.

Opéra: pas officiellement pris en charge NTLM-autorisation, bien que dans les paramètres, vous puissiez trouver un élément qui vous permet d'activer ou de désactiver cette option. Par conséquent, dans les paramètres de votre serveur proxy, vous devez ajouter autorisation de base. Pour désactiver Autorisation NTLM(et faites fonctionner ce navigateur via un proxy), procédez comme suit :

1) tapez about:config dans le navigateur
2) allez dans la section NetWork et décochez le paramètre Enable NTLM
3) redémarrez le navigateur.

Certes, il y a une nuance (un inconvénient, pour ainsi dire) : lors du premier démarrage, vous devrez saisir votre mot de passe de connexion (au complet, c'est-à-dire avec le domaine) et cocher la case "Sauvegarder". Désormais, chaque fois que vous ouvrirez le navigateur la prochaine fois, le signe d'autorisation apparaîtra et il vous suffira d'appuyer sur "D'ACCORD". Ce n'est pas pratique, mais que pouvez-vous faire ?

Note: parfois sur certains OS, au contraire, il fallait activer Autorisation NTLM. Cela dépendait peut-être aussi des versions du navigateur et du système d’exploitation.

FireFox, Chrome : Ils vous soutiennent, même s'il faut faire un peu de chamanisme. Je vais décrire plusieurs options que j'ai trouvées sur Internet, vous devrez peut-être tout essayer jusqu'à ce que vous trouviez celle qui vous convient.

1) vous devrez ajouter un paramètre dans le registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa appelé Niveau de compatibilité Lm taper DWORD et attribuez-lui une valeur 1 . Après quoi vous devrez redémarrer l'ordinateur (c'est l'option qui me convenait)

2) À Firefox pourrait passer ntlm autorisation, il semble qu'il suffise d'ouvrir about:config dans la barre d'adresse et de modifier les paramètres comme suit :

réseau.négocier-auth.delegation-uris = http://,https://
réseau.négocier-auth.trusted-uris = http://,https://

Redémarrez ensuite le navigateur.

3) Ouvrez l'éditeur de stratégie ( gpedit.msc) Configuration ordinateur -> Configuration Windows -> Paramètres de sécurité -> Stratégies locales -> Paramètres de sécurité -> Sécurité réseau : niveau d'authentification LAN Manager et définissez le paramètre Envoyer LM et NTLM - utilisez la sécurité de session NTLMv2 lors de la négociation.

Ensuite, nous fermons la politique et redémarrons.

Si vous avez version anglaise, puis comme ceci : stratégie de la machine-> configuration de l'ordinateur->paramètres de Windows->stratégies locales->option de sécurité->Sécurité réseau : niveau d'authentification de LAN Manager et sélectionnez LM & NTLM — Utiliser la session NTLMv2 si négociée.

4) Une autre option consiste à configurer via calmar_ldap:

programme de base auth_param /usr/lib/squid3/squid_ldap_auth -b "cn=users,dc=office,dc=ru" -f "sAMAccountName=%s" -h 192.168.0.74 -D "cn=administrator,cn=users, dc=office,dc=ru" -w "secpass"
auth_param enfants de base 5
auth_param domaine de base Mon proxy inet
auth_param informations d'identification de basettl 60 minutes

external_acl_type nt_groups %LOGIN /usr/lib/squid3/squid_ldap_group -R -b "cn=users,dc=office,dc=ru" -f "(&(cn=%v)(memberOf=cn=%a,cn= utilisateurs,dc=office,dc=ru))" -D "cn=administrateur,cn=utilisateurs,dc=office,dc=ru" -w "secpass" -h 192.168.0.74

acl tous les src 0.0.0.0/0.0.0.0
acl group_inet externe nt_groups inet

http_access autoriser group_inet
http_reply_access autoriser tout
icp_access autorise tout
http_access refuser tout

Essayez quand même :)

Travaillant dans un environnement Windows, tout le monde administrateur du système d'une manière ou d'une autre, il rencontre des systèmes d'authentification. Mais pour beaucoup, ce mécanisme est une boîte noire, alors que l’essence des processus en cours reste floue. En même temps de paramètres corrects l'authentification affecte directement la sécurité du réseau, il est donc important non seulement de connaître les méthodes et les protocoles, mais aussi de comprendre leur fonctionnement, au moins à un niveau général.

Dans le cadre de ce matériel, nous envisagerons une présentation volontairement simplifiée des procédures d'authentification, suffisante pour comprendre le principe de base de fonctionnement par la suite, ces connaissances pourront être approfondies par l'étude de la littérature spécialisée ;

Tout d’abord, clarifions les termes. Beaucoup de gens confondent les notions d’authentification et d’autorisation, bien qu’il s’agisse de procédures différentes.

• Authentification- vient du mot anglais authentification, que l'on peut traduire par identification ou authentification. Cela reflète pleinement l'essence du processus - l'authentification de l'utilisateur, c'est-à-dire nous devons nous assurer que l'utilisateur qui tente d'accéder au système est bien celui qu'il prétend être.
• Autorisation- traduction de mots autorisation moyens autorisation, c'est-à-dire vérifier les droits d'accès à un objet. Le processus d'autorisation ne peut être appliqué qu'à un utilisateur authentifié, car avant de vérifier les droits d'accès, nous devons connaître l'identité de l'objet auquel nous allons accorder des droits.

Pour faciliter l'imagination de ce processus, faisons une analogie simple. Vous êtes à l'étranger et un policier vous arrête, vous montrez votre passeport. Le policier vérifie les informations contenues dans le passeport et compare la photo - il s'agit d'un processus d'authentification. Après s'être assuré que vous êtes bien vous, le policier vous demande de montrer votre visa - il s'agit d'une procédure d'autorisation, c'est-à-dire tu as le droit d'être ici.

De la même manière, un policier, après avoir arrêté un travailleur migrant et vérifié son passeport, demande un permis de travail, s'il n'y a pas d'autorisation, alors l'invité étranger a réussi l'authentification, mais a échoué à l'autorisation ; Si l'authentification échoue, l'autorisation ne sera pas effectuée.

Pour l'authentification dans systèmes informatiques Traditionnellement, une combinaison d'un nom d'utilisateur et d'une certaine phrase secrète (mot de passe) est utilisée, ce qui permet de déterminer que l'utilisateur est exactement celui qu'il prétend être. Il existe également d'autres méthodes d'authentification, par exemple à l'aide d'une carte à puce, mais nous n'y reviendrons pas dans cet article.

Authentification locale

Commençons par l'authentification locale, où l'utilisateur souhaite se connecter directement à un poste de travail qui ne fait pas partie d'un domaine. Que se passe-t-il une fois que l'utilisateur a saisi son nom d'utilisateur et son mot de passe ? Immédiatement après, les données saisies sont transmises au sous-système de sécurité local (LSA), qui convertit immédiatement le mot de passe en hachage ; le hachage est une transformation cryptographique unidirectionnelle qui rend impossible la restauration de la séquence d'origine. En texte clair, le mot de passe n'est stocké ni affiché nulle part dans le système ; l'utilisateur est le seul à le connaître.

Le service LSA contacte ensuite le gestionnaire de comptes de sécurité (SAM) et lui fournit le nom d'utilisateur. Le répartiteur accède à la base de données SAM et récupère le hachage du mot de passe à partir de là utilisateur spécifié, généré à la création compte(ou pendant le processus de changement de mot de passe).

Le LSA compare ensuite le hachage du mot de passe saisi et le hachage de la base de données SAM, s'ils correspondent, l'authentification est considérée comme réussie et le hachage du mot de passe saisi est placé dans le stockage du service LSA et y reste jusqu'à la fin du session utilisateur.

Si un utilisateur se connecte à un domaine, d'autres mécanismes sont utilisés pour l'authentification, principalement le protocole Kerberos. Toutefois, si l'une des parties ne peut pas l'utiliser, NTLM et même les protocoles LM existants peuvent être utilisés par accord. Nous examinerons ci-dessous le fonctionnement de ces protocoles.

Gestionnaire de réseau local (LM)

Le protocole LAN Manager est apparu à l'aube des réseaux locaux. Contrôle Windows et a été introduit pour la première fois en Windows 3.11 pour les groupes de travail, d'où il a émigré dans la famille Windows 9.x. Nous ne considérerons pas ce protocole, car il n’a plus été trouvé dans le milieu naturel depuis longtemps, mais son support, pour des raisons de compatibilité, est toujours présent. Et si système moderne Si une demande d'authentification utilisant le protocole LM est reçue, alors, si vous disposez des autorisations appropriées, elle sera traitée.

Qu'est-ce qui ne va pas avec ça ? Essayons de le comprendre. Tout d'abord, voyons comment un hachage de mot de passe est créé pour travailler avec le protocole LM, sans entrer dans les détails, attirons votre attention sur les principales limitations :

• Le mot de passe n'est pas sensible à la casse et est converti en majuscules.
• La longueur du mot de passe est de 14 caractères ; les mots de passe plus courts sont complétés par des zéros lors de la création du hachage.
• Le mot de passe est divisé en deux et un hachage est créé pour chaque partie à l'aide de l'algorithme DES.

Sur la base des exigences de sécurité modernes, nous pouvons dire que le hachage LM n'est pratiquement pas protégé et, s'il est intercepté, il est déchiffré très rapidement. Réservons tout de suite que la récupération directe du hachage est impossible, cependant, grâce à la simplicité de l'algorithme de cryptage, il est possible de sélectionner une combinaison correspondant au mot de passe dans un temps extrêmement court.

Et maintenant, la chose la plus intéressante, le hachage LM, à des fins de compatibilité, est créé lors de la saisie d'un mot de passe et est stocké dans les systèmes jusqu'à Windows XP inclus. Cela permet d'attaquer lorsque le système reçoit délibérément une requête LM et qu'il la traite. Vous pouvez éviter de créer un hachage LM en modifiant votre politique de sécurité ou en utilisant des mots de passe de plus de 14 caractères. Sur les systèmes commençant par Windows Vista et Server 2008, un hachage LM n'est pas créé par défaut.

Gestionnaire de réseau local NT (NTLM)

Le nouveau protocole d'authentification est apparu dans Windows NT et, avec quelques modifications, a survécu jusqu'à ce jour. Et avant l'avènement de Kerberos dans Windows 2000, c'était le seul protocole d'authentification du domaine NT.

Aujourd'hui, le protocole NTLM, ou plutôt sa version plus moderne NTLMv2, est utilisé pour authentifier les ordinateurs des groupes de travail ; dans les réseaux de domaine Active Directory, Kerberos est utilisé par défaut, mais si l'une des parties ne peut pas utiliser ce protocole, alors par accord NTLMv2, NTLM et même L.M.

Le principe de fonctionnement de NTLM a beaucoup en commun avec celui de LM et ces protocoles sont rétrocompatibles, mais il existe également des différences significatives. Le hachage NT est formé sur la base d'un mot de passe comportant jusqu'à 128 caractères à l'aide de l'algorithme MD4, le mot de passe est sensible à la casse et peut contenir non seulement des caractères ACSII, mais également Unicode, ce qui augmente considérablement sa force par rapport à LM.

Comment fonctionne le protocole NTLM ? Considérons le schéma suivant :

Disons ordinateur local veut accéder à une ressource de fichier sur un autre PC, que nous considérerons comme un serveur, et il n'est pas du tout nécessaire que ce PC ait un système d'exploitation Northern ou des rôles de serveur. Du point de vue du protocole NTLM, le client est celui qui accède, le serveur est celui à qui l'on s'adresse.

Pour accéder à une ressource, le client envoie une requête au serveur avec le nom d'utilisateur. En réponse, le serveur lui envoie nombre aléatoire, appelé requête du serveur. Le client chiffre à son tour cette demande selon l'algorithme DES, en utilisant le hachage NT du mot de passe comme clé, malgré le fait que le hachage NT soit de 128 bits, en raison de limitations techniques une clé de 40 ou 56 bits est utilisée (le hachage est divisé en trois parties et chaque partie crypte la requête du serveur séparément).

Une requête serveur chiffrée avec un hachage de mot de passe est appelée Réponse NTLM et est renvoyé au serveur, le serveur récupère du stockage SAM le hachage du mot de passe de l'utilisateur dont le nom lui a été transmis et exécute des actions similaires avec la requête du serveur, puis compare le résultat obtenu avec la réponse NTLM. Si les résultats correspondent, alors l'utilisateur client est celui qu'il prétend être et l'authentification est considérée comme réussie.

Dans le cas de l'authentification de domaine, le processus se déroule quelque peu différemment. Contrairement aux utilisateurs locaux, dont les hachages de mots de passe sont stockés dans les bases de données SAM locales, les hachages de mots de passe des utilisateurs de domaine sont stockés sur les contrôleurs de domaine. Lors de la connexion, le LSA envoie une demande au contrôleur de domaine disponible avec le nom d'utilisateur et le nom de domaine et la suite du processus se déroule comme indiqué ci-dessus.

En cas d'accès à des ressources tierces, le schéma change également légèrement :

Ayant reçu une requête du client, le serveur lui enverra également une requête serveur, mais ayant reçu une réponse NTLM, il ne pourra pas calculer la valeur à vérifier de son côté, puisqu'il ne dispose pas du hachage du mot de passe de l'utilisateur du domaine. , il redirige donc la réponse NTLM vers le contrôleur de domaine et lui envoie sa propre requête de serveur. Après avoir reçu ces données, le contrôleur de domaine récupère le hachage de l'utilisateur spécifié et calcule une combinaison de vérification basée sur la demande du serveur, qu'il compare avec la réponse NTLM reçue. S'il y a une correspondance, un message est envoyé au serveur indiquant que le serveur a reçu ces données. l'authentification a réussi.

Comme vous pouvez le constater, le hachage du mot de passe n’est en aucun cas transmis sur le réseau. Le hachage du mot de passe saisi est stocké par le service LSA ; les hachages des mots de passe des utilisateurs sont stockés soit dans les magasins SAM locaux, soit dans les magasins du contrôleur de domaine.

Mais malgré cela, le protocole NTLM ne peut pas être considéré comme sécurisé aujourd’hui. Un cryptage faible permet de récupérer rapidement le hachage du mot de passe, et si non seulement NTLM, mais également une réponse LM a été utilisée, alors de récupérer le mot de passe.

Mais le hachage intercepté peut être tout à fait suffisant, puisque la réponse NTLM est générée sur la base du mot de passe de l'utilisateur et que l'authenticité du client n'est en aucun cas vérifiée par le serveur, il est possible d'utiliser les données interceptées pour un accès non autorisé aux ressources du réseau. L'absence d'authentification mutuelle permet également des attaques de l'homme du milieu, dans lesquelles l'attaquant se fait passer pour le serveur du client et vice versa, établissant deux canaux et interceptant les données transmises.

NTLMv2

Réalisant que le protocole NTLM ne répondait pas aux exigences de sécurité modernes, avec la sortie de Windows 2000, Microsoft a introduit la deuxième version du protocole NTLMv2, qui a été considérablement améliorée en termes d'amélioration de la force cryptographique et de lutte contre les types d'attaques courants. A partir de Windows 7 / Server 2008 R2, l'utilisation des protocoles NTLM et LM est désactivée par défaut.

Considérons immédiatement le schéma avec un contrôleur de domaine ; s'il est absent, le schéma d'interaction ne change pas, seuls les calculs effectués par le contrôleur de domaine sont effectués directement sur le serveur.

Comme dans NTLM, lorsqu'un client contacte le serveur, il lui indique le nom d'utilisateur et le nom de domaine, et en réponse le serveur lui envoie un nombre aléatoire : requête du serveur. En réponse, le client génère également un nombre aléatoire, auquel est ajouté, entre autres, un horodatage appelé demande du client. La présence d'un horodatage permet d'éviter une situation où un attaquant accumule dans un premier temps des données interceptées puis les utilise pour mener une attaque.

La requête du serveur est combinée avec la requête du client et le hachage HMAC-MD5 est calculé à partir de cette séquence. Ensuite, un autre hachage HMAC-MD5 est extrait de ce hachage, dont la clé est le hachage NT du mot de passe de l'utilisateur. Le résultat obtenu est appelé réponse NTLMv2 et est envoyé au serveur avec la requête du client.

La force cryptographique de cet algorithme est pertinente et aujourd'hui, seuls deux cas de piratage de ce hachage sont connus, l'un d'eux a été produit par Symantec à des fins de recherche. Il est prudent de dire qu’à l’heure actuelle, il n’existe pas d’outils répandus pour attaquer NTLMv2, contrairement à NTLM, qui peut être piraté par tout écolier ayant lu attentivement les instructions.

Le serveur, ayant reçu la réponse NTLMv2 et la requête du client, combine cette dernière avec la requête du serveur et calcule également le hachage HMAC-MD5, puis le transmet avec la réponse au contrôleur de domaine. Il récupère le hachage enregistré du mot de passe de l'utilisateur dans le stockage et effectue des calculs sur le hachage HMAC-MD5 des requêtes du serveur et du client, en comparant le résultat obtenu avec la réponse NTLMv2 qui lui est transmise. S'il y a une correspondance, une réponse indiquant une authentification réussie est renvoyée au serveur.

Dans le même temps, comme vous l'avez peut-être remarqué, NTLMv2, comme son prédécesseur, n'effectue pas d'authentification mutuelle, bien que certains documents sur Internet l'indiquent.

Paramètres de sécurité

Maintenant que vous avez une idée du fonctionnement des protocoles d'authentification, il est temps de parler des paramètres de sécurité. NTLMv2 est un protocole totalement sécurisé, mais si le système n'est pas configuré correctement, un attaquant peut envoyer une requête NTLM ou LM et recevoir une réponse correspondante, ce qui permettra une attaque réussie.

Le choix du protocole d'authentification relève de la responsabilité de l'autorité locale ou politique de groupe. Ouvrez l'éditeur de stratégie et accédez à Configuration ordinateur - Configuration Windows- Politiques de sécurité - Politiques locales- Paramètres de sécurité, dans cette section nous trouverons la politique Sécurité réseau : niveau d'authentification LAN Manager.

Dans la même section, il y a une politique Sécurité du réseau : ne stockez pas les hachages LAN Manager la prochaine fois que vous modifierez votre mot de passe, qui désactive la création d'un hachage LM, est actif par défaut à partir de Vista/Server 2008.

Dans notre politique, nous voyons un large choix de valeurs ; il est évident qu’aujourd’hui les politiques commençant en bas de la liste peuvent être considérées comme sûres.

Les mêmes valeurs peuvent être définies via le registre, ce qui est pratique dans les réseaux de niveau groupe de travail, pour cela dans la section HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lsa vous devez créer un paramètre DWORD avec nom Niveau de compatibilité Lm, qui peut prendre des valeurs de 0 à 5. Examinons-les plus en détail :

Nom du paramètre	Ordinateur client	Contrôleur de domaine	Niveau de compatibilité Lm
Envoyer des réponses LM et NTLM	Les ordinateurs clients utilisent l'authentification LM et NTLM et n'utilisent jamais la sécurité de session NTLMv2.		0
Envoyer LM et NTLM - utiliser la sécurité de session NTLMv2	Les ordinateurs clients utilisent l'authentification LM et NTLM et utilisent la sécurité de session NTLMv2 si le serveur la prend en charge.	Les contrôleurs de domaine autorisent l'authentification LM, NTLM et NTLMv2.	1
Envoyer uniquement la réponse NTLM	Les ordinateurs clients utilisent l'authentification NTLMv1 et la sécurité de session NTLMv2 si le serveur la prend en charge.	Les contrôleurs de domaine autorisent l'authentification LM, NTLM et NTLMv2.	2
Envoyer uniquement la réponse NTLMv2		Les contrôleurs de domaine autorisent l'authentification LM, NTLM et NTLMv2.	3
Envoyez uniquement la réponse NTLMv2. Refusez LM.	Les ordinateurs clients utilisent l'authentification NTLMv2 et utilisent la sécurité de session NTLMv2 si le serveur la prend en charge.	Les contrôleurs de domaine refusent d'accepter l'authentification LM et n'accepteront que NTLM et NTLMv2.	4
Envoyez uniquement la réponse NTLMv2. Refusez LM et NTLM.	Les ordinateurs clients utilisent l'authentification NTLMv2 et utilisent la sécurité de session NTLMv2 si le serveur la prend en charge.	Les contrôleurs de domaine refusent d'accepter l'authentification LM et NTLM, et n'acceptera que NTLMv2.	5

Un lecteur attentif, étudiant ce tableau, fera certainement attention à Sécurité des sessions NTLMv2. Cette fonctionnalité, comme toutes les interactions via NTLMv2 en général, est plutôt mal documentée, donc beaucoup de gens comprennent mal la signification de cette fonctionnalité. Mais en fait, tout est assez simple.

Une fois l'authentification du client réussie, une clé de session est générée, qui est utilisée pour confirmer l'authenticité lors d'une interaction ultérieure. La clé de session NTLM est basée uniquement sur le hachage NT et sera la même jusqu'à ce que le client modifie le mot de passe de l'utilisateur. Il nous semble qu’il n’est pas nécessaire d’expliquer les menaces pour la sécurité que cela représente. La sécurité de session NTLMv2 implique le calcul de la clé de session en utilisant non seulement le hachage NT, mais également les requêtes du serveur et du client, ce qui rend la clé unique et beaucoup plus résistante aux attaques possibles. De plus, cette fonctionnalité peut être utilisée conjointement avec l'authentification NTLM ou LM.

Nous espérons que ce matériel vous aidera à mieux comprendre les processus d'authentification dans Systèmes Windows. Dans cet article, nous examinerons en détail la conception et le fonctionnement du protocole Kerberos.

J'ai configuré avec succès l'authentification ntlm. Malheureusement, la configuration permet une autorisation semi-primaire. Par exemple, lorsque j'utilise Turtle svn1.8.4 (avec un accès privilégié à la bibliothèque), les navigateurs Web Chrome ou IE, ils terminent NTLM avec succès sans rien demander. Dans le fichier journal, je peux voir les utilisateurs authentifiés. Malheureusement, lorsque j'utilise par exemple FireFox ou Maxthon non configurés, ce navigateur me demande des identifiants. Je n'en ai pas besoin car la même situation se produit lorsque j'essaie d'accéder à partir d'un autre ordinateur.

j'utilise Serveur Windows en tant que contrôleur de domaine, Windows7/8 en tant que client système, Linux/Debian en tant que serveur Web. J'ai configuré Kerberos depuis Linux avec Windows AD, Winbind pour l'authentification NTLM locale et la série Apache 2.2. Pour l'authentification Apache Glue, j'utilise le module mod_auth_ntlm_winbind.so d'apache2 et dans le contexte config/ntlm pour prendre en charge la communication avec winbind. Cela fonctionne correctement, exemple pour Apache :

# valeurs par défaut pour le répertoire www principal Options Index FollowSymLinks MultiViews AllowOverride Aucun # modifié, empêche tout accès IP, pour l'avenir ajouter un accès sans authentification à partir des hôtes spécifiés Ordre de refus, autoriser le refus de tous #autoriser depuis IP/masque #paramètres pour l'authentification NTLM avec l'assistant winbind AuthName "Authentification NTLM" NTLMAuth sur NTLMAuthHelper "/usr/bin/ntlm_auth --domain=MY.WINDOWS.DOMAIN --helper-protocol=squid-2.5-ntlmssp" NTLMBasicAuthoritative sur AuthType NTLM nécessite un utilisateur valide #car l'adresse IP est refusée par défaut satisfaire n'importe qui

J'espérais pouvoir effectuer une redirection en utilisant la variable Apache authtype, puis l'ajouter à la configuration de réécriture ci-dessus :

RewriteEngine sur RewriteRule ^ /cgi-bin/TestAuth.pl?DollarOne=1&AUTH_TYPE=%(AUTH_TYPE)&REMOTE_USER=%(REMOTE_USER)

Et un exemple du script TestAuth.pl en tant que contenu cgi :

#!/usr/bin/perl utilise strict ; utiliser des avertissements ; utilisez Data :: Dumper ; #moyen simple d'imprimer les variables système print "Content-type:text/plain\r\n"; #respectint Protocole HTML print "\r\n"; print "L'environnement contient :\r\n" ; imprimer "x\r\n" ; print Data::Dumper->Dump([\@ARGV,\%ENV],); #imprime tous les arguments du script et les variables de processus

Malheureusement, dans tous les cas, en utilisant l'authentification ntlm basée sur Windows et en demandant des informations d'identification, je vois toujours que AUTH_TYPE est toujours NTLM. Il n’y a alors aucun moyen de savoir ce que fait le navigateur. Dans cette situation, je peux accéder aux clients du domaine.

J'ai essayé d'emballer ntlm hepler strace. Malheureusement, je ne vois rien de significatif dans mon dump avec quatre méthodes combinant succès/échec et accès IE provoqués par une requête ANT FF. Je pense que la même situation se produit lorsque l'assistant ntlm s'authentifie auprès du serveur samba local, mais je n'ai jamais testé cela.

Maintenant, j'essaie de faire une configuration avec plusieurs types d'authentification, Basic et NTLM. J'essaie d'abord de faire du Basic, de le filtrer en cas d'échec et de le rediriger vers la page d'informations. Malheureusement, actuellement aucun succès avec le mix NTLM :(NTLM est toujours effectué en premier.

Alors, quelqu'un a-t-il une idée sur la façon d'empêcher les informations d'identification ? Comment révoquer l'accès des clients invités ? Comment reconnaître les informations d'identification à partir de l'invite ou de la fenêtre du client API ?

0

2 réponses

J'ai actuellement résolu ce problème en basculant NTLM vers l'authentification Kerberos. Tous ceux prêts pour Winbind fonctionnent directement sous Kerberos car j'ai déjà configuré Kerberos pour Winbind avec la communication du serveur AD. Étant donné que Kerberos est ouvert, les développeurs ont prévu différents sous-authentificateurs sur le point final de l'utilisateur. Un indicateur très utile dans le module Kerberos Apache2.2 est :

KrbMethodNégocier sur KrbMethodK5Passwd désactivé

C'est ce que je veux. Le navigateur reçoit une trame krb avec l'attribut "Ne pas bulle les informations d'identification de l'utilisateur", alors le client ne le fait tout simplement pas. Mais si c'est le cas (une sorte d'incompatibilité ?), le module serveur Apache devrait le détecter et révoquer l'authentification.

Avec NTLM de Microsoft, cela n'est pas possible car le protocole est rompu. La première trame NTLM après qu'un site Web renvoie un code 201 n'a pas la possibilité d'ajouter un attribut « Ne pas demander d'informations d'identification à l'utilisateur ». Je peux ensuite filtrer ce cadre après la fenêtre contextuelle ou la signature de la clé de session du système d'exploitation. Ce navigateur affiche toujours une fenêtre contextuelle lorsque la clé de session du système d'exploitation n'est pas disponible.

Après tout, c'est une autre chance. L'utilisateur prend un certain temps pour saisir ses informations d'identification ou accepte lorsque les informations d'identification sont stockées dans le navigateur. Je peux compter le temps entre l'envoi de la trame d'authentification au navigateur et la composition de la trame à partir du client. Lorsque le délai est trop long, je peux annuler. Malheureusement, cela peut entraîner de fausses non-autorisations sur des ordinateurs ou des réseaux occupés.

J'utiliserai les deux méthodes à l'avenir :) Ce sera amusant si tout peut être fait en utilisant le module d'authentification apach winbind. L'ensemble de la configuration peut ensuite être encapsulé sous Apache, de la même manière que pour l'authentification Kerberos.

Merci à tous pour vos recherches intéressantes et votre aide :)

L’utilisation de l’authentification NTLM ne garantit pas une autorisation sans informations d’identification. Si vous disposez d'informations d'identification valides Données Windows que le serveur peut reconnaître, vous ne recevrez pas de demande de mot de passe.

Si l’utilisateur ne dispose pas d’informations d’identification NTLM manquantes valides, il sera invité à les fournir. Ce n’est pas une manière de revenir à une authentification « de base ».

Malheureusement, il n'est pas possible de déterminer si l'utilisateur a fourni ses informations d'identification ou est passé par le système.

Peut-être demander nouvelle question sur ce que vous voulez que vos utilisateurs expérimentent (c'est-à-dire différents sites pour les utilisateurs internes et externes) et quelqu'un peut vous aider d'une manière différente.