none
RDS - Es konnte keine Sperrprüfung für das Zertifikat durchgeführt werden. RRS feed

 > 

  • Allgemeine Diskussion

  • Discussion
    Anmelden
    0
    Anmelden

    Wir haben eine Serverlandschaft von 2008 R2 auf 2012 R2 umzuziehen.

    U.a. gibt es auch eine neue RDS-Farm, welche via AD interner Zertifizierungsstelle mit
    einem WildCard Zertifikat versorgt ist.

    Konfiguriert ist via GPO Single Sign On, das WildCard ist auf den RDS Hosts installiert, an die
    RDS Dienste gebunden, die RDP  Datei signiert und der AD CA Server als vertrauenswürdiger
    Herausgeber via GPO im Netz bekannt.

    Die Clients (W7) verbinden sich innerhalb der Domäne mit der RDS-Farm.

    Die Anmeldung funktionierte auch ohne jegliches Hinweisfenster zur RDS-Farm.

    Am letzten Wochenende wurde als nächste zu migrierende Funktion die AD CA umgezogen.

    Alter Server:
    - CA gesichert
    - CA Root Austellerzertifikat gesichert
    - Regkey mit der Config exportiert, der CAServer Name auf den neuen Server geändert
    - CA deinstalliert

    Neuer Server:
    - CA Rolle installiert, 
    - Zertifikat importiert
    - Regkey importiert
    - CA Rücksicherung
    - Rechte via ADSI der neuen Container CDP und AIA auf Vollzugriff des neuen Server geprüft
    - CA Dienstneustart


    Alle Zertifikate wieder da.

    Leider funktioniert seitdem das SSO auf die RDS-Farm nicht mehr.

    "Es konnte keine Sperrprüfung für das Zertifikat durchgeführt werden."

    Wenn man den Dialog, ob man trotz Zertifikatsfehler verbinden möchte, mit Ja bestätigt,
    wiederholt sich der Dialog. Bestätige ich erneut mit Ja, wird per SSO ohne weiteres angemeldet.
    Bei der nächsten Anmeldung an der RDS-Farm wiederholt sich das Spiel.

    Im ersten Schritt dachte ich, es liegt daran, dass die CRL ja noch auf den alten Server zeigen.
    Korrigiert mich, aber das ist wohl Quatsch, da dort ja nur Variablen im Pfad verwendet werden.

    Ich habe daher am Anfang dann ein neues Wildcard erzeugt und nach bekannten und ursprünglichen Procedere
    erneut verteilt. Mit dem gleichen Ergebnis.
    Im Zertifikat wurden nur LDAP Pfade hinterlegt, was m.W. innerhalb der AD auch kein Problem sein sollte und
    vor dem CA Umzug auch keines war.
    Habe dennoch in den Erweiterungen in der CA die Haken gesetzt, dass auch Http Pfade angelegt werden sollen und
    nun mittlerweile ein 3. Zertifikat erzeugt und verteilt.
    Der Fehler bleibt. Ein Abruf der CRL über den hinterlegten Http Pfad ist aber ohne Probleme möglich.

    Die angezeigte Zertifikatskette vom Client aus ist gültig.

    Was kann ich tun?

    Gruß

    Dirk

    Mittwoch, 28. Juni 2017 15:20
    |

Alle Antworten

  • Discussion
    Anmelden
    1
    Anmelden

    Im ersten Schritt dachte ich, es liegt daran, dass die CRL ja noch auf den alten Server zeigen.
    Korrigiert mich, aber das ist wohl Quatsch, da dort ja nur Variablen im Pfad verwendet werden.

    Fühle Dich korrigiert ;-)

    In der Konfiguration der CA stehen Platzhalter in den Pfaden, bei der Ausstellung der Zertifikate werden sie natürlich durch Werte ersetzt. Sonst bräuchte der Client bei der Validierung ja Zusatzinformationen.

    Kannst ja mal den Trust mit viel Output prüfen lassen (certutil -f -urlfetch -verify <Pfad zur .cer>), vielleicht fällt Dir da was auf.

    Welchen Vertraulichkeitsstatus zeigt denn Deine Farm? (Get-RDCertificate | Select Role, Level)?

    Du könntest versuchen statt einem Wildcard ein Zert zu verwenden, der auf den LoadBalancing-Namen Deiner Connection Broker ausgestellt ist.

    Und, last but not least, must Du natürlich den Thumbprint des als RDPublishing eingestellten Zertifikates auch an die Clients als "vertrauenswürdigen Signierer" per GPO verteilen.

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> http://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    Mittwoch, 28. Juni 2017 15:38
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Ok. ich kann wohl kaum verbergen, dass ich im Thema AD CA nicht sonderlich tief drin bin. :-)

    Danke.

    Der Output vom urlfetch:

    Aussteller:
        CN=XXXXXXXXX - interne Zertifizierungsstelle
        DC=XXXXXXXXX
        DC=local
    Antragsteller:
        CN=*.XXXXXXXXX.local
        OU=IT
        O=XXXXXXXXX e.V.
        L=XXXXXXXX
        S=NRW
        C=DE
    Zertifikatseriennummer: 29000000238400195b4e942e55000100000023

    dwFlags = CA_VERIFY_FLAGS_ALLOW_UNTRUSTED_ROOT (0x1)
    dwFlags = CA_VERIFY_FLAGS_IGNORE_OFFLINE (0x2)
    dwFlags = CA_VERIFY_FLAGS_FULL_CHAIN_REVOCATION (0x8)
    dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
    dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
    ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN (0x20000000)
    HCCE_LOCAL_MACHINE
    CERT_CHAIN_POLICY_BASE
    -------- CERT_CHAIN_CONTEXT --------
    ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

    SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

    CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
      Issuer: CN=XXXXXXXXX - interne Zertifizierungsstelle, DC=XXXXXXXXX, DC=local
      NotBefore: 26.06.2017 22:17
      NotAfter: 26.06.2019 22:17
      Subject: CN=*.XXXXXXXXX.local, OU=IT, O=XXXXXXXXX e.V., L=XXXXXXXX, S=NRW, C=DE
      Serial: 29000000238400195b4e942e55000100000023
      Template: WebServer
      c8 26 30 31 55 7c d2 ae a6 08 d4 9f 84 52 b8 4b fb 60 e5 f6
      Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
      ----------------  Zertifikat abrufen  ----------------
      Überprüft "Zertifikat (0)" Zeit: 0
        [0.0] ldap:///CN=XXXXXXXXX%20um%20XXXXXXXXX%20-%20interne%20Zertifizierungsstelle,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=XXXXXXXXX,DC=local?cACertificate?base?objectClass=certificationAuthority

      Überprüft "Zertifikat (1)" Zeit: 0
        [0.1] ldap:///CN=XXXXXXXXX%20um%20XXXXXXXXX%20-%20interne%20Zertifizierungsstelle,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=XXXXXXXXX,DC=local?cACertificate?base?objectClass=certificationAuthority

      ----------------  Zertifikat abrufen  ----------------
      Überprüft "Basissperrliste (07c3)" Zeit: 0
        [0.0] ldap:///CN=XXXXXXXXX%20um%20XXXXXXXXX%20-%20interne%20Zertifizierungsstelle,CN=XXXXX-SRV-0021,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=XXXXXXXXX,DC=local?certificateRevocationList?base?objectClass=cRLDistributionPoint

      Überprüft "Deltasperrliste (07c3)" Zeit: 0
        [0.0.0] ldap:///CN=XXXXXXXXX%20um%20XXXXXXXXX%20-%20interne%20Zertifizierungsstelle,CN=XXXXX-SRV-0021,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=XXXXXXXXX,DC=local?deltaRevocationList?base?objectClass=cRLDistributionPoint

      Überprüft "Basissperrliste (07c3)" Zeit: 0
        [1.0] http://XXXXX-SRV-0021.XXXXXXXXX.local/CertEnroll/XXXXXXXXX%20um%20XXXXXXXXX%20-%20interne%20Zertifizierungsstelle.crl

      Überprüft "Deltasperrliste (07c3)" Zeit: 0
        [1.0.0] ldap:///CN=XXXXXXXXX%20um%20XXXXXXXXX%20-%20interne%20Zertifizierungsstelle,CN=XXXXX-SRV-0021,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=XXXXXXXXX,DC=local?deltaRevocationList?base?objectClass=cRLDistributionPoint

      ----------------  Basissperrliste veraltet  ----------------
      OK "Deltasperrliste (07c5)" Zeit: 0
        [0.0] ldap:///CN=XXXXXXXXX%20um%20XXXXXXXXX%20-%20interne%20Zertifizierungsstelle,CN=XXXXX-SRV-0021,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=XXXXXXXXX,DC=local?deltaRevocationList?base?objectClass=cRLDistributionPoint

      ----------------  Zertifikat-OCSP  ----------------
      Keine URLs "Keine" Zeit: 0
      --------------------------------
        CRL 07c3:
        Issuer: CN=XXXXXXXXX - interne Zertifizierungsstelle, DC=XXXXXXXXX, DC=local
        62 d7 62 a7 59 65 10 05 45 3e 84 7e 10 32 30 bd c3 29 8b 18
        Delta CRL 07c5:
        Issuer: CN=XXXXXXXXX - interne Zertifizierungsstelle, DC=XXXXXXXXX, DC=local
        eb 98 9d 20 22 9c 6d ff a9 26 9c bf 5a dd c9 3b f9 f4 89 50
      Application[0] = 1.3.6.1.5.5.7.3.1 Serverauthentifizierung

    CertContext[0][1]: dwInfoStatus=10c dwErrorStatus=0
      Issuer: CN=XXXXXXXXX - interne Zertifizierungsstelle, DC=XXXXXXXXX, DC=local
      NotBefore: 09.01.2012 17:13
      NotAfter: 08.02.2023 13:08
      Subject: CN=XXXXXXXXX - interne Zertifizierungsstelle, DC=XXXXXXXXX, DC=local
      Serial: 3936312c7dd8d0914f8ced629492c59e
      b5 f4 2a 78 7b 27 b8 9f 22 ab db ef a3 64 37 bd 49 27 65 89
      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:
      4b 7b e4 9f 23 d7 41 cb f5 d2 e5 5d 7a 6e 03 81 5f 0e 93 91
    Full chain:
      0e b6 69 df 56 dd 35 e4 85 4b 55 a4 f7 6b 40 2c 3a 1d fa f4
    ------------------------------------
    Verfizierte Ausstellungsrichtlinien: Kein
    Verfizierte Anwendungsrichtlinien:
        1.3.6.1.5.5.7.3.1 Serverauthentifizierung
    Sperrstatussüberprüfung des untergeordneten Zertifikats erfolgreich abgeschlossen.
    CertUtil: -verify-Befehl wurde erfolgreich ausgeführt.

    Sieht glaub ich ok aus.

    Der RD Status ist bei allen vertrauenswürdig. 

    Den Thumbprint habe ich versäumt zu erwähnen. Auch er wird via GPO verteilt.

    Mittwoch, 28. Juni 2017 16:12
    |
  • Discussion
    Anmelden
    1
    Anmelden

    Ja, sieht erst mal gut aus. Die Deltas verteilst Du nur über LDAP, die Basis-CRLS über beide Kanäle - glaube zwar nicht, dass es daran liegt, aber einheitlich ist immer besser, gerade wenn Du eines Tages einen Client kriegst, der nicht in der Domäne ist.

    Ich würde mich als erstes vergewissern (hast Du bestimmt schon gemacht ;-) ), dass wenn ich beim Pop-Up auf "Zertifikat anzeigen" gehe, auch das richtige Zertifikat rauskommt und nicht eine seiner früheren Inkarnationen. Und dann eine Testmaschine, GPO-Vererbung abschneiden und nur die aktuelle PKI verteilen (auch den Thumbprint), ohne irgendwelche Spuren der alten. Vielleicht noch rein aus Jux die CRL neu generieren. Auch schauen, ob auf RDS-Servern noch alte Zertifikate schlummern, und gnadenlos wegputzen.

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> http://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    Mittwoch, 28. Juni 2017 20:04
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Ich habe auf jeden Fall Clients, welche aus einem separaten Schulungsnetz (andere Domäne) zugreifen bzw. zugreifen werden.

    Beim Login wird das richtige Zertifikat genommen.

    Die RDS Server haben nur noch das aktuelle Zertifikat, da ich die alten immer über das SnapIn wieder gelöscht habe.

    Jetzt bekomme ich heute die Rückmeldung, dass die 4 User, welche schon die neue RDS-Farm testweise nutzen, überhaupt keine Fehlermeldung beim connect (ebenso W7 Clients) erhalten, sondern nur ich in der Test VM?!

    Dort ist aber der Aussteller in den richtigen Zertifikatsspeichern (Stammzert./Herausgeber) enthalten.

    Die W7 VM aus der Domäne raus und wieder rein, anderen Testuser genommen und die Maschine bringt immer noch den Fehler.

    Eine neue Test VM aufgesetzt und da funktioniert der Login auch ohne Fehler! Also habe bis dato nur ich auf der Testmaschine das Problem. Wenn es so bleiben sollte, ist das natürlich schön. Wäre dumm, wir gehen mit der Farm nun produktiv und 20% der Mitarbeiter bekommen auch das Problem. Dann wüsste ich gerne, wonach ich auf den einzelnen Clients noch gucken soll.

    Hast Du noch eine Idee wo ich da ansetzen könnte, oder erfahrungsgemäß einfach "Deckel drauf" und die schlafenden Hunde schlafen lassen. :-)

    Gruß

    Dirk

    Donnerstag, 29. Juni 2017 12:48
    |