Active Directory Domain Services (AD DS) hat sich zu einer wunderbar zuverlässigen, hoch skalierbaren und fehlertoleranten Kernkomponente der IT-Infrastruktur Ihres Unternehmens entwickelt. Er funktioniert im Allgemeinen recht gut, ohne viel Aufmerksamkeit zu erfordern. Aber der AD DS-Administrator muss zusätzliche Arbeit investieren, um den Dienst von einem "täglich gut funktionierenden" Niveau auf ein "kugelsicheres, zuverlässiges Niveau zu bringen, wenn irgendeine ungewöhnliche Situation auftritt". Wenn diese ungewöhnliche Situation eintritt (und beachten Sie, dass ich "wenn" und nicht "falls" gesagt habe), gibt es eine Reihe von schlechten Konfigurationen und Praktiken, die Ihre AD DS-Domäne oder -Forest dem Risiko eines Datenverlusts, eines Ausfalls des Domänencontrollers (DC) oder sogar eines Ausfalls der Domäne oder des Forests aussetzen. Einige dieser Punkte mögen elementar erscheinen, aber Sie wären erstaunt, wenn Sie wüssten, wie verbreitet sie tatsächlich sind.
Verwandte Lektüre
Sie haben immer noch Windows Server 2003 DCs. Windows Server 2003 war zu seiner Zeit ein hervorragendes Betriebssystem... aber seine Zeit ist vorbei. Und was noch wichtiger ist: Es ist ein anfälliges, nicht zu patchendes Betriebssystem. Warum sollten Sie Ihr Unternehmen einem Risiko aussetzen? Gehen Sie weiter!
Alle Ihre DCs und Backups befinden sich an einem physischen Standort. Viele schlimme Dinge können an einem einzigen Standort passieren. Es ist gut, dass Sie mehr als einen DC haben, aber wenn sie sich alle im selben Rechenzentrum befinden, ist Ihr Forest immer noch anfällig für alles, was dieses Rechenzentrum ausschalten kann. Und das gilt natürlich auch für die Backups Ihres Forests. Es gibt keine Entschuldigung dafür, dass Sie nicht auf eine langsam voranschreitende Naturkatastrophe wie den Hurrikan Sandy an der Ostküste der USA vorbereitet sind. Aber ich habe auch schon erlebt, dass schnell um sich greifende Brände von außen erhebliche Schäden in einem Rechenzentrum verursacht haben und es zumindest nicht mehr verfügbar war, wenn es nicht sogar schwer beschädigt wurde. Die Moral von der Geschicht': Suchen Sie nach allen einzelnen Schwachstellen in Ihrer AD DS-Umgebung.
Der Papierkorb ist nicht aktiviert. Wir Admins haben alle aufgeatmet, als der Active Directory-Papierkorb in Windows Server 2008 R2 erstmals verfügbar wurde. Es hat jedoch eine Weile gedauert, bis dieses dringend benötigte Dienstprogramm zur Wiederherstellung von Objekten weithin genutzt wurde, da es eine Mindest-Forest-Funktionsstufe von Windows Server 2008 R2 erfordert. Und um das zu erreichen, müssen Sie alle Ihre DCs im Forest von älteren Versionen, insbesondere Windows Server 2003, aktualisieren. Da eine peinlich große Anzahl von Unternehmen ihre Windows Server 2003 DCs erst vor kurzem in den wohlverdienten Ruhestand geschickt hat, haben viele dieser Unternehmen auch den Papierkorb nicht aktiviert. Sie wissen, wer Sie sind; machen Sie sich an die Arbeit!
Sie halten sich nicht an die Best Practices für die Virtualisierung. Wenn Sie über DCs verfügen, die älter als Windows Server 2012 sind, verstehen sie sich nicht mit virtualisierten Umgebungen. Insbesondere erholen sie sich schlecht von Image-basierten Wiederherstellungen, bei denen die AD-Datenbank zu einem früheren Zeitpunkt ohne Trigger wiederhergestellt wurde. Stellen Sie sicher, dass Sie (und insbesondere Ihre Virtualisierungsadministratoren) die Best Practices von Microsoft für die Virtualisierung von AD DS befolgen.
Sie überwachen den Zustand von DC / DNS nicht regelmäßig. Eine der häufigsten Ursachen für Probleme mit Active Directory ist, dass sich niemand darum kümmert. Wenn Sie ein kleines Unternehmen sind, haben Sie vielleicht nicht die finanziellen Mittel für eine umfassende Überwachungslösung (obwohl es ausgezeichnete kostenlose Lösungen für kleine und mittlere Unternehmen wie SpiceWorks gibt). Alles, was Sie für eine grundlegende Überwachung brauchen, ist ein geplantes Skript, das DCDIAG /s: /E ausführt und es in eine Datei schreibt. Sehen Sie sich das jeden Morgen an. Wenn Sie z.B. Replikationsfehler feststellen, steht Ihnen das kostenlose Tool ADREPLSTATUS zur Verfügung.
Sie führen mehrere Rollen auf einem DC aus. Die Ausführung mehrerer Rollen auf einem DC gefährdet sowohl die Sicherheit als auch die Wiederherstellbarkeit. In einer Zeit, in der VMs leicht erstellt werden können, gibt es keinen Grund, keine eigenen Server für diese Aufgabe zu haben.
Sie ändern nie die Passwörter Ihrer Servicekonten. Dies ist ein schmutziges kleines Geheimnis, das die meisten IT-Abteilungen nicht zugeben wollen: Die Dienstkonten für viele ihrer wichtigen Infrastrukturdienste wurden seit Jahren nicht mehr aktualisiert. Vor Windows Server 2008 R2 bedeutete die Änderung des Kennworts eines Dienstkontos eine Ausfallzeit des Dienstes (z.B. einer SQL Server-Datenbank in einer mehrstufigen Geschäftsanwendung). Also wurde es nie geändert. In einem großen Unternehmen, das ich kenne, war das Passwort für das SMS-Dienstkonto mindestens drei Generationen von Systemadministratoren bekannt! Diese Schwachstelle wurde behoben, zunächst durch verwaltete Dienstkonten (MSAs) in Windows Server 2008 R2 und dann durch Gruppen-MSAs in Windows Server 2012. Haben Sie etwas dagegen unternommen?
Zu viele Administratoren. Das sollte Sie nachts wach halten. In vielen, vielen Unternehmen gibt es viel zu viele administrative Konten, weil sich derjenige, der den AD DS erstellt hat, nie die Zeit genommen hat, ein Modell für die delegierte Verwaltung zu entwickeln. Infolgedessen ist die Gewährung umfassender Rechte der schnellste Weg, ein Service-Ticket zu schließen. Das ist so ziemlich der schnellste Weg, der mir bekannt ist, um Ihr Unternehmen in die Schlagzeilen der Sicherheitsnachrichten des SC Magazine zu bringen oder noch schlimmer.
Machen Sie sich nichts vor. Wenn Sie eine dieser Bedingungen in Ihrer AD DS-Umgebung vorfinden, ist es Ihre Aufgabe, dem Management zu zeigen, warum deren Beseitigung für die Sicherheit Ihres Unternehmens Priorität haben muss.
