Ende Januar findet der Teams Community Day statt, eine verteilte Community-Konferenz zum MS-365-Universum im Allgemeinen und zu Teams im Speziellen. In einer Mischung aus Vor-Ort-Konferenzen und Online-Beiträgen bringt das Format die Community zusammen.

In Hannover wird es ein lokales Event geben, das am 28. Januar 2025 in den Räumen vom ATD Systemhaus stattfindet. Die Agenda ist aktuell in Planung, es steht aber schon fest, dass es spannende Sessions u.a. zu Teams und zu Microsofts Copilot geben wird. Die Planung und Organisation liegt bei der MS Cloud and Collaboration Community Hannover (MSCCCH).

Das Event ist kostenlos und öffentlich – kurze Anmeldung genügt.

[TeamsCommunityDay Hannover 2025]
https://atd-systemhaus.de/teamscommunityday2025

Kurz und knapp: Ich brauchte einen Jahreskalender in Excel und habe keine Vorlage gefunden, die das machte, was ich wollte. Da habe ich mir selbst eine gebaut.

Mein Jahreskalender ist klassisch nach Monaten und Tagen aufgeteilt mit einem Feld pro Tag, das beschreibbar ist. Oben links kann man eine Jahreszahl eintragen, der Kalender passt sich dann an.

Alle Felder mit Formeln sind gegen versehentliche Eingaben geschützt. Wer die Vorlage verändern möchte, hebt über das Menü Überprüfen/Schützen/Blattschutz aufheben den Schutz auf. An derselben Stelle kann man ihn dann wieder einschalten.

  Excel-Jahreskalender (11,8 KiB, 104-mal heruntergeladen, letzte Änderung am 10. Dezember 2024)

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."

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/

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.

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, 673-mal heruntergeladen, letzte Änderung am 12. Juni 2024)

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.

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/

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/

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