Added some details about v. 1.6.11.3 which fixes a security issue.
Microsoft released a major update of Azure AD Connect. This major release brings a lots of new features and requirements for the local infrastructure. In this article I will cover the latest information and how you can upgrade to the new release.
The new version 2 of Azure AD Connect was released on 20/07/2021 and bring the product to the version 2.0.3.0 the lastet release of version 1 was 1.6.4.0 1.6.11.3. Microsoft found a security issue in 1.6.4.0 and 2.0.3.0 and updated the Azure AD Connect v2 to 2.0.8.0.
Microsoft released also an update for AAD Connect v1 and brings it to 1.6.11.3. This is for customers who running an older version of Windows Server who can not upgrade to WS 2016 and fixes an security issue in 1.6.4.0.
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 đ
There are some improvements and changes in the AzFilesHybrid module, I updated the article with this changes.
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.
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.
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.
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.
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.
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. Standard-Installation von Windows Server 2008 R2 Enterprise Edition (Aktivierung auch gleich erledigen)
PrimÀren DNS-Suffix eintragen
Unter C: ein Verzeichnis ADCS mit zwei Unterverzeichnissen “Database” und “Logs” anlegen
Serverrolle Active Directory Zertifikatsdienste (Active Directory Certificate Services) installieren
Bei Rollendiesten “Zertifizierungsstelle” auswĂ€hlen
Allgemeiner Name dieser Zertifizierungsstelle “F1NaLByte Root Authority” (denkt euch euren eigenen aus đ )
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.
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:
Konfiguration Stelleninformationen
Zuletzt sollte ebenfalls der Zugriff auf die Stelleninformationen angepasst werden.
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.
Zertifikatssperrliste Konfiguration
Nun muss noch die Zertifikatssperrliste veröffentlicht werden:
Ist der “File-Pfad” nicht verĂ€ndert worden, so befindet sich die veröffentlichte Sperrliste nun an folgendem Ort: “C:WindowsSystem32CertSrvCertEnroll”
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.
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).
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.
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.
