phatair

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? 

vor 2 Minuten schrieb Dukel:

Machen die Administratoren alles (Clients, Server und AD)?

Dann gibt es vier Accounts für jeden Admin (mit Unterschiedlichen Passwörtern!). Einen normalen User, einen AD Admin, einen Server Admin und einen Client Admin.

Ja, wir sind ein kleines IT Team (3 Leute - 50 Server - 200 AD User)

Wir haben schon eine grobe Aufteilung, aber Clients macht bei uns jeder. Auf einige Server müssen wir alle mal schauen, andere wiederum nur ausgewählte Kollegen. Die AD macht eigentlich nur einer.

Das dachte ich mir dann schon so, klingt am vernünftigsten aber natürlich auch am "Aufwendigsten". Aber Sicherheit geht immer etwas zu lasten von Komfort und hier muss dann jeder wohl seine Prioritäten legen.

vor 2 Minuten schrieb Dukel:

Was für Programme waren denn auf den Servern offen? Die Verwaltungstools der Dienste?

Unterschiedlich - die AD Verwaltung (DNS, User, Computer, DHCP, usw.) läuft eigentlich über die Admin PCs. Dort sind die RSAT Tools installiert und wir öffnen diese mit unserem persönlichen Admin um die Arbeiten durchzuführen. Das müsste so ja ok sein, oder ist es besser sich mit seinem persönlichen Server Admin per RDP auf den jeweiligen Server zu schalten und dort die Arbeiten auszuführen?

Auf den Servern waren dann meistens Anwendungen offen, für die es keine "Remote Verwaltungskonsolen" gab und man eben direkt auf den Server arbeiten musste. Nichts zwingendes und eben nur Komfort. In Zukunft müsste man das eben erst noch öffnen, wenn man sich mit seinem persönlichen Server Admin Account angemeldet hat.

Ich tendiere jetzt zu folgender Lösung

3 Accounts - normaler User, einen AD Admin und einen Server/Client Admin. Bin noch etwas unentschlossen ob wir wirklich die harte Grenze zwischen Server und Clients ziehen müssen.

Ich muss mir auch noch den Link von testperson anschauen (

)

vor 4 Minuten schrieb NilsK:

keine Sammel-Accounts für die Administration. Niemals. Auch keine Sammel-Accounts für Dienste. Alles, was hohe Berechtigungen braucht, wird mit personalisierten bzw. dedizierten Accounts gemacht. Diese Accounts sind nur für die administrative Arbeit bzw. zur Anmeldung von Diensten, für nichts anderes. Jeder Admin hat separat einen normalen User-Account für die alltägliche nicht-administrative Arbeit.

So machen wir das auch bei den Clients, nur muss das jetzt noch auf die Server ausgeweitet werden. 

Dienste sind auch alle mit separaten Accounts versehen (beginnen z.B. immer mit svc-<name des dienstes>

vor 4 Minuten schrieb NilsK:

Domänen-Admins nur zum Verwalten der Domäne, also nur in Ausnahmefällen. Auch die normale User-Administration oder das Aufnehmen von Rechnern ins AD braucht keine Dom-Admin-Rechte. 

Wir haben die personalisierten Admin Accounts berechtigt bestimmte Dinge in den ausgewählten OUs zu machen (z.B. Objekte zu löschen oder PCs aufzunehmen). Das müsste hoffentlich passen.

vor 22 Minuten schrieb testperson:

schau dir das (und den Link dort) mal an: https://www.mcseboard.de/topic/214871-admin-für-software-installation-client-pcs/?do=findComment&comment=1371787

In die entsprechenden Gruppen packst du dann die personalisiertern Admin (oder Sammel) Accounts.

Das klingt sehr interessant - werde ich mir mal genauer anschauen. Danke für den Tip!

vor 23 Minuten schrieb testperson:

P.S.: LAPS kann man machen, muss man aber nicht. LAPS speichert die Kennwörter halt im Klartext im AD. Ggfs. ist AdmPwd.E (https://www.admpwd.com/) eine Alternative.

Hm...heißt das, jeder der lesenden Zugriff auf das AD hat kann die Passwörter auslesen? AdmPwd.E klingt auch interessant und ist preislich auch fair. Werde ich mir auch mal anschauen. Das Programm scheint sich in die AD einzuklinken - ändert das auch was am AD Schema oder kann das Probleme beim AD Upgrade machen?

vor 21 Minuten schrieb RolfW:

Ihr habt nur ein AD und eine Firma?

 

Ja, wir haben nur eine AD/Domäne.

vor 25 Minuten schrieb RolfW:

Ich würde für jeden Admin ein persönliches Konto erstellen und für die Workstation einen generellen  Admin, der lokal Admin ist, aber in der Domäne nur Benutzer. Wenn Du dann noch möchtest, könntest Du für die DomAdmins noch einzelne persönliche Konten erstellen.

 

So ähnlich haben wir es eben für die PCs gemacht. Jeder Admin hat einen normalen Account und einen Account der auf den PCs in der lokalen Admin Gruppe ist. Einen generellen Account haben wir nicht, damit es besser nachvollziehbar ist, wer was gemacht hat. Die Frage ist, ob dann für ausgewählte Kollegen ein persönlicher Domänen Admin Account erstellt wird oder wir hier den Standard Domänen Admin verwenden.

Guten Morgen,

ich möchte bei uns in der Firma die Verwaltung der Admin Accounts überarbeiten.

Im Moment arbeitet die IT Abteilung mit 2 Accounts ( einen normalen Benutzer Account für die tägliche Arbeit und einen Admin Account der nur genutzt wird, wenn erhöhte Berechtigungen verwendet werden).

Beides sind AD Accounts.

Wir haben uns bei der Verwaltung der Admin Accounts bei den PCs an dem Beitrag vom Mark orientiert (https://www.gruppenrichtlinien.de/artikel/verwaltung-der-lokalen-administratoren/)

Auf allen PCs werden per GPO die Mitglieder aus der lokalen Administratoren Gruppe geschmissen und eine "Workstation-Admin" Gruppe hinzugefügt. In dieser sind dann die Admin Accounts der IT Abteilung.

Somit können wir mit unseren Admin Accounts alles an den PCs machen, benötigen keinen Domänen Admin und es ist sichergestellt das auch sonst kein anderer Admin vorhanden ist.

Auf den Servern sieht es im Moment noch anders aus. Hier arbeiten wir immer mit dem Domänen Admin Account. Das würde ich aber gerne ändern, da auch hier keine Notwendigkeit besteht.

Nun könnte ich das genau so durchführen. Wir fügen auf den Servern eine weitere Gruppe (z.B. Server-Admins) der Administratoren Gruppe hinzu. Alle darin enthaltenen Admins können auf den Servern arbeiten.

Bisher war es oft so, dass bestimmte Programme offen waren und jeder Admin diese gleich nutzen konnte. Das würde dann natürlich wegfallen, da jeder mit seinem eigenen Account arbeiten würde.

Die andere Lösung wäre, man erstellt z.B. einen Server Admin Account und dieser wird auf allen Servern in die Administratoren Gruppe aufgenommen und man arbeitet mit diesem.

Die lokalen Administratoren Accounts möchte ich über Microsoft LAPS verwalten. Das Passwort des Domänen Admin Accounts wird dann nach der Änderung geändert und nur noch für notwendige Tätigkeiten genutzt (von ausgewählten IT Kollegen).

Wie macht ihr das den mit den Servern und den Admin Accounts?

- persönliche Admin Accounts?

- einheitlicher Admin Account?

- lokalen Admin Account?

- andere Lösung?

Vielen Dank schon mal für eure Gedanken.

Gruß