Wenn man automatisiert Benutzerkonten in einer AD-Umgebung erzeugt, kann es – je nach Methode – vorkommen, dass diese Konten keine Kennwörter haben. Das passiert etwa, wenn man solche Konten mit dem uralten Kommando csvde.exe erzeugt. Die Konten sind dann auch deaktiviert, es entsteht also keine direkte Gefahr. Es lauert aber eine – mit der man wahrscheinlich nicht rechnet.
Hinter den Kulissen setzen solche Tools nämlich oft ein Attribut bei den Konten, damit sie diese überhaupt mit leerem Kennwort erzeugen können, auch wenn die Kennwortrichtlinie das gar nicht zulässt. Das Attribut heißt “PasswordNotRequired” oder auch “PASSWD_NOTREQD”. Das Perfide daran: die grafischen AD-Tools zeigen das Attribut nicht an. Und auch sonst ist es nicht ganz einfach zu handhaben, es ist nämlich ein Flag in einem Binärfeld des AD, nämlich “userAccountControl” (mehr dazu findet sich bei Microsoft Learn).
Manche Schwachstellen-Scanner schlagen aber – zu Recht – an, wenn sie solche Accounts auffinden. Aber wie wird man das Attribut nun wieder los?
Da man es meist wohl einfach für alle Konten zurücksetzen will, habe ich hier ein Holzhammer-Skript. Es sucht alle Konten, bei denen das Flag gesetzt ist, und setzt es bei jedem dieser Accounts zurück. Am Ende prüft es noch mal, ob das auch geklappt hat.
$SuspectUsers = (Get-ADUser -Filter {PasswordNotRequired -eq $true})
$Count = $SuspectUsers.Count
"Found $Count suspect users."
$SuspectUsers | ForEach-Object {
"Correcting $_.name ..."
Set-ADUser $_ -PasswordNotRequired $false
}
$SuspectUsers = (Get-ADUser -Filter {PasswordNotRequired -eq $true})
$Count = $SuspectUsers.Count
"$Count suspect users left."
Kurzlink zu diesem Artikel:
http://faq-o-matic.net/?p=8933
Aus der LDAPS-ohne-PKI-Diskussion sind noch ein paar weitere Punkte hervorgegangen. Der AD-Spezialist Evgenij Smirnov hat nun einige technische und logische Aspekte in einem sehr lesenswerten Artikel zusammengefasst, auf den wir ohne weitere Umschweife hier verweisen:
[LDAP auf Port 389 deaktivieren – ein Reality Check – Evgenij Smirnov]
https://it-pro-berlin.de/2024/06/ldap-deaktivieren-ein-reality-check/
Kurzlink zu diesem Artikel:
http://faq-o-matic.net/?p=8931
Eine meiner Thesen in meiner Session “Broken by Design: Warum wir PKIs nicht trauen können (aber keine andere Wahl haben)” auf der Experts Live Germany 2024 lautete: Betreibe keine PKI, wenn du sie nicht wirklich brauchst. Das führte zu einiger Diskussion.
Ein Teilnehmer fragte mich, ob ich damit etwa davon abraten würde, LDAPS in einer Windows-Domäne zu aktivieren, denn dafür brauche man ja eine PKI. Die kurze Antwort dazu ist: Nein, natürlich rate ich nicht von LDAPS ab, aber man braucht dafür auch keine PKI. Man braucht nur passende Zertifikate, was im Wesentlichen normale TLS-Zertifikate (früher “SSL-Zertifikate” genannt) für jeden Domänencontroller sind.
Die Voraussetzungen dafür hat Microsoft hier zusammengefasst (im Folgenden gekürzt):
- das Zertifikat liegt im lokalen Zertifikatsspeicher des DCs (Computer-Teil)
- der Private Schlüssel dazu ist vorhanden
- das Zertifikat hat den Einsatzzweck “Server Authentication”
- der FQDN des DCs steht in den Feldern Subject und SAN des Zertifikats
- sowohl der DC als auch alle Clients vertrauen der CA, die das Zertifikat ausgestellt hat
(Anmerkung: das bezieht sich auf die gesamte Zertifikatskette, weil LDAPS die Kette nicht mit ausliefert, wie das Webserver tun)
Es braucht also keine interne PKI und auch kein automatisches Ausstellen der Zertifikate. Man bekommt das mit einfacheren Mitteln hin, ohne dass man sich eine pflegeintensive Struktur bauen muss.
Eine Anleitung, wie man das mit einem verbreiteten Open-Source-Werkzeug hinbekommt, habe ich als Beispiel hier gefunden:
[LDAPs ohne Windows CA aktivieren – SchweigersTechBlog]
https://schweigerstechblog.de/ldaps-ohne-windows-ca-aktivieren-microsoft/
Das ist nicht der einzige mögliche Weg, aber er ist dort vollständig beschrieben. Man kann das auch per PowerShell oder mit anderen Mitteln machen. Wichtig ist hier natürlich, dass man die nötige Sorgfalt walten lässt.
Kurzlink zu diesem Artikel:
http://faq-o-matic.net/?p=8929
Hier findet ihr das Handout meiner Session “Broken by Design: Warum wir PKIs nicht trauen können (aber keine andere Wahl haben)” auf der Experts Live Germany 2024.
Experts Live 2024: PKI Broken by Design (Folien) (1,8 MiB, 555-mal heruntergeladen, letzte Änderung am 12. Juni 2024)
Kurzlink zu diesem Artikel:
http://faq-o-matic.net/?p=8927
Heute mal wieder ein (hihi) Quickie: Die Gruppe “BUILTIN\Prä-Windows 2000 kompatibler Zugriff” in Active Directory ist ein eingebautes Sicherheitsloch. Warum das so ist, könnt ihr an vielen Stellen im Web nachlesen. Kurz zusammengefasst: Diese Gruppe enthält standardmäßig die Pseudo-Systemgruppe “Authentifizierte Benutzer”, und damit kann jeder Benutzer (und auch jeder Computer) nahezu alles lesen, was im Active Directory so steht. Angepasste Zugriffsrechte lassen sich so schwer umsetzen, und Angreifer haben es allzu leicht.
Es ist mit wenigen Mausklicks möglich, diesen Eintrag zu entfernen und so in einem neu installierten AD die Gruppe zu leeren. Vor vielen Jahren haben wir schon ein Holzhammer-Skript dazu vorgestellt:
[Gruppe “Prä-Windows 2000 kompatibler Zugriff” per Skript leeren | faq-o-matic.net]
https://www.faq-o-matic.net/2010/06/21/gruppe-pr-windows-2000-kompatibler-zugriff-per-skript-leeren/
Heute mal eine ganz kurze Variante, die ohne VBScript auskommt:
REM Get Domain LDAP name
FOR /f "usebackq" %%a IN (`DSQUERY * DomainRoot -Filter "(objectClass=domain)" -SCOPE base`) DO (
SET Domain=%%a
)
SET Domain=%Domain:"=%
DSMOD GROUP "CN=Prä-Windows 2000 kompatibler Zugriff,CN=Builtin,%Domain%" -RMMBR "CN=S-1-5-11,CN=ForeignSecurityPrincipals,%Domain%"
Das Skript setzt voraus, dass die AD-Verwaltungstools auf dem ausführenden Rechner installiert sind, und es funktioniert in einem deutschsprachigen AD.
Kurzlink zu diesem Artikel:
http://faq-o-matic.net/?p=8922
Die Experts Live Germany hat vor ein paar Tagen die Agenda und die Sprecher*innen der 2024-er Konferenz bekannt gegeben. 18 Tech-Vorträge werden in drei parallelen Tracks den Tag füllen. Die Speakers kommen aus der deutschen IT-Community, viele sind MVPs.
Die Konferenz findet am 11. Juni 2024 in Erfurt statt, die Location ist wieder der Zughafen. Diesmal mit optimiertem Audio-Erlebnis – wir dürfen also auch auf die Technik vor Ort gespannt sein, nicht nur auf die Inhalte.
Noch wenige Tage läuft der “Early Bird” mit reduzierten Ticketpreisen – es lohnt sich also, schnell zu sein. Hier geht’s lang:
[Experts Live Germany]
https://expertslive.de/
Kurzlink zu diesem Artikel:
http://faq-o-matic.net/?p=8917
Die Nachricht ist nicht mehr ganz neu, aber sie ist auch aktuell wenig bekannt: In Kürze wird es endlich eine festgelegte Top Level Domain (TLD) für rein intern genutzte DNS-Domänennamen geben. Die zuständigen Gremien IANA und ICANN haben sich nach jahrelangem Prozess darauf geeinigt, dass die TLD “.internal” künftig dafür herhalten soll, lokale Netzwerke zu bezeichnen, deren Namen nicht im Internet aufgelöst werden.
Damit beenden die beiden Gremien eine unklare Situation, die schon jahrzehntelang bestand, sich aber vor allem seit 2008 deutlich verschärft hatte. Bis dahin hatte es nur eine festgelegte Liste von Top Level Domains gegeben, die zum größten Teil aus Zwei-Buchstaben-Kürzel für Länder bestand. Im Sommer 2008 erfolgte dann eine fast vollständige Freigabe von TLDs, sodass nahezu beliebige Wörter dafür registriert werden konnten. Hieraus wiederum entstanden Probleme für “ausgedachte” interne Domänennamen, denn diese konnten plötzlich auch regulär im Internet auftauchen.
Insbesondere gab es langjährige Missverständnisse und falsche Annahmen. So ist das beliebte Kürzel “.local” nie für den internen Gebrauch reserviert gewesen. Hier war es Apple, die urplötzlich auf die Idee kamen, die TLD produktiv zu verwenden, und prompt gab es Probleme.
So ganz fest ist die Entscheidung für “.internal” noch nicht, aber es ist auch nicht damit zu rechnen, dass sie noch wackelt. Nach der Vorentscheidung der IANA von Ende Januar 2024 läuft aktuell noch ein Kommentierungs- bzw. Einspruchsverfahren bei der “Internet-Behörde” ICANN. Die Frist für Einsprüche ist vor einigen Tagen ausgelaufen, bis Anfang April muss die ICANN nun einen zusammenfassenden Bericht vorlegen. Auf dessen Basis wird das Gremium dann vermutlich ein paar Wochen dne TLD “.internal” offiziell festlegen.
Mehr dazu:
[Überfällig: ICANN legt sich auf Namen für interne Domains fest | heise online]
https://www.heise.de/news/Ueberfaellig-ICANN-legt-sich-auf-Namen-fuer-interne-Domain-fest-9612253.html
[Proposed Top-Level Domain String for Private Use]
https://www.icann.org/en/public-comment/proceeding/proposed-top-level-domain-string-for-private-use-24-01-2024
[Welcher Name ist der beste für eine AD-Domäne? | faq-o-matic.net]
https://www.faq-o-matic.net/2007/06/08/welcher-name-ist-der-beste-fuer-eine-ad-domaene/
Kurzlink zu diesem Artikel:
http://faq-o-matic.net/?p=8915
Die Experts Live Germany ist ein jährliches Event, das die deutschsprachige IT-Community zusammenbringt und sich auf Microsoft Cloud-, Hybrid- und On-Premises-Lösungen konzentriert. Die Veranstaltung bietet spannende Vorträge, Demos und Diskussionen mit Microsoft MVPs und erfahrenen Microsoft Experten und Expertinnen.
Die nächste Konferenz findet am 11. Juni 2024 in Erfurt statt. Erfurt ist als zentraler Knotenpunkt für den Bahnverkehr gut zu erreichen, egal ob Berlin, Frankfurt, München oder Stuttgart. Auch wer mit dem Auto anreist, kommt über A4 und A71 ohne Probleme schnell ans Ziel. Die Veranstaltung ist eine perfekte Gelegenheit, um sich mit anderen IT-Enthusiasten zu vernetzen und neueste Technologien kennenzulernen. Wir freuen uns auf eure Teilnahme!
Markiert euch also schon mal eure Kalender, Tickets gibt’s im neuen Jahr.
[Experts Live Germany]
https://expertslive.de/
Aktuell ist der Call for Speakers geöffnet, falls ihr also nicht nur vor, sondern auf der Bühne dabei sein wollte, dann hier entlang: https://sessionize.com/experts-live-germany-2024
Kurzlink zu diesem Artikel:
http://faq-o-matic.net/?p=8912
Mein Metareporting-Tool Angelo für Active Directory hat nun nach vielen Jahren ein Update bekommen. Es ergänzt die Reports und behebt ein paar ärgerliche Fehler.
Angelo eignet sich gut, um einen ersten umfassenden Überblick über eine AD-Umgebung zu erhalten, ohne stundenlang in den GUI-Tools herumzuklicken. Es eignet sich auch als Basis, um den “Gesundheitszustand” und die Security-Konfiguration einzuschätzen. Anders als andere Tools berechnet es dabei keinen “Score” und keine Bewertung, sondern sammelt nur Report-Daten. Die sind dann mit Fachkenntnis zu interpretieren.
Vorsicht: In großen oder sicherheitskritischen Umgebungen sollten man sich den Einsatz von Angelo genehmigen lassen. Es führt sehr umfangreiche Abfragen an das AD durch, so dass das Sicherheits-Monitoring schon mal anschlagen kann.
Näheres zu Angelo:
[Angelo: Meta-Reporting für Active Directory | faq-o-matic.net]
https://www.faq-o-matic.net/2015/02/23/angelo-meta-reporting-fr-active-directory/
Und der Download:
Angelo: AD-Metareporting (15,9 KiB, 3.448-mal heruntergeladen, letzte Änderung am 19. September 2023)
Kurzlink zu diesem Artikel:
http://faq-o-matic.net/?p=8910
Nach einer längeren (Pandemie-)Pause findet am 16.09.2023 nun endlich wieder ein PowerShell Saturday in Hannover statt.
Bei dem Event wird es vor allem um PowerShell-bezogene Themen gehen, aber natürlich kommen auch andere Produkte, für die PowerShell als „Kleber“ dient, nicht zu kurz.
Die Veranstaltung findet in den Räumen der Netz-Weise statt, die viele aus den monatlichen Treffen der PowerShell User Group Hannover (PSUGH.de) kennen.
Durch die Sponsoren Netz-Weise, Script Runner und Au2Mator ist für das leibliche Wohl gesorgt.
Nähere Infos zum Event sowie die Möglichkeit; sich anzumelden, findet man auf pssat.de.
Kurzlink zu diesem Artikel:
http://faq-o-matic.net/?p=8907