LDAPS (LDAP over TLS) auf DCs schnell testen

Nach und nach wird LDAPS anstelle des unverschlüsselten LDAP auf Windows Domänen Controllern (DCs) eingeführt. Das ist auch sinnvollso. Das einzige was der Admin dazu tun muss, ist ein passendes (Domänen-) Zertifikat zu installieren. Das funktioniert auch bestens mit Wildcard-Zertifikaten, sofern man eine Domäne mit „Routingfähigem“ FQDN verwendet.

Wann man nun ein Zertifikat hinzugefügt hat, wie testet man das denn auf die schnelle? Natürlich hat Microsoft kein Werkzeug dafür an Boad, aber OpenSSL to the rescue.

Lösung

Man verbinde sich einfach mit dem openSSL-Client mit dem LDAPS-Port

openssl.exe s_client -connect DC.EXMAPLE.COM:636

und warte auf den CONNECTED output. Wenn es den gibt, war die Verbindung erfolgreich.

Die Ausgabe des TLS-Tests sieht dann (in etwa) so aus:

C:\>openssl.exe s_client -connect DC.EXAMPLE.COM:636
Connecting to <IP>
CONNECTED(000001F8)
depth=1 C=US, O=DigiCert Inc, OU=www.digicert.com, CN=RapidSSL TLS RSA CA G1
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN=*.EXAMPLE.COM
verify return:1
---
Certificate chain
 0 s:CN=*.EXAMPLE.COM
   i:C=US, O=DigiCert Inc, OU=www.digicert.com, CN=RapidSSL TLS RSA CA G1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 01 00:00:00 2026 GMT; NotAfter: Jun 29 23:59:59 2096 GMT
 1 s:C=US, O=DigiCert Inc, OU=www.digicert.com, CN=RapidSSL TLS RSA CA G1
   i:C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root G2
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Nov  2 12:24:33 2017 GMT; NotAfter: Nov  2 12:24:33 2029 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
ETZGLDCCBRSgAwIBAgIQAp8gNFzPD8DDuYunngMxzzANBgkqhkiG9w0BAQsFADBg
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3

[...]

Ein Gruppenrichtlinienobjekt (GPO) auf alle Organisationseinheiten (OUs) mit bestimmtem Namen unterhalb eines DNs anwenden (linken)

Problem

Als Windows-Administrator wird man mit Aufgaben konfrontiert, die recht einfach klingen. Bis man sie sehr oft von Hand ausführen muss.

Ein Beispiel aus der Praxis:
„Erstelle eine neue GPO und verlinke diese auf alle OUs, die ‚Würstchen‘ heißen, unterhalb von OU=Speisekarte“.

Oder anders formuliert: Verknüpfe eine Gruppenrichtlinie auf alle 3673409 OUs mit diesem Namen.

Das ist in der Gruppenrichtlinienverwaltung technisch gar kein Problem; sofern die Anzahl übersichtlich ist (und die OUs nicht über mehrere Ebenen verteil sind). Man klickt sich durch die AD-Verwaltungskonsole, öffnet Eigenschaften, fügt die GPO hinzu … und wiederholt das sehr oft.

Lösung

Das kann man glücklicherweise ganz gut mit der PowerShell automatisieren.

Dieser Schnippsel durchsucht mit -like alle OUs unterhalb eines angegebenen DN nach einem bestimmten Begriff und verlinkt automatisch die gewünschte GPO dazu.

$BaseDN = "OU=UNTERSTRUKTUR,DC=EXAMPLE,DC=COM"
$Suchbegriff = "WÜRSTCHEN"
$GPO = Get-Gpo -Name "NEUE_GRUPPENRICHLINIE"

Get-ADOrganizationalUnit -SearchBase $BaseDN -Filter * -SearchScope Subtree |
    Where-Object { $_.Name -like "*$Suchbegriff*" } |
    ForEach-Object {
    New-GPLink -Guid $GPO.id -Target $_.DistinguishedName -LinkEnabled Yes
    }

Mit diesen Zeilen wird aus ermüdender Klickarbeit eine schnelle Aktion.

Outlook startet nach Windows-Updates nicht mehr oder stürzt ab

Problem

Seid den Windows-Updates vom 14.05.2025 startet auf einigen Computern das „klassische“ Outlook nicht mehr, oder stürzt direkt nach dem Start ab. Falls konfiguriert, wird auch die Outlook-Profilauswahl nicht mehr angezeigt.

Outlook lässt aber im abgesicherten Modus starten:

outlook.exe /safe

Sowohl die Online-Reparatur als auch das Deaktivieren des Add-ins helfen leider nicht.

Lösung

Um Outlook wieder „normal“ zu benutzen, scheint es aktuell keine andere Lösung zu geben, als Outlook (je nach Installation auch das komplette Office-Paket) zu deinstallieren und ganz neu herunterzuladen und zu installieren.

Es hilft leider auch nicht, das Outlook-Profil neu zu erstellen.

Anzahl der echten CPU-Kerne in der PowerShell anzeigen

Manchmal braucht man „mal eben“ die Anzahl der echten physischen CPU-Cores. Sei es um Systemvoraussetzungen zu prüfen, Daten zu inventarisieren oder einer Asset-Verwaltung auf die Sprünge zu helfen. Nein, wir nennen Asset.Desk, Service.Desk und dieses unglaublich furchtbare Heinzelmann nicht beim Namen.

Windows zählt die physischen und logischen Cores getrennt und kann diese auch ausgeben – via WMI.

Display CPU Core count in PowerShell

Get-WmiObject win32_processor | ft Name,NumberOfCores,NumberOfLogicalProcessors