AzureAD Connect V2

Im August 2021 gab es ein Sicherheitsupdate für ADSync, über den viele Administratoren vermutlich erst einmal aufgefallen ist, dass es neben der lange genutzten Version 1.x mittlerweile auch eine Version 2 gibt. Das Security Updates korrigiert einen Fehler in der Version 2.0.8 und früher und ich bin nicht sicher, ob die 1.x Version nicht auch angreifbar wäre. Nutzen wir dieses Security Updates doch direkt um ein Update, denn die Version 1.6.11.3 kann nicht mehr auf Windows 2016 installiert werden.

Etwas verwirrend ist, dass die Versionsgeschichte auf zwei Seiten verteilt und überlappt ist.

Achtung: Nutzen Sie immer das englische Original. Die deutschen Seiten haben nicht alle Informationen und im Aug 2021 auch noch nicht die Version 2

Die neuere Version 2.x können Sie erst ab Win2016 und höher einsetzen.

Achtung: ADSync hat durchaus viele Rechte, z.B. PasswordSync und Password Writeback. Auch hier gibt es Bugs und Fixes. z.B.
CVE-2021-36949 Microsoft Azure Active Directory Connect Authentication Bypass Vulnerability
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36949

Version 2.0.9 hat z.B. Probleme beim einer hohen Anzahl an PasswordHashSync-Transaktionen.

Download und Installation

Welche Version sie gerade für ADSync nutzen, können Sie auf dem Server selbst über "Systemsteuerung - Software" sehen. Ein anderer Weg ist der Blick ins Office 365 AdminCenter unter

Die neue Version 2.x gibt es wieder bei Microsoft auf dem Download Portal.

Microsoft Azure Active Directory Connect
https://www.microsoft.com/en-us/download/details.aspx?id=47594

Die MSI-Datei kann direkt als Administrator gestartet werden und erlaubt eine Neuinstallation aber auch ein Update einer bestehenden Installation.

Tipp: Exportieren und Dokumentieren Sie vor eine Updates die aktuelle Konfiguration, damit sie im Nachgang kontrollieren können, welche Einstellungen vielleicht nicht übernommen werden konnten. ADSync hat dazu ein PowerShell-Skript "C:\Program Files\Microsoft Azure Active Directory Connect\Tools\MigrateSettings.ps1" mit installiert. Als Parameter geben Sie einen Pfad an. Dort landen dann einige Dateien, z.B.: C:\ProgramData\AADConnect\Exported-ServerConfiguration-764e6c1a-2c75-4a49-b04a-1cf93d4d4c8c\GlobalSettings\MV.xml

TLS 1.2

Ich habe ein Update auf Windows 2016 von ADSync Version 1.5.xxx auf 2.0.9 machen wollen. Direkt nachdem sich das MSI ausgepackt und den Assistenten gestartet hat, wurde ich gleich wieder ausgebremst.

Das fand ich interessant, dass der Windows 2016 Server noch kein TLS 1.2 aktiviert haben sollte. Zumal ein Browser sehr wohl schon TLS 1.2 nutzen konnte. Der Link unter "this document" verweist auf folgende Seite:

Im August 2021 konnte ich da aber direkt die PowerShell-Befehle finden, die alle erforderlichen Registrierungseinstellungen vornehmen.

New-Item 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319' -name 'SystemDefaultTlsVersions' -value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319' -name 'SchUseStrongCrypto' -value '1' -PropertyType 'DWord' -Force | Out-Null
New-Item 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -name 'SystemDefaultTlsVersions' -value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -name 'SchUseStrongCrypto' -value '1' -PropertyType 'DWord' -Force | Out-Null
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -name 'Enabled' -value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -name 'DisabledByDefault' -value 0 -PropertyType 'DWord' -Force | Out-Null
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -name 'Enabled' -value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -name 'DisabledByDefault' -value 0 -PropertyType 'DWord' -Force | Out-Null
Write-Host 'TLS 1.2 has been enabled.'

Dennoch interessant, dass Microsoft kein Import einer REG-Datei mehr anbietet oder gar im Setup die Änderung integriert hat. Danach habe ich einfach das gleiche MSI-File noch einmal gestartet um dann das Update über die GUI durchzuführen.

Natürlich wollte das Setup noch die Zugangsdaten zu einem Office 365-Admin Konto haben und hat weitere Bestätigungen angefordert. Im Hintergrund wurde dann nicht nur der eigentliche Sync-Service aktualisiert, sondern auch noch die SQL-Express-Datenbank auf 2019 angehoben und der ADSync Health-Service aktualisiert. Bei mir habe ich in der Systemsteuerung dann folgende Produkte gefunden:

Seamless SSO deaktiv!

Immer mehr Firmen nutzen mittweile Password Hash Sync (PHS) oder Pass Through Authentifizierung (PTA) in Verbindung mit Seamless Single Sign On. Hier sollten sie dann noch mal genauer hinschauen. Bei meinem Update ging genau diese Einstellung verloren, wie ein XML-Vergleich der MV.XML vor und nach dem Update anzeigt.

Der Vergleich wurde mit "Azure AD Connect Configuration Documenter" https://GitHub.com/microsoft/AADConnectConfigDocumenter durchgeführt

In der alten Datei war hier noch ein "true" zu sehen:

Auch das Computerkonto wurde durch das Update nicht angefasst.

Ich hab dann natürlich sofort wieder den AzureAD Connect Assistenten gestartet und die Verwaltung des "User Sign-in" ausgewählt. Hier wurde dann auch angezeigt, dass die Checkbox bei "Single Sign-on" nicht mehr aktiv war.

Ich habe dann natürlich sofort wieder die Checkbox aktiviert. Ich vermute, dass dieser "Fehler" gar nicht auffällt, solange in der Cloud das Flag noch gesetzt und das lokal AzureADSSOACC-Konto immer noch das gleiche Kennwort hat.

Weitere Links