17
User sollen abgelaufene Kennwörter via RDP ändern können ( TS-Farm mit RDP via MS RDS Session Broker)
Hallo Admins,
ich stehe derzeit vor folgendem Problem und komme nicht ganz weiter.
Kunde hat eine TS-Farm aus 2 WTS und einem Session Broker (alle Windows Server 2019).
Alle Domuser müssen nach einer gewissen Zeit Ihr Kennwort ändern. Zusätzlich arbeiten alle User mit Linux Thinclients von Igel (keine Windows Fatclients)
Wenn nun das Kennwort ausläuft, weil der User vergessen hat dies vorzeitig zu ändern, hat dieser derzeit keine Chance mehr dies nachträglich zu tun.
Die Anmeldung wird verweigert.
Bei Umgebungen ohne Session Broker nutze ich folgenden "Trick" um das startverhalten der RDP anzupassen ( Kennwortabfrage erst nach Verbindung der RDP).
Wenn nun das Kennwort ausläuft kann der User dies Problemlos ändern.
Leider funktioniert dies in einer Umgebung mit einem Broker leider nicht, oder ich habe es noch nicht hinbekommen.
Gibt es noch andere Lösungen die mich hier weiter bringen könnten ? Könnt ihr das Problem nachvollziehen ?
danke für eure Hilfe
ich stehe derzeit vor folgendem Problem und komme nicht ganz weiter.
Kunde hat eine TS-Farm aus 2 WTS und einem Session Broker (alle Windows Server 2019).
Alle Domuser müssen nach einer gewissen Zeit Ihr Kennwort ändern. Zusätzlich arbeiten alle User mit Linux Thinclients von Igel (keine Windows Fatclients)
Wenn nun das Kennwort ausläuft, weil der User vergessen hat dies vorzeitig zu ändern, hat dieser derzeit keine Chance mehr dies nachträglich zu tun.
Die Anmeldung wird verweigert.
Bei Umgebungen ohne Session Broker nutze ich folgenden "Trick" um das startverhalten der RDP anzupassen ( Kennwortabfrage erst nach Verbindung der RDP).
Wenn nun das Kennwort ausläuft kann der User dies Problemlos ändern.
Leider funktioniert dies in einer Umgebung mit einem Broker leider nicht, oder ich habe es noch nicht hinbekommen.
Gibt es noch andere Lösungen die mich hier weiter bringen könnten ? Könnt ihr das Problem nachvollziehen ?
danke für eure Hilfe
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: 1918933701
Url: https://administrator.de/forum/user-sollen-abgelaufene-kennwoerter-via-rdp-aendern-koennen-ts-farm-mit-rdp-via-ms-rds-session-broker-1918933701.html
Ausgedruckt am: 23.12.2024 um 03:12 Uhr
17 Kommentare
Neuester Kommentar
Hi,
wir hatten bei uns das selbe Problem.
Die Lösung :
Im RDWEB die Seite RDWeb/Pages/de-DE/password.aspx freischalten und via IGEL Profil (FF oder Chrome) auf die Clients verteilen.
Dort können die Benutzer die PW ändern uns sich wieder normal anmelden.
Dann brauchst du auch nicht die Authentifizierung auf Netzwerkebene abschalten.
Gruß
Delta
wir hatten bei uns das selbe Problem.
Die Lösung :
Im RDWEB die Seite RDWeb/Pages/de-DE/password.aspx freischalten und via IGEL Profil (FF oder Chrome) auf die Clients verteilen.
Dort können die Benutzer die PW ändern uns sich wieder normal anmelden.
Dann brauchst du auch nicht die Authentifizierung auf Netzwerkebene abschalten.
Gruß
Delta
1
DAnke für die schnelle Antwort.
An das hatte ich auch schon gedacht. Fande es aber bisher nicht wirklich eine schicke Lösung.
Gibt es denn wirklich nichts anderes ?
An das hatte ich auch schon gedacht. Fande es aber bisher nicht wirklich eine schicke Lösung.
Gibt es denn wirklich nichts anderes ?
mMn. ohne die Authentifizierung auf Netzwerkebene abzuschalten nicht.
Dann schließen wir das Ganze hier mal.
Lösung ist nun wie von Delta9 beschrieben eine Webseite die via IGEL-Profil verteilt wird.
Webseite = https://SERVERNAME.local/RDWeb/Pages/de-DE/password.aspx
Wichtig: RDPWeb Access muss installiert sein
Hier noch eine Hilfestellung um die "password.aspx" zu aktivieren.
https://www.windowspro.de/wolfgang-sommergut/passwort-aendern-ueber-remo ...
Danke nochmal für die Hilfe
Wem noch was anderes einfällt kann gerne schreiben.
Lösung ist nun wie von Delta9 beschrieben eine Webseite die via IGEL-Profil verteilt wird.
Wichtig: RDPWeb Access muss installiert sein
Hier noch eine Hilfestellung um die "password.aspx" zu aktivieren.
https://www.windowspro.de/wolfgang-sommergut/passwort-aendern-ueber-remo ...
Danke nochmal für die Hilfe
Wem noch was anderes einfällt kann gerne schreiben.
1
Warum markierst du deine Beiträge als Lösung und nicht den von @Delta9?
Zitat von @Scrises:
DAnke für die schnelle Antwort.
An das hatte ich auch schon gedacht. Fande es aber bisher nicht wirklich eine schicke Lösung.
Gibt es denn wirklich nichts anderes ?
DAnke für die schnelle Antwort.
An das hatte ich auch schon gedacht. Fande es aber bisher nicht wirklich eine schicke Lösung.
Gibt es denn wirklich nichts anderes ?
es gibt eine bessere Lösung...
IGEL ans AD anbinden, die User darüber anmelden lassen bzw Kennwort bei abgelaufenen Kennwort ändern lassen, danach erfolgt der Login und die Credentials werden per Passtrough an RDP weitergegeben.
Nutzen wir hier bei über 250 Clients so
1
Da beißt die Maus keinen Faden ab. Pfusch bleibt Pfusch.
Guten Abend 
Es geht auch anders...
IGEL unterstützt grundsätzlich auch die Anmeldung am Active Directory.
Bevor ich hier einen langen Roman schreibe - Hier gibt es ein Video, wie das konfiguriert werden muss: https://www.youtube-nocookie.com/embed/JxGOEGAb3LI
Wenn es konfiguriert ist, werden die Benutzer bei abgelaufenem Kennwort ganz normal bei der Anmeldung dazu aufgefordert das Kennwort zu ändern und können das dann natürlich auch durchführen.
Überfordert eure Benutzer nicht damit, dass ihr von ihnen erwartet, dass sie selbstständig bei Login-Problemen auf die Idee kommen, dass das Kennwort abgelaufen sein könnte... (Aber man darf ja auch mal träumen...)
Gruß
@techflare: Ja.. habe ich erst nach meinem Post gesehen, dass Du das auch vorgeschlagen hattest
. Nutzen wir halt auch immer so bei unseren Kunden...
Es geht auch anders...
IGEL unterstützt grundsätzlich auch die Anmeldung am Active Directory.
Bevor ich hier einen langen Roman schreibe - Hier gibt es ein Video, wie das konfiguriert werden muss: https://www.youtube-nocookie.com/embed/JxGOEGAb3LI
Wenn es konfiguriert ist, werden die Benutzer bei abgelaufenem Kennwort ganz normal bei der Anmeldung dazu aufgefordert das Kennwort zu ändern und können das dann natürlich auch durchführen.
Überfordert eure Benutzer nicht damit, dass ihr von ihnen erwartet, dass sie selbstständig bei Login-Problemen auf die Idee kommen, dass das Kennwort abgelaufen sein könnte... (Aber man darf ja auch mal träumen...)
Gruß
@techflare: Ja.. habe ich erst nach meinem Post gesehen, dass Du das auch vorgeschlagen hattest
. Nutzen wir halt auch immer so bei unseren Kunden...1Zitat von @148656:
Da beißt die Maus keinen Faden ab. Pfusch bleibt Pfusch.
Da beißt die Maus keinen Faden ab. Pfusch bleibt Pfusch.
Pfusch?? Ich nehme an, Du bist "Generation Z"... Früher war es einmal Best Practice von Microsoft AD-Domänen so zu benennen. Und auch wir haben noch viele Kunden, wo die Domain auf .local endet. Die Frage ist ja, ob es sinnvoll ist, so tief in eine funktionierendes System einzugreifen und eine Umbenennung durchzuführen. Mit ggf. ungeahnten Problemen, die die Systemstabilität nachhaltig negativ beeinflussen. Und was in manchen Fällen ja nicht einmal möglich ist. Z.B. wenn Exchange im Einsatz ist..
Also: Nicht von "Pfusch" reden, wenn man nicht wirklich weiß, was das für eine Umgebung ist...
Hast du dir das Jammern selbst beigebracht oder warst du auf der Akademimimimi?
Deine Standpunkt "Never touch a running system" war bereits bei der 1 Generation "Administratoren" verpönt. Denn die Kernaussage dieser Phrase lautet: Mit dem neumodischen Kram kenne ich mich nicht aus und will mich auch nicht damit beschäftigen.
Was ist die Generation Z? Welche Eigenschaften werden ihr zugesprochen? Haben die eine Glaskugel?
Deine Standpunkt "Never touch a running system" war bereits bei der 1 Generation "Administratoren" verpönt. Denn die Kernaussage dieser Phrase lautet: Mit dem neumodischen Kram kenne ich mich nicht aus und will mich auch nicht damit beschäftigen.
Was ist die Generation Z? Welche Eigenschaften werden ihr zugesprochen? Haben die eine Glaskugel?
Hallo Zusammen,
Ich habe nun auch die Variant von Huber N. getestet und muss sagen, dass ich nach genau so etwas gesucht habe... vielen Dank!
Die Lösung mit der Webseite sehe ich eher als Workaround. Hat mir aber zumindest gestern schon mal weiter gehofen. Es war zumindest eine lösungsorintierte Antwort. Auch hierzu vielen Dank!
Auf Antworten wie diese kann zukünftig verzichtet werden, da sie keine Lösung oder Lösungansatz beinhalten !
Danke für die Info -> wurde behoben ( habe mich verklickt)
Genau so sieht es aus. Es dreht sich hierbei um eine Domäne die schon seit Jahren bestand hat und sich nicht ohne enorme Kosten umbauen lässt.
Ich habe nun auch die Variant von Huber N. getestet und muss sagen, dass ich nach genau so etwas gesucht habe... vielen Dank!
Zitat von @Hubert.N:
IGEL unterstützt grundsätzlich auch die Anmeldung am Active Directory.
Bevor ich hier einen langen Roman schreibe - Hier gibt es ein Video, wie das konfiguriert werden muss: https://www.youtube-nocookie.com/embed/JxGOEGAb3LI
IGEL unterstützt grundsätzlich auch die Anmeldung am Active Directory.
Bevor ich hier einen langen Roman schreibe - Hier gibt es ein Video, wie das konfiguriert werden muss: https://www.youtube-nocookie.com/embed/JxGOEGAb3LI
Die Lösung mit der Webseite sehe ich eher als Workaround. Hat mir aber zumindest gestern schon mal weiter gehofen. Es war zumindest eine lösungsorintierte Antwort. Auch hierzu vielen Dank!
Zitat von @Delta9:
Die Lösung :
Im RDWEB die Seite RDWeb/Pages/de-DE/password.aspx freischalten und via IGEL Profil (FF oder Chrome) auf die Clients verteilen.
Dort können die Benutzer die PW ändern uns sich wieder normal anmelden.
Dann brauchst du auch nicht die Authentifizierung auf Netzwerkebene abschalten.
Die Lösung :
Im RDWEB die Seite RDWeb/Pages/de-DE/password.aspx freischalten und via IGEL Profil (FF oder Chrome) auf die Clients verteilen.
Dort können die Benutzer die PW ändern uns sich wieder normal anmelden.
Dann brauchst du auch nicht die Authentifizierung auf Netzwerkebene abschalten.
Auf Antworten wie diese kann zukünftig verzichtet werden, da sie keine Lösung oder Lösungansatz beinhalten !
Zitat von @148656:
Da beißt die Maus keinen Faden ab. Pfusch bleibt Pfusch.
Da beißt die Maus keinen Faden ab. Pfusch bleibt Pfusch.
Danke für die Info -> wurde behoben ( habe mich verklickt)
Genau so sieht es aus. Es dreht sich hierbei um eine Domäne die schon seit Jahren bestand hat und sich nicht ohne enorme Kosten umbauen lässt.
Zitat von @Hubert.N:
Pfusch?? Ich nehme an, Du bist "Generation Z"... Früher war es einmal Best Practice von Microsoft AD-Domänen so zu benennen. Und auch wir haben noch viele Kunden, wo die Domain auf .local endet. Die Frage ist ja, ob es sinnvoll ist, so tief in eine funktionierendes System einzugreifen und eine Umbenennung durchzuführen. Mit ggf. ungeahnten Problemen, die die Systemstabilität nachhaltig negativ beeinflussen. Und was in manchen Fällen ja nicht einmal möglich ist. Z.B. wenn Exchange im Einsatz ist..
Also: Nicht von "Pfusch" reden, wenn man nicht wirklich weiß, was das für eine Umgebung ist...
Zitat von @148656:
Da beißt die Maus keinen Faden ab. Pfusch bleibt Pfusch.
Da beißt die Maus keinen Faden ab. Pfusch bleibt Pfusch.
Pfusch?? Ich nehme an, Du bist "Generation Z"... Früher war es einmal Best Practice von Microsoft AD-Domänen so zu benennen. Und auch wir haben noch viele Kunden, wo die Domain auf .local endet. Die Frage ist ja, ob es sinnvoll ist, so tief in eine funktionierendes System einzugreifen und eine Umbenennung durchzuführen. Mit ggf. ungeahnten Problemen, die die Systemstabilität nachhaltig negativ beeinflussen. Und was in manchen Fällen ja nicht einmal möglich ist. Z.B. wenn Exchange im Einsatz ist..
Also: Nicht von "Pfusch" reden, wenn man nicht wirklich weiß, was das für eine Umgebung ist...
Zitat von @148656:
Hast du dir das Jammern selbst beigebracht (...)
Hast du dir das Jammern selbst beigebracht (...)
Nein... Für das, was Du als "jammern" bezeichnest und ich eher als leicht frustriertes Kopfschütteln bezeichnen würde, sind Menschen verantwortlich, die nicht einmal versuchen einen konstruktiven Beitrag zu leisten und sich daran ergötzen bei anderen das Haar in der Suppe zu suchen.
Was ist die Generation Z?
Frag Google...
Zitat von @Hubert.N:
Nein... Für das, was Du als "jammern" bezeichnest und ich eher als leicht frustriertes Kopfschütteln bezeichnen würde, sind Menschen verantwortlich, die nicht einmal versuchen einen konstruktiven Beitrag zu leisten und sich daran ergötzen bei anderen das Haar in der Suppe zu suchen.
Ich lese wieder nur "Mimimi".Zitat von @148656:
Hast du dir das Jammern selbst beigebracht (...)
Hast du dir das Jammern selbst beigebracht (...)
Nein... Für das, was Du als "jammern" bezeichnest und ich eher als leicht frustriertes Kopfschütteln bezeichnen würde, sind Menschen verantwortlich, die nicht einmal versuchen einen konstruktiven Beitrag zu leisten und sich daran ergötzen bei anderen das Haar in der Suppe zu suchen.
Das was du als Haar in der Suppe bezeichnest, ist ein dicker weißer Vollbart.
Und ich bin den Leuten schon Dankbar, wenn sie mich auf das Haar hinweisen. Dann kann ich um das "Haar" herumlöffeln.
Was ist die Generation Z?
Frag Google...
Würde ich machen, wenn es zur Sache etwas beitragen würde. Aber es ist in der IT Wumpe, welche "Generation" man ist. Ein Grundschüler kann deine Infrastrukturen penetrieren, aber auch ein Rentner mit Langerweile und Youtube-Account.
Das was du als Haar in der Suppe bezeichnest, ist ein dicker weißer Vollbart.
Das wüsste ich aber gerne, weshalb das in diesem Zusammenhang der Vollbart sein soll und was das überhaupt mit der AD-Integration von IGEL-TCs zu tun hat.Würde ich machen, wenn es zur Sache etwas betragen würde.
na das schreibt da ja gerade der Richtige Ein Grundschüler kann deine Infrastrukturen penetrieren, aber auch ein Rentner mit Langerweile und Youtube-Account.
Weil die Domäne bei einem Kunden noch .local endet??? Und um das noch mal klarzustellen: Es geht ja nicht darum, wie AD-Domänen benannt werden, wenn sie neu aufgesetzt werden. Es geht darum, ob es sinnvoll ist, ein Rename auf einer Domäne, die seit 20 Jahren existiert und damals nach den Best-Practice-Vorgaben mit der Endung .local installiert wurde, durchzuführen.
Und gerade weil ich ja so lernfähig bin, wüsste ich mal gerne von Dir, wozu das gut sein soll das grundsätzlich durchzuführen und auch, inwiefern das die Sicherheit der Domäne erhöht.
Zitat von @Hubert.N:
...
Und gerade weil ich ja so lernfähig bin, wüsste ich mal gerne von Dir, wozu das gut sein soll das grundsätzlich durchzuführen und auch, inwiefern das die Sicherheit der Domäne erhöht.
...
Und gerade weil ich ja so lernfähig bin, wüsste ich mal gerne von Dir, wozu das gut sein soll das grundsätzlich durchzuführen und auch, inwiefern das die Sicherheit der Domäne erhöht.
Gleiches Recht für alle.
Frag Google....
Zitat von @148656:
Frag Google....
Frag Google....
Google hält das in den meisten Fällen für Unsinn.
Zitat von @148656:
Frag Google....
Frag Google....
haha - gut gebrüllt Löwe... Habe ich gemacht. Ich habe mal "wieso soll man eine ad domäne umbenennen" bei Google eingegeben
Nils Kaczenski schreibt auf faq-o-matic und im mcsebord dazu:
scheinbar “einfache” AD-Umbenennungen mit rendom.exe funktionieren nicht, wenn Exchange genutzt wird. Auch ohne Exchange sind sie in Wirklichkeit riskant. Einige Berater (auch ich) raten entschieden davon ab.
oder
ja, das "Umbenennen" einer AD-Domäne ist sehr kompliziert, weil es einfach nicht vorgesehen ist. Aus dem Grund gibt es ja seit 20 Jahren genügend Best Practices, wie man solche Situationen von vornherein vermeidet. Und es gibt den "Who-cares-Algorithmus", in dem man das "Problem" eines unpassenden Namens einfach ignoriert, weil es sich ja nur kosmetisch auswirkt.
Yusuf Dikmenoglu schreibt im Technet dazu :
gibt es denn einen *trifftigen* Grund, warum die Domäne umbenannt werden soll? Denn dieser Vorgang ist alles andere als "einfach" (wie so vieles in der IT). (...) Es ist zwar möglich (...) doch (...) muss vorher die Umgebung genauestens analysiert und die notwendigen Schritte geplant werden. Die Hauptproblematik sind die eingesetzten (Netzwerk-) Applikationen.
Abgesehen davon, der Name der AD-Domäne fällt doch dem Benutzer kaum auf. Der ist in den meisten Fällen *nur* für die IT interessant. (...)
Ja... Google ist doch toll. Ich habe sofort etliche Seiten gefunden, auf denen meist sogar explizit davon abgeraten wird, eine bestehende AD-Domain neu zu benennen. Eine Argumentation dafür konnte ich auf die Schnelle nicht finden
