RemoteApps: Sperrlistenfehler unter Win7

[Unleashed 10]

Hallo!

 

Hab' hier ein Problem an dem ich mir nun schon Stunden die Zähne ausbeiße -

vielleicht hat ja jemand Rat:

 

Im Prinzip hab ich die gleiche Konstellation wie in diesem alten Thread beschrieben: http://www.mcseboard.de/windows-7-forum-76/rdp-server-2008-zertifikat-sperrpruefung-157785.html

 

Also zusammengefasst:

ein Srv2008-R2 als DC

ein Srv2008-R2 als RemoteApp-Server

 

Clients mit Windows XP und Windows Vista können anstandslos auf

die RemoteApps zugreifen - keine Zertifikatswarnung oder ähnliches -

funktioniert einfach.

 

Clients mit Windows 7 jedoch können sich noch an der \RDWeb Seite anmelden (Zertifikat ok) - sobald jedoch auf das Icon der RemoteApp geklickt wird kommt dieser ominöse Sperrlistenfehler.

 

Unterschied zu obigem Thread ist jedoch:

Ich KANN die CRL von überall abfragen (Laptop mit mobilem Netz ohne Domainzugriff und von 3 verschieden Providern getestet).

 

Copy/Paste des Sperrlisteneintrages aus dem Zertifikat in den Browser öffnet die CRL problemlos - also auch kein Tippfehler.

 

Auch der in obigem Thread erwähnte CertUtil Test läuft ohne Fehler durch.

 

Ich kapier's einfach nicht mehr :confused:

 

Bin für jede Hilfe äußerst dankbar!

[brenni 10]

Hallo Unleashed,

 

hast du für dein Problem eigentlich ne Lösung gefunden? Stehe nämlich grad vor dem gleichen Problem.

 

UAWG. Danke Brenni

[blub 115]

vielleicht ein Rechteproblem.

Wenn ich's richtig verstehe, greift ihr auf die CRL zu, wenn noch kein Benutzer angemeldet ist, also unauthorized.

 

blub

[olc 18]

...oder genau anders herum: Anonym würde klappen, nur die Computeridentität nicht.

 

Ab Windows 7 verwendet ein SYSTEM Dienst bei NTLM Authentifizierung keine NULL Session mehr, sondern standardmäßig den Computer als Authenticator. Wenn dieser nicht berechtigt ist, auf die CRL zuzugreifen, dann kann es bei NTLM Zugriff zu Problemen kommen. Kerberos dagegen würde korrekt funktionieren.

 

Changes in NTLM Authentication

 

Also beides prüfen: blubs Idee mit der Berechtigung als auch die Frage, ob der Computer ggf. im Gegensatz zum anonymen Benutzer nicht authorisiert ist.

 

Viele Grüße

olc

[blub 115]

@brenni,

 

du kannst mal versuchen, ob du ein Userzertifikat im Systemkontext verifizieren kannst.

 

Besorg dir bei Sysinternals das Tool psexec und geh in die Commanline

 

psexec -sdi cmd.exe

 

dann gibst du in der System-cmd diesen Befehl ein

certutil -v -verify -urlfetch Zertifikat.cer 

 

Schau mal, ob da was kommt wie, "Sperrliste nicht erreichbar" oder ähnliches.

 

 

Sieh dir auch mal diesen sehr gut geschriebenen Artikel an. Vielleicht liegt hier auch die Ursache

http://blogs.technet.com/b/deds/archive/2010/04/12/kerberos-im-local-system-kontext-und-ntlm-fallback.aspx

 

blub

[brenni 10]

Vielen Dank Leute für die Antworten und eure Mühe,

 

folgende Lösung habe ich gefunden und auch erfolgreich getestet....

 

@olc ...dein Tip war der richtige

 

Das Symptom ist nur ab Window 7 vorhanden. Installiert man das Root-Zertifikat im Speicher des Computerkontos unter "Vertrauenswürdige stammzertifizierungsstellen" dann funktioniert es einwandfrei.

Die Überprüfung des Zertifikates scheint im Kontext des Computers zu erfolgen.

Wenn ich mal zeit habe, überprüfe ich mal, ob auch in dieser konstellation die Zertifikatssperrliste wirklich abgefragt wird, oder nur übergangen wird. Würde mich rein Sicherheitstechnisch schon interessieren.

 

Das werd ich dann wohl mit certutil testen wie von "blub" beschrieben. Muss mich da mal ein bissl mehr einarbeiten.

 

Grüße Brenni

[olc 18]

Hi Brenni,

 

das Installieren des Root-Zertifikats im Computerspeicher hat nichts mit dem von mir angesprochenen Lösungsansatz zu tun ;) - aber gut, daß es damit nun geklappt hat.

 

Wenn das Zertifikat nicht im Computerspeicher lag, sondern im Benutzerspeicher, ist das Problem auch nachvollziehbar. Der Computer vertraut schlichtweg der Root CA nicht, solange es nicht im eigenen Speicher liegt.

 

Du kannst das Root-Zertifikat innerhalb einer Domäne über GPOs verteilen oder aber über den Import in den "Public Key Services" Container im Configuration NC der AD (Stichwort "certutil.exe -dsPublish"). Das macht es in Zukunft vielleicht einfacher.

 

Viele Grüße

olc

[blub 115]

Das Symptom ist nur ab Window 7 vorhanden. Installiert man das Root-Zertifikat im Speicher des Computerkontos unter "Vertrauenswürdige stammzertifizierungsstellen" dann funktioniert es einwandfrei.

Die Überprüfung des Zertifikates scheint im Kontext des Computers zu erfolgen.

 

Ähmm, der Speicher "Vertrauenswürdige Stammzertifizierungsstellen" ist ein Highlander.

Da gibts keinen Benutzerspeicher oder Computercontext

 

Nutzt du eine AD integrierte CA oder was Selbstständiges?

 

blub

[brenni 10]

Kurz zur Erläuterung,

wir nutzen eine interne CA. Innerhalb der Domäne ist auch der ganze Rollout der Zertifikate automatisiert. Da besteht auch das Problem nicht.

Wir haben bei uns einen Kundenzugang per Remotedesktopdienste eingerichtet (TS-Gateway...). Unsere Kunden gehören natürlich nicht zur Domäne. Daher die Zertifikatprobleme die jetzt mit Win 7 aufgetaucht sind.

 

Ich dachte bisher, dass ich das Problem über die Veröffentlichung der Zertifikatsperrliste per http lösen könnte, jedoch scheint die Überprüfung über ldap zu laufen (zumindest klingt das so in den Zahlreichen berichten)... und das funktionert natürlich nicht.

Zertifikatdienste sind schon recht umfangreich...leider fehlt mir die Zeit um diese mal korrekt zu studieren... kann jemand ein gutes Buch empfehlen?

Grüße Brenni

[olc 18]

Hi blub,

 

doch, es gibt zwei Speicher, auch für die vertrauenswürdigen Stammzertifizierungsstellen. :)

Ein dort importiertes Zertifikat gilt dann nur für den aktuellen Benutzer, nicht für die Maschine.

 

@Brenni: Schau in das Zertifikat hinein der Remote Apps und der Root (bzw. Zertifikatkette dahin) hinein - dort siehst Du, welche CRL URLs verwendet werden.

 

Als Buchempfehlung wie immer: http://www.amazon.de/Windows-Server%C2%AE-Certificate-Security-PRO-Other/dp/0735625166/ref=sr_1_1?ie=UTF8&qid=1297239247&sr=8-1

 

Viele Grüße

olc

[blub 115]

was ist das denn für ein Mechanismus?

 

a) Wenn ich unter "lokaler Computer" Zertifikate in die Stammzertifikate importiere, dann erscheinen sie auch unter "aktueller Benutzer".

b) Importier ich Zertifikate unter "aktueller Benutzer", erscheinen sie aber nicht unter "lokaler Computer".

 

sorry, für meine Falschaussage: Ich hab bisher immer die Zertifikate nach b) oder mit GPOs importiert und bin daher davon ausgegangen, dass es ein einziger Store ist.

 

Danke

blub

[brenni 10]

Danke olc

 

hab grad mal ins Zertifikat am Gateway geguggt...ich bin ja so ein schussel...

hier steht wirklich nur der LDAP-Pfad drin. Das ist natürlich ein Webserver-Zertifikat und ich hab das Computerzertifikat unseres TS-Servers angepasst.

 

Die Fehlermeldung ist aber auch verwirrend....im Remotedesktopclient steht ja auch "verbinden mit "INTERNER-SERVERNAME" und dann die Fehlermeldung, dass die Zertifikatssperrliste nicht geprüft werden kann...daher hab ich mich um das Computerzertifikat des Terminalservers gekümmert....dass das Zertifikat des Gateways angemeckert wird war mir nicht klar.

 

Werd mich gleich mal drum kümmern...dank euch für eure Hilfe...werde weiter berichten...die Frage, die sich mir jetzt schon im vorhinein stellt (da ich ja gefährliches Halbwissen hab) ist....wenn ich das Root-Zertifikat nun in den Benutzerspeicher importiere ist nach anpassen des Webserverzertifikats dann die Fehlermeldung weg? Also wenn er dann alle Sperrlisten, die ich jetzt im Zertifikat hinterlege abfragt...dann sollte es ja klappen *gespanntbin*

[olc 18]

Hi blub,

 

der Mechanismus dahinter geht (neben anderen Punkten) davon aus, daß nur ein Administrator Zugang zum Computerspeicher hat. Ein dort importiertes Zertifikat hat dann "computerweite" Gültigkeit, also für alle Benutzer, Dienste und SYSTEM.

 

Wenn jedoch ein Benutzer ein Zertifikat importiert (etwa nach dem im Internet Explorer eine entsprechende Fehlermeldung wegen einer fehlenden vertrauenswürdigen Zertifikatkette gemeldet wurde), dann kann der Benutzer das Zertifikat in den eigenen Speicher für vertrauenswürdige Zertifizierungsstellen importieren (nicht wirklich empfehleswert). Dieser gilt dann nur für ihn.

 

Bevorzugt werden sollte meiner Meinung nach die GPO Variante für Domänen oder die AD Configuration NC Variante für den Forest. In beiden Fällen landen die Zertifikate dann im Computerspeicher.

 

@Brenni: Ja, prüf einmal, ob es nun klappt. :)

 

Viele Grüße

olc