7
Passwort Abfrage bei work resources remoteapp
Hallo Miteinander,
Kurz:
seit kurzem habe ich das Problem, dass bei immer mehr Rechner das Passwort beim Aufruf über RemoteApps (wieder)fordern.
Aufbau:
Wir sind IT-Dienstleister und bieten unsere Eigene Software über die "Cloud" an. Früher noch über Citrix aber wir sind jetzt auf die Windows Remote Apps umgestiegenen. (Erst ein Kunde)
In unserer Firma läuft ein Windows 2012r2 Standard Domänencontroller(mit ADDS,DNS, Dateiserver), ein Windows 2012r2 Standard Gatewayserver (RDWeb), zwei Windows 2012r2 Standard Terminalserver.
Die Kunden PCs(alle Windows 10) werden über VPN(Router mit IPSec Netz zu Netz) in unser Netz angebunden.
Die PCs sind in unserer Domäne und arbeiten mit unprivilegierten DomainUsern.
Sämtliche Einstellungen werden über GPO verteilt.
(Meiner Meinung nach wichtigen
-Computerkonfiguration --> System/Delegierung von AnmeldeinformationenEinblenden
Soll Zustand (hat etwa ein Jahr genau so funktioniert)
Der Kunde startet seinen PC, meldet sich an der Domäne an, Bekommt per GPO einen Ordner "Work Resources" auf den Desktop mit allen Anwendungen, klickt auf das Icon, die Anwendung startet, fertig.
Problem:
Bei inzwischen 3 von 20 PCs dauert es nach dem anklicken des Icons etwas (Timeout?) und dann wird der User nach dem Passwort gefragt.
Sobald er es eingegeben hat(dauert es wieder ziemlich lange), kann er problemlos arbeiten (bis die Sitzung getrennt wird)
Ich hoffe jemand kann mir bei dem Problem helfen oder Hinweise geben wonach ich suchen soll.
Vielen Dank
MfG Thekivi
Kurz:
seit kurzem habe ich das Problem, dass bei immer mehr Rechner das Passwort beim Aufruf über RemoteApps (wieder)fordern.
Aufbau:
Wir sind IT-Dienstleister und bieten unsere Eigene Software über die "Cloud" an. Früher noch über Citrix aber wir sind jetzt auf die Windows Remote Apps umgestiegenen. (Erst ein Kunde)
In unserer Firma läuft ein Windows 2012r2 Standard Domänencontroller(mit ADDS,DNS, Dateiserver), ein Windows 2012r2 Standard Gatewayserver (RDWeb), zwei Windows 2012r2 Standard Terminalserver.
Die Kunden PCs(alle Windows 10) werden über VPN(Router mit IPSec Netz zu Netz) in unser Netz angebunden.
Die PCs sind in unserer Domäne und arbeiten mit unprivilegierten DomainUsern.
Sämtliche Einstellungen werden über GPO verteilt.
(Meiner Meinung nach wichtigen
-Computerkonfiguration --> System/Delegierung von AnmeldeinformationenEinblenden
- Delegierung von gespeicherten Anmeldeinformationen mit reiner NTLM-Serverauthentifizierung zulassen (TERMSRV/rdweb.domain.de)
- Delegierung von gespeicherten Anmeldeinformationen zulassen(TERMSRV/rdweb.domain.de)
- Delegierung von Standardanmeldeinformationen mit reiner NTLM-Serverauthentifizierung zulassen. (TERMSRV/rdweb.domain.de)
- Delegierung von Standardanmeldeinformationen zulassen (TERMSRV/rdweb.domain.de)
- Speichern von Kennwörtern nicht zulassen --> deaktiviert
- Standardverbindungs-URL: https://RDWeb.domain.de/RDWeb/Feed/
- Authentifizierungsmethode für Remotedesktopgateway festlegen (Lokale Anmeldeinformationen verwenden) *Diese Einstellung hat am Anfang geholfen*
- Speichern von Kennwörtern nicht zulassen --> deaktiviert
Soll Zustand (hat etwa ein Jahr genau so funktioniert)
Der Kunde startet seinen PC, meldet sich an der Domäne an, Bekommt per GPO einen Ordner "Work Resources" auf den Desktop mit allen Anwendungen, klickt auf das Icon, die Anwendung startet, fertig.
Problem:
Bei inzwischen 3 von 20 PCs dauert es nach dem anklicken des Icons etwas (Timeout?) und dann wird der User nach dem Passwort gefragt.
Sobald er es eingegeben hat(dauert es wieder ziemlich lange), kann er problemlos arbeiten (bis die Sitzung getrennt wird)
Ich hoffe jemand kann mir bei dem Problem helfen oder Hinweise geben wonach ich suchen soll.
Vielen Dank
MfG Thekivi
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 363359
Url: https://administrator.de/forum/passwort-abfrage-bei-work-resources-remoteapp-363359.html
Ausgedruckt am: 22.12.2024 um 21:12 Uhr
7 Kommentare
Neuester Kommentar
Hi.
Hatten wir auch. Meistens hilft hierbei schlicht Folgendes als Problemuser: öffne mstsc, gib den Namen des RemoteApp-Servers als Ziel ein (sowohl den FQDN als auch den kurzen Netbiosnamen), klicke auf "Optionen" und entferne den Haken bei "immer nach Anmeldeinfos fragen" und klicke auf speichern - danach sollten auch bei den remoteApps wieder die eigenen Anmeldeinfos automatisch genommen werden.
Hatten wir auch. Meistens hilft hierbei schlicht Folgendes als Problemuser: öffne mstsc, gib den Namen des RemoteApp-Servers als Ziel ein (sowohl den FQDN als auch den kurzen Netbiosnamen), klicke auf "Optionen" und entferne den Haken bei "immer nach Anmeldeinfos fragen" und klicke auf speichern - danach sollten auch bei den remoteApps wieder die eigenen Anmeldeinfos automatisch genommen werden.
1
Hi,
danke für den Tipp, hat aber leider überhaupt nichts gebracht.
Bei den Servernamen waren keine Anmeldedaten hinterlegt und der Punkt war nicht angehackt.
Bei dem rdweb Server FQDN stand als info: "zum herstellen der Verbindungen werden Ihre Windows-AnmeldeInformationen verwendet", der Hacken war auch hier nicht gesetzt.
hinzufügen, speichern und dann wieder entfernen, speichern hat leider nichts gebracht.
Die User können sich auch nicht am Remotedesktop selber anmelden, sondern nur die freigegebenen Apps nutzen.
Noch eine Andere Idee?
MfG
Thekivi
danke für den Tipp, hat aber leider überhaupt nichts gebracht.
Bei den Servernamen waren keine Anmeldedaten hinterlegt und der Punkt war nicht angehackt.
Bei dem rdweb Server FQDN stand als info: "zum herstellen der Verbindungen werden Ihre Windows-AnmeldeInformationen verwendet", der Hacken war auch hier nicht gesetzt.
hinzufügen, speichern und dann wieder entfernen, speichern hat leider nichts gebracht.
Die User können sich auch nicht am Remotedesktop selber anmelden, sondern nur die freigegebenen Apps nutzen.
Noch eine Andere Idee?
MfG
Thekivi
Könnte es wohl sein, dass das Zertifikat abgelaufen ist, welches der Server verwendet?
1
Das Zertifikat ist noch bis Mitte 2018 Gültig und wird per GPO als Vertrauenswürdige Stammzertifikatsstelle verteilt.
Nach erneuter Eingabe des Passwortes kann er sich anmelden.
Nach erneuter Eingabe des Passwortes kann er sich anmelden.
Beschränkt sich das Problem auf einen Zielserver oder mehrere? Teste mit anderen PCs (dafür müssen das keine Server sein).
1
Nachdem ich in den GPO etwas umgespielt habe, und bei "Benutzerkonfiguration/Administrative Vorlagen/Windows-Komponenten/Remotedesktopdienste/Remotedesktopgateway/Authentifizierungsmethode für Remotedesktopgateway festlegen/Benutzer können diese Einstellung ändern" auf erlauben/Aktiviert gestellt hatte, konnte niemand mehr ohne Passwort rein.
Panisch habe ich den Hacken wieder weggenommen und plötzlich funktionierte es wieder bei allen auch die die vorher gesponnen haben.
(Ein Rechner fehlt noch zum überprüfen an den ich gerade nicht rankomme.)
Also keine Ahnung was es war aber es scheint wieder wie gewünscht zu gehen o.O
Herzlichen Dank an "DerWoWusste" der versucht hat mir zu helfen.
Panisch habe ich den Hacken wieder weggenommen und plötzlich funktionierte es wieder bei allen auch die die vorher gesponnen haben.
(Ein Rechner fehlt noch zum überprüfen an den ich gerade nicht rankomme.)
Also keine Ahnung was es war aber es scheint wieder wie gewünscht zu gehen o.O
Herzlichen Dank an "DerWoWusste" der versucht hat mir zu helfen.
Vielen, vielen, vielen, vielen Dank!
Ich habe selbst das Probleme gehabt, dass die Workstations bei einem Kunden nach und nach das Passwort verlangt haben.
Zuerst hatte ich die neu installierte CA im Verdacht.
Zwar hat das Problem sich nicht durch deine Lösung lösen lassen; doch das Anwenden deiner geposteten GPO-Settings brachte den gewünschten Erfolg. Offensichtlich greift hier eine der Richtlinien...
Super!
Ich habe selbst das Probleme gehabt, dass die Workstations bei einem Kunden nach und nach das Passwort verlangt haben.
Zuerst hatte ich die neu installierte CA im Verdacht.
Zwar hat das Problem sich nicht durch deine Lösung lösen lassen; doch das Anwenden deiner geposteten GPO-Settings brachte den gewünschten Erfolg. Offensichtlich greift hier eine der Richtlinien...
Super!
