P.Foeckeler

Doch, LDAP-Filter gibt es auch Rekursiv, jedenfalls was die Attribute member + memberOf angeht. Man muss allerdings im LDAP-Filter einen seltsamen Modifier verwenden: :1.2.840.113556.1.4.1941: (LDAP_MATCHING_RULE_IN_CHAIN) Der Filter muss dann so aussehen: (memberOf:1.2.840.113556.1.4.1941:=CN=Gruppe98_Gesamt,OU=Gruppen,OU=Gesamt) oder eben für zwei Gruppen: (|(memberOf:1.2.840.113556.1.4.1941:=CN=Gruppe98_Gesamt,OU=Gruppen,OU=Gesamt)(memberOf:1.2.840.113556.1.4.1941:=CN=Gruppe99_Gesamt,OU=Gruppen,OU=Gesamt)) Diesen Filter sollte man allerdings nicht intensiv verwenden, denn er erzeugt eine relativ hohe Last am Domänencontroller. Auch kann ich Dir nicht genau sagen, wie das dann ist mit Domäne-übergreifenden Mitgliedschaften, ob er die auch rausfindet damit. Müßte man mal ausprobieren :) Gruß, Philipp

Hallo zusammen, ich stimme mal meinen Vorrednern zu, es wird nicht ohne ReDesign/Umstrukturierung der Gruppenmechanik gehen. Denn vor Win2012 gibt es eine fixe Grenze für die Größe des Access Tokens, und die liegt genau bei 1014 Gruppenmitgliedschaften. Daraus resultieren dann nicht nur Zugriffsprobleme bei Filezugriff oder DB-Zugriff oder HTTP "Request Header too long" Fehler, sondern auch so häßliche Nebeneffekte dass z.B. plötzlich die Verarbeitung der Gruppenrichtlinien nicht mehr funktioniert. Sehr hinterhältig, deswegen besser frühzeitig die Gruppen und Mitgliedschaften restrukturieren... Zur Info: In das Access Token kommen nicht nur die SIDs der Gruppen, in denen ein User- oder Computer-Account unmittelbar enthalten ist, sondern die SIDs auch derjenigen, in denen eine Mitgliedschaft nur über Gruppenverschachtelung existiert. Da kommt dann schnell was zusammen in größeren Umgebungen. Sichtbar wird das am AD-Attribut "tokenGroups", hier sind die SIDs ALLER Gruppen sichtbar, in denen man direkt und indirekt enthalten ist. Sichtbar mit ADSIEdit, oder der W2K8 Registerkarte "Attribut-Editor" in der AD-Verwaltung...oder mit einem LDAP Browser. Gruß, Philipp

Hallo, wie Dukel schon ganz richtig gesagt hat: Was hast du denn damit vor? Denn Deine Frage ist von vornherein erstmal viel zu unspezifisch um was dazu zu sagen... 1) Um welchen LDAP-Server handelt es sich denn auf der Linux-Seite? OpenLDAP, DirX, iPlanet oder ein anderer? 2) Welches Ergebnis soll denn die Kopplung erreichen? Willst Du Einträge aus dem Linux-LDAP in deinem globalen Adressbuch (Exchange/AD) sehen, oder sollen etwa Linux-Maschinen oder Benutzer auf Linux-Maschinen sich am AD anmelden können? Oder was anderes? Erst wenn das geklärt ist, kann man vielleicht vage antworten, was Dir weiterhelfen könnte. Es gibt für solche Kopplungen mehrere Lösungswege: Entweder Du machst den Abgleich auf Basis von eigenen Scripts oder Applikationen (powershell, vbscript, .NET etc), oder man macht es mit Hilfe von fertigen Kopplungs-Produkten (z.B. Microsoft Forefront Identity Manager). Im ersten Fall braucht man viel KnowHow, im zweiten Fall braucht man viel Geld :)

Hallo, das Attribut das Du lesen möchtest, heißt nicht "AccountExpirationDate", sondern vielmehr "accountExpires". Hier siehst du die technischen LDAP-Namen von User-Attributen: SelfADSI : Attribute für AD User (Windows 2008) Das Attribut ist nicht ganz trivial auszulesen, weil es als so genannter Integer8-DateTime Wert gespeichert wird. Das sind dann Datum+Zeit ausgedrückt als 100-Nanosekunden-Abschnitte seit 01.01.1601 !! :) Hier gibt's Infos, wie mn solche Werte umwandelt in ein lesbares Datum: SelfADSI : Microsoft Timestamp / Interval Attribute mit Integer8 Syntax Viel Spass beim Scripten! Philipp

Hallo, einen Vorschlag hätte ich noch: Wenn Du den Inhalt Deines Papierkorbes in einem Tool mit grafischer Anzeige anschauen willst, dazu vielleicht noch Objekte wiederherstellen am Original-Ort oder einem beliebigen anderen Container, dazu einen Überblick über die Parameter zu Thombstone-Lifetime und Deleted-Objects-Lifetime... ..dann nimm doch das kostenlose Tool hier: LAZARUS - Active Directory Deleted Objects Recovery :) Gruß, Philipp

Warum zu lang ? Also rein vom System her kann ein DC locker mit Abfragen von weit mehr als 1000 Characters umgehen. Ist dass Eingabefeld in der MMC beschränkt oder was?

Hmm, leider sieht es so aus, als müsstest du mit der langen Filtersyntax zurechtkommen. Denn wenn du mehrere Gruppen hast (z.B. XY.1, XY.2 oder XY.3), dann gibt es tatsächlich nur den Weg, die Mitgliedschaft einzeln über ODER-Verknüpfungen abzufragen. Also an (&(|(memberof=CN=XY.1,OU=Groups,OU=XY,OU=X,DC=subdomain2,DC=subdomain1,DC=de)(memberof=CN=XY.2,OU=Groups,OU=XY,OU=X,DC=subdomain2,DC=subdomain1,DC=de)(memberof=CN=XY.3,OU=Groups,OU=XY,OU=X,DC=subdomain2,DC=subdomain1,DC=de))(objectCategory=user)) führt nichts vorbei. Denn: Für die Abfrage nach einem Distinguished Name - Attribut (in unserem Fall "memberOf") sind keine Wildcards erlaubt. Ein (&(memberof=CN=XY.*,OU=Groups,OU=XY,OU=X,DC=subdomain2,DC=subdomain1,DC=de)(objectCategory=user)) klappt also nicht! Übrigens würde ich das Kriterium "(objectCategory=user)" immer ans Ende des Filters hängen, der Filter wird nämlich in der Reihenfolge der Kriterien ausgewertet, wenn das am Anfang steht, dann dauert die Abfrage viel länger, weil der DC erstmal ziemlich viele Treffer hat dadurch. Tip: SelfADSI : LDAP Filter Gruß, Philipp

Hallo, also es noch nicht allzulange her ist, seitdem die Accoutns gelöscht wurden - d.h. wenn die Tombstones noch vorhanden sind (z.B. unter W2K8 180 Tage), dann kannst Du die Objekte mit einem geeigneten Tool im "Deleted Objects"-Container anzeigen lassen mit SID. LEX - The LDAP Explorer kann z.B. sowas: Gruß, Philipp

Hallo, ich wollte noch anmerken, dass Quest Intrust mittlerweile abgelöst wurde durch das Produkt Quest Change Auditor. Der kann u.A. Mitgliedschaften überwachen und dann in Echtzeit eine Mail senden. Ist als ausgewachsene Audit-Lösung allerdings nicht gerade sehr billig und wahrscheinlich nicht so geeignet für das was du willst. Der Vorschlag mit dem stündlichen Powershell-Script dürfte wahrscheinlich am passensten für Deine Zwecke sein. Gruß, Philipp

Hallo, also allein von der Logik her müßte es eigentlich reichen, den "System Management" Container genau in der Domäne anzulegen, in der sich der oder die SCCM-Server befinden. Denn was in diesem Container liegt, ist ein Objekt für je einen SCCM Server mit Managemenent Point Rolle, der in der Domäne installiert wird (Außerdem noch jeweils ein Objekt für jede SCCM-Site, der die betreffenden Server zugeordnet sind). Und diese Objekte werden doch dann von den Servern selbst dort angelegt (deswegen muss man ja auch die entsprechenden Berechtigungen vergeben...). D.h.: Jeder SCCM-Server legt das Zeug in seiner Domäne an und das war's. Die Clients müssten diese Info doch eigentlich aus dem Global Catalog auslesen können (also auch über Domänengrenzen hinweg), um "ihre" SCCM-Server und -Sites zu finden. Nur so eine Vermutung... Gruß, Philipp

Hi Alex, ja das Attribut ist auch in einem W2K8 R2 / Ex 2010 Schema noch nach wie vor mit den gleichen Eigenschaften wie früher vorhanden, es ist ein Unicode-String: Phone-Pager-Primary attribute (Windows) Gruß, Philipp

Hallo, nö, man kann ruhig einen ganzen ScriptBlock mit Try/Catch "versorgen", um größere Scripts leserlich zu halten...Schließlich werden Try/Catch Strukturen auch oft hierarchisch verschachtelt, wenn man da nicht zusammenfasst wird einem ja schwindelig :) Eine Verbesserung und genaue Information, woher der Fehler kommt und in was der Fehler besteht, wäre z.B. sowas hier: try { $currentAction = "Schritt 1" Mach-Irgendwas -IrgendeinParameter $currentAction = "Schritt 2" Mach-Nochwas -IrgendeinParameter $currentAction = "Schritt 3" Mach-Waszuletzt -IrgendeinParameter } catch [exception] { Write-Host ("Fehler bei $currentAction : " + $_.ToString()) } Gruß, Philipp

Hallo, also die "Import-Module" Kommandos springen im Fehlerfall erst dann in den "Catch"-Bereich, wenn du sie so verwendest: Import-Module servermanager [b]-ErrorAction Stop[/b] Import-Module activedirectory [b]-ErrorAction Stop[/b] Un bei dem anderen, der im Fehlerfall trotz Sprung in den Catch trotzdem noch seinen Fehlertext ausgibt, würde ich es mal mit Remove-Windowsfeature RSAT-AD-PowerShell [b]-ErrorAction SilentlyContinue[/b] probieren. Gruß, Philipp

Vielleicht fehlt Eurem Account noch die Berechtigung : "Reset Password" auf Computer-Objekte, und zwar auf Domänenebene, vererbt nach unten. Es handelt sich dabei um eines der "Extended Rights"....mit DSACLS muss man dann "Control Access" (CA) als Recht vergeben, mit einem "Reset Password" dahinter. Gruß, Philipp

Hallo, das hört sich für mich nach einem Problem der maximalen Token Size an, und zwar wegen der "vielen" Gruppen, in denen ein betroffener Benutzer Mitglied ist. Denn er muss die SID (Security ID) jeder Gruppe bei der Anmeldung in seinem Access Token speichern. Man kann auf den Workstations die MaxTokenSize hochsetzen, dann passen mehr rein. Bei maximal 1015 Gruppen ist jedoch Schluss, da gibt es eine nicht unüberwindliche Grenze..... Schau mal hier nach: EventID 6 - Maximale Tokensize überschritten | Michael Foltin IT Consulting Gruß, Philipp