Namenskonventionen sind schwer. Jedes Mal rate ich mir einen Ast, wie ich Dinge im Windows-Netzwerk am besten benennen soll. Vor allem wegen den Zeichen die einem vorgegeben werden. Im 21. Jahrhundert in einem Netzwerk auf 2016/2019 Ebene sollte es da eigentlich keine großen Beschränkungen mehr geben. So kann ein gMSA nur 15 Zeichen (plus Dollar-Zeichen) haben. Das macht eine sinnvolle Trennung zwischen mehreren Standorten/Sprachen und/oder Servern ein wenig schwierig.
gMSA
Die Grouped Managed Service Accounts sind besonders für Dienste und Tasks/Aufgaben geeignet und sollten auch verwendet werden. Ein gMSA hat nur speziellen Zugriff, den man eventuell auch dafür konfigurieren muss. Ein Passwort wird nicht vergeben, dennoch wird eines zwischen dem Account und der Windows Domäne ausgetauscht und auch regelmäßig erneuert. Der User bekommt davon nichts mit. Genau deshalb SOLLTE ER VERWENDET WERDEN!
Es gibt viele Möglichkeiten gMSA’s zu verwenden, daher ist eine Namenskonvention aus 15 Zeichen auch etwas schwer. Standorte, Sprachen, Verwendungszweck etc. Es sollte ja trotzdem irgendwie erkennbar sein, wofür der gMSA verwendet wird.
Hier ein Beispiel vom goSecurity Blog:
| Name (max. 15 Zeichen) | Dienst oder Task | Beschreibung |
|---|---|---|
| SA_T_B_SRV-XY | Scheduled Task | Backup Skript auf dem Server SRV-XY |
| SA_D_SQL_SRV_YX | Dienst | Dienst für SQL_Server auf SRV-YX |
Da wir leider auf mehreren Standorten ähnliche Servernamen verwenden, ist dies ein wenig schwierig, da ich entweder den gleichen gMSA verwenden müsste oder den Standort irgendwie mit einfließen lassen muss. Jetzt könnte ich gMSA’s auch einfach durchnummerieren, dann müsste ich aber behalten wofür ein gMSA eingerichtet wurde.
Erste Versuche liefen also hier hin:
SA_T_PSR_FILE (Service Account, Task, PowerShell Report, FileServer)
SA_S_SQL_MAIN (Service Account, Service, SQL, Haupt-Instanz)
Momentan versuche ich es daher aus genannten Gründen wie folgt; nicht perfekt, läuft aber:
SASD_SQL01_MAIN (Service, Deutschland, SQLServer01, Default Instanz)
SASS_SQL01_MAIN (Service, Schweden, SQLServer01, Default Instanz)
SATD_PSR_FILE (Task, Deutschland, PowerShell Report, FileServer)
SA = Service Account. MAIN, weil DEFAULT/STANDARD wäre zu lange.
Zum Testen auf den Rechnern: Test-AdServiceAccount -Identity „SA-AccountName“. Damit könnte man die Server durchschleifen und testen, ob ein SA wieder verwendet wird/wurde. Natürlich sollte ein nicht verwendeter gMSA sofort wieder gelöscht/deinstalliert werden, damit solche “Leichen” gar nicht erst auftreten.
SQL Instanzen, SQL Alias, DNS SQL Alias
Instanzen kann man kaum eine Namenskonvention erzwingen, wenn man externe Häuser/Software mit im Boot hat. Namen von Instanzen sollten ein Schema haben, bisher habe ich dafür keines. Dies im Nachhinein zu Ändern ziehe ich aber auch nicht in Betracht. Wenn jemand was sinnvolles in mehreren Sprachen hat, darf er sich gerne melden.
Den SQL Alias richten wir ein, damit wir die Datenbank einfacher umziehen können. Wenn dann noch ein DNS Alias (CNAME) hinzukommt, kann man das ganze Konstrukt über DNSAlias\SQLAlias erreichen. Einzig für mich sichtbare Problem: Wenn der DNS wegfällt, kann niemand den Server erreichen.
DNS Alias Beispiele:
SQL_SharepointFarmS01.PROD.SQL
SQL_SharepointFarmS01.ENTW.SQL
SQL_ExchangeFarm01.PROD.SQL
SQL Alias Beispiele (cliconfg in x64 und x86):
SQL_Default
SQL_Sharepoint
Kombiniert:
SQL_SharepointFarmS01.PROD.SQL\SQL_Sharepoint
AD Gruppen, SQL Instanz Berechtigungen (64 Zeichen)
Hier komme ich bei meiner letzten Konvention etwas an meine Grenzen, Gruppen sind nämlich auf 64 Zeichen begrenzt.
SG-SQL-DE-SQLSRV3-MSSQLSERVER-Database-SharePoint-Administrator (63 Zeichen)
Erklärung:
SG = Security Global
MSSQLSERVER = Instanz-Name, Haupt-Instanz
Database-SharePoint = Damit man sieht, dass es keine Berechtigung für die SharePoint Instanz ist
Administrator = Obvious, aber es ist kein Service Account, nur ein Administrator
Der SQL sa-Account sollte übrigens nicht verwendet werden. Am besten wird die Instanz schon gar nicht mit einem solchen installiert. Dieser kann im Nachhinein aber auch deaktiviert werden.
Wenn ich versuche das etwas kürzer zu halten, sähe es in etwa so aus:
SG-SQL-DE-SQL1-MSSQLSERVER-Public
SG-SQL-DE-SQL3-MSSQLSERVER-Public
SG-SQLDB-DE-SharePoint-Reader
SG-SQLDB-DE-SharePoint-User
SG-SQLDB-DE-SharePoint-Administrator
So wäre es nicht ganz so lange und könnte leichter erweitert werden. SQLDB wären dann direkt die Datenbanken, ohne DB wären es die Instanzen.
SQL Cluster Benennung (erste ihrer Art bei uns)
Maschinen:
DE-VS-SQL-PC01-01 (17 Zeichen)
DE-VS-SQL-PC01-02
DE-VS-SQLC01P01 (Virtuell, Server, SQL Cluster)
DE-VS-SQLC01P02
DE-VS-SQLC01D01 (Development)
Hier sieht man eine mögliche Herangehensweise. Man könnte ein zweites Cluster zu Test-Zwecken aufbauen. Der Unterschied hier ist der Buchstabe D/P. Dies steht für Development/Produktiv. So könnte man das gleiche für die Anwendungsserver machen und entsprechend Anwendungen und Zugriffe besser/schneller testen.
Notiz: Mit den 17 Zeichen habe ich mich natürlich ein wenig verrannt. Wichtig ist dabei natürlich auch, dass jeder eigene Präferenzen hat.
Instanzen: Deutschland, Virtuell, Windows, SQL, Produktiv, Cluster 01, Maschine 1 oder 2
Ist aber noch nicht fertig, ich teste das demnächst mit einem Kollegen.
Mailverteilergruppen
Damit man die Mailverteiler schneller finden kann, sollten diese auch eine Namenskonvention erfüllen. Da Verteilergruppen als Distribution Groups eingerichtet werden, bietet sich die Abkürzung DG dafür an.
DG-MV-DE-ITOperations
DG-MV-DE-ITDevelopment
Relativ einfach hier die Vergabe nach: Gruppen-Typ – Mail-Verteiler – Deutschland – Name des Verteilers.
(Hatte noch einen Gedanken. Ist verloren gegangen)…
Lokale Berechtigungsgruppen (Rechtevergabe, Rollen-Konzepte, File-Server)
Lokale Berechtigungsgruppen lassen sich durch Security Local (also SL) erklären. Diese werden verwendet um in einer relativ flachen Ordner-Hierarchie Berechtigungen im Datei-System zu vergeben. Das sollte vor allem verwendet werden um Ordner-Leichen im System zu vermeiden.
SL-DE-FILE-Daten-List
SL-DE-FILE-Daten-EDV-RW
SL-DE-FILE-Daten-EDV-List
Dazu sollte man dann auch SG-Gruppen anlegen, die man dann in die SL-Gruppen packt. Damit niemand direkten Zugriff auf etwas hat. Beispiele dafür:
SG-EDV-DE-All
SG-EDV-DE-Operating
SG-EDV-DE-Development
Server und Rechner-Namen
Servernamen und Rechnernamen können eine ähnliche Namenskonvention haben. Ich habe mir dabei mal das folgende überlegt, kommt aber immer auf die jeweilige Situation an:
| Abkürzung | Bezeichnung |
|---|---|
| C | Client |
| S | Server |
| L | Linux oder Laptop |
| LC | Laptop: Client |
| F | Firewall |
| P | Printer/Drucker |
| M | Mobile Geräte |
| V | VM Ware VM |
| VC | Virtuell: Client |
| VS | Virtuell: Server |
| W | Workstation oder Windows |
| WC | Workstation: Client |
| T | VOIP Telefon |
| P | Physikalisch |
| MX/EXC | Exchange |
| H | Hyper-V VM |
| X | Xen VM |
| A | Appliance |
| C | Cluster |
DE-VL-<NAME>
DE-VC-<NAME>
DE-VS-<NAME>
DE-H-<NAME>
DE-PC-IT01/H8V01
DE-VS-MX01
DE-CL-SQL01 (SQL Cluster)
SE-PS-FL01 (File-Server)
Deutschland, Virtuell, Linux, Name.
Aber: DNS = 63 Zeichen, NetBIOS = 15 Zeichen.
Das sollte man beachten, so wird in manchen Systemen der Name abgehackt. Das Gilt auch für die Cluster oben, die ich entsprechend geändert habe.
Wichtig für alles!
- Das Active Directory ist die globale Nutzerverwaltung des Unternehmens!!!
- KEINE UMLAUTE!
- KEINE USER DIREKT WO REINPACKEN!
- Versteckte Freigaben mit SL sind mit einem Dollar gekennzeichnet.