RemoteApps: Sperrlistenfehler unter Win7

[Unleashed]

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-fo...ng-157785.html (RDP auf Server 2008 mit Zertifikat - Sperrprüfung)

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

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

[brenni]

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]

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

blub

[olc]

...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]

@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/arch...-fallback.aspx

blub

[brenni]

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]

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]

Zitat von brenni 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]

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]

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%...7239247&sr=8-1

Viele Grüße
olc