Domäne nicht mehr erreichbar nach Gruppenzuweisung

[XenBo]

Damit ein Domänen Nutzer per Remote Desktop auf einen Domänen Rechner zugreifen kann muss er in der Gruppe "Remote Desktop Users" sein, richtig?

Erste Preisfrage, wie bekomme ich den Domänen-Nutzer in diese Gruppe? Die Gruppe gibt es in dem Synology Directory Server nicht. Versucht man sie anzulegen kommt die Fehlermeldung, die Gruppe existiere schon:



Dann habe ich auf dem Rechner die RSAT Tool gestartet und dem Nutzer hier die Gruppe zugewiesen, was dazu führt, dass die Domäne quasi abstürzt. Bei dem RSAT Tool dreht sich das Rädchen endlos, man muss es per Task Manager beenden, die Domäne ist danach nicht mehr zu erreichen. Es kann keine Verbindung mehr zum DC aufgebaut werden.

Ich kann den Rechner dann noch aus der Domäne raus nehmen, aber nicht mehr hinzufügen. Im Synology Directory Server ist der Rechner aber nach wie vor gelistet und lässt sich auch nicht entfernen.



Jemand eine Idee was hier falsch läuft? Kann ja nicht richtig sein, dass eine Gruppenzuweisung die Domäne zum Absturz bringt. Ich kann das reproduzieren, habe es auf zwei Synology NAS als Server getestet.

 

[blurrrr]

Keine Ahnung was Du da feierst, aber leg eine neue Gruppe an, pack die entsprechenden User da rein und am "Client"(!) packst Du dann diese Gruppe in die erlaubten RDP-Users, ganz einfach (Wenn es noch fluffiger sein soll, Einstellung direkt via GPO an die Clients verteilen)

 

[NSFH]

Aktiviert man unter folgender GPO:
Computerkonfiguration - Softwareeinstellungen - Administrative Vorlagen - Windows Komponenten - Remotedesktopdienste - Remotedesktopsitzung-Host - Verbindungen und dann Remoteverbindungen für Benutzer mithilfe der Remotedesktopdienste zulassen.

 

[XenBo]

Danke euch für die schnellen Antworten.

Keine Ahnung was Du da feierst, aber leg eine neue Gruppe an, pack die entsprechenden User da rein und am "Client"(!) packst Du dann diese Gruppe in die erlaubten RDP-Users, ganz einfach

Mit "erlaubten RDP-Users" meinst du Builtin->Remote Desktop Users? Das ist ja das Gleiche, was ich vorher gemacht habe, nur über einen anderen Weg. Wenn ich den Benutzer oder eine auf der Syno angelegte Gruppe da rein packe bleibt das Programme (dsa.msc) auf dem Client hängen und verliert die Verbindung zum Controller. Auf dem Syno Server muss ich den Controller neu starten sonst geht nichts mehr. Nach dem Neustart ist die Zuordnung weg.

Computerkonfiguration - Softwareeinstellungen - Administrative Vorlagen - Windows Komponenten - Remotedesktopdienste - Remotedesktopsitzung-Host - Verbindungen und dann Remoteverbindungen für Benutzer mithilfe der Remotedesktopdienste zulassen.

Habe ich versucht, kommt aber immer noch die Fehlermeldung:"Die Verbindung wurde abgeleht, da das Benutzerkonto nicht zur Remoteanmeldung autorisiert ist."

 

[blurrrr]

Hä? Einmal zum testen...:

1) AD-User erstellen
2) AD-Gruppe erstellen
3) Die "Gruppe" packst Du dann händisch "am Client" unter "Systemsteuerung/System/Remoteeinstellungen/Remotedesktop/Benutzer auswählen" dazu.

Danach sollte sich der AD-User auch an der Kiste anmelden können... Zwecks Automatismus dann später (sofern erfolgreich) via GPO. Falls die GPO nicht sofort greift:

gpupdate /force

Und ganz wichtig: Auch zwischen Computer- und Benutzer-Richtlinien unterscheiden und diese dann auch entsprechend auf das korrekte Ziel anwenden...

 

[XenBo]

perfeket, so hat es funktioniert. Dank dir vielmals blurrr!

Dann geht es jetzt an die nächste Baustelle. Wie verteile ich das per GPO und schränke es pro User und pro Gerät ein?

 

[blurrrr]

GPO erstellen und entsprechend ausrollen? Pro User und pro Gerät kommt ganz auf Deine Wünsche an.

 

[XenBo]

Also das funktioniert! Nochmal vielen Dank für eure Hilfe!

Ich hätte noch eine kurze Off-Topic Frage: Wenn ich Einstellungen einer GPO verändern möchte klicke ich in der Gruppenrichtlinienverwaltung in den GPO Einstellungen auf bearbeiten. Da öffnet sich dann der Gruppenrichtlinienverwatungs-Editor, aber immer an der Wurzel und nicht an der Stelle, die ich bearbeiten möchte, muss dann jedesmal den richtigen Ast erst aufklappen. Gibt es keine Möglichkeit ein Einstellung so zu öffnen, dass man in dem Gruppenrichtlinienverwaltungs-Editor gleich an der richtigen Stelle steht?

 

[blurrrr]

Ist wohl die Frage wo Du Dich befindest... bei "Gruppenrichtlinien" werden die erstellten erstmal abgelegt (ohne jegliche Zuweisung) und dann kann man die GPO auf eine bestimmte OU verknüpfen. Alternativ direkt in der OU erstellen, wird dann auch direkt mit der OU verknüpft.

 

[XenBo]

Ja, aber das meinte ich nicht. Ich meinte, wenn du dir den Inhalte der GPO anschaust, was da genau eingestellt ist und dann die Einstellungen alle aufklappst. Um in diesen tief verschachtelten Strukturen was zu ändern mußt du über bearbeiten in den Editor wechseln und da steht man dann nicht an der Stelle die man ändern möchte, sondern immer am Anfang und muss sich zu der Einstellung durchklicken.

 

[blurrrr]

Das ist normal, dass wenn Du eine GPO bearbeitest, ganz am Anfang landest und nicht dort, wo Du gerne wärst ??

 

[XenBo]

?? Da wird man doch wahnsinnig.

 

[blurrrr]

In der Regel weiss man schon wohin man hin muss (alles eine Frage der Übung)

 

[XenBo]

Eine Sache verstehe ich jetzt doch nicht. Ich dachte der Domänen Admin hat immer Zugriff per Remotedesktop, so steht es in den Systemeigenschaften:



Mit dem Administrator kann ich mich nur anmelden, wenn er Mitglied der Gruppe RDP-Users ist, ansonsten bekomme ich den Hinweis, dass der Administrator keine Berechtigung hat. Da stimmt doch was nicht?

 

[blurrrr]

Ich dachte der Domänen Admin hat immer Zugriff per Remotedesktop, so steht es in den Systemeigenschaften

1. Trugschluss: "ich dachte" ?
2. Trugschluss: Steht denn "unten" (unter der Userliste) auch wirklich <Domäne>\administrator, oder ist das nur der "lokale" Gerätename?

Wenn dort steht, dass <Domäne>\Administrator bereits Zugriff "hat", dann ist dem auch so.

 

[XenBo]

Wenn dort steht, dass <Domäne>\Administrator bereits Zugriff "hat", dann ist dem auch so.

Da unten steht <Domäne>\Administrator und dem ist leider nicht so. Das Verhalten ist genau so wie ich es beschrieben habe.

Seit eben habe ich ein weiteres Problem:

Domäne ist example.com
Der Controller und DNS: dc.example.com

Egal was ich per DNS auflöse, die Domäne wird als Suffix dran gehangen, also nslookup dc.example.com löst dc.example.com.example.com auf. Das fürht dazu, dass der Rechner den eigenen Domänen Controller nicht mehr findet. Nehme ich den Rechner aus der Domäne raus (DNS Server bleibt gleich) funktionert alles, packe ich ihn wieder rein, geht es nicht mehr.

Ich dachte zunächst es ist ein lokales Problem, denn z.B. nslookup web.de 8.8.8.8 löst web.de.example.com auf. Also schickt ja offensichtlich der Client schon den falschen Hostnamen. Der Client ist eine VM, die habe ich an einen Stand rollbacked, wo es sicher lief, geht aber plötzlich auch bei dem Stand nicht mehr. Das spricht dafür, dass das Problem doch vom Directory Server kommt.

Ich lade gerade eine frische VM von MS und schaue mal, wie die sicher verhält.

Das ist gerade alles ein sehr unschönes Verhalten. Ich finde keine Fehler. Es fühlt sich für mich buggy an. Jemand sowas schon mal erlebt oder eine Idee?

 

[XenBo]

Die frische VM zeigt das gleiche Problem, liegt also am Server. Das Problem liegt möglicherweise darin, dass die Windows Clients sich nicht am Synology DNS registrieren können. Das Problem ist auch hier beschrieben:

https://www.synology-forum.de/threads/dns-ereignis-update-security-was-bedeutet-das.84040/
Leider gibt es in diesem Thread keine Lösung, außer die Domäne mit andererm Namen neu aufzusetzen. An der Stelle werde ich morgen weiter suchen oder ist die Frage, wie man das ohne Namensänderung fixt jetzt vielleicht elitär genug, um sie hier zu stellen? Die DNS Einträge im Server stimmen jedenfalls, daran kann es nicht liegen.

 

[blurrrr]

Das Prbblem liegt möglicherweise darin

..."möglicherweise" Wäre schon gut, wenn man es "wüsste", oder? Dafür müsste man aber schon verstehen, wie das gesamte Konstrukt funktioniert. Weisst Du überhaupt, wofür die DNC-Clientregistrierung gut ist? Das dient lediglich, dass sich ein Client mit dynamischer IP mit der selbigen im DNS erneut verewigen darf (nicht umsonst gibt es z.B. sowas)... mit einem DNS-"Suffix" hat das erstmal weniger zu tun.

Prüf halt erstmal indem Du hingehst und die Auflösung entsprechend prüfst:

nslookup dc
nslookup dc 8.8.8.8
nslookup dc.example.com
nslookup dc.example.com 8.8.8.8

"Wann" passt "was".... Zum einen kann der Client selbst was intus haben (DNS-Suffix) oder es wird ggf. direkt vom DHCP mitgeliefert. Fakt ist aber, dass der Client selber eigentlich garnichts damit zu tun hat, das macht der DNS-Server normalerweise schon von alleine. Normalerweise haben die Clients auch keinerlei DNS-Suffix intus, das kommt dann vom DNS-Server.



Wie Du siehst, funktioniert das auch ohne Client-DNS-Suffix ganz gut. Blau ist der angefragte Hostname (angefragt ohne Domain), die entsprechende Antwort kommt allerdings mit Domain (gelb) zurück, der Rest hat nicht zu interessieren ?

So oder so, hilft Dir aber sicherlich ein Paketmitschnitt, dann brauchst Du nur die Pakete abgreifen und schauen, welche Anfrage rausgegangen ist und wie das ganze wieder reingekommen ist. Punkt ist halt, wenn Client und DNS-Server beide ein Suffix anhängen, kommt am Ende halt nur Murks bei rum.... Und nu ist aber mal gut hier, denn dieser "elitäre" Kram (wie Du ihn nennst), hat hier dann doch eher weniger verloren und wir sind hier (meiner Meinung nach) schon viel zu weit abgekommen (der Thread hatte ja auch mal einen passenden Titel für ein Problem). Da Du die Grundlagen also nach wie vor nicht beherrscht (da hat das AD nix mit zu tun, scheitert ja schon am DNS-Thema), nix für ungut - aber das komplette Kompendium kannst Du Dir mal aus irgendwelchen Fachbüchern/Schulungen holen - das was Du mal gelernt hast, hat man vermutlich halt auch nicht "mal eben" gemacht ? Soderle... blurrrr Ende, blurrrr Bubu ??

EDIT: Btw... MS-Technet ist auch öfters mal hilfreich, Google auch, kann man Themen wie "double dns-suffix" suchen und so...

 

[XenBo]

Ich habe viel gelesen zu dem Problem und auch einige Threads im englischen Forum dazu gefunden. Nirgends wurde eine Lösung gefunden.

Ich habe den Rechner aus der Domäne raus genommen und wieder in die Domäne aufgenommen, jetzt läuft es wieder. Aber wie man in anderen Threade liest vielleicht nur ein paar Tage, bis es wieder von vorne los geht. Irgendwas ist da faul. Das ist irgendeine Besonderheit mit dem Synology DNS, siehe. z.B. hier:

https://www.synology-forum.de/threads/dns-ereignis-update-security-was-bedeutet-das.84040/
https://community.synology.com/enu/forum/17/post/108970
https://community.synology.com/enu/forum/1/post/119531