AD Attribute vermisst

[Molle 0]

Hallo Community,

 

ich stehe etwas auf dem Schlauch und mit der schleichenden Angst mich selbst zu disqualifizieren beschreibe ich mein folgendes Problem:

 

Auf meinem Testsystem möchte ich einen Powershell - Befehl ausführen welcher unter anderem per "get-aduser" Benutzer herausfiltert.

Hierbei wird u.A. "Enabled = $True" und "PasswordNeverExpires = $False" abgefragt. Ich erhalte jedoch als Ergebnis nur die Domain Admins aus der OU "Administrators" und keinen einzigen Domain User.

Mir ist nun aufgefallen, dass diese beiden Attribute (und noch ein paar andere die ich benötige) überhaupt nicht im Attribute Editor der User aufgeführt werden. Stimmt hier etwas mit dem Schema nicht oder mache ich generell etwas falsch?

Umgebung ist ein DC Windows 2012 auf selbigem Funktionslevel.

 

Grüße und Danke.

[Doso 77]

Falls du über das GUI drauf schaust, da musst du erst die "Advanced Features" anschalten das du die siehst. Bei get-aduser wird nur ein Teil der Attribute eingelesen, weitere musst du mit dem Prameter -properties angeben.

[Molle 0]

Danke für deine Antwort. Advanced Features waren aktiviert. Auch die Variable "properties" hilft nicht.

 

get-aduser -identity "mein Domain User Account" -> Attribut "Enabled" taucht nicht auf

get-aduser -identity "mein Domain Admin Account" -> Attribut "Enabled" wird aufgeführt.

 

Selbiges mit dem Zusatz " -properties * ", beim Domain User steht lediglich das Attribut "PasswordLastSet wohingegen beim Domain Admin Account hier auch "PasswordExpired" und "PasswordNeverExpires" aufgeführt werden.

[NilsK 3.046]

Moin,

 

es gibt kein Attribut "enabled" und auch kein Attribut "password never expires". Diese Eigenschaften sind in dem Attribut userAccountControl binär kodiert.

 

Die PowerShell nutzt Pseudo-Attribute, um den Umgang damit zu erleichtern.

 

Mein Doku-Tool José wertet diese Eigenschaften aus, einige andere tun das auch.

http://www.faq-o-matic.net/jose/

 

Gruß, Nils

bearbeitet 27. Januar 2015 von NilsK

[Doso 77]

PasswordNeverExpires ist einer der Sachen die du mit propierties reinladen musst:

 

get-aduser username -properties "passwordneverexpires"

 

Beide Attribute die du genannt hast sind auch berechnet und so nicht vorhanden, bei set muss man hier aufpassen wegen true/false.

[Reingucker 3]

Stimmt. In 2012 r2 geht es mit

 

"get-aduser -identity karl -properties enabled,passwordneverexpires | fl Name,enabled,passwordneverexpires"

 

in der Powershell und gibt dann

 

"Name: Karl

enabled: True

passwordneverexpires: True"

 

aus.

Edit:

 

Oder wenn man viele auf spezielle properties mit bestimmten Werten abfragen will, dann z.B.

 

"get-aduser -filter * | where-object -property "enabled" -eq $true | ft Name,enabled"

 

Listet dann alle mit enabled true in einer Tabelle mit zwei Spalten auf, links der Name, rechts Wert für enabled.

[Molle 0]

Vielen Dank für eure Antworten. Mit "get-aduser -identity "Karl" -properties enabled,passwordneverexpires | fl Name,enabled,passwordneverexpires" erhalte ich nur:

 

Name: Karl

enabled:

passwordneverexpires:

 

und das obwohl Karl Enabled ist und auch den Haken bei Password never expires gesetzt hat.

 

Mit "get-aduser -filter * | where-object -property "enabled" -eq $true | ft Name,enabled" werden auch nur wieder die Domain Admins aus der OU "Administrators" ausgegeben, kein einziger Domain User.

 

Gleiches Spiel mit Nils' Doku - Tool (was ich schon seit längerem gerne nutze, danke hierfür an dieser Stelle). Bei den Domain Admins werden Kontenattribute wie z.B. "ADS_UF_DONT_EXPIRE_PASSWD" angezeigt, bei den Usern fehlen diese.

[NilsK 3.046]

Moin,

 

das ist ja spannend. Kannst du bei den Usern, wo die Ausgabe fehlt, per ADSI Edit auf das Attribut userAccountControl zugreifen? Wenn ja, was steht da drin?

 

Gruß, Nils

[Molle 0]

66048 bzw. 0x10200 = (NORMAL_ACCOUNT | DONT_EXPIRE_PASSWD)

[Reingucker 3]

Als Idee (ohne ausreichenden Wissenshintergrund)

 

Vielleicht fehlt ihm mit seinem Acc das Recht die erweiterten Attribute anderer User zu lesen?

 

Edit:

 

Gut, widerspricht sich hier aber mit dem Zugreifen über adsiedit.

bearbeitet 28. Januar 2015 von Reingucker

[NilsK 3.046]

Moin,

 

gut, das ist schon mal konsistent. Ich kann mir nicht recht erklären, warum die PowerShell und die anderen Tools das nicht ausgeben.

 

Sind in eurem AD evtl. die Zugriffsberechtigungen angepasst? Normalerweise sind die genannten Attribute ganz normal für Authentifizierte Benutzer lesbar, wenn ich nicht irre.

Vielleicht liegt es aber auch an "Prä-Windows 2000-kompatibler Zugriff", das kann ich gerade nicht nachverfolgen. Wer ist denn in deinem AD in dieser Gruppe Mitglied?

 

Gruß, Nils

bearbeitet 28. Januar 2015 von NilsK

[Reingucker 3]

Mit den Filtern "Verbindlich" und "Optional" im AD-Benutzer-Computer auf einen ACC Eigenschaften des Users im Reiter "Attribut-Editor" hat es mal nichts zu tun. Die Powershell kann dann trotzdem auslesen.

[NilsK 3.046]

Moin,

 

Mit den Filtern "Verbindlich" und "Optional" im AD-Benutzer-Computer auf einen ACC Eigenschaften des Users im Reiter "Attribut-Editor" hat es mal nichts zu tun. Die Powershell kann dann trotzdem auslesen.

 

das steuert ja auch nur die Anzeige im Attribut-Editor (bzw. in ADSI Edit, wo der Editor herkommt). Das ist keine Funktion, sondern ein Anzeigefilter (der sich auf die Schema-Definition der Attribute bezieht: sind sie "verbindlich", müssen also beim Objekt vorhanden sein, oder sind sie "optional", können also leer bleiben).

 

Gruß, Nils

[Reingucker 3]

Moin,

 

 

das steuert ja auch nur die Anzeige im Attribut-Editor (bzw. in ADSI Edit, wo der Editor herkommt). Das ist keine Funktion, sondern ein Anzeigefilter (der sich auf die Schema-Definition der Attribute bezieht: sind sie "verbindlich", müssen also beim Objekt vorhanden sein, oder sind sie "optional", können also leer bleiben).

 

Gruß, Nils

 

Yep.

 

Wie ist es mit

 

ADS_RIGHT_DS_READ_PROP +

 

Damit kann man ja auch Berechtigungen setzen welche properties eines Objektes von wem gelesen werden können. Naja, ich hör mal auf zu spammen :)

[Molle 0]

Nach dem Tip von Nils habe ich mich mal mit dem User angemeldet der die Schema- & Enterprise Admin Rolle hat. Mit diesem werden nun alle User korrekt gemäß dem Powershell - Befehl gefunden.