[English]Es scheint, als ob es einen Bug im Active Directory (AD) bezüglich der Abfragemöglichkeiten über LDAP_MATCHING_RULE_IN_CHAIN gibt. Damit sollen sich rekursive Gruppen auflösen und Benutzer, die Mitglieder sind, finden lassen. Ein Blog-Leser hat mich diesbezüglich kontaktiert und den Fehler beschrieben, konnte aber keine zusätzliche Verifizierung vornehmen, weil ein zweites AD zum Testen fehlt. Ich stelle es mal ein, vielleicht können andere Administratoren das bestätigen.
Blog-Leser Marco Di Feo hat mich zum 21. April 2023 per Mail kontaktiert, um mich über das Problem zu informieren und schrieb in diesem Zusammenhang:
Guten Tag Herr Born,
als großer Fan Ihrer Seite wollte ich mich gerne bei Ihnen für Ihre hervorragend recherchierten Inhalte bedanken. Ein ums andere Mal haben wir so schnell wichtige und hilfreiche Informationen gefunden um Probleme in unserer Umgebung zu lösen.
Als großes Unternehmen haben wir schon den ein, oder anderen Bug gefunden, den wir bei Microsoft eskaliert haben. Nun haben wir ggf. einen weiteren Bug gefunden, den ich allerdings auf Grund eines fehlenden weiteren ADs nicht verifizieren kann und bereits bei Microsoft eingekippt habe.
Es geht um die LDAP_MATCHING_RULE_IN_CHAIN-Abfragemöglichkeit die rekursiv Gruppen in Gruppen auflöst und alle Benutzer findet, die Mitglied sind.
Diese funktioniert ganz gut, allerdings scheint diese bei uns zumindest Probleme mit Usern zu haben die mal über eine zeitbasierte Gruppenmitgliedschaft verfügten. Diese tauchen im Ergebnis der Abfrage ebenfalls auf, wie normale User, obwohl diese nicht mehr Mitglied der Gruppe sein dürften.
Marco hat das Problem in einem ausführlichen Beitrag in seinem Blog-Beitrag Active Directory time based group membership and LDAP_MATCHING_RULE_IN_CHAIN bug verfasst. Dort lassen sich die Details des Fehlers nachfragen. Marco schrieb mir dazu:
Ich dachte vllt wäre das für Sie interessant. Ich aktualisiere den Eintrag mit den Ergebnissen meines Cases bei Microsoft. Ich dachte, wenn das wirklich ein Bug wäre, wäre es sicher hilfreich für andere, hiervon etwas zu wissen.
Nochmals herzlichen Dank für Ihr Engagement.
An dieser Stelle meine Frage an Blog-Leser, die AD-Umgebungen administrieren, ob diese die Beobachtungen von Marco Di Feo verifizieren und bestätigen können?
Man sollte ggf. anmerken, dass eine LDAP Anfrage zur Gruppenzugehörigkeit NICHT ein Kerberos/NTLM token/ticket mit seinen AD-berechneten SIDs sicherheitstechnisch ersetzen kann – wer nachgeschaltete LDAP queries zur Authorisierung macht…. ist selbst dran Schuld… 🙈
Frage also: Betrifft dieses Verhalten auch Kerberos/NTLM token oder nur die client-seitigen LDAP queries..? 🤔
Stichwort: constructed msds-tokenGroupNames* attribute des Users
Interessanter Aspekt! Gerade mal mittels „whoami /groups“ überprüft: im Kerberos TGT sind keine dynamische Gruppenmitgliedschaften enthalten, deren TTL abgelaufen ist. Genauso nicht im konstruierten Attribut „msds-tokenGroupNames“ des Benutzerobjektes.
Nun gibt es leider häufig den Anwendungsfall, dass man irgendein Tool mit eigenständiger Nutzer- und Gruppenverwaltung einsetzt (z. B. von Atlassian). LDAP dient hier einerseits zur (Passwort-)Authentifizierung und andererseits zur Synchronisation/zum Import von Benutzern und Gruppen. Berechtigungen innerhalb dieser Tools werden anhand der importierten Gruppen(-zugehörigkeiten) festgelegt. Es besteht keine Möglichkeit mit Kerberostickets zu arbeiten, weshalb das im Blogartikel beschriebene Problem problematisch bleibt.
Der geschilderte Sachverhalt lässt sich so erstmal nachstellen, wobei ich noch skeptisch bin, ob man nicht einfach abwarten müsste bis ein Garbage Collector aufzuräumen beginnt.
Getestet habe ich in einem AD mit „Forest Functional Level“=“Windows Server 2016“ und aktiviertem PAM. Ein Testnutzer wurde einer Gruppe hinzugefügt, die ihrerseits Mitglied einer anderen Gruppe ist:
Add-ADGroupMember -Identity ‚CN=Group2,OU=demo,DC=contoso,DC=com‘ -Members ‚CN=User1,OU=demo,DC=contoso,DC=com‘ -MemberTimeToLive (New-TimeSpan -Minutes 1)
Wider Erwartens liefert nachfolgende Abfrage selbst nach Ablauf der TTL weiterhin den Testnutzer zurück:
Get-ADObject -LDAPFilter ‚(memberof:1.2.840.113556.1.4.1941:=CN=Group2,OU=demo,DC=contoso,DC=com)‘
Man kann übrigens alternativ auch das Attribut „msds-memberTransitive“ der jeweiligen Gruppe abfragen, was zum selben Ergebnis führt:
Get-ADGroup -Properties msds-memberTransitive -SearchBase „CN=Group2,OU=demo,DC=contoso,DC=com“ -SearchScope „Base“ -Filter * | Select-Object -ExpandProperty msds-memberTransitive
Und der Vollständigkeit halber kann ich natürlich auch umgekehrt für das Benutzerobjekt das Attribut „msds-memberOfTransitive“ abfragen, dessen Ergebnis weiterhin die beiden Gruppen enhält in denen dieses kein Mitglieder mehr sein sollte:
Get-ADUser -Property msds-memberOfTransitive -SearchBase „CN=User1,OU=demo,DC=contoso,DC=com“ -SearchScope „Base“ -Filter * | Select-Object -ExpandProperty msds-memberOfTransitive
Vielen Dank für den Hinweis! Ich werde auf jeden Fall beide Blogartikel im Auge behalten.
Ja, das ist korrekt für Applikationen, die Windows native sind. Der Markt und gerade auch Nischenprodukte gehen hier oft andere Wege und binden rudimentär LDAP (also nicht AD) an. Somit steht dann nur ein eigener Userstore, oder AD/LDAP zur Verfügung. Bei verschachtelten Gruppen kommt man da schon an diverse Grenzen, die man je nach Flexibilität der Anwendung mit msds-tokengroupnames umschiffen kann.
Bei der genannten Implementierung im speziellen ist es so, dass hier nachts ein „Sync“ angestoßen wird, der dann alle Mitglieder von bestimmten Gruppen in die interne DB synct und diese dann berechtigt.
Über Sinn und Unsinn dieser Implementierung brauchen wir nicht streiten, da sind wir uns einig :).
Kern der Frage ist trotzdem, warum bekommt man über die LDAP_MATCHING_RULE_IN_CHAINS Abfrage User angezeigt, die bereits per TTL nicht mehr Mitglied der Gruppe sind.
Dieses Verhalten betrifft nach meiner Recherche aktuell „nur“ die LMRIC Abfrage. In msds-tokengroupnames sehe ich die Testgruppen nicht.
Danke für dein Feedback Markus und für’s verifizieren.
Ich beobachte das Verhalten für Gruppen in denen vor über 3 Monaten bereits User per TTL entfernt wurden. Ich glaube nicht, dass es am GC liegt. Ich bin gespannt, was Microsoft zu dem Thema sagt und melde mich gerne hier und auf meinem Blog für weitere Infos.
Meine Erfahrungen mit dem Microsoft Support sind leider durchweg negativ was solche Themen anbelangt. Falls du keinen Erfolg haben solltest, versuche die Aufmerksamkeit von Ryan Ries zu gewinnen. Hier sein Profil inkl. Link zu seinem Twitter Account:
https://techcommunity.microsoft.com/t5/user/viewprofilepage/user-id/138461
Danke für deinen Tipp. Ich habe das über unseren Premier Support eingekippt und lasse das ggf. über unseren TAM eskalieren. Damit lief es in der Vergangenheit meistens ganz gut. Bei einigen Sachen haben wir dank eines Bugs dann auch kein Supportkontigent eingebüßt.
Microsoft kann das Problem bei sich nachvollziehen. Es ist also kein Bug, der nur bei uns auftritt, sondern auch bei Microsoft nachgestellt werden kann. Ich bin gespannt, wann es hier ein weiteres Update zu dem Topic gibt. Ich halte euch auf dem Laufenden
Gibt es mittlerweile etwas neues?