none
RDS mit selbst signiertem Zertifikat RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo,

    ich habe vor kurzem zwei Remotedesktopserver mit einem selbst signiertem Zertifikat erstellt. Zusätzlich habe ich dort Passwortrichtlinien eingerichtet, die u.A. bewirken, dass nach 30 Tagen das Kennwort geändert werden muss.

    Wenn nun das Passwort eines Users abgelaufen ist und er sich dort anmelden möchte erscheint die Fehlermeldung:

    Authentifizierungsfehler.
    Die lokale Sicherheitsautorität (LSA) ist nicht erreichbar.
    Remotecomputer: %servername$
    Ursache könnte ein abgelaufenes Kennwort sein. Aktualisieren Sie das Kennwort, wenn es abgelaufen ist. Wenden Sie sich an den Administrator oder den technischen Support, wenn Sie Unterstützung wünschen.

    Es gibt allerdings keine Möglichkeit das Kennwort zu Ändern. Man kann nur auf "OK" klicken.

    Nach ein wenig Google-Recherche kam mir nun als einziger Anhaltspunkt, das Zertifikat. Aber dann sollte die Verbindung generell nicht funktionieren, oder?

    Donnerstag, 2. Juni 2016 06:21
    |

Antworten

  • Question
    Anmelden
    1
    Anmelden
    > Die lokale Sicherheitsautorität (LSA) ist nicht erreichbar.
     
    Ich werf als Stichwort mal noch "Network Level Authentication" in den
    Raum :) Besonders wegen der Thin Clients - die dürften dann
    Schwierigkeiten bekommen.
     

    Das war das richtige Stichwort!!!

    Nachdem ich die NLA auf dem Server deaktiviert habe, funktionierte die Anmeldung über den Fatclient auf Anhieb.

    Da ich in der Scout-Console (Thinclient Administration) die NLA nicht deaktivieren konnte habe ich den xfreerdp folgendermaßen aufgerufen und nun funktioniert es auch so!

    xfreerdp --no-nla -f %hostname%:%port%
    Vielen Dank an euch beide für die Hilfe!!!

    Donnerstag, 2. Juni 2016 13:10
    |

Alle Antworten

  • Question
    Anmelden
    2
    Anmelden

    Moin,

    sehe ich das richtig, dass

    • das Ganze keine Domänen-Authentifizierung nutzt, sondern lokale Konten
    • die User deren Credentials schon am Client eingeben (Popup beim Verbindungsaufbau, ggfls. mit der Möglichkeit, das Kennwort abzuspeichern)?

    In diesem Fall musst Du ihnen - als zweite oder vielleicht sogar als einzige - eine RDP-Datei geben, in der Du folgende Einstellungen machst:

    enablecredsspsupport:i:0
authentication level:i:0
prompt for credentials:i:0

    Die letzte Einstellung dürfte vorhanden sein (ggfls. mit einem anderen Wert), die ersten beiden musst Du vermutlich hinzufügen.

    Das bringt die USer ohne Vorab-Authentifizierung auf die Anmeldepage des Terminalservers, wo sie die Möglichkeit bekommen, das Kennwort zu ändern.

    Gruß

    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Donnerstag, 2. Juni 2016 06:35
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin,

    achso, dass hatte ich nicht erwähnt. Die beiden RD-Server befinden sich in einer Windows 2012 R2 Domain und die User authentifizieren sich auch über AD. 

    Die Authentifizierung findet zum größten Teil an HP Thinclients mit eLux RL Betriebssystem statt. Von dort aus stellen Sie eine Remotedesktopverbindung zu den RD-Servern her. Die Eingabe der Credentials erfolgt an der Anmeldemaske des Thinclients (keine Windows Anmeldemaske). Das Problem kommt aber auch bei normalen Workstations.

    Nur um sicher zu gehen, die RDP-Datei erstelle ich mit dem RemoteApp-Manager? Ich dachte der wäre nur für veröffentlichte Anwendungen gedacht, nicht für Desktops oder liege ich da falsch?

    Donnerstag, 2. Juni 2016 07:28
    |
  • Question
    Anmelden
    1
    Anmelden

    Siehst Du, eine Beschreibung der Infrastruktur tut doch immer gut, wenn man ein Problem postet ;-) Lass uns mal schauen, was von meiner Antwort mit den neuen Erkenntnissen noch die Gültigkeit behält...

    Erste Erkenntnis: Wenn das Domänenkonten sind, dann läuft das Kennwort ja global ab und nicht "auf den RDS-Servern". Will heißen, auf den Fat Clients (die hoffentlich in der Domäne sind) muss der Benutzer ja schon bei der Anmeldung am Client damit konfrontiert werden, dass sein Kennwort abgelaufen ist, und es dann ändern - dann ist es halt geändert und er kann sich lustig mit dem neuen Kennwort auch am RDS-Server anmelden bzw. wenn Du es ordentlich gemacht hast, halt auch per SSO ohne zusätzliche Kennwort-Eingabe.

    Zweite Erkenntnis: Linux Thin Clients. Ist die Autorisierung gegen das AD und somit auch Pass-Through zu RDS eingeschaltet? Denn auch in diesem Fall müßte die Anmeldung bei abgelaufenem Kennwort ja bereits dort scheitern...

    Was Du brauchst ist eine Instanz, die es erlaubt, das abgelaufene Kennwort zu ändern. Bei Windows-Workstations, die Domänen-Mitglied sind, ist es klar. Beim Thin Client musst Du mit Unicon klären, ob das geht, und dann ggfls. Autorisierung einschalten. Wenn der Kunde Exchange am Start hat, könnte man es auch über OWA abwickeln. Auch RDWeb bietet diese Funktionalität, man muss sie nur in der web.config aktivieren. Kommt das alles nicht in Frage, sind wir zurück bei meiner ersten Antwort:

    Dann musst Du nämlich sicherstellen, dass die Verbindung zu RDS ohne Authentifizierung erfolgt und die User auf der Anmeldemaske des RDSH landen. Dort haben sie wieder die Kennwortänderung von Windows zur Verfügung. Wenn Du allerdings einen Connection Broker und Load Balancing eingerichtet hast, wird es i.d.R. nicht möglich sein.

    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Donnerstag, 2. Juni 2016 08:00
    |
  • Question
    Anmelden
    0
    Anmelden

    Danke erstmal für die schnelle Antwort.

    Ja, ich wollte nur nicht mit der Tür ins Haus fallen, weil die Infrastruktur ziemlich kompliziert aufgebaut ist. 

    Die Fatclients befinden sich in einer anderen Domäne aber die Anmeldung wird über die normale Remotedesktopverbindung hergestellt. Dort kommt auch die Fehlermeldung, die ich gepostet habe. Der Großteil der Benutzer verbindet sich allerdings über die Thinclients. 

    Ich schau jetzt mal ob ich herausfinde wie ich auf eLux das Passthrough aktiviere. Soweit ich weiß, läuft auf den Thinclients "xfreerdp". Vielleicht kann ich das ja mit den richtigen Parametern so konfigurieren.

    Alternativ versuch ich vielleicht auch mal die Lösung mit RDWeb.

    Donnerstag, 2. Juni 2016 08:28
    |
  • Question
    Anmelden
    1
    Anmelden
    > Die lokale Sicherheitsautorität (LSA) ist nicht erreichbar.
     
    Ich werf als Stichwort mal noch "Network Level Authentication" in den
    Raum :) Besonders wegen der Thin Clients - die dürften dann
    Schwierigkeiten bekommen.
     
    Donnerstag, 2. Juni 2016 10:32
    |
  • Question
    Anmelden
    0
    Anmelden
    Schon, aber dann doch von Anfang an, nicht erst zum Kennwortwechsel, oder?

    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Donnerstag, 2. Juni 2016 12:08
    |
  • Question
    Anmelden
    1
    Anmelden
    > Die lokale Sicherheitsautorität (LSA) ist nicht erreichbar.
     
    Ich werf als Stichwort mal noch "Network Level Authentication" in den
    Raum :) Besonders wegen der Thin Clients - die dürften dann
    Schwierigkeiten bekommen.
     

    Das war das richtige Stichwort!!!

    Nachdem ich die NLA auf dem Server deaktiviert habe, funktionierte die Anmeldung über den Fatclient auf Anhieb.

    Da ich in der Scout-Console (Thinclient Administration) die NLA nicht deaktivieren konnte habe ich den xfreerdp folgendermaßen aufgerufen und nun funktioniert es auch so!

    xfreerdp --no-nla -f %hostname%:%port%
    Vielen Dank an euch beide für die Hilfe!!!

    Donnerstag, 2. Juni 2016 13:10
    |
  • Question
    Anmelden
    0
    Anmelden
    > Schon, aber dann doch von Anfang an, nicht erst zum Kennwortwechsel, oder?
     
    Doch - weil erst dann der Client eins auf die Finger kriegt. NLA hat
    kein UI, das hochpoppen könnte, der Client weiß nix von NLA (der kriegt
    nur "Anmeldung fehlgeschlagen" mit) und damit hat sichs :-))
     
    Donnerstag, 2. Juni 2016 13:32
    |