15
2008 R2 Remotedesktopdienste - XP SingleSignOn - 2 Domänen mit Vertrauensstellung
Hallo Leute,
hätte da mal eine Frage ob SingleSignOn in der folgenden Konstellation funktioniert.
2 Domänen mit Vertrauensstellung
2008R2 Server mit Remoteapps in Domäne A
XP Clients in Domäne B
An den XP Clients habe ich die nötigen REG Einstellungen vorgenommen (SingleSignOn innerhalb Domäne A funktioniert).
Nun wäre es ideal, wenn man SSO auch aus Domäne B funktionieren würde.
Aber an den Clients aus Domäne B startet man die RemoteApp und dann wird einem der Desktop des Servers angezeigt an dem man sich anmelden muss. Gibt man seine Daten aus Domäne B ein, startet die Anwendung dann auch.
Kann mir jemand sagen an welcher Schraube ich hier noch drehen kann/muss damit das funktioniert. Oder ist SSO Domänenübergreifend nicht möglich?
Gruß
KangarooJack
hätte da mal eine Frage ob SingleSignOn in der folgenden Konstellation funktioniert.
2 Domänen mit Vertrauensstellung
2008R2 Server mit Remoteapps in Domäne A
XP Clients in Domäne B
An den XP Clients habe ich die nötigen REG Einstellungen vorgenommen (SingleSignOn innerhalb Domäne A funktioniert).
Nun wäre es ideal, wenn man SSO auch aus Domäne B funktionieren würde.
Aber an den Clients aus Domäne B startet man die RemoteApp und dann wird einem der Desktop des Servers angezeigt an dem man sich anmelden muss. Gibt man seine Daten aus Domäne B ein, startet die Anwendung dann auch.
Kann mir jemand sagen an welcher Schraube ich hier noch drehen kann/muss damit das funktioniert. Oder ist SSO Domänenübergreifend nicht möglich?
Gruß
KangarooJack
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 189319
Url: https://administrator.de/contentid/189319
Printed on: April 19, 2024 at 05:04 o'clock
15 Comments
Latest comment
Moin.
Ich weiß es nicht, aber Folgendes sollte weiter führen:
Google zunächst nach, ob Deine Vermutung "ist SSO Domänenübergreifend nicht möglich" zutrifft: Stichworte: sso + "trusted domain"
Wenn das nicht zutrifft, nimm Dir einen Win7 oder Vista-Client und richte dort das sso ein (nicht über regedit, wie bei xp, sondern über lokale Policies) und setzte als vertraute Terminalserver mal TERMSRV/* ein.
Anleitung siehe http://blogs.msdn.com/b/rds/archive/2007/04/19/how-to-enable-single-sig ...
Geht es von dort aus?
Ich weiß es nicht, aber Folgendes sollte weiter führen:
Google zunächst nach, ob Deine Vermutung "ist SSO Domänenübergreifend nicht möglich" zutrifft: Stichworte: sso + "trusted domain"
Wenn das nicht zutrifft, nimm Dir einen Win7 oder Vista-Client und richte dort das sso ein (nicht über regedit, wie bei xp, sondern über lokale Policies) und setzte als vertraute Terminalserver mal TERMSRV/* ein.
Anleitung siehe http://blogs.msdn.com/b/rds/archive/2007/04/19/how-to-enable-single-sig ...
Geht es von dort aus?
Moin.
Ich habe lediglich 2 oder 3 Hinweise gefunden,dass SSO Domänenübergreifend funktionieren soll, aber keine konkrete Umsetzung.
Deinen Vorschlag mit dem Windows 7 Client habe ich eben ausprobiert. Nachdem ich SSO in der lokalen Policy aktiviert habe funktioniert Domänenübergreifendes SSO! Jetzt müsst ich nur noch wissen wie man das für XP konfiguriert!?
Ich habe lediglich 2 oder 3 Hinweise gefunden,dass SSO Domänenübergreifend funktionieren soll, aber keine konkrete Umsetzung.
Deinen Vorschlag mit dem Windows 7 Client habe ich eben ausprobiert. Nachdem ich SSO in der lokalen Policy aktiviert habe funktioniert Domänenübergreifendes SSO! Jetzt müsst ich nur noch wissen wie man das für XP konfiguriert!?
Du solltest analysieren, wo Win7 TERMSRV/* in der Registry einträgt und das einfach bei xp setzen - ich denke, das wird schon reichen.
Also, ich habe nun einfach mal die Einstellungen in der GPO so gesetzt wie für die Windows 7 Maschine - XP SP3 übernimmt diese Einstellungen auch obwohl bei der GPO mindestens Vista steht.
SSO funktioniert nun auch Domänenübergreifend! ABER nur einmal. d.h. ich starte die RemoteApp, beende diese wieder. Nun starte ich erneut und dann wird nach dem Login gefragt- seeeeehr seltsame Sache!
Starte ich den Client neu, kann ich die Anwendung wieder einmal starten inkl. SSO - beim zweiten Start fragt er dann wieder nach den Daten
. Nur abmelden reicht nicht, der PC muss neu gestartet werden damit ich die RemoteApp einmalig ohne Anmeldedaten starten kann.
Ne Idee?
SSO funktioniert nun auch Domänenübergreifend! ABER nur einmal. d.h. ich starte die RemoteApp, beende diese wieder. Nun starte ich erneut und dann wird nach dem Login gefragt- seeeeehr seltsame Sache!
Starte ich den Client neu, kann ich die Anwendung wieder einmal starten inkl. SSO - beim zweiten Start fragt er dann wieder nach den Daten
. Nur abmelden reicht nicht, der PC muss neu gestartet werden damit ich die RemoteApp einmalig ohne Anmeldedaten starten kann.Ne Idee?
Erstmal keine Idee. Bei Win7 geht es mehrfach?
Ja, unter 7 kann man die Anwendung X-Fach nacheinander mit SSO starten. Bei XP nur einmal dann wird nach den Daten gefragt. Sieht so aus für mich, als würde der XP Client die Daten nicht nochmal übermitteln.
Vermutlich ein Bug. Melde das doch mal in einem speziellen Forum, z.B. der Newsgroup für Remote Desktop Dienste von MS.
Ok, dann werd ih mein Glück mal dort probieren.
Danke für Deine Unterstützung.
Danke für Deine Unterstützung.
So, das SSO habe ich nun hinbekommen.
Es gibt allerdings noch ein Problem.
Starte ich ne RDP Sitzung auf den Server ist die in ca 3 Sekunden da.
Starte ich ne RDP Sitzung in der ich automatisch das Programm starte - legt der Loginvorgang ca 20 Gedenksekunden ein, bevor die Anwendung startet
Probiere ich das mit dem Windows Rechner, oder Wordpad - geht das beides unter 5 Sekunden auf.
Hab schon wieder 3 Tage daran rumprobiert, ich raffe es nicht, warum das so ist.
Jemand eine Idee?
Es gibt allerdings noch ein Problem.
Starte ich ne RDP Sitzung auf den Server ist die in ca 3 Sekunden da.
Starte ich ne RDP Sitzung in der ich automatisch das Programm starte - legt der Loginvorgang ca 20 Gedenksekunden ein, bevor die Anwendung startet
Probiere ich das mit dem Windows Rechner, oder Wordpad - geht das beides unter 5 Sekunden auf.
Hab schon wieder 3 Tage daran rumprobiert, ich raffe es nicht, warum das so ist.
Jemand eine Idee?
Das Warten hatten wir auch und es trat genau dann auf, wenn mehr als nur ein paar User angemeldet waren. Ich sage bewusst "trat" - mittlerweile geht es nämlich, ohne dass wir irgendwo irgendetwas verändert hätten.
Mir schien es damals so, als würde es ein Problem des Lizenzservers sein - als ob der sich ein paar Sekunden sortieren müsste. Warum dies jedoch nur bei RemoteApps auftrat? Keine Ahnung. Warum es sich plötzlich (nach Wochen!) von alleine löste? Noch weniger Ahnung.
Du kannst mal einen Test machen indem Du einen anderen Lizenzierungsserver einrichtest und angibst.
Mir schien es damals so, als würde es ein Problem des Lizenzservers sein - als ob der sich ein paar Sekunden sortieren müsste. Warum dies jedoch nur bei RemoteApps auftrat? Keine Ahnung. Warum es sich plötzlich (nach Wochen!) von alleine löste? Noch weniger Ahnung.
Du kannst mal einen Test machen indem Du einen anderen Lizenzierungsserver einrichtest und angibst.
Der Lizensserver ist lokal auf diesem Server installiert.
Aber meines Erachtens kann es doch nicht daran liegen, denn wenn ich eine normale RDP Sitzung mit Desktop öffne wird der Lizenzserver doch genau so angefragt. Und das starten von z.b. calc.exe oder notepad.exe geht unter 5 Sekunden. Ich brings echt nicht zusammen an was das noch liegen könnte.
Aber meines Erachtens kann es doch nicht daran liegen, denn wenn ich eine normale RDP Sitzung mit Desktop öffne wird der Lizenzserver doch genau so angefragt. Und das starten von z.b. calc.exe oder notepad.exe geht unter 5 Sekunden. Ich brings echt nicht zusammen an was das noch liegen könnte.
Bei uns war es genau so. Normale Sitzung schnell, remoteApp langsam, es sei denn, man ist der einzige Nutzer 8oder nur sehr wenige sind drauf).
Es kann sein, dass es sogar nach der Umstellung des Lizenzservers verschwunden ist, wenn ich es mir recht überlege. Dieser war bei uns zuerst auch auf dem TS selbst.
Es kann sein, dass es sogar nach der Umstellung des Lizenzservers verschwunden ist, wenn ich es mir recht überlege. Dieser war bei uns zuerst auch auf dem TS selbst.
Also an der Useranzahl kann es nicht liegen - da nur ein einziger, der Testbenutzer - verbunden war. Das System ist noch nicht produktiv. Ok, danke für den Tipp. Werde den Lizenzserver morgen woanders installieren, mal schauen ob das was bringt.
Was seltsam ist: einer von 30 Versuchen und die Anwendung startet direkt.
Das einzig auffällige im AnwendungsLog ist der Eintrag:
Quelle: CertificateServicesClient-AutoEnrollment
Ereignis-ID: 6
Bei der automatischen Zertifikatregistrierung für Domäne\Username ist ein Fehler aufgetreten (0x8007000d) Die Daten sind unzulässig.
Was seltsam ist: einer von 30 Versuchen und die Anwendung startet direkt.
Das einzig auffällige im AnwendungsLog ist der Eintrag:
Quelle: CertificateServicesClient-AutoEnrollment
Ereignis-ID: 6
Bei der automatischen Zertifikatregistrierung für Domäne\Username ist ein Fehler aufgetreten (0x8007000d) Die Daten sind unzulässig.
Ich fasse es nicht, ich habs endlich hinbekommen. An dieser Stelle hätte ich nie gesucht:
In den Einstellungen des INTERNET EXPLORERS !!!
Folgedes auf dem TS für jeden User deaktivieren:
IE => Internetoptionen => Ereitert => Auf gesperrte Serverzertifikate überprüfen
kann man per GPO machen unter Benutzer, Richtlinien, Administrative Vorlagen, Windows Komponenten,Internet Explorer, Internetsystemsteuerung, Seite "Erweitert"
dann noch
IE => Internetoptionen => Ereitert => auf gesperrte zertifikate von herausgebern überprüfen
Hierzu gibt es keine GPO! Ich habe es über GPP gelöst, indem ich
HKCU\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing
State, Typ REG_DWORD mit dem HEX Wert 0x23E00 setze..
gpupdate /force auf dem Server, anschließend neugestartet.
Die Anwendung startet jetzt in ca 4-7 Sekunden!!!
Man soll dieses Problem mit dem langsamen Anwendungsstart nicht haben, wenn der User auf dem TS in Internet kann, dann kann nämlich das Zertifikat abgefragt werden und man läuft nicht in den Timeout - somit auch keine Wartezeit von ca 20-30 Sekunden!
Ich hoffe das hilft einigen weiter.
Gruß
KangarooJack
In den Einstellungen des INTERNET EXPLORERS !!!
Folgedes auf dem TS für jeden User deaktivieren:
IE => Internetoptionen => Ereitert => Auf gesperrte Serverzertifikate überprüfen
kann man per GPO machen unter Benutzer, Richtlinien, Administrative Vorlagen, Windows Komponenten,Internet Explorer, Internetsystemsteuerung, Seite "Erweitert"
dann noch
IE => Internetoptionen => Ereitert => auf gesperrte zertifikate von herausgebern überprüfen
Hierzu gibt es keine GPO! Ich habe es über GPP gelöst, indem ich
HKCU\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing
State, Typ REG_DWORD mit dem HEX Wert 0x23E00 setze..
gpupdate /force auf dem Server, anschließend neugestartet.
Die Anwendung startet jetzt in ca 4-7 Sekunden!!!
Man soll dieses Problem mit dem langsamen Anwendungsstart nicht haben, wenn der User auf dem TS in Internet kann, dann kann nämlich das Zertifikat abgefragt werden und man läuft nicht in den Timeout - somit auch keine Wartezeit von ca 20-30 Sekunden!
Ich hoffe das hilft einigen weiter.
Gruß
KangarooJack
Sehr cool.
Bei uns können die Anwender zwar vom TS aus ins Internet, aber ich hatte etwa zu der Zeit von der an es schnell ging doch etwas geändert, was die Verbindung ins Netz beeinflusst: die Proxysettings wurden auf wpad umgestellt. Nicht auszuschließen, dass damit der Zugriff auf Sperrzertifikate o.Ä. wesentlich längert dauert - wir hatten ohne wpad auch mit https-Seiten lange Verzögerungen.
Bei uns können die Anwender zwar vom TS aus ins Internet, aber ich hatte etwa zu der Zeit von der an es schnell ging doch etwas geändert, was die Verbindung ins Netz beeinflusst: die Proxysettings wurden auf wpad umgestellt. Nicht auszuschließen, dass damit der Zugriff auf Sperrzertifikate o.Ä. wesentlich längert dauert - wir hatten ohne wpad auch mit https-Seiten lange Verzögerungen.
