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.