Active Directory - Mitglieder zu Gruppe hinzufügen Rechte
Moin zusammen,
ich nutze einen Samba4 Server auf meinem Testserver, den ich als Active Directory Domain Controller aufgesetzt habe. Es läuft auch alles super, wie es zu erwarten ist.
Ich habe einzig allein ein Problem mit den Rechten, wenn ich einen Benutzer zu einer Gruppe hinzufügen möchte.
Ich habe zwei Gruppen: Mitarbeiter und Gast.
Sowie einen Benutzer "test.mitarbeiter". Der "test.mitarbeiter" befindet sich in der Gruppe Mitarbeiter.
Alle Mitarbeiter die in der Gruppe Mitarbeiter sind, soll es möglich sein Benutzer zur Gruppe Gast hinzufügen. Ich habe also die Sicherheitseinstellungen der Gruppe "Gast" aufgerufen und unter Erweitert -> Hinzufügen den Principal "Mitarbeiter" mit der Option "Nur auf dieses Objekt anwenden" das Recht "Mitglied schreiben hinzugefügt". (Das ist auch das einzige, dass ADUC mit dem Delegation Wizard setzt, wenn man "Darf Mitglieder zur Gruppe hinzufügen auswählt".
Ich teste meine LDAP immer mit LDAPAdmin ((http://www.ldapadmin.org) hat auch andere Gründe) und wollte hier einen Benutzer zu dieser Gruppe hinzufügen. Allerdings kam lediglich die Fehlermeldung, dass die Rechte nicht ausreichend seien.
Nach intensiveren Bruteforcen welcher Parameter denn der richtige ist, damit es mit LDAPAdmin klappt, fand ich heraus, dass es funktioniert, wenn man das Schreiben von "groupType" erlaubt.
Jetzt sehe ich allerdings keinen direkten Zusammenhang zwischen GroupType und den Mitgliedern einer Gruppe.
Hat vielleicht einer von euch eine Idee, wieso das so ist? Ist das ein Bug in LDAPAdmin oder liegt es an einem Missverständnis der "Mitglieder hinzufügen"-Rechte?
Disclaimer:
Ich poste diesen Thread unter Windows Server, da ich eher von einer Fehlbedienung ausgehe und da RSAT identisch mit den Windows Server Tools ist, erhoffe ich mir hier mehr Resonanz ;).
ich nutze einen Samba4 Server auf meinem Testserver, den ich als Active Directory Domain Controller aufgesetzt habe. Es läuft auch alles super, wie es zu erwarten ist.
Ich habe einzig allein ein Problem mit den Rechten, wenn ich einen Benutzer zu einer Gruppe hinzufügen möchte.
Ich habe zwei Gruppen: Mitarbeiter und Gast.
Sowie einen Benutzer "test.mitarbeiter". Der "test.mitarbeiter" befindet sich in der Gruppe Mitarbeiter.
Alle Mitarbeiter die in der Gruppe Mitarbeiter sind, soll es möglich sein Benutzer zur Gruppe Gast hinzufügen. Ich habe also die Sicherheitseinstellungen der Gruppe "Gast" aufgerufen und unter Erweitert -> Hinzufügen den Principal "Mitarbeiter" mit der Option "Nur auf dieses Objekt anwenden" das Recht "Mitglied schreiben hinzugefügt". (Das ist auch das einzige, dass ADUC mit dem Delegation Wizard setzt, wenn man "Darf Mitglieder zur Gruppe hinzufügen auswählt".
Ich teste meine LDAP immer mit LDAPAdmin ((http://www.ldapadmin.org) hat auch andere Gründe) und wollte hier einen Benutzer zu dieser Gruppe hinzufügen. Allerdings kam lediglich die Fehlermeldung, dass die Rechte nicht ausreichend seien.
Nach intensiveren Bruteforcen welcher Parameter denn der richtige ist, damit es mit LDAPAdmin klappt, fand ich heraus, dass es funktioniert, wenn man das Schreiben von "groupType" erlaubt.
Jetzt sehe ich allerdings keinen direkten Zusammenhang zwischen GroupType und den Mitgliedern einer Gruppe.
Hat vielleicht einer von euch eine Idee, wieso das so ist? Ist das ein Bug in LDAPAdmin oder liegt es an einem Missverständnis der "Mitglieder hinzufügen"-Rechte?
Disclaimer:
Ich poste diesen Thread unter Windows Server, da ich eher von einer Fehlbedienung ausgehe und da RSAT identisch mit den Windows Server Tools ist, erhoffe ich mir hier mehr Resonanz ;).
Please also mark the comments that contributed to the solution of the article
Content-ID: 362644
Url: https://administrator.de/contentid/362644
Printed on: December 14, 2024 at 20:12 o'clock
20 Comments
Latest comment
Hi,
Teste mal, ob es ausreicht, wenn Du der Gruppe "Mitglieder" explizit Lese-Recht für groupType erteilst.
Der Zusammenhang ist hier, dass man je nach Gruppentyp andere Mitglieder hinzufügen kann. Zu einer Globalen Gruppe z.B. keine Benutzer und Gruppen anderer Domänen, usw. Ich vermute, dass LDAPAdmin eigentlich einfach nur den Gruppentyp auslesen will. Oder es bietet bei Bedarf die Möglichkeit an, den Gruppentyp zu ändern. z.B. wenn eben doch versucht einen Benutzer einer anderen Domäne hinzufügen will, dass es dann anbietet, den Gruppentyp in "domänenlokal" oder "universell" zu ändern. Ist nur ne Vermutung von mir.
In jedem Fall würde ich niemals einem Nicht-Admin das Recht einräumen, einen Gruppentyp zu ändern! Sowas kann fatale Folgen haben.
E.
Jetzt sehe ich allerdings keinen direkten Zusammenhang zwischen GroupType und den Mitgliedern einer Gruppe.
Na doch, diesen gibt es schon. Aber man muss diesen nicht schreiben können, um die Mitglieder zu schreiben.Teste mal, ob es ausreicht, wenn Du der Gruppe "Mitglieder" explizit Lese-Recht für groupType erteilst.
Der Zusammenhang ist hier, dass man je nach Gruppentyp andere Mitglieder hinzufügen kann. Zu einer Globalen Gruppe z.B. keine Benutzer und Gruppen anderer Domänen, usw. Ich vermute, dass LDAPAdmin eigentlich einfach nur den Gruppentyp auslesen will. Oder es bietet bei Bedarf die Möglichkeit an, den Gruppentyp zu ändern. z.B. wenn eben doch versucht einen Benutzer einer anderen Domäne hinzufügen will, dass es dann anbietet, den Gruppentyp in "domänenlokal" oder "universell" zu ändern. Ist nur ne Vermutung von mir.
In jedem Fall würde ich niemals einem Nicht-Admin das Recht einräumen, einen Gruppentyp zu ändern! Sowas kann fatale Folgen haben.
E.
Timeout abwarten oder setzen!
Temporäre Credentials während einer Windows-Sitzung wieder löschen
Temporäre Credentials während einer Windows-Sitzung wieder löschen
Verbinde ich mich jetzt neu mit dem Share wurden die Gruppen allerdings nicht geupdatet. Auch in klist tauchen keine neuen Tickets auf.
Ja, sorry, mein Fehler.Das musst Du nicht am Client sondern am Server ausführen!
Purge the Kerberos client ticket cache for all sessions (Powershell one-liner)
Beim Zugriff auf ein Share kommt es doch auf das Ticket der Sitzung auf dem Fileserver an. Hatte ich nicht bedacht.
Das einfache "klist purge" in der Clientsitzung ist nur bei lokalen Ressourcen relevant.
Also Benutzer ändern (dessen Gruppenmitgliedschaft) und dann als Admin auf dem Server entweder die Sitzung des Benutzers trennen (kann man i.A. problemlos tun) oder z.B. mit o.g. PS-Script die Tickets der Sitzungen löschen.
Ich nutze Windows 10 1709 mit Profile Roaming was ja scheinbar öfter mal Probleme macht.
Im Zusammenspiel mit einem Windows Fileserver haben wir da Null Probleme.Jetzt habe ich das Phänomen, dass der Logout teilweise extrem lange dauert (ca. 1-2 Minuten).
Ich habe mich ca. 20 An und Abgemeldet, wodurch ich zu folgendem Ergebnis kam:
- Wenn sich ein User anmeldet und direkt wieder abmeldet, so dauert der Logout extrem lange.
- Wenn sich der User anmeldet und erst ca. 2-3 Minuten wartet und sich dann abmeldet, dann geht der Logout innerhalb von ein paar Sekunden.
Teste das mal mit einem Windows Server. Das kann zum Test auch eine Workstation sein. (keine Windows Server Edition)Ich habe mich ca. 20 An und Abgemeldet, wodurch ich zu folgendem Ergebnis kam:
- Wenn sich ein User anmeldet und direkt wieder abmeldet, so dauert der Logout extrem lange.
- Wenn sich der User anmeldet und erst ca. 2-3 Minuten wartet und sich dann abmeldet, dann geht der Logout innerhalb von ein paar Sekunden.
Edit:// Ich lösche die Benutzerprofile, sobald sich der User abmeldet. Könnte es sein, dass Windows da irgendetwas in AppData/Local generiert?
Ja, natürlich sorgt das dafür, dass die Anmeldezeiten dadurch länger werden, weil er jedes Mal alles neu kopieren muss.Warum löschst Du es?
Beim Abmelden sollte es so sein, dass das Löschen erst nach dem Abmelden der Sitzung erfolgt. D.h. aber, dass alle Prozesse dieses Benutzers beendet sein müssen und nicht bloß die sichtbaren.
Edit:
Allgemein: siehe auch "Ordnerumleitung"'
vielleicht hast du ja einmal kurz die Möglichkeit dich an einem Roaming Profil anzumelden und direkt wieder abzumelden mit der aktuellen Windows 10 Version?
Keine Probleme in aktuellster Lab-Config. Geht ruck zuck auch mit Löschen der Profile. Mach halt mal ein Logging mit ProcMon.Ich schätze mal da blockiert dein AV oder anderer Dienst die Abmeldung.
vielleicht hast du ja einmal kurz die Möglichkeit dich an einem Roaming Profil anzumelden und direkt wieder abzumelden mit der aktuellen Windows 10 Version?
Ich und die anderen auch, arbeiten am Win10 Pro 1709. Sonst würde ich nicht schreiben "haben wir da Null Probleme."Beim Anmelden habe ich keine Probleme. Nur beim direkten wieder Abmelden nach dem Login. Vermutlich wartet Windows dann auf irgendeinen Prozess, bis der beendet ist.
Ich erinnere mich, hier im Forum vor kurzen schon mal sowas im Zusammenhang mit eiem NAS als Filserver gelesen zu haben. Suche Du einfach mal ...Ich lösche den Benutzerordner, weil auf dem Computer diverse Nutzer arbeiten sollen. Ich hätte sonst ca 100 lokale Benutzerprofile die entsprechend Platz benötigen.
Du hast einen PC, an welchem 100 verschiedene Benutzer abwechselnd arbeiten?Wenn Dein geschildertes Problem nur dann auftritt, wenn man sich sofort nach Anmeldung wieder abmeldet: Wie oft kann/wird dann sowas im Produktivfall voraussichtlich eintreten?
In ProcMon gibt es eine TimeLineansicht "ProcessTree"' in der du siehst welcher Prozess die Wartezeit verursacht.
http://www.winhelponline.com/blog/procmon-track-process-creation-exit-t ...
http://www.winhelponline.com/blog/procmon-track-process-creation-exit-t ...
Ich wiederhole nochmal meine Frage:
Wenn ich richtig gelesen habe, tritt das bei Euch nur auf, wenn das Abmelden unmittelbar nach dem Anmelden erfolgt. Habe ich das richtig verstanden?
Falls ja:
Wie oft ist zu erwarten, dass dieser Fall denn eintreten wird? Falls Du die Wahrscheinlichkeit als gering einstufen kannst (ich tippe auf "sehr gering"), dann kann es Dir doch egal sein, oder?
Wenn ich richtig gelesen habe, tritt das bei Euch nur auf, wenn das Abmelden unmittelbar nach dem Anmelden erfolgt. Habe ich das richtig verstanden?
Falls ja:
Wie oft ist zu erwarten, dass dieser Fall denn eintreten wird? Falls Du die Wahrscheinlichkeit als gering einstufen kannst (ich tippe auf "sehr gering"), dann kann es Dir doch egal sein, oder?