phatair

Danke Martin!

Hat jetzt alles wunderbar funktioniert, nach dem ich mich mit dem Schema Master verbunden hatte - danke Martin. Habe jetzt alles umgesetzt und Berechtigungen werden für neue GPOs korrekt gesetzt. Die AD Gruppe darf auch GPOs bearbeiten und verlinken. Vielen Dank an euch und vor allem Mark für die super Anleitung!

Schema-Master ist unserer 2. DC (mit dem war ich nicht verbunden). Muss ich mit dem Schema Master verbunden sein? repadmin /showreps zeigt aktuelle Daten und alles erfolgreich an. Ausgeführt auf dem 1. DC (von dem ich ADSI-Edit ausgeführt hatte).

Hm..nicht das ich wüsste. DCDiag zeigt auch keinerlei Fehler an. Ich habe beim verbinden mit dem ADSI-Editor direkt einen DC ausgewählt (Pfad:LDAP://DC1.kts.schlaeger.com/Schema Ist das vielleicht ein Problem - muss ich beim Verbinden unter "Computer" nicht "Standard (Domäne oder Server, an der/dem Sie angemeldet sind)" auswählen, sondern "Domäne oder Server auswählen oder eingeben:" und dort dann den Domänennamen angeben?

Panische Angst nicht, aber schon etwas Respekt davor Es gibt aber leider ein Problem beim ändern des Werts defaultSecurityDescriptor. Ich habe auf einem DC den ADSI-Editor geöffnet, mich mit dem Schema verbunden und bin zum CN-Group-Policy-Container navigiert. Ich erhalte folgende Fehlermeldung beim Übernehmen der Änderung. Unser Default Wert lautet: D:P(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;DA)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;EA)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;CO)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;SY)(A;CI;LCRPLORC;;;AU)(OA;CI;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;CI;LCRPLORC;;;ED) Marks Wert ist identisch (nur die Sortierung ist anders). Diesem Wert habe ich dann (A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;<SID DER GPO GRUPPE>) angehängt. Also so: D:P(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;DA)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;EA)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;CO)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;SY)(A;CI;LCRPLORC;;;AU)(OA;CI;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;CI;LCRPLORC;;;ED)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;<SID DER GPO GRUPPE>) Hab ich irgendwas übersehen?

Danke Dir. Erhöhen solche Änderungen im Schema nicht auch die Fehleranfälligkeit z.B. bei einem DC Update und dem damit verbundenen Schema Update?

Hallo zusammen, ich muss leider noch einen Beitrag aufmachen - die Umstrukturierung der Admin Accounts zieht ganz schöne Kreise :) Ich möchte eine GPO Admin Delegierung durchführen. Dazu hab ich 2 Beiträge gefunden Vom Mark Von 4Sysops Die beiden Beiträge unterscheiden sich aber etwas: Marks Variante ändert das AD Schema ab, damit bei allen GPOs die neue Sicherheitsgruppe mit den Berechtigungen korrekt übernommen werden. Die Variante von 4Sysops fügt erstmal in AD Benutzer und Computer die Sicherheitsgruppe hinzu, danach wird per powershell befehl für jede GPO die Berechtigung angepasst. Das ganze wird dann per Scheduled Task immer wieder durchgeführt, um neue GPOs auch mit der Berechtigung zu versehen. Ich habe immer noch das (vielleicht veraltete Info) das Schema Änderungen vermieden werden sollten. Wäre somit die 4Sysops Variante die bessere oder ist die Mark Variante problemlos durchführbar? Danke euch schon mal. Gruß

Habe ich auch nicht als Empfehlung aufgenommen. Danke Dir!

Das heißt, ihr habt nur noch eure eigenen DL-Sec-Gruppen in den lokalen Admins und die Domänen-Admins Gruppe komplett entfernt? Da bei uns nur noch max. 2 Domänen Admin Accounts bestehen werden, werde ich wohl dazu tendieren die Anmeldung zu verweigern.

Das habe ich so mitgenommen, allerdings wird das noch dauern bis zur Umsetzung. Das ganze muss ich erstmal verstehen und so schnell setzt man das dann ja auch nicht um. Aber noch mal ganz zurück zum Anfang. Irgendwie sehe ich jetzt gerade den Wald vor lauter Bäumen nicht mehr. Wenn man spezielle Server Admins hat und diese den lokalen Server Administratoren Gruppen zuweist, kann ich die Domänen Administratoren ja aus den lokalen Administratoren Gruppen der jeweiligen Server rausschmeißen (wenn Sie nirgends mehr auf dem Server verwendet werden), richtig? Oder verbietet man nur das anmelden? Stehe gerade auf dem Schlauch...

Ok, ich mache es ab sofort manuell :) Heißt Shared Mailbox erstellen oder konvertieren, Berechtigungen setzen und dann manuell dem User hinzufügen. Was genau meinst du damit? Bezog es sich auf diese Aussage von mir, dass beim automatischen hinzufügen der Mailbox unter Postfächer nichts erscheint? EDIT: Irgendwie finde ich den Befehl -AutoMapping $False beim Exchange 2010 nicht. Gab es die Option noch nicht bzw. gebe ich diesen Parameter beim erstellen der Mailbox mit oder beim berechtigen des Users?

Ok, was für Nachteile wären das beim AutoMapping? Wenn ich das manuell hinzufüge, gehe ich ja im Outlook in die Account Settings -> E-Mail Tab -> Ändern -> Weitere Einstellungen ->Erweitert Tab ->Postfächer Hier kann ich es dann hinzufügen. Ist es dann eigentlich normal, wenn es automatisch hinzugefügt wurde, dass es dort nicht drinnen steht? Bei mir ist das nämlich so

Danke Dir - habs jetzt auch gefunden. https://docs.microsoft.com/en-us/powershell/module/exchange/mailboxes/set-mailboxsentitemsconfiguration?view=exchange-ps Das heißt ich kann entweder ein normales User Postfach erstellen und das danach in eine Shared Mailbox umwandeln oder ich erstelle gleich eine Shared Mailbox mit den Befehlen aus Beitrag 1. Sollen weitere User auf die Shared Mailbox zugreifen, lasse ich den Befehl "Add-MailboxPermission <Mailbox Name> -User "<domain\username>" -AccessRights FullAccess" nochmal laufen oder gehe über die Exchange Konsole und gebe dem User Vollzugriff. Korrekt?

Das kann gut sein, macht eigentlich auch mehr Sinn. Ist das eine Globale Einstellung und gilt dann für alle shared Mailboxes oder stellt man das pro Shared Mailbox separat ein (oder sowohl als auch)? Ich habe folgende Befehle gefunden. die klingen für mich nach einer Globalen Einstellung.

Ist das die Option, damit gesendete Elemente in der Shared Mailbox abgelegt werden und nicht im Benutzer Postfach? Ich dachte, dass in Outlook 2016 dies schon standardmäßig so gemacht wird. Ist das SenderandForm ein Parameter den ich beim erstellen der Shared Mailbox mit gebe?

Hallo zusammen, wir setzen bei uns noch einen Exchange 2010 SP3 Rollup 24 ein. Outlook ist Version 2016 Wir haben bei uns ein paar Postfächer (z.B. für Bewerbungen oder Rechnungen) die von mehreren Usern eingesehen und genutzt werden sollen (Unterordner erstellen, Mail löschen und verschieben und auch mal eine Mail im Namen des Postfaches verschicken können). Bisher wurde über die Exchange Management Konsole ein normales User Postfach für einen User erstellt und dann wurde den entsprechenden Usern Vollzugriff auf das Postfach gegeben. Das ist dann nach ein paar Minuten automatisch im Outlook erschienen und alles war gut. Die erste Frage wäre nun, ist das ein "korrektes" Vorgehen um ein Gruppenpostfach zu erstellen - Stichwort Shared Mailbox? Das scheint ja nur über die EMS zu funktionieren. Stimmen diese Befehle um eine Shared Mailbox zu erstellen und muss ich den Befehl "Add-MailboxPermission <Mailbox Name> -User "<domain\username>" -AccessRights FullAccess" jedes mal für die Shared Mailbox ausführen, wenn ein weiterer User Zugriff auf diese erhalten soll? Die Shared Mailbox scheint ja in der AD ein deaktivierter Benutzer zu sein und keine AD Gruppe in der ich weitere User schieben kann. New-Mailbox -Name <Maibox Name> -Alias <Alias> -OrganizationalUnit "<OU path>" -Database "<Database>" -UserPrincipalName <E-mail Address> -Shared Add-MailboxPermission <Mailbox Name> -User "<domain\username>" -AccessRights FullAccess Add-ADPermission <Mailbox Name> -User "<domain\username>" -ExtendedRights Send-As Kann ich mit diesem Befehlen unsere bestehenden User Postfächer in Shared Mailboxen umwandeln? Set-Mailbox "<Maibox Name>" -Type shared Add-MailboxPermission <Mailbox Name> -User "<domain\username>" -AccessRights FullAccess Add-ADPermission <Mailbox Name> -User "<domain\username>" -ExtendedRights Send-As Vielen Dank.

Guten Abend zusammen, die Umstellung schreitet voran. Wir haben nun eine strikte Trennung zwischen Client Admins und Server Admins. Ebenso gibt es keine Admin Sammelaccounts mehr und die Server Admins sind auf ihre benötigten Server beschränkt. Jede Applikation hat eine eigene Sicherheitsgruppe in der die benötigten Admin Gruppen hinzugefügt wurden. Als nächstes kommt der Domänen Administrator dran. Die Thematik mit PAW ist nach einigem einlesen doch eine etwas größere Geschichte. Diese werde ich so schnell nicht umsetzen können - erstmal muss ich das alles überhaupt richtig verstehen :) Nun hatten ja einige von euch geschrieben, dass ihr einen "Admin Terminalserver" habt, auf dem die wichtigsten Admin Programme installiert sind und von denen ihr die administrative Tätigkeit ausführt. Wir machen das im Moment noch von unseren normalen Arbeitsplätzen aus. Das würde ich auch gerne zentralisieren und ändern. Hat diese Lösung mit einem zentralen Admin Server überhaupt einen richtigen Sicherheitsvorteil? Ich muss mich dazu ja trotdzdem von meinem PC aus per RDP auf diesen Server verbinden- es wäre also hier auch eine "Pass-the-Hash" Attake möglich, oder verstehe ich das komplett falsch? Ich verbinde mich dann ja mit meinem Server-Admin auf diesen Admin PC. Oder verwende ich dann dafür einen anderen Account? Ich würde gerne noch etwas für die Sicherheit einführen, aber größere Projekte wie PAW oder VLANs erstellen ist im Moment nicht drin. Da hat unser 2. Serverraum im Moment Prio 1. Danke schon mal und einen schönen Abend.

Zitat Zitat

Das bezieht sich dann ja auf die Situation, wenn 2 Domänen vorhanden sind. In einer Domäne werden eben alle Gruppen im Token berücksichtigt. Der User ist in 3 Globalen Domänengruppen und diese sind wiederum in 10 Lokale Domänengruppen enthalten. Das heißt alle 13 Gruppen werden gezählt - 3 mit je 8 Bytes und 10 mit je 40 Bytes + 1200 für die Verwaltungsinformationen. Da haben wir bei unserer Struktur mit maximal 80 Berechtigungsgruppen pro User noch gut Luft nach oben. Aber wieder etwas gelernt.

Da kann man ja wirklich vom vom Hundertsten ins Tausendste kommen Wenn ich das ganze richtig verstehe, bezieht sich die MaxTokenSize ja pro User. Da die Admin Accounts wahrscheinlich eine überschaubare Anzahl an Gruppenmitgliedschaften erhalten (werden ja keine Berechtigungen auf dem File Server erhalten), hält sich das Problem hier in Grenzen. Problematisch könnte es dann bei den normalen Usern werden, wenn die File Server Berechtigungen mehr werden. Mit dem Script könnte man das wohl schön testen - läuft aber leider nicht wenn der DC ein 2012R2 oder neue ist.

Guten Morgen, ich hätte da noch ne Frage in die Stammtischrunde Ich habe beim informieren über das A-G-DL-P Prinzip folgende Seite gefunden: http://www.fileserver-tools.com/2013/02/agdlp-prinzip-und-das-tokensize-problem/ Hier wird davon gesprochen, dass der Kerberos-Security-Token mit dem A-G-DL-P Prinzip sehr schnell "voll" wird und das zu Problemen führen kann. Ist das wirklich ein Problem? Ich könnte mir vorstellen, dass dies erst bei Umgebungen mit mehreren 1000 Usern und ebenso vielen Berechtigungsgruppen zu Problemen führen könnte, oder was meint ihr?

Administriert ihr dann nur über VMware Console?

Danke fürs gegenprüfen. Dann passt das ja soweit. Genau das hatte ich auch schon geschrieben, das anmelden gilt ja nur für Lokal (Tastatur/Vmware) und hier hat kein normaler User Zugriff bzw. Möglichkeiten das zu tun. Ich werde das mit dem verbieten der Domänen Benutzer noch mal überlegen. Gibt erstmal wichtigere Punkte. RDP ist natürlich für normale User nicht möglich. In Zukunft wird auch hier per GPP eine AD Gruppe für die RDP User zur lokale Gruppe Remotedesktopbenutzer zugewiesen. Ich denke ich habe jetzt einen ganz guten Plan für die Struktur. Vielen Dank noch mal für die ganzen Ideen, Gedanken und Tips!

Auf unseren 2012R2 Servern sind in der lokalen "Benutzer Gruppe" auch die Domänen-Benutzer enthalten. In der Richtlinie -> Zuweisen von Benutzerrechten -> Lokal anmelden zulassen steht folgendes: Heißt für mich, dass sich auf den Servern (Ausnahme Domain Controller) die Domänen-Benutzer anmelden können. Soweit ich weiß, werden die Domänen-Benutzer beim Domain Join automatisch in die lokalen Benutzer aufgenommen. Somit müsste man diese entweder aus der lokalen Gruppe rausschmeißen oder eben über die Richtlinie die Anmeldung verweigern. Ich würde hier die Richtlinie bevorzugen, da diese global auf alle Server wirkt und man das entfernen der Domänen-Benutzer aus der lokalen Benutzer Gruppe nicht vergessen kann. Oder ich habe hier irgendwas total falsch verstanden... Genau so möchte ich das umsetzen. AGDLP setzen wir bei uns sowieso gerade für File Server Berechtigungen um und ich finde das Prinzip einfach genial. So in der Richtung habe ich mir das auch vorgestellt. Ich habe mir die Artikel von Dukel erstmal nur grob durchgelesen. Ich möchte einfach zentrale "Admin Arbeitsplätze" haben und nicht mehr über die normalen Arbeitsplätze die administrativen Tools bedienen. Im Moment hängen bei uns Server und Clients auch noch im gleichen VLAN - wir haben hier also noch so einiges zu tun die alten gewachsenen Strukturen auf Vordermann zu bringen. Die Thematik steht aber noch etwas weiter hinten an. Erstmal die einfachen Sachen gerade ziehen.

Da gebe ich dir ja auch vollkommen Recht und ich habe ja auch nichts gegenteiliges behauptet. Deswegen bauen wir die Verwaltung der Admin Accounts auch um. Wir wollen getrennte Admin Accounts und best möglichst auch Jump Server. Die Aussage bezog sich auf den genannten Link und hier geht es vor allem um die Vergabe der Admin Accounts bzw. die Zuweisung der Gruppen auf die Server mittels GPO. Diese Lösung scheint mir für unsere Umgebung zu komplex - da ich hier die paar Admin Gruppen auch manuell eintragen oder eben per GPP zuweisen kann. Mir geht es jetzt vor allem darum, ob es sinnig ist die Domänen Benutzer aus den lokalen Anmeldungen für Server zu entfernen oder nicht.