8
Windows NPS: Drucker via 802.1x Zertifkat (EAP-TLS) anbinden
Hallo,
Ich versuche einen Brother Drucker (DCP-L3550CDW) via 802.1X anzubinden.
Die 802.1x Authentifizierung der Windows Clients funktioniert auf diesem Switch bereits. (auf dem auch der Drucker hängt)
Ich habe auf dem Drucker nun folgende Einstellungen gesetzt:
Das Client-Zertifikat habe ich manuell über die MMC erstellt. Orientiert habe ich mich an den Beiträgen von colinarodo (11.11.2021 11:34 + 15.11.2021 16:00) aus folgendem Thread. Windows NPS Drucker meldet sich als User
d.h.:
1. Computer-Objekt mit dem Namen printer-brother erstellt
2. Zertifikatsvorlage erstellt, bei der ich den „Common name“ und „DNS“ übergeben kann
3. Zertifikat exportiert und am Drucker hinterlegt
Meine Einstellungen der Network Policy:
Leider kappt bei mir die Verbindung nicht. Am NPS bekomme ich die Fehlermeldung
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.
Die fehlende Zertifikatserweiterung 1.3.6.1.4.1.311.25.2 sollte nicht die Ursache sein. StrongCertificateBindingEnforcement ist noch auf „1“ gesetzt. Dies wäre dann der nächste Punkt, den es im Zertifikat im Anschluss noch zu ergänzen gilt.
Hat jemand eine Idee, warum die Verbindung nicht klappt?
Danke
Ich versuche einen Brother Drucker (DCP-L3550CDW) via 802.1X anzubinden.
Die 802.1x Authentifizierung der Windows Clients funktioniert auf diesem Switch bereits. (auf dem auch der Drucker hängt)
Ich habe auf dem Drucker nun folgende Einstellungen gesetzt:
Das Client-Zertifikat habe ich manuell über die MMC erstellt. Orientiert habe ich mich an den Beiträgen von colinarodo (11.11.2021 11:34 + 15.11.2021 16:00) aus folgendem Thread. Windows NPS Drucker meldet sich als User
d.h.:
1. Computer-Objekt mit dem Namen printer-brother erstellt
2. Zertifikatsvorlage erstellt, bei der ich den „Common name“ und „DNS“ übergeben kann
3. Zertifikat exportiert und am Drucker hinterlegt
Meine Einstellungen der Network Policy:
Leider kappt bei mir die Verbindung nicht. Am NPS bekomme ich die Fehlermeldung
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.
Die fehlende Zertifikatserweiterung 1.3.6.1.4.1.311.25.2 sollte nicht die Ursache sein. StrongCertificateBindingEnforcement ist noch auf „1“ gesetzt. Dies wäre dann der nächste Punkt, den es im Zertifikat im Anschluss noch zu ergänzen gilt.
Hat jemand eine Idee, warum die Verbindung nicht klappt?
Danke
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 71999504987
Url: https://administrator.de/forum/windows-nps-drucker-via-802-1x-zertifkat-eap-tls-anbinden-71999504987.html
Ausgedruckt am: 14.04.2025 um 19:04 Uhr
8 Kommentare
Neuester Kommentar
Hat jemand eine Idee, warum die Verbindung nicht klappt?
Ja!Certificate Subject Matching wurde mit den Updates im Mai 2022 deaktiviert, damit das wieder klappt muss ein Registry Key gesetzt werden was die schwachen Abgleichmethoden wieder erlaubt, wenn man noch Zertifikate ohne SID Extension einsetzt.
1
2
3
4
2
3
4
Path: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Key name: CertificateMappingMethods
Type: DWORD
Value: 1FSchannel versucht, jede von Ihnen aktivierte Zertifikatzuordnungsmethode zuzuordnen, bis eine erfolgreich ist. Schannel versucht zuerst, die S4U2Self-Zuordnungen (Service For User-To-Self) zuzuordnen. Die Zertifikatzuordnungen Antragsteller/Aussteller, Aussteller und UPN gelten jetzt als schwach und wurden standardmäßig deaktiviert. Die bitmasked-Summe der ausgewählten Optionen bestimmt die Liste der verfügbaren Zertifikatzuordnungsmethoden.
Der SChannel-Registrierungsschlüssel wurde standardmäßig 0x1F und ist jetzt 0x18. Wenn bei Schannel-basierten Serveranwendungen Authentifizierungsfehler auftreten, empfiehlt es sich, einen Test durchzuführen. Fügen Sie den Registrierungsschlüsselwert CertificateMappingMethods auf dem Domänencontroller hinzu, oder ändern Sie ihn, und legen Sie ihn auf 0x1F fest, und überprüfen Sie, ob das Problem dadurch behoben wird. Weitere Informationen finden Sie in den Systemereignisprotokollen auf dem Domänencontroller nach fehlern, die in diesem Artikel aufgeführt sind. Beachten Sie, dass das Ändern des Werts des SChannel-Registrierungsschlüssels wieder auf den vorherigen Standardwert (0x1F) rückgängig machen wird, um schwache Zertifikatzuordnungsmethoden zu verwenden.
Der SChannel-Registrierungsschlüssel wurde standardmäßig 0x1F und ist jetzt 0x18. Wenn bei Schannel-basierten Serveranwendungen Authentifizierungsfehler auftreten, empfiehlt es sich, einen Test durchzuführen. Fügen Sie den Registrierungsschlüsselwert CertificateMappingMethods auf dem Domänencontroller hinzu, oder ändern Sie ihn, und legen Sie ihn auf 0x1F fest, und überprüfen Sie, ob das Problem dadurch behoben wird. Weitere Informationen finden Sie in den Systemereignisprotokollen auf dem Domänencontroller nach fehlern, die in diesem Artikel aufgeführt sind. Beachten Sie, dass das Ändern des Werts des SChannel-Registrierungsschlüssels wieder auf den vorherigen Standardwert (0x1F) rückgängig machen wird, um schwache Zertifikatzuordnungsmethoden zu verwenden.
Die fehlende Zertifikatserweiterung 1.3.6.1.4.1.311.25.2 sollte nicht die Ursache sein. StrongCertificateBindingEnforcement ist noch auf „1“ gesetzt.
In dem Sinne ist die fehlende Erweiterung schon daran schuld da die alten Abgleichmethoden wie der Namensabgleich des Subjects ja im Mai 2022 deaktiviert wurden und nur durch den von mir oben genannten Registry Key wieder freigeschaltet werden.Dies wäre dann der nächste Punkt, den es im Zertifikat im Anschluss noch zu ergänzen gilt.
Lord of the SID: How to Add the objectSID Attribute to a Certificate ManuallyGruß siddius
1
Wenn hier nix mehr an Rückmeldung kommt dann auch bitte als gelöst markieren!
Hallo,
Sorry für die späte Rückmeldung.
Habe leider noch Troubles.
Bei gesetztem CertificateMappingMethods DWORD auf 1F hat die Verbindung auf Anhieb geklappt. Danke.
Leider schaffe ich es anscheinend nicht, die fehlende Zertifikatserweiterung 1.3.6.1.4.1.311.25.2 korrekt anzugeben, damit die Verbindung auch ohne gesetztem CertificateMappingMethods klappt.
gesetzt habe ich in der MMC bei der Zertifikatsaustellung:
+ ObjectSid des manuell angelegten Computerobjekts)
...zumindest hätte ich den Artikel so verstanden.
Bekomme leider jetzt wieder die Fehlermeldung
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.
Bitte Danke
lg
Sorry für die späte Rückmeldung.
Habe leider noch Troubles.
Bei gesetztem CertificateMappingMethods DWORD auf 1F hat die Verbindung auf Anhieb geklappt. Danke.
Leider schaffe ich es anscheinend nicht, die fehlende Zertifikatserweiterung 1.3.6.1.4.1.311.25.2 korrekt anzugeben, damit die Verbindung auch ohne gesetztem CertificateMappingMethods klappt.
gesetzt habe ich in der MMC bei der Zertifikatsaustellung:
- Common name
- DNS
- Custom extension definition (zusammengesetzt aus dem Teil vor der SID anhand anderer Computerzertifikate
+ ObjectSid des manuell angelegten Computerobjekts)
...zumindest hätte ich den Artikel so verstanden.
Bekomme leider jetzt wieder die Fehlermeldung
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.
Bitte Danke
lg
(zusammengesetzt aus dem Teil vor der SID anhand anderer Computerzertifikate
Könnte man annehmen ist aber leider falsch! Das Prefix vor der SID ist dynamisch und musst auch von der SID abhängig ASN1 DER kodiert werden!Des weiteren klappt das auch nicht bei Computer-Objekten die sich nicht schon einmal selbst beim DC autorisiert haben, diesen fehlen sonst die entsprechenden Attribute.
Am einfachsten erstellt man dazu das Computer-Objekt so dann ist es bereits Domain-Joined ist (offline join) ohne das es je ein Gerät gegeben hat das Kontakt hatte
Wenn das Computer-Objekt bereits angelegt wurde wird dieses mit dem Parameter /resuse wiederverwendet anstatt das ein neues erstellt wird. Mit dem optionalen Parameter /MACHINEOU <Organisationseinheit> lässt sich auch gleich die OU mitgeben in dem das Konto abgelegt werden soll.
Wenn du nun die Einwahl mit dem Zertifikat versuchst das die SID enthält wird es auch ohne Änderung des Registry-Eintrags zu 100% klappen!
1
djoin /provision /domain "MYDOMAIN" /machine "MYCOMPUTER" /reuse /savefile join.txt Wenn du nun die Einwahl mit dem Zertifikat versuchst das die SID enthält wird es auch ohne Änderung des Registry-Eintrags zu 100% klappen!
Vielen vielen Dank, es funktioniert nun.
Deinen Hinweis
Mit welchem Tool hätte ich den Prefix ermitteln können/müssen?
Danke
lg
Deinen Hinweis
Könnte man annehmen ist aber leider falsch! Das Prefix vor der SID ist dynamisch und musst auch von der SID abhängig ASN1 DER kodiert werden!
habe ich erst danach gelesen.Mit welchem Tool hätte ich den Prefix ermitteln können/müssen?
Danke
lg
Servus @soeale,
Habe dafür mal eine kleine Powershell-Funktion geschrieben. Du findest sie in folgendem Beitrag der das ganze Prozedere noch einmal zusammenfasst:
NPS 802.1x Radius Authentication with EAP-TLS and strong certificate mapping for non domain joined devices
Grüße Uwe
Habe dafür mal eine kleine Powershell-Funktion geschrieben. Du findest sie in folgendem Beitrag der das ganze Prozedere noch einmal zusammenfasst:
NPS 802.1x Radius Authentication with EAP-TLS and strong certificate mapping for non domain joined devices
Grüße Uwe
1
Wow.
Danke für die die sehr ausführliche Dokumentation und die Powershell Funktion.
lg Alex
Danke für die die sehr ausführliche Dokumentation und die Powershell Funktion.
lg Alex
