RDP: Authentifizierungsfehler Smartcard

Hallo Leute,

folgendes Problem:

Wenn sich ein User per Terminalclient auf einem Terminalserver mittels Smartcard anmelden will, bekomme ich folgenden Fehler:

Authentifizierungsfehler.
Beim Verarbeiten des Domänencontrollerzertifikats, das für die Smartcard-Authentifizierung verwendet wird, wurde eine nicht vertrauenswürdige Zertifizierungsstelle ermittelt. Weitere Informationen stehen im Systemereignisprotokoll. Wenden Sie sich an den Systemadministrator.

- Im Systemereignisprotokoll steht aber nichts. Weder am TC noch am Connection Broker noch am Terminalserver noch am Domänencontroller (auf welchem auch die Root-CA installiert ist).
- Das Problem tritt nur auf einem TC auf, auf welchen Win 8 Embedded installiert ist. Auf allen anderen Clients (laufen mit Win 7 Embedded) funktioniert es ohne Probleme.
- Der Fehler trat erst mit einem Wechsel der Domäne (inkludierte einen Wechsel aller Server inkl. CA) auf
- Das Root-Zertifikat ist am TC unter "Vertrauenswürdige Stammzertifizierungsstellen" installiert
- ohne Smartcard klappt alles ohne Probleme

Hat irgendwer noch eine Idee, wie ich dem Problem auf die Schliche komme?

Patrick

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 537443

Url: https://administrator.de/forum/rdp-authentifizierungsfehler-smartcard-537443.html

Ausgedruckt am: 31.12.2024 um 04:12 Uhr

5 Kommentare

Neuester Kommentar

Zitat von @Badger:
- Der Fehler trat erst mit einem Wechsel der Domäne (inkludierte einen Wechsel aller Server inkl. CA) auf

Hi Patrick,

passt da das Zertifikat nicht mehr zur Domäne?!

mfg
kowa

Doch - ist ja ein neues Zertifikat.

Was prinzipiell etwas komisch ist:
certutil -v -scinfo liefert u.A. als Ergebnis

Die Zertifizierungskette wurde richtig verarbeitet, doch wird eines der Zertifizierungsstellen-Zertifikate vom Richtlinienanbieter nicht für vertrauenswürdig gehalten. 0x800b0112 (-2146762478)

Doch das wird sowohl bei den Win 7 TCs (wo es geht) als auch beim Win 8 TC (wo es nicht geht) ausgegeben.

Habe mir nun das Smartcard Zertifikat exportiert und mittels certutil -verify -urlfetch x:\xxx.cer überprüft.
Dabei ist mir folgendes ausgefallen:

Gescheitert "AIA" Zeit: 0
Fehler beim Abrufen der URL: Der Benutzername oder das Kennwort ist falsch. 0x8007052e (WIN32: 1326)

Gescheitert "CDP" Zeit: 0
Fehler beim Abrufen der URL: Der Benutzername oder das Kennwort ist falsch. 0x8007052e (WIN32: 1326)

Doch auch das ist sowohl ident bei den Win 7 TCs als auch bei den Win 8 TCs. Erklärt also auch nicht, warum es bei den einen geht und bei den anderen nicht.

Hier die komplette Ausgabe von certutil -verify:

Aussteller:
CN=TESTDOMAIN-CA
DC=TESTDOMAIN
DC=work
Antragsteller:
CN=Test
OU=Anwender
OU=User
OU=TESTDOMAIN
DC=TESTDOMAIN
DC=work
Zertifikatseriennummer: 0X0X0X0X0X0X0X0X0X0X

dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE

CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
ChainContext.dwRevocationFreshnessTime: 2 Hours, 47 Minutes, 38 Seconds

SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwRevocationFreshnessTime: 2 Hours, 47 Minutes, 38 Seconds

CertContext: dwInfoStatus=102 dwErrorStatus=0
Issuer: CN=TESTDOMAIN-CA, DC=TESTDOMAIN, DC=work
NotBefore: 16.10.2019 14:27
NotAfter: 16.10.2021 14:37
Subject: CN=Test, OU=Anwender, OU=User, OU=TESTDOMAIN, DC=TESTDOMAIN, DC=work
Serial: 0X0X0X0X
SubjectAltName: Anderer Name:Prinzipalname=test@TESTDOMAIN.com
Template: 1.3.6.1.4.1.311.21.8.12489544.11250457.6507141.10031919.15469860.181.8514864.12019296
0X0X0X0X
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
---------------- Zertifikat abrufen ----------------
Gescheitert "AIA" Zeit: 0
Fehler beim Abrufen der URL: Anmeldung fehlgeschlagen: unbekannter Benutzername oder falsches Kennwort. 0x8007052e (WIN32: 1326)
ldap:/CN=TESTDOMAIN-CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=TESTDOMAIN,DC=work?cACertificate?base?objectClass=certificationAuthority

Überprüft "Zertifikat (0)" Zeit: 0
[1.0] http://DC01.TESTDOMAIN.work/CertEnroll/DC01.TESTDOMAIN.work_TESTDOMAIN- ...

---------------- Zertifikat abrufen ----------------
Gescheitert "CDP" Zeit: 0
Fehler beim Abrufen der URL: Anmeldung fehlgeschlagen: unbekannter Benutzername oder falsches Kennwort. 0x8007052e (WIN32: 1326)
ldap:/CN=TESTDOMAIN-CA,CN=DC01,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=TESTDOMAIN,DC=work?certificateRevocationList?base?objectClass=cRLDistributionPoint

Überprüft "Basissperrliste (011e)" Zeit: 0
[1.0] http://DC01.TESTDOMAIN.work/CertEnroll/TESTDOMAIN-CA.crl

Gescheitert "CDP" Zeit: 0
Fehler beim Abrufen der URL: Anmeldung fehlgeschlagen: unbekannter Benutzername oder falsches Kennwort. 0x8007052e (WIN32: 1326)
[1.0.0] ldap:/CN=TESTDOMAIN-CA,CN=DC01,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=TESTDOMAIN,DC=work?deltaRevocationList?base?objectClass=cRLDistributionPoint

Überprüft "Deltasperrliste (011e)" Zeit: 0
[1.0.1] http://DC01.TESTDOMAIN.work/CertEnroll/TESTDOMAIN-CA+.crl

---------------- Basissperrliste veraltet ----------------
Gescheitert "CDP" Zeit: 0
Fehler beim Abrufen der URL: Anmeldung fehlgeschlagen: unbekannter Benutzername oder falsches Kennwort. 0x8007052e (WIN32: 1326)
ldap:/CN=TESTDOMAIN-CA,CN=DC01,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=TESTDOMAIN,DC=work?deltaRevocationList?base?objectClass=cRLDistributionPoint

OK "Deltasperrliste (0123)" Zeit: 0
[1.0] http://DC01.TESTDOMAIN.work/CertEnroll/TESTDOMAIN-CA+.crl

---------------- Zertifikat-OCSP ----------------
Keine URLs "Keine" Zeit: 0
--------------------------------
CRL 011e:
Issuer: CN=TESTDOMAIN-CA, DC=TESTDOMAIN, DC=work
0X0X0X0X
Delta CRL 0123:
Issuer: CN=TESTDOMAIN-CA, DC=TESTDOMAIN, DC=work
0X0X0X0X
Application = 1.3.6.1.4.1.311.20.2.2 Smartcard-Anmeldung
Application[1] = 1.3.6.1.5.5.7.3.2 Clientauthentifizierung

CertContext[1]: dwInfoStatus=10c dwErrorStatus=0
Issuer: CN=TESTDOMAIN-CA, DC=TESTDOMAIN, DC=work
NotBefore: 27.03.2019 16:08
NotAfter: 27.03.2118 16:18
Subject: CN=TESTDOMAIN-CA, DC=TESTDOMAIN, DC=work
Serial: 0X0X0X0X
0X0X0X0X
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
---------------- Zertifikat abrufen ----------------
Keine URLs "Keine" Zeit: 0
---------------- Zertifikat abrufen ----------------
Keine URLs "Keine" Zeit: 0
---------------- Zertifikat-OCSP ----------------
Keine URLs "Keine" Zeit: 0
--------------------------------

Exclude leaf cert:
0X0X0X0X
Full chain:
0X0X0X0X

Verfizierte Ausstellungsrichtlinien: Kein
Verfizierte Anwendungsrichtlinien:
1.3.6.1.4.1.311.20.2.2 Smartcard-Anmeldung
1.3.6.1.5.5.7.3.2 Clientauthentifizierung
Sperrstatussüberprüfung des untergeordneten Zertifikats erfolgreich abgeschlossen.
CertUtil: -verify-Befehl wurde erfolgreich ausgeführt.

Obowhl in der GUI das Root-Zertifikat angezeigt wurde, lieferte certutil -verifystore root kein passendes Ergebnis. Doch auch ein hinzufügen mittels certutil -addstore root RootCA.crt ändert am Hauptproblem nichts.

Ich frage mich, ob ich überhaupt die ganze Zeit der richtigen Spur hinterherlaufe. Denn eine Verbindung ohne Smartcard geht ja. Und wenn da das Stammzertifikat nicht passen würde, würde ja diese Verbindung schon nicht gehen (habe eingestellt, dass eine Serverauthentifizierung Pflicht ist).

So Problem dank dieser Webseite gelöst:

Mittels certutil -viewstore -enterprise NTAuth konnte ich feststellen, dass hier kein Zertifikat hinterlegt war.
Habe daraufhin mittels certutil -enterprise -addstore NTAuth CA_CertFilename.cer das Root-Zertifikat hinzugefügt. Nun gehts.

Interessant dabei:
Unter Win 7 ist hier auch kein Zertifikat hinterlegt. Trotzdem geht es...