phatair

Am 7.3.2019 um 10:25 schrieb MurdocX:

Wir haben diese Praxis (DL-Sec-Gruppe in den lokalen Admins) seit Jahren so und bisher keine Probleme bei Anwendungen oder sonstigen Remoteverwaltungen (wmi, winrs(ps),dcom) gehabt.

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.

vor 23 Stunden schrieb RolfW:

Wichtig ist es, dass man eben von einer gesicherten WS (PAW) aus zu den Servern sich verbindet, sonst hat man hier ein leichteres Einfallstor.

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...

vor 8 Minuten schrieb Nobbyaushb:

Diverse.

Fängt an, das z.B. gesendete Elemente in den eigenen langen, auch aknn die OST nicht beeinflusst werden, da gemeinsam mit dem Hauptpostfach etcpp - die Liste ist lang.

Ok, ich mache es ab sofort manuell :)

Heißt Shared Mailbox erstellen oder konvertieren, Berechtigungen setzen und dann manuell dem User hinzufügen.

vor 8 Minuten schrieb Nobbyaushb:

Und nein, das wird als weiteres, eigenes Postfach eingerichtet - ist besser, glaube mir...

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?

vor 7 Minuten schrieb Nobbyaushb:

Ergänzend: ich hänge an den Shell-Befehl immer noch -AutoMapping $False dran und binde die Mailboxen manuell ein - geht schnell und die Nachteile werden vermieden

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.

Zitat

 

To save sent items in the sender's Sent Items folder, use this cmdlet:
Set-MailboxSentItemsConfiguration alias -SendAsItemsCopiedTo Sender -SendOnBehalfOfItemsCopiedTo Sender

 

To save sent items in the Sent Items folder of both the sender and the shared mailbox, use this cmdlet:
Set-MailboxSentItemsConfiguration alias -SendAsItemsCopiedTo SenderAndFrom -SendOnBehalfOfItemsCopiedTo SenderAndFrom

 

vor 30 Minuten schrieb RolfW:

Was noch zu beachten ist, sind die Gesendet Objekte, die setze ich dann immer auf "SenderandFrom" damit man auch im Postfach die Mails sieht.

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.

vor 16 Minuten schrieb RolfW:

Wie sieht das bei universalen Gruppen aus?

Zitat

Zitat

 

In der deutschen Windows-Oberfläche nennt sich dieser Gruppentyp “Universell”. Gruppen dieser Art können Mitglieder aus allen Domänen des Forests aufnehmen (aber nicht aus externen vertrauten Domänen!) und sind in allen Domänen des Forests sichtbar.

Damit eignet sich dieser Gruppentyp in Multi-Domänen-Forests dazu, Benutzer domänenübergreifend zusammenzufassen und ihnen in beliebigen Domänen des Forests Berechtigungen zu erteilen. Nun könnte man meinen, dieser Gruppentyp sei damit ja auch der flexibelste und deshalb nur noch mit dieser Sorte arbeiten. Davon ist aber abzuraten: Einerseits erzeugen diese Gruppen einen gewissen Overhead, denn im Unterschied zu den anderen Typen speichert Active Directory sie nicht innerhalb der Domäne, sondern im Global Catalog. Andererseits ist dieser Gruppentyp in großen Umgebungen mit mehr als einer Domäne schwer abzugrenzen – eben deshalb, weil er Mitglieder aus allen Domänen enthalten und gleichzeitig in allen Domänen Berechtigungen haben kann. Eine solche Gruppe zu verändern, ist daher immer ein planungs- und analyseintensiver Schritt.

 

Zitat

Zitat

1200 für die Verwaltungsinformation
+ 40 * Anzahl der Mitgliedschaften in Domainlokalen Gruppen
+ 40 * Anzahl der Mitgliedschaften in universellen Gruppen anderer Domains 
+ 40 * Anzahl der SIDs in der SIDHistory
+  8 * Anzahl der Mitgliedschaften in globalen Securitygruppen
+  8 * Anzahl der Mitgliedschaften in universellen Gruppen der eigenen Domain
=======================
Gesamtgröße des Tokens

vor 11 Minuten schrieb magheinz:

Im übrigen ist das ein Grund warum man AGDLP macht. Im Forst sind nur die Gruppen der lokalen Domäne im Token. Würde man die Permission über globale Gruppen verwalten wären immer alle im token.

 

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?

vor 8 Minuten schrieb Nobbyaushb:

Keiner unserer Server ist per RDP erreichbar... - außer natürlich die TS

Administriert ihr dann nur über VMware Console?

vor 14 Minuten schrieb Dukel:

Habe eben nachgeschaut. Das ist korrekt. Durch die Users Gruppe dürfen sich Domain User an Servern anmelden. Hier geht es aber um das Lokale anmelden per Bildschirm/Tastatur bzw. VmWare /Hyper-V Konsole. Auf beides sollte kein User Zugriff haben. Außerdem hat der Benutzer auch nicht mehr Rechte auf einem Server oder in einer Applikation, nur weil er sich lokal einloggen darf.

Du kannst es entfernen, sollte aber nicht so kritisch sein

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.

vor 17 Minuten schrieb Dukel:

Wichtig! Nicht nur das Lokal anmelden, sondern auch per RDP, sollte beidem ganzen Thema betrachtet werden.

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!

vor 6 Minuten schrieb Dukel:

Meines Wissens ist der Default, dass sich nur Administratoren auf Servern einloggen dürfen. Wenn das bei dir anders ist, ist das selbst gemacht und sollte weg.

 

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...

vor 23 Minuten schrieb magheinz:

Ansonsten: niemals manuel eintragen, immer per GPO/GPP. 

Ich würde mich da streng an AGDLP halten, also eine Domainlokale Serveradmin-Gruppe pro Server. Diese dann per GPP den lokalen Admins hinzufügen. Dann eine globale Gruppe Serveradmins wenn jeder admin jeden Server administrieren soll, ansonsten halt mehrere. Dann diese bei den jeweiligen domain lokalen zum Mitglied machen. 

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. 

vor 25 Minuten schrieb magheinz:

Was sind denn für dich hier die jump-server? 

Wir hier haben z. B. Einen Terminalserver auf dem alle admin tools etc installiert sind. Von dem aus kommt man in jedes VLAN. 

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.

vor 32 Minuten schrieb Weingeist:

Solche Konzepte haben mir der Komplexität einer Umgebung erstmal nichts direkt zu tun. Im Gegenteil, gerade auch in kleinen Umgebungen sind Abschottungen genauso wichtig, weil da nicht immer ein Team von Admins vor Ort ist und sofort reagieren kann. Auch die Firewalls sind selten so komplex, alleine schon aus Kostengründen.

Im Grunde ist es eine Massnahme um die Hürden einer allfälligen Infektion mit Schadsoftware möglichst hoch zu halten. Sprich kommt etwas über einen Client rein, soll nicht gleich die ganze Umgebung kompromittiert sein nur weil die Anmeldedaten der Admins im Cache liegen und diese auch für den Server gelten.

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.

Hi Martin,

diesen Beitrag habe ich mir schon mehrmals durchgelesen. Es klingt logisch aber auch sehr komplex. Ich bin am grübeln ob das für unsere Umgebung wirklich notwendig ist.

Wir sind nur 3 Admins und 2 davon sind für die Server zuständig. Das heißt, es gibt nicht so viele komplexe Berechtigungen - da wir beide eigentlich für jeden Server und jede Anwendung zuständig sind.

Wir werden zwar in den nächsten Wochen/Monaten noch etwas wachen - aber auch nur um 2 Mitarbeiter (1 Azubi, 1 weiterer Admin). Deswegen möchte ich die Grundlegende Sturktur und Verwaltung der Admin Accounts verbessern, aber die Frage ist wo zieht man die Grenze bei unserer Größe.

Ich hätte auch nicht mit Restricted Groups gearbeitet und auch keine direkten Zuweisungen von Usern gemacht - vielleicht habe ich mich da falsch ausgedrückt.

Die neuen Admin Accounts (Server Admins und Client Admins) hätte ich per GPO den lokalen Administrator Gruppe hinzugefügt.- > Group Policy Preferences Lokale Benutzer und Gruppen

Beispiel:

AD User "Admin-srv-user1" kommt in die Domain Global Group "Server-Admins". Diese wird dann per GPP Lokale Benutzer und Gruppen in die jeweiligen lokalen Administrator Gruppen der Server eingetragen.

Das gleiche gilt dann für die Client Admins auf den PCs

Nun ging es mir ja noch darum, den Domänen Benutzern das anmelden auf den Servern zu verbieten (wenn das Sinn macht). Dazu hätte ich über eine GPO - Benutzerrechte zuweisen den Domänen Benutzern das lokale anmelden verboten.

Das mache ich gerne.

Bin gerade dabei die Konfig der Server genauer zu prüfen und mit dem Tool Hyena (Danke ans Forum für den Tip) die Dienste und Aufgaben zu prüfen (welche Accounts hier verwendet wurden).

Dabei ist mir jetzt aufgefallen, dass unsere Server die Anmeldung von Domänen Benutzern zulassen (Standardeinstellung). Unsere Server sind alle virtualisiert und ein Zugriff ist nur per RDP oder VMWare Console möglich. Hier sind natürlich die Domänen Benutzer in keiner Weise berechtigt.

Wenn ich die bisherige Diskussion aber richtig verstehe, nehme ich die Domänen Benutzer hier raus bzw. konfiguriere es wie folgt.

Über eine GPO -> Zuweisen von Benutzerrechten -> "Lokal anmelden zulassen" -> hier packe ich meine AD "Server Administratoren" Gruppe rein, die "lokale Administratoren" Gruppe und sonstige Gruppen die sich anmelden dürfen (z.B Applikations bezogenen Gruppen).

Über eine GPO -> Zuweisen von Benutzerrechten -> "Lokal anmelden verweigern" könnte ich noch den Domänen Admins das anmelden verbieten

Ebenso füge ich dann per GPO -> Einstellungen -> Lokale Benutzer und Gruppen die gewünschten Gruppen der lokalen Administratoren Gruppe hinzu.

Somit wären die Domänen Benutzer und sonstige Benutzer raus und dieser Punkt schon mal sauber konfiguriert.

Einen großen Dank an euch alle - es hilft mir sehr einen guten Weg für die Verwaltung der Admin Accounts zu finden.

vor 17 Stunden schrieb RolfW:

Kannst du mehr über Jump Server sagen? Hatte ich noch nicht.

Zitat von hier

Zitat

Jump server

Administrative "Jump Server" architectures set up a small number administrative console servers and restrict personnel to using them for administrative tasks. This is typically based on remote desktop services, a 3rd-party presentation virtualization solution, or a Virtual Desktop Infrastructure (VDI) technology.

vor 11 Stunden schrieb daabm:

Aufpassen, daß es nicht zu kompliziert wird, sonst scheiterst Du an der Akzeptanz... Ein Anwendungs-Admin braucht auf den zugehörigen Servern nur RDP/Interactive, da braucht es keinen extra User. Und wenn da nur die eine Anwendung läuft, dann schadet lokaler Admin auch nicht wirklich. Wenn die Anwendung nicht ohnehin remote zu administrieren ist.

Da hast du Recht, ich möchte es auch gar nicht zu kompliziert machen und erstmal muss dieses sinnlose verwenden des Domänen Admins für Arbeiten auf dem Server verhindert werden. Der erste Schritt mit den getrennten Admin Accounts ist im moment am wichtigsten. Alles andere müssen wir dann langsam entwickeln und uns eine eigene passende Struktur überlegen.

Aber jetzt habe ich erstmal eine gute Übersicht, was es alles zu berücksichtigen gibt und eben auch verschiedene Ideen wie man was umsetzen kann. Die Details und alles andere müssen wir dann für uns intern klären.

Danke euch beiden.

Wir werden dies dann auch so umsetzen. Server Admin Accounts für jeden IT Mitarbeiter, diese Accounts werden dann Gruppen zugeordnet und diese Gruppen wiederum den entsprechenden Servern/Applikationen.

Die Workstation Admins sind dann separate Accounts, Domänen Admins gibt es nur für spezielle Mitarbeiter und werden auch nur für solche Tätigkeiten genutzt. Anmelden von Domänen Admins an PCs wird unterbunden. Lokale Admin Passwörter werden über LAPS oder AdmPwd.E gemanaged.

Als letzten Schritt werden wir dann noch die Server und Clients trennen (VLAN) und entsprechende Jump Server einführen. 

Da wir demnächst sowieso unsere komplette Firewall austauschen, werden wir das dort gleich berücksichtigen.

Es gibt viel zu tun, aber es wird Zeit diese sehr gewachsene (und auch unsichere) Struktur endlich aufzuräumen 

Also für mich bedeutet Service Account = Account unter dem ein Dienst ausgeführt wird. Davon spreche ich nicht.

Ich meine Admin Accounts für bestimmte Applikationen z.b. um mich am vmware vsphere Web Client anmelden zu können oder in der Veeam Konsole etwas durchführen zu können.

vor 4 Minuten schrieb Dukel:

Teilweise bekommen (via Gruppen geregelt) dann bestimmte Server Admin Accounts nur auf bestimmten Servern oder in bestimmten Applikationen rechte.

Z.b. User1 hat einen Server-Admin und bekommt auf Server1,2 und 3 Adminrechte und für die Applikationen1,2 und 3 Adminrechte. Und User2 hat einen Server-Admin und bekommt auf Server2,3 und 4 Adminrechte und für die Applikationen2,3 und 4.

Das würde bedeuten, User1 kann sich mit User1 am Server 1, 2 und 3 anmelden und kann dort auch die Applikationen mit dem Benutzer User1 nutzen. 

Das würde bedeuten, er kann mit seinem "Server Admin" sowohl auf den Server als auch auf die Applikationen zugreifen, richtig?

Die Methode von RolfW wäre, User1 kann sich mit dem Benutzernamen User1 am Server 1, 2 und 3 anmelden. Auf die Applikationen kann er dann aber mit dem User  App1-User1 auf Server1, App2-User1 auf Server2 und App3-User1 auf Server3 zugreifen. 

Das würde bedeuten es gibt einen Server Admin Account, mit diesem kommt er auf die ausgwählten Server. Für jede Applikation gibt es aber dann noch mal einen extra Admin Account.

Das wäre natürlich schon eine recht komplexe Vergabe von Admin Accounts.

Verstehe ich das richtig?

Eine Frage stellt sich mir noch, vielleicht habt ihr hier auch noch eine Idee.

Wir erstellen im 1. Schritt nun für die Admins erstmal 4 Accounts ( normaler User Account, Workstation Admin, Server Admin und für ausgewählte Kollegen einen Domain Admin).

Nun gibt es ja aber auch Systeme die z.B. über eine Webseite oder eine eigene Konsole administriert werden. Hier werden dann ja auch Berechtigungen delegiert (z.B. vmware vSphere Client oder Veeam).

Nun kann ich den normalen Benutzer oder den Server Admin Account dort verwenden. Was würde aus eurer Sicht mehr Sinn ergeben?

Ich hätte jetzt gesagt, alle administrativen Tools werden dann auch über den Server Admin Account genutzt.

Oder sollte man dann für jede Applikation noch mal einen eigenen AD User erstellen, der dann die Rechte in der Applikation erhält? Ich glaube die Zeit habe ich im Moment nicht und das wäre dann der nächste oder übernächste Schritt :)

Was wären eure Ideen dazu?

Danke euch - ich sehe schon, dass kann ein großes Projekt werden :)

Ich werde jetzt erstmal die Verwaltung der Admin Accounts anpassen. Wir werden pro Admin 4 Accounts verwenden (wie von Dukel geschrieben). Das sollte schon mal eine deutliche Verbesserung sein.

Dann werden wir die Nutzung des Domain Admins unterbinden und schauen ob wir das über GPOs geregelt bekommen (https://evilgpo.blogspot.com/2015/04/wer-bin-ich-und-was-darf-ich.html )

Die lokalen Admin Passwörter werden wir dann über LAPS oder AdmPwd.E verwalten.

Danach werde ich mir Gedanken über die PAW/Jump Server machen und prüfen ob und wie wir unsere VLANs anpassen/erweitern müssen. Da bin ich dann mal etwas beschäftigt - aber das sehe ich als wichtig an. Vor allem da wir eher noch mehr IT Mitarbeiter werden.

Vielen Dank für eure schnelle Hilfe und die Tips.

OK, soweit verstanden. Damit im "Schadensfall" nur die Clients betroffen sind und nicht die Server, sollte diese Trennung stattfinden.

Aber was ist dann mit meinem PC. Ist es in Ordnung z.B. AD Snap-ins vom RSAT auf meinem Client auszuführen ("Als Administrator ausführen" und dann as entsprechenden Admin Server Login zu verwenden) oder sollte man lieber direkt auf den Servern per RDP arbeiten?