P.Foeckeler

Hey, wenn ich noch ein paar technische Internas anmerken darf... User, die sich noch nie angemeldet haben, für die steht das Attribut "lastlogonTimeStamp" auf 0 oder ist nicht vorhanden. Das Datum, wann ein Benutzer sein Passwort zum letzten Mal gesetzt hat, kannst Du aus dem Attribut "pwdLastSet" auslesen, allerdings handelt es sich um einen Microsoft Integer-Wert, der erst in ein Datums-und Zeitformat umgewandelt werden will... entweder per Script oder mit Tools: Artikel im SelfADSI Tutorial über Microsoft Integer8 Auslesen, ob ein User ein Passwort hat oder nicht, das geht nicht, dazu müßtest du schon ein Cracking-Tool (oder im Euphemismus "Password Auditing" tool) wie z.B. L0phtCrack einsetzen. Aber gibt's da nicht "ethical issues", wenn man die Paswörter seiner Benutzer auslesen will? :shock: Gruß, Philipp

Hmmm, ok probier nochmal alles was in http://support.microsoft.com/kb/921913 steht, ist eigentlich das gleiche in grün, aber vielleicht haben wir irgendeine Kleinigkeit vergessen, wie z.B. das noch eine aktive MMC da war oder das die DLL erst nach %SFUDIR% kopiert werden soll.... Gruß Philipp

Hey, probiers mal mit dem Neuregistrieren der entsprechendn DLL: REGSVR32 NISPROP.DLL Unabhängig davon könnte Dich das hier auch interessieren: http://www.selfadsi.de/attributes-sfu.htm Gruß, Philipp

Hmmm, es gibt auf dem Server kein einfaches Protokoll-Log a la "LDAP Session wurde erfolgreich über SSL aufgebaut"... Um wirklich sicher zu gehen, dass man auf dem Netz LDAP-verschlüsselt unterwegs ist, fällt mir mal auf die Schnelle nur der hier ein: http://www.wireshark.org/ Unverschlüsseltes LDAP ist nämlich im Paket Sniffer sehr leicht zu identifizieren, ein Beispiel für einen Wireshark-LDAP-Sniff unverschlüsselt hast du z.B. hier: http://www.selfadsi.de/ldap.htm#Frame Wenn Du bei dir keine lesbaren Kommandos / DNs / Attributwerte siehst wenn Dein Script läuft, dann kannst Du beruhigt sein ;) Gruß, Philipp

Halli Hallo, im Artikel den Nils genannt hat ist es irgendwo im Kleingedurckten versteckt, ich wollte es aber nochmal klarstellen, weil es des öfteren zur Verwirrungen führt: Active Directory Domänencontroller / AD LDS Server unterstützen z.Zt. das StartTLS Kommando NICHT. Das sieht man u.a. daran, wenn man über LDAP die Eigenschaften supportedCapabilities und die supportedControls im rootDSE-Eintrag ausliest. Für StartTLS müßte hier die OID 1.3.6.1.4.1.1466.20037 vorhanden sein. Was geht, ist LDAP over SSL, d.h. du kannst zwar nicht innerhalb einer LDAP-Session auf TLS wechseln, aber Du läßt von vornherein die gesamte LDAP Session innerhalb eines SSL-Tunnels ablaufen, indem Du Dich mit Port 636 auf dem Domänencontroller verbindest, das geht aber nur wenn dort ein Zertifikat installiert ist (aber dies ist ja im Artikel den Nils genannt hat ausführlich beschrieben). Btw.: Wenn du das hier machst dann hat das nix mit SSL zu tun, sondern du benutzt den Signing and Sealing Channel Encryption Mechanismus der Negotiate Auth Kerberos Authentication, die ein Domänencontroller unterstützt, d.h. nicht nur User/PAsswort wird verschlüsselt, sondern auch die Daten (das ist aber Microsoft SSPI und nicht SSL...), Hinweise darauf findest Du hier http://www.joekaplan.net/SearchView.aspx?q=digest#afcdf0808-8196-4eb7-b171-8b54a5790687 da geht es zwar um Digest Auth, aber es wird auch was zur Channel Encryption erklärt. Fazit: Probiers mal über den 636 Port, oder benutz einfach Negotiate Auth, das verschlüsselt auch. Gruß, Philipp

Hallo, Nein, das ist genau anders herum, wenn du die Vererbung deaktivierst (Option "Block Inheritance" im Kontextmenu einer OU in der GPMC-Konsole), dann werden die Einstellungen der oberhalb liegenden OUs nicht übernommen, also genau das was du willst. Ansonsten denk bitte daran, dass der Begriff "Vererbung" in Filesystemen, bei AD-Objektrechten, bei GPOs, bei GPO-BErechtigungen uswuswusw. vorkommen kann, deswegen war die Frage anfangs ziemlich unverständlich ;) Gruß, Philipp

...ist gegeben, da Standard-Permission "Authenticated Users: Read", und da gehört der TS dazu. Hab mich vielleicht unklar ausgedrückt :rolleyes:: autowolf, also nicht alle Rechte wegnehmen, sondern nur das Häckchen "Apply" für Authenticated Users in der Advanced Ansicht der GPO Rechte). Dann ein neues Recht hinzufügen, mit "Apply" für die Gruppe der Azubis. ...du hast genau recht....:eek: :) Gruß, Philipp

Hallo, es kann daran liegen, dass der Loopback-Modus so arbeitet, dass die am TS hängende GPO über deine Azubi-GPO gewinnt, auch wenn Du Loopback auf "Zusammenführen" stellst. Gibt es hier Einstellungen, die miteinander konkurrieren, dann gewinnt hier die Loop-Back-GPO, also bei Dir die TS-GPO.... Probiers mal hiermit: - Ändere Die Rechte, so dass für Deine AZUBI-GPO niemand das "Apply"-Recht hat außer den Azubis selbst. - Häng Deine AZUBI-GPO zusätzlich zu der Azubi-OU auch an deine TS OU, und aktiviere hier auch das Loopback-Verfahren mit "Merge". - Achte darauf, dass die Priorität der GPOs an Deiner TS-OU so ist, dass deine Azubi-GPO VOR der WTS-GPO steht. Gruß, Philipp

Ich noch mal, ich lass nicht locker ;) olc hat mal wieder Recht, ich habe die Sache mit der Primary Group verschlafen. Also hier nur noch mal der Vollständigkeit halber der vollständige LDAP Filter, der auch die primäre Gruppenmitgliedschaft in Domain Admins (RID 512) und Enterprise Admins (RID 519) auffängt (die dom-lokalen BuiltIn-Gruppen können keine Primary Gruppen für einen User sein): DSQUERY * dc=domain,dc=tld –filter "(|(memberOf:1.2.840.113556.1.4.1941:=CN=Domain Admins,CN=Users,DC=domain,DC=tld)(memberOf:1.2.840.113556.1.4.1941:=CN=Enterprise Admins,CN=Users,DC=domain,DC=tld)(memberOf:1.2.840.113556.1.4.1941:=CN=Administrators,CN=Builtin,DC=domain,DC= tld)(memberOf:1.2.840.113556.1.4.1941:=CN=Account Operators,CN=Builtin,DC=domain,DC=tld)(memberOf:1.2.840.113556.1.4.1941:=CN=Backup Operators,CN=Builtin,DC=domain,DC=tld)(primaryGroupID=512)(primaryGroupID=519))" Schöne Grüße, Philipp

Oouch! Stimmt, adminCount wird nicht zurückgesetzt, auch nach dem Entfernen aus den Gruppen. Na da hilft nur das Durchforsten der hochprivilegierten Gruppen nach direkten und indirekten Mitgliedern mit diesem Monster-Filter: DSQUERY * dc=domain,dc=tld –filter "(|(memberOf:1.2.840.113556.1.4.1941:=CN=Domain Admins,CN=Users,DC=domain,DC=tld)(memberOf:1.2.840.113556.1.4.1941:=CN=Administrators,CN=Builtin,DC=domain,DC=tld)(memberOf:1.2.840.113556.1.4.1941:=CN=Account Operators,CN=Builtin,DC=domain,DC=tld)(memberOf:1.2.840.113556.1.4.1941:=CN=Backup Operators,CN=Builtin,DC=domain,DC=tld))" wuuaaaaaa :)

Halli Hallo, eine kleine Idee am Rande, die ganz gut zu Deinem Anliegen passt. Probier mal den LDAP-Filter hier aus: DSQUERY * dc=domaene,dc=de –filter "(adminCount=1)" Damit kriegst du alle Objekte, für die das System die AdminSDHolder-Berechtigungen erzwingt. Das sind im Prinzip alle hoch privilegierten Gruppen Account Operators Administrators Backup Operators Domain Admins Domain Controllers Enterprise Admins Print Operators Read-only Domain Controllers Schema Admins Server Operators und alle Objekte (User, Computer, Gruppen), die dort Mitglied sind, entweder direkt oder über verschachtelte Mitgliedschaften. Das sind doch dann genau die, die Du suchst, oder? Gruss, Philipp

Hallo LEX - The LDAP Explorer kann das auch: :cool: Soweit ich weiß, gab es mal im Windows SDK eine Vorlage für ein C++ DLL-Projekt, mit dem man die Registerkärtchen von "ADS User und Computer" erweitern kann, die dortige Beispiel-DLL hat glaube ich das Photo im User-Attribute "jpegPhoto" angezeigt.... Ich finde es aber auf Anhieb nicht mehr, sorry.... Stichwort war glaube ich "IADSPropertyExtensionHandler"... Gruß, Philipp

Hey, ich nochmal, also grundsätzlich haben die anderen Jungs natürlich Recht und ADModify kann das auch, wobei du immer Rechte brauchst, das zu tun, was du tun willst im AD, egal ob mit einem VBScript, Powershell oder inem Tool.... also daran kann es nicht liegen. Naja, das Script hat in unserem Fall halt die Stärke, dass man eben genau die User aus der Datei auslesen kann, deren Wert man setzen will, und dass man es später erweitern kann wenn man für verschiedene User verschiedene Werte setzen will... Wenn du einfach ALLE User der Domäne oder unterhalb einer bestimmten OU mit einem Einheitswert beglücken willst, dann geht es mit ADModify wirklich _viel_ schneller... Jetzt zu Deinen nicht gefundenen Benutzern: Sicher dass Du oben bei domainDN = ... den richtigen LDAP-PFad Deiner Domäne gesetzt hast... Also für firma.de müßte z.B. DC=firma,DC=de da stehen, und für support.firma.de entsprechend dann DC=support,DC=firma,DC=de. :eek: Außerdem mußt Du das Script auf einem Domänenmitglied ausführen, und zwar als Benutzer, der das Recht dazu hat, im AD die entsprechenden Benutzereigenschaften zu ändern. :eek: Und: Bitte geh sicher, dass in deiner Input-Textdatei mit Benutzernamen pro Zeile _NUR_ der Anmeldenamen des Benutzers dasteht. Ist da vielleicht noch ein Semicolon hinter jedem Namen?? :eek: Die Fehlermeldung wirkt so, als wenn in der Datei in mindestens in der erten Zeile "User" steht, vielleicht als Spalten-Header irgendeines CSVDE-Exports.... Gruß, Philipp

Hallo Abraxas, probiers mal hiermit... das Script liest die Anmeldenamen der Benutzer aus einer Input-Datei, sucht dann das entsprechenden User-Objekt und setzt dann die Werte. Ich habe mal angenommen, dass Du fixe Werte setzen willst, wenn die Werte sich noch pro User unterscheiden und dass in der Input-Datei hinter dem User stehen muß, dann gibt's noch was zu Ändern am Script... Aber mit einer Text-Datei, in der pro Zeile ein Anmeldename eines Users steht, müßte es funktionieren. Vergiss nicht, deinen eigenen Domänennamen als LDAP-PFad einzusetzen. Anregungen/Erklärungen, wie das Script die User sucht und die Werte setzt, gibt's hier: SelfADSI : LDAP Objekte im Verzeichnis suchen mit ADO SelfADSI : LDAP Objekt-Attribute schreiben On Error resume next [color="Red"]inputFilename = "c:\usernames.txt" 'hier eigene Werte einsetzen! domainDN = "DC=yourdomain,dc=com" 'wert für Domäne "yourdomain.com"[/color] Set ado = CreateObject("ADODB.Connection") 'Neue ADO Connection erzeugen ado.Provider = "ADSDSOObject" 'Die ADSI-Schnittstelle verwenden ado.Open "ADS-Search" 'Beliebigen Namen für die Connection vergeben Set adoCmd = CreateObject("ADODB.Command") 'Neues ADO-Kommando erzeugen adoCmd.ActiveConnection = ado 'Zuordnung zur bestehenden ADO-Connection Set fso = CreateObject ("Scripting.Filesystemobject") 'Input-Datei öffnen Set inputFile = fso.OpenTextFile(inputFilename) While Not inputFile.AtEndOfStream 'Zeilen mit Usernamen lesen... userName = Trim(inputFile.ReadLine()) If (Len(userName) > 0) Then wscript.Echo "<LDAP://" & domainDN & ">;(sAMAccountName=" & userName & ");ADsPath;subtree" adoCmd.CommandText = "<LDAP://" & domainDN & ">;(sAMAccountName=" & userName & ");ADsPath;subtree" Set objectList = adoCmd.Execute 'Suche durchführen If (objectList.RecordCount = 1) Then Err.Clear 'mit dem UserObject verbinden Set user = GetObject(objectList.Fields("ADsPath")) If (Err.Number <> 0) Then WScript.Echo "ERROR: Could not connect to user: " & userName & " : " & Err.Number End If user.mDBStorageQuota = [color="Red"]180000[/color] 'Werte setzen user.mDBOverQuotaLimit = [color="Red"]200000[/color] user.mDBOverHardQuotaLimit = [color="Red"]240000[/color] Err.Clear user.SetInfo If (Err.Number <> 0) Then WScript.Echo "ERROR: Could not set limits for user: " & userName & " : " & Err.Number End If Else WScript.Echo "ERROR: User not found: " & userName End If End If Wend Gruß, Philipp

Hi Mini, eine sehr schöne Quelle für Informationen über die Attribute, die hinter den Feldern im den Registerkarten von "ADS User und Computer" stecken, ist das hier: SelfADSI : Attribute für ADS User (Windows 2008) SelfADSI : Attribute für ADS User (Windows 2000 / Windows 2003) SelfADSI : Spezielle AD Attribute für Exchange 2007 SelfADSI : Attribute für ADS Gruppen (Windows 2008) SelfADSI : Attribute für ADS Gruppen (Windows 2000 / Windows 2003) Wie Du dort sehen kannst, sind die Felder die Du meinst Teil des Kombi-Attributes "userParameters". Das Freigeben geschieht, indem du einfach Berechtigungen für dieses Attribut vergibst: Wenn Deine Benutzer in der OU "ou=benutzer,dc=firma,dc=de" liegen, und Du das Recht für eine Gruppe "FIRMA\TerminalOperatoren" freigeben willst, dann geht ds z.B. so: DSACLS "ou=benutzer,dc=firma,dc=de" /I:T /G "FIRMA\TerminalOperatoren":WP;userParameters;user Gruß, Philipp

Hallo rima: Das geht nur mit setzen der Rechte: Du muß das Recht "Write Property" (WP) auf das Attribut "member" an den Manager vergeben, z.B. mit DSACLS.EXE... Hier kannst du sehen, was hinter den Registerkarten der Gruppen-Eigenschaften steckt: SelfADSI : Attribute für ADS Gruppen (Windows 2000 / Windows 2003)

Hallo Stefan, Du hast lediglich das Attribut "Nachname" geändert, für das was Du willst, mußt du ganz grundsätzlich den Objektnamen des Userobjektes ändern. Öffne dazu nicht den Benutzer mit Doppelklick, sondern markiere ihn und drück F2. Dann kommt ein Dialog, indem du nicht nur Vor-, Nach- und Anzeigename ändern kannst, sondern eben auch den kompletten Objektnamen... Gruß, Philipp

OK, für einen kompletten Parallel-Zugriff mußt du erst einen System.IO.FileStream öffnen, da kann man entsprechende FileMode/FileAccess Parameter übergeben, den Streamreader erzeugst Du dann auf der Basis vom Filestream.....es müßte ungefähr so gehen: $path = "C:\test.txt" $open = [system.IO.FileMode]::Open $read = [system.IO.FileAccess]::Read $share = [system.IO.FileShare]::Read $stream = New-Object System.IO.FileStream(($path, $open, $read, $share) $reader = New-Object System.IO.StreamReader($path, $true) ...der Rest dann wie gehabt. :cool: Gruß, Philipp

Hey, hmmm...also wenn man sichs genau überlegt, kann das hier objGroup.Put ("managedBy"), strManagedBy auch nicht funktionieren, versuchs bitte mal mit objGroup.Put "managedBy", strManagedBy oder objGroup.managedBy = strManagedBy Ich weiß, Du hast Dich weiter oben schon gewundert über diese Varianten...schau einfachmal hier nach, da wird das erklärt: SelfADSI : LDAP Objekt-Attribute schreiben Falls es immer noch einen Laufzeitfehler gibt, dann mal her damit mit komplettem Output der Fehlermeldung.. Gruß, Philipp

Hallo rima, ersetz das Set objGroup = GetObject("WinNT://" & Range("conf_NTDomain").Text & "/" & "ACL_SCRIPTING_TEST" & ",Group") mal durch Set objGroup = GetObject("LDAP://CN=ACL_SCRIPTING_TEST,OU=Groups,DC=ABC,DC=mustergroup,DC=com") oder, wenn die ACL_SCRIPTING_TEST Gruppe nicht in der OU "Gruppe" liegt, durch den entsprechenden LDAP Pfad (Erlärungen der LDAP-Pfade -> SelfADSI : LDAP-Pfadnamen und Distinguished Names) Gruß, Philipp

Hallihallo, dsget group "cn=groupe,ou=test,dc=test,dc=local -members | dsget user -hmdir ja, genau so müßte das gehen :) Gibt allerdings einen Fehler, falls in der Gruppe nicht nur User, sondern auch andere Gruppen drin sind... Gruß, Philipp

Hmm ich interpretiere Dein "Die Gruppe ACC_SCRIPTING_TEST soll in die ACL_SCRIPTING_TEST" mal dahingehend, dass Du nicht eine Gruppenmitgliedschaft meinst, sondern nach wie vor das Setzen des ManagedBy-Attributes... Somit müßte das Script-Beispiel von meinem letzten Post eigentlich trotzdem funktionieren. Am besten zu postest hier mal den Code, den Du tatsächlich verwendest... :p Gruß, Philipp

Hallo rima, dein Fehler: Du versuchst die Gruppe selbst in Ihr eigenes ManageBy einzutragen. Das ist für AD-Gruppen verboten. Versuchs mal damit Sub add_manager() Dim objGroup As Object Dim strManagedBy As String Set objGroup = GetObject("LDAP://CN=ACL_SCRIPTING_TEST,OU=Groups,DC=abc,DC=mustergroup,DC=com") strManagedBy = "[color="Red"]CN=IrgendeinManager[/color],DC=abc,DC=mustergroup,DC=com" objGroup.Put "managedBy", strManagedBy objGroup.SetInfo End Sub Gruß, Philipp

Hallo Lamu, du meinst höchstwahrscheinlich die "lokalen" Administratoren der Domäne (man würde hier eher von "Domänen-lokal" reden. Mitglieder dieser Gruppe sind lokaler Admin auf den Domänen-Controllern, und zusammen mit dieser Berechtigung ergibt sich (leider) auch der volle Zugriff auf alle Partitionen der AD-Datenbank, die auf den DCs gespeichert werden (also auch der Inhalt der normalen Domäne). Dadurch hast du also den Zugriff auf Objekte der Domäne. Eine saubere Trennung gibt es leider nicht. Wenn du Administrativen Zugriff auf eine DC vergeben willst (z.B. RDP-Login, Software installieren, Treiber updaten, Patches aufspielen, Rechner booten etc.) dann hast du mit den "Administratoren", die das alles als einzige out-Of-The Box dürfen , auch Zugriff auf das AD.... Du könntest höchsten eine Gruppe erzeugen und dieser Gruppe versuchen, alle gewünschten Berechtigungen direkt zu vergeben, aber das ist ein großer Aufwand und fraglich, ob das tatsächlich in allen Fällen geht (z.B.: wo die BErechtigungen, Windows-Patches auf einem Domänencontroller aufzuspielen, wenn ich kein lokaler Administrator bin???) Fazit: die "Administratoren" der Domäne sind indirekt spo mächtig wie die Domänen-Admins, in der Root-Domäne des Forests sogar so mächtig wie die Enterprise-Admins. Also Vorsicht beim Verteilen dieser Mitgleidschaft! Lokal auf den DCs haben dann einfach nur Domänen-Admins was zu suchen.... Gruß, Philipp

[sorry - hab grad erst bemerkt, dass das ja wirklich uralt ist...naja, jetzt hab ich's schon geschrieben, was soll's... ] HeyHo, ich hab' mir grad Deinen ersten Versuch mit DSACLS.EXE angeschaut, der Ansatz war eigentlich ganz gut, jedenfalls nicht so komplex wie mit .NET System.DirectoryServices eine ACL setzen... schau mal, Dein erstes set ouRoot="OU=Groups,OU=0940,OU=NL,OU=Firma,OU=Domain Resources,DC=xy,DC=xyz" set managergroup=XY\L-AV-0946-VLManager dsacls %ouRoot% /I:S /G %managergroup%:WD;members;group war deswegen falsch, weil das Attribut, für das du das Recht vergeben willst "member" heißt und nicht "members", außerdem willst Du das Recht "WD : Write DACL" vergeben, das hieße du willst das Recht vergeben, Rechte zu setzen. In Wirklichkeit müßte es "WP : Write Property" heißen... also: set ouRoot="OU=Groups,OU=0940,OU=NL,OU=Firma,OU=Domain Resources,DC=xy,DC=xyz" set managergroup=XY\L-AV-0946-VLManager dsacls %ouRoot% /I:S /G %managergroup%:[color="Red"]WP[/color];[color="Red"]member[/color];group Jetzt bleibt "nur" noch ds Problem, wie du das nicht auf den ganzen Container setzt, sondern nur auf die gewünschten Gruppen-Objekte (wobei das eigentlich ganz schlechter Stil ist, das ist als ob du im Filesystem Berechtigungen an einzelne Dateien vergibst...:cry:). Vielleicht haust Du die L-AV-xxxx-PP-*** Gruppen ja in eine Textdatei raus mit eine DSQUERY und wandelst dann jede Zeile schnell in sowas hier um (die Vererbung mit /I:S kannste dann weglassen): set managergroup=XY\L-AV-0946-VLManager dsacls "[i]Gruppe1DN[/i]" /G %managergroup%:[color="Red"]WP[/color];[color="Red"]member[/color];group dsacls "[i]Gruppe2DN[/i]" /G %managergroup%:[color="Red"]WP[/color];[color="Red"]member[/color];group dsacls "[i]Gruppe2DN[/i]" /G %managergroup%:[color="Red"]WP[/color];[color="Red"]member[/color];group ... Besser wär's eigentlich, die Gruppen in eine OU zu verschieben und die Rechte einmal auf die ganze OU zu vergeben... Gruß, Philipp