Verwaltung der Admin Accounts in der IT Abteilung

[magheinz 110]

Bei uns ist RDP für die jeweiligen Admins offen.

Die VMwareconsole ist aber natürlich auch möglich und die Windowsrollen werden per RSAT vom admin-server aus  verwaltet.

[Dukel 451]

Das wird aktuell zu sehr OT. Ob man per Dameware, RDP oder sonst wie administriert ändert nichts an Zonenkonzept und Adminkonzept.

[Nobbyaushb 1.464]

Stimmt. Back to Toppic, sorry

[v-rtc 88]

Da wäre mal ein Stammtisch interessant :)

[phatair 39]

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?

[magheinz 110]

Man kann die Token-max-size vergrößern. 

Und ja, mit jeder Gruppemitgliedschaft wird der token größer und erreicht irgendwann das maximum. 

Das hat mit der Anzahl der Mitarbeiter nichts zu tun. 

[MurdocX 949]

Bei Server 2012 ist die Standardeinstellung für MaxTokenSize bei 48.000 Bytes.

[phatair 39]

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.

[magheinz 110]

richtig, das ist pro User. Wird der token zu groß scheitert die Anmeldung. Im eventlog steht dann glaube ich sowas wie: "zu viele Gruppenmitgliedschaften".

Man kann das einfach ausrechnen. In der KB ist irgendwo eine Formel. Oder auch hier: https://www.msxfaq.de/windows/kerberos/kerberosticketsize.htm#groesse_berechnen

 

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.

 

[phatair 39]

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.

[magheinz 110]

Jap, ich wollte es nur als Info ergänzen. 

Die meisten Konzepte von MS sind halt für riesige Umgebungen gedacht. Wenn man die dann auf KMUs runterbricht muss man halt schauen ob man etwas anpassen will. 

[v-rtc 88]

Wie sieht das bei universalen Gruppen aus?

[phatair 39]

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

 

[phatair 39]

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.

[magheinz 110]

der zentrale Adminserver hat vor allem einen Bequemlichkeitsvorteil. Ich muss nichts mehr lokal installieren und habe immer alles bereit. Egal ob ich am Arbeitsplatz sitze, ein notebook nutze oder im schlimmsten Fall mit dem Smartphone unterwegs bin.

In den meisten admin-tools muss man sich ja eh noch mal anmelden und man kann die Administration auf den Zielgeräten auf die eine IP einschränken, so diese das können.