Tag Archives: AD

AzureAD Connect mit AD Service Account konfigurieren

Eines der ersten Aufgaben bei Hybrid Szenarien ist die Einrichtung von AzureAD Connect, um die Domänenidentitäten für Cloud Produkte bereitzustellen und Single-Sign-On zu ermöglichen.

In diesem kleinen HowTo möchte ich die Einrichtung anhand eines Gatewayservers erläutern, der zwischen dem eigentlichem DC und AzureAD die Identitäten synchronisiert.

Continue reading AzureAD Connect mit AD Service Account konfigurieren

#CIMLingen Recap

Bereits zum 13. Mal traf sich wieder die IT-Community zur alljährlichen CIM Konferenz im IT-Mekka Lingen. Nachdem ich bereits häufiger als Teilnehmer dabei war, konnte ich diesmal als Speaker einen kleinen Part übernehmen. Wie in den Jahren zuvor war die Konferenz voll ausgebucht und man sah, neben vielen bekannten Gesichtern, wieder viele neue.

#CIMLingen - IT Emsland Hallen
#CIMLingen – IT Emsland Hallen

Continue reading #CIMLingen Recap

Installation einer Offline Root CA

Aufgrund eines Fehlers und wahrscheinlich, weil ich nicht aufgepasst habe, habe ich bei der Migration von ESXi auf Hyper-V eine VM gelöscht, auf der meine Offline CA gespeichert war. Natürlich hatte ich ausgerechnet von diesem Zertifikat keine Datensicherung des privaten Schlüssels. Da in der Root CA auch noch ein Designfehler vorhanden war bzgl. der CRL, habe ich mich dazu entschieden, ein neues Root Zertifikat zu erstellen und die vorhandenen Designfehler zu korrigieren.

Da sieht man mal wieder, wie wichtig eine vernünftige Planung, auch in einer Testumgebung ist und das man natürlich die Datensicherung, gerade von kritischen Geräten nicht vergessen sollte 😉

Die Grundkonfiguration lässt sich mit folgenden Schritten schnell erledigen:

  1. 1. Standard-Installation von Windows Server 2008 R2 Enterprise Edition (Aktivierung auch gleich erledigen)
  2. Primären DNS-Suffix eintragen
  3. Unter C: ein Verzeichnis ADCS mit zwei Unterverzeichnissen “Database” und “Logs” anlegen
  4. Serverrolle Active Directory Zertifikatsdienste (Active Directory Certificate Services) installieren
  5. Bei Rollendiesten “Zertifizierungsstelle” auswählen
  6. Installationstyp “Eigenständig
  7. Zertifizierungsstellentyp “Stammzertifizierungsstelle
  8. Privater Schlüssel “Neuen privaten Schlüssel erstellen
  9. Kryptografiediensteanbieter: “RSA#Microsoft Key Storage Provider
    1. Schlüsselzeichenlänge “4096” (meine Empfehlung)
    2. Hashalgorithmus “SHA1
  10. Allgemeiner Name dieser Zertifizierungsstelle “F1NaLByte Root Authority” (denkt euch euren eigenen aus 😉 )
  11. Gültigkeitsdauer, da es sich um eine Offline Root CA handelt, kann diese zwischen 20 und 30 Jahren liegen. Wenn dieses Zertifikat kompromitiert werden sollte, verliert es ohnehin seine Gültigkeit.
  12. Zertifikatdatenbank, auswählen des im Vorfeld angelegenten Database-Verzeichnis für die Datenbank und Logs-Verzeichnis für die Logs.

Restliche Abfragen mit Standardwerten bestätigen. Daraufhin ist die Rolle installiert.

Konfiguration Sperrlistenverteilungspunkt

Nun müssen die Sperrlisteninformationen angepasst werden, dass ist wichtig! Hier sind zunächst alle Einträge mit “ldap” und “file” zu löschen, siehe Bild.

Das ganze sollte, nach geänderter Konfiguration, folgendermaßen aussehen:

Eintragen einer verfügbaren URL

Konfiguration Stelleninformationen

Zuletzt sollte ebenfalls der Zugriff auf die Stelleninformationen angepasst werden.

Konfiguration des Zugriffs auf die Stelleninformationen

Veröffentlichung der Sperrliste

Nächster Schritt ist die Konfiguration für das Veröffentlichungsintervall der Sperrliste. Da ich mit dieser Root CA nur meine Sub CA autorisiere, kann das Intervall ziemlich hoch eingestellt werden. Dies sollte aber im Einzelfall betrachtet werden. Bei Ausstellung von mehrere SubCA, sollte man das Intervall entsprechend der Anforderungen anpassen. In meinem Fall habe ich mich für 2 Jahre entschieden.

 

Konfiguration der Zertifikatssperrliste
Zertifikatssperrliste Konfiguration

Nun muss noch die Zertifikatssperrliste veröffentlicht werden: Veröffentlichung der Zertifikatssperrliste

Ist der “File-Pfad” nicht verändert worden, so befindet sich die veröffentlichte Sperrliste nun an folgendem Ort: “C:WindowsSystem32CertSrvCertEnroll

Speicherort der Sperrliste

Diese beiden Dateien können nun mit dem Root- Zertifikat exportiert werden. Die beiden Dateien müssen unter der konfigurierten URL auf dem Webserver zur Verfügung gestellt werden.

Damit ist die Konfiguration der Offline Root CA abgeschlossen und alle notwendigen Dateien stehen zur Verfügung. Der nächste Schritt wäre die Erstellung einer untergeordneten Online CA (SubCA) die, beispielsweise, im Active-Directory veröffentlicht ist.

Schemaerweiterung für SCCM2012

Die Installation der derzeitig, frei verfügbaren System Center Configuration Manager 2012 Beta 2 ist in Vorbereitung. Dazu wurde gerade eine Schemaerweiterung auf einem Domänencontroller erfolgreich abgeschlossen (Successfully extended the Active Directory schema).

Vorgehen erfolgte nach folgendem TechNet-Artikel: SCCM Schemaerweiterung TechNet

Nach der Schemaerweiterung muss noch der Container “System Management” angelegt werden, dieser wird durch die Schemaerweiterung nicht automatisch angelegt.

  • Zum Anlegen des Containers “System Management” ADSI-Edit mit Domänenrechten starten.
  • Rechtsklick Container “System” ->Neu->Objekt
  • Auswahl von “Container”
  • Name: System Management

Mit diesem Vorgehen ist der Container System Management nun vorhanden. Siehe auch TechNet-Artikel

Im nächsten Schritt muss dem Computerobjekt, auf dem der SCCM installiert ist, Schreibende Berechtigung auf den Container eingerichtet werden.

 

Computerkonten im AD und SMS 2003 löschen

Nachdem wir vor einigen Wochen eine Regeneration hatten, sind nahezu 80% der Clients ausgetauscht worden. Diese Clients besitzen ja nun noch Computerkonten in der AD und im SMS 2003.
Wie sollte es auch anders sein, kam natürlich vor kurzem eine Lizenzabfrage, der aktuellen Clients, so müssen wir nun adhoc die Computerkonten im AD und SMS bereinigen.

Active Directory
Im AD lässt sich dies relativ einfach realisieren (Vorraussetzungen: min. Windows Server 2003). Mit dem Tool dsquery lassen sich die inaktiven Computerkonten der vorgegebenen Wochen anzeigen. Die Ausgabe lässt sich auch zugleich als Eingabe für eine Löschung nutzen.
Beispiel: dsquery computer ou=Clients,DC=Test,DC=Domain -inactive 3 -limit 0 -s domaincontroller01 | dsrm -s domaincontroller01 -c
Im Beispiel werden alle Computerobjekte, die in den letzten 3 Wochen (-inactive 3) inaktiv waren, auf dem Domaincontroller01, aus der OU=Clients entfernt. Das Entfernen geschieht nach der Pipe (|) mit dsrm, der Parameter -c gibt an, dass auch bei Fehlern, der Vorgang fortgesetzt wird.
Zu beachten ist, dass die AD Computerobjekte als Tree ansieht, wenn an den entsprechenden Computerobjekten ein Drucker frei gegeben wurde. Hier muss der Parameter -subtree angehängt werden.

SMS 2003
Für den SMS 2003 bin ich über einen Interesannten Blogeintrag gestolpert:

Deleting computers from SMS 2003 (and perhaps SCCM 2007), with a script.


Das Script steht zum Download zur Verfügung und funktioniert einwandfrei.

Mit diesen beiden Tools konnte ich unsere Umgebung relativ schnell auf einen sauberen Stand bringen und wir waren in der Lage die Lizenzabfrage relativ schnell zu beantworten.

Gesamtstrukturebene auf 2003 heraufgestuft

Soeben wurde die Gesamtstrukturfunktionsebene auf 2003 heraufgestut. Bisher war nur die Domänenstrukturfunktionsebene heraufgestuft.  Vorgegangen wurde nach dem Microsoft KB-Artikel: http://support.microsoft.com/kb/322692/de

  • Klicken Sie in der Konsolenstruktur mit der rechten Maustaste auf Active Directory-Domänen und Vertrauensstellungen, und klicken Sie auf Gesamtstrukturfunktionsebene heraufstufen.
  • Klicken Sie unter Wählen Sie eine verfügbare Gesamtstrukturfunktionsebene auf Windows Server 2003 und dann auf Heraufstufen
  • Weitere Domaenencontroller Basis 2008 R2

    Es wird ein weiterer Domaenencontroller aufgesetzt um existierende Probleme mit Direct Access evtl. zu loesen. In dem Zuge wird die Domaene darauf vorbereitet, in dem auf dem DC2 ein adprep32 /forestprep und ein adprep32 /domainprep ausgefuehrt wird.

    Meldungen:

    Die aktuelle Schemaversion ist 44.
    Schema wird auf Version 47 aktualisiert.
    Verbindung mit “DC2” wird hergestellt

    Adprep hat die gesamtstrukturweiten Informationen erfolgreich aktualisiert.

    Adprep hat die domänenweiten Informationen erfolgreich aktualisiert.