Authentifizierung über RADIUS: MSCHAPv2-Fehler 691

Ich arbeite daran, die Authentifizierung in einem Acme Packet Net-Net 3820 (SBC) über RADIUS einzurichten. Die Buchhaltung funktioniert ohne Probleme. Die Authentifizierungsseite der Dinge ist eine andere Sache. Ich kann einer Paketerfassung entnehmen, dass die Zugriffsanforderungsnachrichten tatsächlich an den RADIUS-Server gelangen. Ab diesem Zeitpunkt beginnt der RADIUS-Server mit der Kommunikation mit den Domänencontrollern. Ich sehe dann, wie die Kommunikationskette zurück zum RADIUS und schließlich zurück zum SBC geht. Das Problem ist, dass die Antwort, die ich zurückerhalte, immer eine Zugriffsverweigerungsnachricht mit einem Ursachencode von 16 ist (Authentifizierung fehlgeschlagen aufgrund einer Nichtübereinstimmung der Benutzeranmeldeinformationen. Entweder stimmt der angegebene Benutzername nicht mit einem vorhandenen Benutzerkonto überein oder das Kennwort war falsch). Dies wird durch Betrachten der Sicherheitsereignisprotokolle bestätigt, in denen die Ereignisse 4625 und 6273 angezeigt werden.

Ereignis-ID: 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.

Ereignis-ID: 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.

Auf den ersten Blick scheint es sich also lediglich um einen ungültigen Benutzernamen oder ein nicht übereinstimmendes Kennwort zu handeln. Dies wird in der Paketerfassung weiter bestätigt, in der die MSCHAPv2-Antwort den Fehlercode 691 aufweist (Zugriff verweigert, da Benutzername oder Kennwort oder beide in der Domäne nicht gültig sind). Die Sache ist, dass ich weiß, dass ich einen gültigen Benutzernamen verwende, und ich habe viele Benutzernamen ausprobiert, einschließlich neuer, die ich nur zur Fehlerbehebung erstellt habe. Ich weiß nicht, wie oft ich das Kennwort zurückgesetzt habe, um sicherzustellen, dass es sich nicht um ein nicht übereinstimmendes Kennwort handelt. Ich habe sogar darauf geachtet, Passwörter zu verwenden, die ziemlich kurz sind und nur Buchstaben enthalten, um sicherzustellen, dass keine Probleme mit der Terminalcodierung aufgetreten sind (wir stellen über SSH-Clients eine Verbindung zum SBC her). Dasselbe habe ich auch mit dem gemeinsamen Geheimnis gemacht, das während der Kommunikation zwischen dem SBC und dem RADIUS-Server verwendet wird. Ich habe versucht, dem Benutzernamen beim Anmelden den Domainnamen voranzustellen (obwohl ich nicht denke, dass dies notwendig sein sollte). Ich habe auch versucht, den vollständigen UPN des Benutzers zum Anmelden zu verwenden. Ich habe mehrere RADIUS-Testclients (NTRadPing, RadiusTest usw.) ausprobiert, aber sie unterstützen entweder MSCHAPv2 nicht oder nur EAP-MSCHAPv2. Ich habe sogar meinen eigenen Client mit dem PECL RADIUS-Modul von PHP erstellt. Trotzdem scheint es bei der MSCHAPv2-Authentifizierung mit einem Fehlercode von 691 immer fehlzuschlagen. Hat jemand eine Idee, warum ich immer einen ungültigen Benutzernamen oder eine falsche Passwortantwort erhalte, wenn ich alles getan habe, um sicherzustellen, dass dies nicht der Fall ist? Ich habe mehrere RADIUS-Testclients (NTRadPing, RadiusTest usw.) ausprobiert, aber sie unterstützen entweder MSCHAPv2 nicht oder nur EAP-MSCHAPv2. Ich habe sogar meinen eigenen Client mit dem PECL RADIUS-Modul von PHP erstellt. Trotzdem scheint es bei der MSCHAPv2-Authentifizierung mit einem Fehlercode von 691 immer fehlzuschlagen. Hat jemand eine Idee, warum ich immer einen ungültigen Benutzernamen oder eine falsche Passwortantwort erhalte, wenn ich alles getan habe, um sicherzustellen, dass dies nicht der Fall ist? Ich habe mehrere RADIUS-Testclients (NTRadPing, RadiusTest usw.) ausprobiert, aber sie unterstützen entweder MSCHAPv2 nicht oder nur EAP-MSCHAPv2. Ich habe sogar meinen eigenen Client mit dem PECL RADIUS-Modul von PHP erstellt. Trotzdem scheint es bei der MSCHAPv2-Authentifizierung mit einem Fehlercode von 691 immer fehlzuschlagen. Hat jemand eine Idee, warum ich immer einen ungültigen Benutzernamen oder eine falsche Passwortantwort erhalte, wenn ich alles getan habe, um sicherzustellen, dass dies nicht der Fall ist?

Hier sind die Spezifikationen für unsere RADIUS-Konfiguration:

• Windows Server 2012 R2
• SQL Server 2012 Back-End-Datenbank für die Abrechnung.
• Der Server wurde in der Domäne autorisiert und ist Mitglied der Gruppe "RAS- und IAS-Server". Für die diese Gruppe Zugriff auf die Konten hat, mit denen wir testen.
• Bei den Konten, mit denen wir testen, ist die Option "Zugriff über NPS-Netzwerkrichtlinie steuern" auf der Eigenschaftsregisterkarte "Einwahl" aktiviert.
• RADIUS-Clients, die so konfiguriert sind, dass sie einfach mit der IP-Adresse übereinstimmen, die Sie aus den obigen Ereignissen ersehen können, dass sie den clientfreundlichen Namen anwenden.
• Verbindungsanforderungsrichtlinie: Die Richtlinie "SBC-Authentifizierung" wird wie oben dargestellt angewendet. Die einzige Bedingung ist ein regulärer Ausdruck, der erfolgreich mit dem Anzeigenamen übereinstimmt.
• Netzwerkrichtlinie: Wie in den obigen Ereignissen dargestellt, werden keine angewendet. Zur Fehlerbehebung habe ich eine Netzwerkrichtlinie erstellt, die für die Verarbeitungsreihenfolge auf "1" festgelegt ist. Die einzige Bedingung ist eine Tages- und Zeitbeschränkung, die derzeit auf eine beliebige Zeit und einen beliebigen Tag festgelegt ist.
• Die Authentifizierungsmethode ist nur auf MSCHAPv2 oder MSCHAPv2 festgelegt (Benutzer kann das Kennwort nach Ablauf ändern). Ich habe versucht, dies nur zur Netzwerkrichtlinie hinzuzufügen, und ich habe auch versucht, dies zur Verbindungsanforderungsrichtlinie hinzuzufügen und so einzustellen, dass die Authentifizierungsmethode der Netzwerkrichtlinie überschrieben wird.
• Wir haben andere RADIUS-Server in unserer Domäne, die PEAP zur Authentifizierung von drahtlosen Clients verwenden, und alle funktionieren einwandfrei. Dies ist jedoch nur für MSCHAPv2 (kein EAP) erforderlich.
• Alle anderen Konfigurationen sind auf die Standardeinstellungen eingestellt.

Die einzigen anderen zu beachtenden Punkte sind die Tatsache, dass Sie in den obigen Ereignissen sehen können, dass die Sicherheits-ID "NULL SID" ist. Jetzt weiß ich, dass dies besonders bei fehlgeschlagenen Anmeldungen häufig vorkommt. Da dieses Problem jedoch einen ungültigen Benutzernamen oder ein ungültiges Kennwort enthält, ist dies in diesem Fall möglicherweise von Bedeutung. Außerdem wurde dieser Server mit demselben Computerkonto in Active Directory neu erstellt. Ich weiß nicht, ob es vor dem Wiederaufbau funktioniert hätte. Im Wesentlichen haben wir diesen Server erstellt und sind erst so weit gekommen, den Server für die Domäne zu autorisieren und SQL hinzuzufügen, als wir beschlossen haben, die SQL-Rolle auf einen anderen Server zu verteilen. Anstatt SQL zu deinstallieren, haben wir den Computer neu erstellt. Vor der Neuinstallation von Windows habe ich jedoch das Computerkonto zurückgesetzt. Ich nicht

Alles in allem handelt es sich um ein ziemlich einfaches Setup, und ich hoffe, ich habe genügend Informationen bereitgestellt, damit sich jemand ein Bild davon machen kann, was möglicherweise vor sich geht. Entschuldigung, wenn mein Verständnis davon ein bisschen grundlegend erscheint, wenn es um RADIUS-Server geht, könnte man sagen, dass ich der neue Typ hier bin.

Bearbeiten 1:

Um dieses Problem weiter zu beheben, habe ich versucht, zusätzliche Server zum Testen aufzurufen. Hier sind die zusätzlichen Tests, die ich durchgeführt habe.

Mehrere Domänen

Ich habe dies jetzt in 3 verschiedenen isolierten Domänen versucht. Sowohl unsere Test- und Produktionsdomänen als auch meine private Heimdomäne, die abgesehen von den für Exchange und ConfigMgr vorgenommenen Änderungen nur sehr wenige Anpassungen aufweist. Alle haben die gleichen Ergebnisse wie oben beschrieben.

VPN-Dienst

Unter Windows Server 2012 R2 haben wir einen separaten Server aufgerufen, um ein Standard-VPN-Setup auszuführen. Die Absicht war zu sehen, ob wir die RADIUS-Authentifizierung mit dem VPN verwenden können, und wenn dies funktioniert, würden wir wissen, dass das Problem bei den SBCs liegt. Bevor wir es jedoch überhaupt für die Verwendung von RADIUS konfigurieren konnten, haben wir nur versucht, sicherzustellen, dass es mit der Standard-Windows-Authentifizierung auf dem lokalen VPN-Server funktioniert. Interessanterweise schlägt auch dies fehl, wenn dieselben Ereignisse wie bei den RADIUS-Servern protokolliert werden. Der Clientcomputer ist eine Windows 8.1-Workstation. Ich weise erneut darauf hin, dass wir funktionierende RADIUS-Server haben, die speziell für unsere drahtlose Umgebung verwendet werden. Der einzige Unterschied zwischen diesen RADIUS-Servern und denen, mit denen ich Probleme habe, besteht darin, dass die funktionierenden drahtlosen Server PEAP anstelle von MSCHAPv2 verwenden.

FreeRADIUS

Jetzt bin ich kein Linux-Guru, aber ich glaube, ich habe es zum Laufen gebracht. Ich kann ntlm_auth verwenden, um Benutzer zu authentifizieren, wenn sie an der Konsole angemeldet sind. Wenn der Radiusd-Dienst jedoch versucht, mit ntlm_auth im Wesentlichen dasselbe zu tun, schlägt dies fehl und gibt dieselbe Meldung zurück, die ich mit dem Windows-Server erhalten habe (E = 691). Ich habe den Radiusd-Dienst im Debug-Modus ausgeführt, damit ich mehr von dem sehen kann, was gerade passiert. Ich kann die Debug-Informationen, die ich erhalte, posten, wenn ich dazu aufgefordert werde. Die Zeilen, die ich von besonderem Interesse sehe, sind jedoch wie folgt:

(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

Hierbei ist zu beachten, dass der tatsächliche Statuscode (0xc000006d) etwas anders ist als auf den Windows-Servern (0xc000006a), während im Wesentlichen immer noch die Meldung "Falsches Kennwort" angezeigt wird. In diesem Dokument können Sie sehen, was diese Codes bedeuten: NTSTATUS-Werte . Das Gute an diesem FreeRADIUS-Server ist, dass ich im Debug-Modus alle Challenge-Antworten sehen kann. Wenn ich mich also darum kümmern kann, wie eine MSCHAPv2-Antwort berechnet wird, kann ich sie vergleichen, um festzustellen, ob dies einfach eine falsch berechnete Challenge-Antwort ist. Update Es wurde nur bemerkt, dass der 6a-Code nur der Substatuscode für den 6d-Code ist. Da sich also nichts von den Windows-Servern unterscheidet, frage ich mich immer noch, ob bei den Challenge-Antworten ein Rechenfehler vorliegt.

Derzeit arbeite ich daran, eine Windows Server 2008 R2-Instanz eines RADIUS-Servers aufzurufen, um festzustellen, ob dies überhaupt hilft. Ich wäre jedoch überrascht, wenn etwas mit dem Dienst zwischen W2K8 R2 und W2K12 R2 kaputt gehen würde, ohne dass es jemand bemerkt hätte. Wenn dies nicht funktioniert, muss ich möglicherweise einen Fall mit Microsoft eröffnen. Update: Gleiche Ergebnisse mit W2K8 R2.

Update 2

Ich habe einen Fall mit Microsoft eröffnet und sie haben ein paar Wochen daran gearbeitet. In der ersten Woche habe ich nur versucht, sie dazu zu bringen, zu verstehen, dass dies nichts mit Wireless zu tun hat und dass das Gerät, mit dem wir eine Verbindung herstellen möchten, keine Authentifizierung gegen einen RADIUS-Server mit irgendeiner Form von EAP unterstützt. Als sie endlich verstanden hatten, dass wir versuchen, die Authentifizierungsmethode nur als MSCHAPv2 einzurichten, war seine erste Reaktion einfach "Sie können das nicht tun". Er sagte, dass unabhängig davon, was Sie immer irgendeine Form von EAP- oder PEAP-Einrichtung in der oberen Box benötigen (selbst für PAP und andere "weniger sichere Methoden" in diesem Fenster für Authentifizierungsmethoden). Dies schien mir höchst unwahrscheinlich, deshalb bat ich um eine Dokumentation, aus der hervorgeht, dass er dann das Thema wechselte und keine Dokumentation zur Verfügung stellte. Es wurde klar, dass ich mit Microsoft nichts anfangen konnte, als sie mir sagten, dass das Problem anscheinend mit dem Benutzernamen und dem Passwort zusammenhängt. Es dauerte also 2 Wochen, bis sie zu diesem Schluss kamen, als die Betreffzeile meines Premiere-Tickets den E691-Fehlercode enthielt, was bedeutet, dass Benutzername und Passwort nicht übereinstimmten, und trotz des sehr langen Absatzes von mir, in dem erklärt wurde, dass ich alles getan habe, um dies sicherzustellen ist kein schlechter Benutzername und Passwort.

Leider möchte mein Projektleiter keine Premiere-Support-Stunden mehr damit verschwenden, daher haben wir den Fall abgeschlossen. Wir werden uns wahrscheinlich nur mit der lokalen gemeinsamen SBC-Anmeldung befassen und eine andere Möglichkeit einrichten, um die Verantwortlichkeit durchzusetzen (nur vier von uns haben Zugriff).

Ich werde darauf hinweisen, dass ich, bevor mir gesagt wurde, dass ich das Projekt löschen soll, den FreeRADIUS-Server nur mit MSCHAPv2 zum Laufen gebracht habe, dies jedoch nur mit lokalen Konten auf dem FreeRADIUS-Server tun konnte. Das sind Klartextkennwörter, die irgendwo in einer FreeRADIUS-Konfigurationsdatei gespeichert sind. Also offensichtlich keine Lösung, aber es zeigt zumindest, dass der SBC über MSCHAPv2 korrekt mit einem RADIUS-Server kommuniziert. Dies und die anderen Dinge, die ich oben erwähnt habe, lassen mich glauben, dass das Problem zwischen dem RADIUS-Server und den Domänencontrollern liegt. Während die NTLM-Authentifizierung sowohl auf dem Windows RADIUS- als auch auf dem FreeRADIUS-Server einwandfrei funktioniert, während sie lokal bei den Servern angemeldet ist (Kann sich über das Testkonto beim Windows RADIUS anmelden und eine erfolgreiche Authentifizierung auf dem FreeRADIUS-Server erhalten, wenn der Befehl ntlm_auth nur mit einem Benutzernamen und einem Kennwort verwendet wird). ,

Also werde ich diesen Thread hier beenden, aber ich werde ein Auge darauf haben und es wird mich benachrichtigen, wenn jemand etwas veröffentlicht. Wenn jemand eine Lösung veröffentlicht oder Kommentare hat, werde ich antworten.

Lösung

Würdest du es nicht wissen? Ungefähr einen Monat nachdem wir diesen Ansatz aufgegeben hatten, einen RADIUS-Server zur Steuerung des Zugriffs auf den SBC zu verwenden, finden wir eine mögliche Lösung. Natürlich sind wir zu diesem Zeitpunkt zu beschäftigt mit anderen Projekten, um diese Lösung noch einmal auszuprobieren, sodass ich nicht 100% sagen kann, ob dies das Problem beheben würde, aber wenn ich es Ihnen erkläre, werden Sie wahrscheinlich zustimmen, dass dies die Antwort ist.

Einer meiner Kollegen war auf einer Microsoft-Konferenz und hatte verschiedene Diskussionen, als ihm klar wurde, dass MSCHAPv2 auf NTLM angewiesen ist, um die Kennwortherausforderungen und -antworten zu generieren. Jetzt verwenden normales altes MSCHAP und MSCHAPv2 (dh nicht EAP-MSCHAPv2 oder PEAP) bei Verwendung in Windows RAS-Diensten standardmäßig NTLMv1.

Da viele von Ihnen bereits begonnen haben, sich durchzusetzen, haben wir, wie viele Administratoren, NTLMv1 auf unseren Domänencontrollern deaktiviert, sodass die Domänencontroller nur NTLMv2-Anforderungen akzeptieren. Dies erklärt, warum der Fehler, den ich weiterhin erhielt, ein "falsches Passwort" -Fehler war. Das an die Domänencontroller gesendete Kennwort hatte das NTLMv1-Format und wurde ignoriert.

Als wir dies erkannten, konnte ich weitere Nachforschungen anstellen und fand den folgenden Artikel:

http://support.microsoft.com/kb/2811487

Dieser Artikel beschreibt das gleiche Verhalten, das ich hatte, einschließlich des von mir erwähnten E = 691-Fehlercodes. Dieser Artikel bietet auch eine Problemumgehung, um RAS-Dienste zu zwingen, NTMLv2 beim Erstellen einer MSCHAPv2-Antwort zu verwenden. Komisch, wie einfach es ist, diese Artikel zu finden, nachdem Sie genau wissen, worum es geht.

Auch hier muss ich noch überprüfen, ob dies das Problem ist, da ich keine Zeit hatte, die RADIUS-Server, die ich bereits außer Betrieb genommen habe, neu zu erstellen, aber ich plane, dies irgendwann auszuprobieren, wenn ich die Gelegenheit dazu bekomme. Ich wollte nur diese mögliche Lösung veröffentlichen, falls jemand anderes über dieses Problem stolpert. Wenn jemand dies vor mir bestätigen kann, lassen Sie es mich bitte wissen.

Bearbeiten - Bestätigt

Wir wurden gebeten, eine größere Rolle bei diesen SBCs zu übernehmen, und als solche kamen wir zu diesem Projekt zurück und brachten erneut einen Windows RADIUS-Server auf. Diesmal haben wir den im obigen Link beschriebenen Registrierungsschlüssel angewendet. Nachdem ich eine Paketerfassung der Kommunikation zwischen dem RADIUS-Server und den SBCs durchgeführt habe, kann ich jetzt tatsächlich sehen, dass "Access Accept" -Nachrichten an die SBCs zurückgeschickt werden. So kann ich jetzt zumindest in unserem Szenario bestätigen, dass das Problem, das wir hatten, wie oben beschrieben ist.

TL; DR

NTLMv1 wurde auf den DCs deaktiviert. Das Festlegen eines Registrierungsschlüssels, um den RADIUS-Server zur Verwendung von NTLMv2 zu zwingen, hat das Problem behoben.

Aus meiner Erfahrung sagt Ihnen MS NPS, wenn der vorinstallierte RADIUS-Schlüssel nicht übereinstimmt. Etwas wie das:

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.

Sie erhalten es im Ereignisprotokoll.

Die Tatsache, dass Sie Access-Reject in Ihrem erfassten Datenverkehr sehen, bedeutet auch, dass vorinstallierte Schlüssel auf beiden Seiten übereinstimmen, da NPS sonst einfach nicht antworten würde und Sie nach der Access-Anforderung keine weiteren RADIUS-Pakete sehen würden.

In den von Ihnen bereitgestellten Protokollen ist außerdem Folgendes wichtig:

Sub Status:     0xC000006A

Dies bedeutet, dass "Benutzername korrekt ist, aber das Passwort falsch ist". Es ist aus meiner Sicht ziemlich explizit.

Ich weiß, dass MS-CHAPv2 kein Kennwort mit reversibler Verschlüsselung speichern muss. Um diese Vermutung zu überprüfen, können Sie dieses Kontrollkästchen für das von Ihnen verwendete Benutzerkonto aktivieren, das Kennwort danach erneut festlegen und es erneut versuchen.

Zu Ihrer Information - Nach dem Upgrade eines funktionierenden RADIUS + MSCHAP-Systems wurde der gleiche Fehler angezeigt.

"\ 000E = 691 R = 1"

Es stellte sich heraus, dass es eine Art Samba-Änderung gab, die die Rechte an der Winbind-Buchse beeinträchtigte. Das Hinzufügen von Freerad zur Gruppe winbindd_priv hat das Problem behoben.

/ etc / group: winbindd_priv: x: 110: freerad

Wir hatten das gleiche Problem mit der Authentifizierung von unseren NPS-Servern, nachdem wir einer vorhandenen 2008R2-Umgebung neue 2012R2-Domänencontroller hinzugefügt hatten. Bei den neuen 2012R2-Domänencontrollern war NTLMv1 deaktiviert, bei den 2008R2-Domänencontrollern war es aktiviert.

Die NPS-Server (mit 2008R2) verweigerten Benutzern nach dem Zufallsprinzip den Zugriff.

Das folgende Ereignis wurde auf den NPS-Servern protokolliert: Ereignis-ID 6273 (Sicherheitsprotokoll) Der Netzwerkrichtlinienserver hat den Zugriff auf einen Benutzer verweigert. Ursachencode: 16 Grund: Die Authentifizierung ist aufgrund einer Nichtübereinstimmung der Benutzeranmeldeinformationen fehlgeschlagen. Entweder wird der angegebene Benutzername keinem vorhandenen Benutzerkonto zugeordnet oder das Kennwort war falsch.

Als die NPS-Server mit dem 2008R2-Gleichstrom verbunden waren, funktionierte alles wie ein Zauber. Aber auf dem 2012R2 DC wurde der Zugriff verweigert. Alles nur, weil NTLMv1 auf den neuen 2012R2-Domänencontrollern deaktiviert war.

Ich kann bestätigen, dass die Lösung im MS KB-Artikel ( http://support.microsoft.com/kb/2811487 ) einwandfrei funktioniert!.

Vielen Dank für diesen ausgezeichneten Artikel !!! Es hat mir sehr viel Zeit bei der Lösung dieses Problems gespart. -)