antares

ok, vielen Dank für die Antworten.

Hallo:) Auf einem DC versuche ich mit 'gpedit.msc' die lokalen Richtlinien, insbesondere Einträge unter "Zuweisen von Benutzerrechten" etwas aufzuräumen. Dort finde ich manchmal unaufgelöste SIDs, ein Beispiel: "Annehmen der Clientdatei nach Authentifizierung" (Dieser Wert hat das binäre Symbol und ist also nicht von der DDCP geerbt worden) Nach einem Doppelklick sehe ich folgende Einträge: ----------------------------- *S-1-5-21-128.....-1005" *S-1-5-21-128.....-1006" Administrators DIENST IIS_WPG ----------------------------- Die beiden SIDs oben kann ich auch mit sid2user.exe nicht auflösen. Heutige aktive Domänenbenutzer haben SIDs, welche mit "S-1-5-21-163..." beginnen. Leider verstehe den Aufbau der SIDs zuwenig, und weiss auch nicht genug über deren Auflösung in den Richtlinien. Jedenfalls zeigt "FIND /I "nicht gefunden" %SYSTEMROOT%\Security\Logs\winlogon.log" keine Resultate an. Kann ich solche nicht aufgelöste SIDs als Waisen betrachten, die von gelöschten Usern stammen und sie gefahrlos löschen?

danke sehr, ich werde das testen sobald ich wieder vor ort bin.

Wenn ich auf einer beliebigen XP Workstation (adminpak.msi installiert) das DHCP Snap-In hinzufüge und dann zu einem Server verbinde möchte, wird ausser dem (einzigen) korrekten DHCP Server auch noch der Name eines alten DHCP/ DC Servers als Verbindungsziel aufgelistet. Dieser alte Server wurde nie ersetzt und seine Meta Daten mit dem bei MS beschriebenen Verfahren gelöscht. (D.h. als DC ist er im AD nicht mehr zu finden.) Ist diese "Erinnerung" bezüglich DHCP im AD abgelegt, kann ich das mit ADSIEDIT finden und löschen? Danke und Gruss antares

Vielen Dank ;) Hat geholfen.

Stimmt, daran habe ich noch gar nicht gedacht! Gibt es mögliche 'side effects', oder verlieren die User beim Downgrade der FREIGABE Rechte von "Vollzugriff" auf "Ändern" noch sonst etwas, neben der Möglichkeit auch bei Vollzugriff unter den Dateirechten "Berechtigungen zu ändern" ? (Eine Desktop Umleitung ist betroffen und die angebundenen HomeDirDrives) Diese werden bei neuen Usern erstmalig erzeugt. Dies wird mit Dateirechten im übergeorneten Folder erreicht und sollte vom diesem Downgrade eben hoffentlich nicht betroffen sein..) Und falls zur Frage zwei (Tool) noch jemand eine Idee hat, wäre ich sehr dankbar ;) . antares edit: PAT, ich habe dein Post zu spät gesehen, danke! Dann bleibt wohl nur noch die Frage nach dem Tool für die Anzeige eines Besitzers, wenn der Admin schon ausgesperrt ist.

Hallo Die Steuerung der eventlog Security geschieht in der Registrierung: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\Application\CustomSD Der Eintrag ist in der sog. SDDL-Syntax und reichlich kryptisch. Aufschluesselung des Eintrags: O:BA Object owner is Built-in Admin (BA). G:SY Primary group is System (SY). D: This is a DACL, rather than an audit entry or SACL. (D;;0xf0007;;;AN) Deny Anonymous (AN) all access. (D;;0xf0007;;;BG) Deny Built-in Guests (BG) all access. (A;;0xf0005;;;SY) Allow System Read and Clear, including DELETE, READ_CONTROL, WRITE_DAC, and WRITE_OWNER (indicated by the 0xf0000). (A;;0x7;;;BA) Allow Built-in Admin READ, WRITE and CLEAR. (A;;0x7;;;SO) Allow Server Operators READ, WRITE and CLEAR. (A;;0x3;;;IU) Allow Interactive Users READ and WRITE. (A;;0x3;;;SU) Allow Service accounts READ and WRITE. (A;;0x3;;;S-1-5-3) Allow Batch accounts (S-1-5-3) READ and WRITE. Bitmuster: 0x0001 ELF_LOGFILE_READ Permission to read log files. 0x0002 ELF_LOGFILE_WRITE Permission to write log files. 0x0004 ELF_LOGFILE_CLEAR Permission to clear log files. Möchtest Du einen speziellen User berechtigen das eventlog zu durchforsten so brauchst du als ersten dessen SID (dazu gibt es Skripts auf dem Netz, s. unten.) und fügst diese Zeile an obigen Eintrag an: A;;0x2;;;SID Damit ist dann der eventlog DIESES EINEN Servers konfiguriert. Für andere Server muss dieselbe Prozedur wiederholt werden. Offizieller KB von MS: How to set event log security locally or by using Group Policy in Windows Server 2003 weitere Infos und SID Skript unter: "Permission denied" error while calling WSH's LogEvent method - ASP antares

Auf einem Quota-relevanten Fileshare soll verhindert werden, dass auf der Dateirechtsebene Besitzer ihrer Dateien den Administrator ausperren können. Da der Besitzer immer Vollmacht hat und die Sicherheitseinstellungen seiner Dateien nach seinem Gusto gestalten kann, frage ich hier nach Möglichkeiten sowas zu erreichen. Auch auf der Suche bin ich nach einem (command line) Tool, welches einem Serveradmin den Besitzer einer Datei anzeigt, auch wenn das GUI meldet, dass er nicht angezeigt werden könne. (evlt würde auch nur die SID reichen, die kann man sicherlich mit Standard-Tools auflösen.)

Ok danke... Dann muss ich wenigstens nicht länger Bugs suchen, wenn's ein Feature ist ;)

Also nur damit ich das richtig verstehe: Es ist tatsächlich NORMAL (*schock*), dass USB Sticks die Netzlaufwerke NICHT berücksichtigen. Oder anders gesagt, Windows weist einem Stick einen Buchstaben zu, auch wenn dort ein Netzlaufwerk "liegt", und das sogar als Standardnormalverhalten?

Unsere XP Clients (in einer W2k3 Domäne) legen zuweil ein eigenartiges Verhalten zu Tage: Physikalisch vorhanden sind: "Datenträger0", "CD 0" und ein virtuelles "CD 1" (via Daemon Tools). Datenträger0: - primäre NTFS Partition -> C:\ - primäre FAT32 Partition mit LINUX -> kein Buchstabe zugewiesen (gewollt) ---erweiterte Partition---- - logisches FAT32 Laufwerk -> kein Buchstabe zugewiesen (gewollt) - logisches FAT32 Laufwerk -> D:\ CD0: F:\ CD1: E:\ (ich hätte CD0 E:\ und CD1 F:\ erwartet, aber dies ist vielleicht auf eine menschliche Interaktion zurükzuführen und hier auch nicht das Problem.) Nun loggt sich ein User ein, und das Logon Skript bindet noch folgende Netzlaufwerke an: G: (ein CD Server) H: (individuelles Homelaufwerk) K: (Klassenlaufwerke) V: (Vorlagen) Bis hier funktioniert alles toll! Nun steckt ein User einen USB Stick ein. Dieser wird aber nun "unter" das CD Laufwerk G: gemountet und der Inhalt ist im Explorer nicht einsehbar da die Daten des CD Servers angezeigt werden (was auch korrekt ist). Wenn nun mittels Rechtsklick das Laufwerk G: der CD Server getrennt wird, kommt dann der Inhalt des Sticks zum Vorschein noch immer unter dem Buchstaben G. Dieses Verhalten zeigt sich bei allen Userklassen (eingeschränkt wie privilegiert). Hat jemand Ideen dazu? Mir ist nicht klar, nach welchen Regeln die USB Massenspeicher einen Buchstaben erhalten. Eventuell wichtig: Damit Schüler ohne Privilegien ihren Stick brauchen können. Haben wir die gängigsten Sticks auf dem Quell-Image Computer schon mal eingesteckt und dem System "bekanntgemacht" . Diese Testumgebung hat natürlich eine leicht andere "Laufwerksbuchstaben-Umgebung". Das dürfte aber meiner Ansicht nach nichts ausmachen. Sticks sind ja genau dazu da irgendwo eingesteckt zu werden...

ja das geht, mindestens wenn ich als /user: einen anderen admin angebe. (bei schülern meldet es einen fehler: benutzerkontenbeschränkung

Ja, er steht auf gestartet (automatisch).

Hallo Leute Weiss jemand gerade WO ich folgendes Verhalten einstellen könnte: Ich habe lokal auf C: eine vbs Datei, welche ich gerne unter anderem Usernamen ausführen möchte. Ich erzeuge also eine Verknüpfung und gehe auf: Eigenschaften->Verknüpfung->Erweitert: Dort sind beide Checkboxen deaktiviert (ausgegraut). Wo/ Wie kann man das ändern? Freundliche Grüsse antares

Mit Windows 2003 Server / XP ist die Skripting-Unterstützung für DiskQuotas verbessert worden und es ist nun für Administratoren kein Problem mehr, mittels WMI ( Verwalten von Datenträgerkontingenten in Windows Server 2003 und Windows XP ) von jedem Computer aus Quota Objekteigenschaften abzufragen, darunter auch objQuota.Limit objQuota.WarningLimit objQuota.DiskSpaceUsed für einen speziellen User. Am Nützlichsten wäre es allerdings, wenn das der User selbst tun könnte, z.B. im Logonskript, und dann eine Meldung bekäme, wenn die Warngrenze überschrittem wird. Leider sehe ich nur "Permission denied", wenn ich als "normaler User" diese Zeile ausführe: Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2") Kann man dies umschiffen, ohne weitere Nachteile für die Sicherheit? Am besten wäre es, wenn der User nur SEINE Limiten abfragen dürfte... Gibt es dazu Lösungen?

Diese Meldung taucht auch regelmässig auf: Es stimmt, es sind 212 Zertifikate unter "Vertrauenswürdige Stammzwertifikate" eingetragen. Aber wie soll ich nun entscheiden, welche man löschen soll und welche nicht. Die Dinger kommen doch automatisch mit den Windows Updates... Wie macht ihr das? Ereignistyp: Warnung Ereignisquelle: Schannel Ereigniskategorie: Keine Ereigniskennung: 36885 Datum: 08.03.2007 Zeit: 15:12:43 Benutzer: Nicht zutreffend Computer: HANNIBAL Beschreibung: Bei der Nachfrage der Clientauthentifizierung sendet dieser Server eine Liste vertrauenswürdiger Zertifizierungsstellen an den Client. Der Client verwendet diese Liste, um ein Clientzertifikat auszuwählen, das für den Server vertrauenswürdig ist. Momentan vertraut dieser Server sehr vielen Zertifizierungsstellen, sodass die Liste zu lang ist. Die Liste wurde abgeschnitten. Der Administrator dieses Computers sollte die für Clientauthentifizierung vertrauenswürdigen Zertifizierungsstellen überprüfen und diejenigen entfernen, die nicht unbedingt als vertrauenswürdig eingestuft werden müssen.

Ich glaubte schon unsere CertSvc Probleme gelöst zu haben. Nun taucht nach eine Pause von 8 Tagen folgende Kombination von events im log des momentan einzigen DC (hannibal) auf, auf welchem auch die einzige Zertifizierungstelle läuft. Ereignistyp: Fehler Ereignisquelle: CertSvc Ereigniskategorie: Keine Ereigniskennung: 22 Datum: 08.03.2007 Zeit: 11:44:53 Benutzer: Nicht zutreffend Computer: HANNIBAL Beschreibung: Die Anforderung 631 konnte aufgrund eines Fehlers nicht ausgeführt werden: Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war. 0x80092013 (-2146885613). Die Anforderung bezog sich auf CN=NBB02.kinet.local. Weitere Informationen: Fehler beim Verifizieren der Anforderungssignatur oder des Signierungszertifikats Zeitgleich kommt auch folgender Fehler: Ereignistyp: Warnung Ereignisquelle: CertSvc Ereigniskategorie: Keine Ereigniskennung: 77 Datum: 08.03.2007 Zeit: 11:44:53 Benutzer: Nicht zutreffend Computer: HANNIBAL Beschreibung: Der Richtlinienmodul "Windows-Standard" hat folgende Warnung protokolliert: Die Active Directory-Verbindung mit HANNIBAL wurde wiederhergestellt mit HANNIBAL. Ist das zu ignorieren, oder besteht Handlungsbedarf? Leider sind CertSvc eine "black art" für mich... Gibt es eine einfache Checkliste, um zu überprüfen, ob die installierte Ziertifizierungstelle ordentlich ihren Dienst erledigt. (Anders gefragt, was ist eigentlich der Standardbetrieb und die Standardeinstellungen?)

Du musst rausfinden welche Soundkarte / Onboard Soundchip in Deinem Computer steckt. Entweder steht das in der Unterlagen des Computer, oder, falls Deine Soundanschlüsse hinten nicht auf einem "Kartenblech" eines Steckplatzes sind, sondern auf dem Mainboard selber, auf den Internetseiten des Mainboardherstellers. Danach kannst Du wiederum beim Mainboardhersteller Treiber für Sound runterladen, oder beim allfälligen Soundkartenhersteller. Anständigerweise sollten bei Onboard Sound auch die Treiber noch auf einer TreiberCD mit dem Computer gekommen sein. (Pech hast Du, wenn es nur eine AllInOne Wiederherstellungs CD ist) antares

Ich habe gewartet und extra unter "AD-Standorte und -Dienste" noch manuell eine Replizierung erzwungen. Ein erneutes gpresult / rsop.msc liefert immer noch denselben (falschen) output im Vergleich zu gpedit.msc. Kann man irgendwie die lokalen Richtlinien ganz entfernen, resp. alle auf die ursrünglichen Werte zurücksetzen? (Ich komme auf die Idee, weil bei DC (A) gpresult noch steht, dass die lokalen Einstellungen übergangen würden, weil leer) Ich bin wirklich ratlos in der Sache...

Das Verhalten ist nun besser, aber ganz "normal" scheint es immer noch nicht zu sein: Bei der Default DC Policy war die Vererbung deaktivert. Nach dem Aktivieren der Vererbung definierte ich der Default Domain Policy noch einmal neue nie vorher dagewesene Kenntwortrichtlinien und führte beiden DCs ein GPUPDATE aus. Mache ich nun ein gpedit.msc und zeige die Kennwortrichtlinien an, so stimmen die Werte nun mit denjenigen der Default Domain Policy überein, und sie stehen hinter Domänensymbolen. So weit so gut. Irritierend ist aber, dass "rsop.msc" sowie "gpresult /V" beim primären Domänencontroller (A) alles erwartungsgemäss anzeigen, nicht aber beim zusätzlichen / Reserve Domänencontroller (B): Kennwortrichtlinien mittels "rsop.msc": (A) Domänen Symbole und die korrekten Werte aus der Default Domain Policy (B) Lokale Symbole und die Werte "Nicht definiert" (steht im Widerspruch zu gpedit.msc) gpresult /V: (A) Es werden Einstellungen der Default DC Policy und der Default Domain Policy verarbeitet. Die korrekten Kennwortrichtlinien mit Quelle=Default Domain Policy werden ausgegeben. (B) Es werden Einstellungen der Default DC Policy, der Default Domain Policy und der lokalen Richtlinie verarbeitet. Es tauchen keine Kennwortrichtlinien auf (wohl aber Kerberosrichtlinien aus der Default Domain Policy auf.) Verhindern nun lokale Einstellungen, welche ich mit gpedit.msc nun gar nicht mehr zu Gesicht bekomme, die korrekte Ausgabe? Was gilt nun für (B), das was gpedit.msc meldet, oder das was gpresult und rsop.msc melden und warum zum Geier ist da überhautp eine Inkonsistenz....

Hallo;) Kenn jemand von euch Ursachen oder Zusammenhänge, warum Clients plötzlich solche Fehlermeldungen(s. unten) produzieren können? Besonders nach einem Sysprep Vorgang? Mit esentutl lässt sich die "beschädigte" secedit.sdb (welche nur als "out of date" beurteilt wird) wieder in Ordung bringen, zwar nicht mir der "Soft" Variante, sonder mit der option /p forcieren. Danach geht alles gut, bis wir das nächste Mal Images verteilen, oder bis aus uns nicht bekannten Gründen einzelne Clients wieder dieses Problem haben. P.S. an Moderatoren: Ich habe (Schande über mich) seit Jahr und Tag ins andere, allgemeine Forum gepostet, dabei waren es eigentlich immer Server Themen... Auch jetzt ist von mir ein Thema aktiv. Das darf also gerne transferiert werden... ------------------------------------------------------------------------------ Ereignistyp: Warnung Ereignisquelle: SceCli Ereigniskategorie: Keine Ereigniskennung: 1202 Datum: 19.05.2006 Zeit: 12:30:29 Benutzer: Nicht zutreffend Computer: OMIKRON Beschreibung: Die Sicherheitsrichtlinien wurden mit Warnungen verbreitet. 0x4b8 : Ein erweiterter Fehler ist aufgetreten. -------------------------------------------------------------------------- Ereignistyp: Fehler Ereignisquelle: Userenv Ereigniskategorie: Keine Ereigniskennung: 1085 Datum: 19.05.2006 Zeit: 12:30:29 Benutzer: NT-AUTORITÄT\SYSTEM Computer: OMIKRON

Bin nicht sicher ob ich verstanden habe was Du möchtest. Geht es Dir nur darum Daten samt Berechtigung zu kopieren, dann kann ich Robocopy empfehlen. Download details: Windows Server 2003 Resource Kit Tools

Danke für die Antwort. Da ich an der betroffenen Schule immer nur Freitags arbeite, kann ich erst morgen die Vererbung überprüfen. Das scheint mir nun die einzige vernünftige Erklärung zu sein! Die GPOs sind laut GPOTOOL in Ordung und auf beiden DCs korrekt repliziert.

Zwar komme ich der Sache auf die Spur, aber verstehen tu ich es nicht :(. Ich habe wie oben gesagt, versucht Kennwortrichtlinien zu definieren. Ich tat dies mittels dem Snap-In "Gruppenrichtlinienverwaltung" welches ich auf einem XP Client installiert habe. (Dazu installierte ich adminpak.msi von der 2003 Server CD) Ich bearbeitete die Default Domain Policy und checkte dann auf anderen Clients (mit gpedit.msc), ob die neuen Werte korrekt übernommen wurden, was erfolgreich schien. Nur die Scripte (s.oben) meldeten dann immer noch konsequent die alten Werte. Aus lauter Neugier habe ich dann die LOKALEN Richtlinien mal auf den Domänencontrollern angesehen (mit gpedit.msc), und siehe da, dort waren die Werte wie eh und je auf 70 Tagen. Scheinbar muss ich also weder die Default Domain Policy via Snap-IN auf einem Client, noch die Default Domain Policy via Snap-In auf einem DC, SONDERN die lokalen Richtlinien auf einem der beiden DC anpassen! Danach stimmte auch gleich die Default Domain Policy überein, alle Clients, und auch die Skripte. Es kommt auch nicht darauf wessen DCs lokale Kennwortrichtlinien ich anpasse. Ich finde das nicht normal, oder habe ich da systematisch was falsch im Kopf? Ich dachte immer, dass sowas in der Default Domain Policy eingestellt wird, oder falls dort nicht konfiguriert, in einer extra GP, welche auf Domänenebene verknüpft wird. Bitte helft mir, sonst kratze ich mir noch sämtliche Haare vom Kopf... antares

Ich habe vor einer Woche die Kennwortrichtlinie der Default Domain Policy abgeändert. Andere Richtlinien in untergeordneten OUs versuchen NICHT, diese Einstellungen zu konfigurieren, weil das meiner Kenntnis nach sowieso nur auf Domänen - Ebene geregelt werden kann. Alle Änderungen scheinen von den Clients übernommen, jedefalls stimmen die Werte überein, wenn ich auf einem Client "gpedit.msc" ausführe, und die Kenntwortrichtlinien anzeigen lasse. Insbesondere habe ich den Wert "Maximales Kennwortalter" von 70 auf 365 Tage geändert. Hartnäckig meldet mir aber mein ADO Script (vbs schnipsel angehängt), dass das Kennwortalter immer noch 70 Tage sei. (Das entspricht dem früheren Wert) Ich dachte letzte Woche, dass da irgednwas noch nicht propagiert sei, aber heute versetzt mich dieselbe Anwort schon ins Staunen. Ist irgendwas mit den Policies nicht gut, oder ist mein Script irgendwie falsch/veraltet usw? Auch der alternativ verwendete ADSI NT Provider meldet 70 Tage zurück. ---schnippel---VBS----------------------------------------------------------- Set oDomain = GetObject("LDAP://" & strDomainDN) Set maxPwdAge = oDomain.Get("maxPwdAge") '======================================== ' Calculate the number of days that are ' held in this value. '======================================== numDays = CCur((maxPwdAge.HighPart * 2 ^ 32) + _ maxPwdAge.LowPart) / CCur(-864000000000) WScript.Echo "Maximum Password Age: " & numDays 'Umrechung ist etwas verwirrlich, aber VBS kommt mit grossen Zahlen 'nicht allzugut zurecht und man muss sich mit "Currency" behelfen. ---------------------------------------------------------------------------------