Category Archives: Active Directory

Speaking at WVD Tech Fest 2021 about Azure Files

Due do the covid pandamy, many organizations in Germany are in a challenging phase as many employees need to be given the opportunity to work from home. Many companies have not yet made this option available to their employees, or only to a few. Microsoft has created a new option with Windows Virtual Desktop to give employees the ability to work from anywhere and the clients are always hosted in Azure and accessible via an app or browser.

I am very happy to have received an invitation to the WVD Tech Fest. The first conference only focusing on WVD with three parallel tracks around everything you need to know about Windows Virtual Desktop. The agenda is pretty complete and the organizers Simon Binder and Patrick Köhler are doing a great job. The conference will take place on 25/02/21 and is free. So take a look at the Website, plan your Agenda and grab your Ticket.

Azure Files is one of my favorite topics and due to many WVD projects in the past, I will address the question is Azure Files the optimal WVD profile store solution. And I can say: it depends – but you will learn more in my session on Thursday between 10:50 – 11:20 AM 🙂

Take this oppurtunity to learn more about Windows Virtual Desktop and hopefully this can be a solution for your organization to enable more people to work from anywhere and get everyone safely through these challenging time. I hope to see many of you there 🙂

Azure Files enabled AD DS SMB authentication Best Practices and all you need to know

The Azure Files Teams announced the availability of joining Azure Fileshares to AD DS since February 2020. This brings a lot of new possibilites, like to move Fileservers directly to a hosted SMB solution or deploy WVD Profiles directly on Azure Fileshares.

Microsoft did a lot of work to bring this solutions to live, but there are some challenges and pitfalls to activate and maintain the service. In this article I will go in a short way over all related considerations for Azure Fileshares AD DS authentication. Please note this article only focus to enable Azure Files for Active Directory Domain Services – not Azure AD or Azure AD DS.

Continue reading Azure Files enabled AD DS SMB authentication Best Practices and all you need to know

CONFIGURE AZURE FILES ON-PREMISES ACTIVE DIRECTORY (AD DS) AUTHENTICATION FOR FILESERVER OR WVD

Update 2

Please note: This article is replaced by All you need to know about Azure Files SMB authentication via Active Directory Domain Services.

Update 1

Azure Files on-premises Active Directory Domain Services authentication is since 11/06/20 GA. The article is upgraded and integrated the latest features and improvements.

Update 2

12/06/20 Azure Files Hybrid PowerShell Module upgrate to v. 0.2.0

In the past I had a lot of talks about Azure File Sync, a lightwight solutions to sync servers from different locations and branches via Azure Files. One often questions was, it is possible to use Azure Files directly with integrated on-premises Active Directory (AD DS) authentication – the great answer since a few days is Yes, this is possible.

Now you can use Azure Files with on-premises Active Directory authentication as a fully replacement for Fileservers. No need for Azure Active Directory Domain Services (Azure AD DS) or different settings on Azure Files. This gives great new ways to use Azure Files as an replacement for Windows based fileservers or for using as an profile store for Windows Virtual Desktop and come closer to a cloud native solution.

In this article I will explain how Azure files AD DS authentication works, how to configure it, some basic steps and more. Please feel free to use the comment section or Twitter to get in touch with me and give me feedback or ask questions.

Continue reading CONFIGURE AZURE FILES ON-PREMISES ACTIVE DIRECTORY (AD DS) AUTHENTICATION FOR FILESERVER OR WVD

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

Sichere Lokale Admin Kennwörter mit LAPS (Local Administrator Password Solution)

In einer DomĂ€nenumgebung ist eine hĂ€ufig anzutreffende Herausforderung, dass Management von Lokalen Administratorkonten. Da durfte ich bereits in einer Vielzahl unterschiedlicher Landschaften einige Lösungen, von absolut unsicher ĂŒber nicht hĂ€ndelbar, bis hin zu sehr kreativ sehen 😉

Doch genau fĂŒr diese Herausforderung stellt Microsoft das Tool Local Administrator Password Solution kurz LAPS bereit. Dieses dient zum zentralen managen der Lokalen Administratorkonten in einer DomĂ€ne. Dabei werden pro Client dynamische Kennwörter generiert. Die Kennwörter werden im AD am jeweiligem Computerobjekt angehĂ€ngt. Hier gelten dann die ĂŒblichen Berechtigungen, so könnt ihr im AD nur den berechtigten Admins das Auslesen dieser Information ermöglichen. Im folgenden gehe ich zunĂ€chst auf die Installation und Konfiguration ein. FĂŒr die Verwendung von LAPS ist eine Schema Erweiterung notwendig.

Continue reading Sichere Lokale Admin Kennwörter mit LAPS (Local Administrator Password Solution)

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:
http://blog.wisefaq.com/2010/03/31/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