phatair

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.

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. Zitat von hier 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. 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?

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

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

Das klingt sehr interessant - werde ich mir mal genauer anschauen. Danke für den Tip! 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? Ja, wir haben nur eine AD/Domäne. 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ß

Hat wunderbar funktioniert. Danke! Wenn man keine eigene CA im LAN hat, ist das wahrscheinlich die einzige Möglichkeit interne Web Verbindungen mit einem Zertifikat zu versehen. Macht es dann Sinn ein Wildcard Zertifikat für lokale Anwendungen zu erstellen oder lasst ihr diese einfach über SelfSigned Zertifikate laufen?

Hallo zusammen, wir haben 2 IIS Server bei uns im LAN laufen. Diese stellen Webdienste zur Verfügung, die ich gerne per SSL absichern möchte. Wir haben noch keine eigene interne CA und ich sehe in den nächsten Monaten auch keine Kapazität das umzusetzen. Meine Idee wäre jetzt gewesen, über eine CA wie Geotrust ein SAN Zertifikat zu kaufen. Wir haben eine öffentliche Homepage und diese Domain ist identisch zu unserer internen Domäne (öffentlich domain.de, intern intern.domain.de). Wenn ich ein SAN Zertifikat auf domain.de ausstelle, kann ich ja dieses Zertifikat für unseren internen IIS verwenden (z.B. server.intern.domain.de). Seht ihr hier irgendwelche Probleme? Ich habe auch mit dem Gedanken gespielt, das Ganze über Lets Encrypt zu machen. Aber hier komme ich nicht weiter und mir fehlt die Zeit mich weiter einzulesen. Wenn das wie oben beschrieben funktionieren sollte, wäre das der schnellere und einfachere Weg (natürlich auch kostenpflichtig). Vielen Dank schon mal für eure Hilfe. Gruß

Hi Dukel, danke für den Tip. Ich habe nun für die Default Web Site eine Umleitung festgelegt. Nach einigen Tests funktioniert es jetzt auch. Ich musste beim Umleitungsverhalten die Option "Anforderungen zu Inhalt in diesem Verzeichnis (nicht in Unterverzeichnissen) umleiten" aktivieren und den Statuscode auf Dauerhaft(301) setzen. Wenn ich den Haken bei der "Anforderungen zu Inhalt in diesem Verzeichnis (nicht in Unterverzeichnissen) umleiten" nicht setze wird die URL mehrmals hinten angehängt und nichts funktioniert. Aus http://Anwendung wird dann http://server/Anwendung/Anwendung/Anwendung/Anwendung usw. Wenn ich die Hilfe zu der Option richtig versehe, wird die Umleitung dann auch für jede Unterordner angewendet. Verstehe ich jetzt irgendwas komplett falsch oder kann man die Konfig so umsetzen?

Hi mwiederkehr, danke dir. Das Problem ist, die Webseite besteht aus 2 Anwendungspools - kann ich da genau so verfahren? Eine neue Webseite erstellen (die benenne ich wie ich möchte) Dieser Webseite beide Anwendungspools anhängen Bindung für die neue Webseite erstellen und den gewünschten Namen verwenden DNS Eintrag erstellen

Hallo zusammen, wir setzen bei uns im internen LAN einen Win Server 2012R2 mit IIS ein. Über diesen wird eine Software für die Fertigung realisiert. Nun ist diese Software im Moment über die URL http://<Server-Name/Anwendungsname> aufrufbar. Ich möchte aber die Webseite über http://<Anwendungsname> erreichbar machen. Irgendwie stehe ich auf dem Schlauch und ich bin auch kein großer IIS Experte. Ich komme einfach nicht dahinter wie ich das ändern kann (muss man hier über die Bindungen im IIS arbeiten?). Ein DNS Eintrag (CNAME) von <Anwendungsname> -> <IP des Servers> funktioniert nicht, da dort nur die IIS Seite erscheint. Ich muss die Webseite zwingenden über <Server-Name>/Anwendungsname aufrufen. Kann mir jemand einen Tipp geben, wie ich es hinbekommen? Im Moment sieht es so aus http://server/meine-Anwendung funktioniert. Ich möchte aber die Seite über http://meine-Anwendung aufrufen können. Vielen Dank schon mal. Gruß

Jep, also es ist so. Auch der Organisator sieht dann im Kalender des Raumpostfaches nur noch den Namen des Organisators. Den Betreff sieht man nur noch im eigenen Kalender. Macht so ja auch nur Sinn - trotzdem gut zu wissen :)