Archiv der Kategorie: Allgemein

LDAPS (LDAP over TLS) auf DCs schnell testen

Veröffentlicht am von — Keine Kommentare ↓

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

[...]

Fefes Blog ist down – wir wissen es auch nicht

Veröffentlicht am von — 3 Kommentare ↓

Obwohl wir oft und sehr gerne Gäste im CCC-Umfeld sind, wissen wir auch nicht was mit Fefe und Fefe’s Blog los ist. Bitte nicht mehr nachfragen.

Wir hoffen, es geht ihm gut und wünsche alles Beste! Wir können es auch kaum erwarten, neues zu erfahren.

Update: Danke an die Kommentierenden für die (erfreulichen) Nachrichten zu Fefe. Damit (also mit den Kommentaren) hatten wir nicht gerechnet ♥️
Gute Genesung @fefe 💪

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

Veröffentlicht am von — Keine Kommentare ↓

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.

vSphere: Virtuelle Maschinen nach MAC oder IP Adresse suchen

Veröffentlicht am von — Keine Kommentare ↓

Aus Gründen musste ich heute eine VM ausfindig machen. Genauer musste eine VMWare Gastmaschine mit einer bestimmten IP und eine andere mit einer bestimmten MAC Adresse gefunden werden.

Im vCenter GUI (vSphere Client) geht das nicht, aber an der Powershell. Die MAC der (virtuellen) Netzwerkkarte kann man natürlich schon sehen, genau wie die IP-Adresse von Gastsystemen mit installieren VMWare-Tools. Aber man kann nach beidem nicht suchen.

Lösung

Mit dem VMWare PowerCLI (PowerShell) zum Host oder vCenter verbinden:

Connect-VIServer VCENTER.EXAMPLE.COM

VMWare Gastsystem nach IP-Adresse suchen:

Get-VM | ? { $_.Guest.IPAddress -match "192.168.0.999" }

VMWare Gastsystem nach MAC-Adresse suchen:

Get-VM | Get-NetworkAdapter | ? { $_.macaddress -like "00:50:56:99:1*" } | select Parent,MacAddress

Das Format der MAC-Adressen in VMWare PowerCLI ist die Doppelpunkt-Trennung pro Byte „xx:xx:xx:xx:xx:xx“

Lancom Accesspoints (LW-500) stürzen ständig ab (Denial-of-Service)

Veröffentlicht am von — Keine Kommentare ↓

Problem

LW-500 Accesspoints von Lancom stürzen im laufenden Betrieb sporadisch und scheinbar unvorhersehbar ab. Die Geräte sind dann nicht mehr erreichbar und müssen manuell vom Strom getrennt werden. Nach einem Reboot sind die Geräte wieder da – als wäre nie etwas gewesen. Das passiert unabhängig von VLANs, Management (Cloud/WLC) oder Switch – sogar unabhängig von PoE oder Netzteil.

Der Fehler tritt nicht ständig auf, manchmal funktionieren die Accesspoint auch wochenlang fehlerfrei. Dann gibt es aber auch Tage mit vielen Abstürzen hintereinander.

Lösung

Ursache: Wenn ein LANCOM LW-500 IP-Pakete mit 4 fehlerhaften Bytes im Header empfängt, führt das zum sofortigen Absturz. Sendet man das Paket an den Broadcast (auch WLAN ist betroffen), stürzen alle Geräte im Netzwerk ab. Ein DOS-Angriff ohne weitere Vorbereitung. Solche Pakete stammen oft von alter Hardware, Überwachungstechnik, Flurscannern, WLAN-Clients oder MDE-Geräten und sollten eigentlich verworfen werden.

Zur Fehlerbehebung gibt es (siehe ReleaseNotes) unter Setup/LAN ab Firmware 5.36.0154 RU4 die Option „Hardware-Flow-Dispatching“. Standardmäßig ist die Option, irritierenderweise, eingeschaltet („yes“).

Die Option ist bisher nicht per Web- oder LANconfig erreichbar.

Man verbinde sich via SSH zu jedem Gerät einzeln und gebe ein:

set Setup/LAN/Hardware-Flow-Dispatching No
flash yes

Und schon sind die mysteriösen Abstürze behoben. Die Geheimniskrämerei hat bei Lancom zwar lange Tradition, aber in so einem Fall offensichtlicher Sicherheits- und Stabilitätsprobleme erscheint das gewählte Vorgehen schon etwas ungewöhnlich …