hgk74

hallo allerseits und danke für erste antworten. und nichts verändert - alles auf default / d.h. der "manchmal-admin"-benutzer ist nicht mitglied einer admin-gruppe und auch keine der extra definierten sicherheitsgruppen - die wiederum u.a. auch diesen benutzer enthalten - ist ihrerseits mitglied der domänen-admin-gruppe. alle benutzer - ausser den 2 admins - haben dasselbe script, im script sind benutzerabhängige drivemappings und diese werden richtig ausgeführt - d.h. für den benutzer, der er auch sein soll. also, es wird nicht das script für den domänen-admin ausgeführt. auch dann nicht, wenn aus sicht des DC angebl. mal wieder der admin angemeldet sein soll. ja und auch da habe ich dasselbe ergebnis, also erste anmeldung nach power on des beliebigen client-PCs geht meist auf "admin" und weitere anmeldungen - ohne den client neu zu starten - gehen meist auf den eigentlichen benutzer. da stimme ich Dir in anderen fällen voll zu, allerdings hat der DC hier nicht viel zu tun. alle CRM/ERP anwendungen sind 3270-sessions , die am DC fast ( er hält den lizenzservice für diese sessions vor ) spurlos vorübergehen. mit der 100MB großen SQL2005_Express-DB arbeiten 2 user höchstens 2 mal pro woche. oder mal als kennzahl: das gesamte transfervolumen über den NIC des "all-in-one-DC " übersteigt pro tag keine 5 GB danke f. d. tip mit whoami , kann ich erst morgen, do., testen, wenn ich wieder vor ort bin. gruß heiner

hallo krombi, IDE oder SATA-Wechselplatte? es hängt evtl. an mangelnder Hotplug-fähigkeit des Treibers. ( "für schnelles Entfernen optimieren." ) Kaum ein Treiber von Nachrüst-Controllern ist Hotplug-fähig. ich kann nicht mit einer direkten Abhilfe dienen, aber ich habe eine SATA-Lösung so hinbekommen: 2k3, Delock PCI-SATA-Raid-ctller 70146, das RAID natürlich abgeschaltet. der Treiber ist auf 2k3 stabil, aber nicht Hot-Plug-fähig. und das Teil ist billig. Trotzdem geht das Wechseln der HD einwandfrei, wenn man vom häßlichen Eintrag im Log absieht, der sagt, dass ggf. bei offenen Dateien wg. des Schreibcaches ( den man nicht abschalten kann) Datenverluste eintreten. Freigeben der Wechselplatte führte zu dem von Dir beschriebenen instabilen Verhalten. d.h. nach wechseln der HD war mal die Freigabe für den fernen Client ( von dem aus nachts Sicherungen zur Wechsel-HD geschickt wurden) tot, mal war sie noch lebendig. Folg. Workaraound führte zum Erfolg: Einbau einer "festen" IDE-HD zusätzl. Dort f. Sicherungs-Zweck Freigabe anlegen. auf diese Freigabe übers Netzwerk sichern. danach per lokalem script ( das also auf dem Server läuft, in dem alle Hardware steckt ! ) von IDE-HD auf Wechsel-HD Sicherung umkopieren. nicht prickelnd fein, aber seitdem erfolgreich. gruß heiner

Fortsetzung : nun das i-Tüpfelchen: auf dem fraglichen Client selbst hat der "manchmal-admin" IMMER nur die seinem Benutzerkonto zugewiesenen Rechte. er ist hier - unabhängig davon, wie ihn gerade der Server sieht - immer nur der "Benutzer", als der er auch lokal angezeigt wird. ------ Ich möchte nun nicht in wilder Hektik an allen möglichen Stellschrauben drehen. wärs der Azubi, hätte ich das Konto sofort gelöscht. es ist aber ein neuer GF, der eh fast alles im Dateisystem sehen und bearbeiten darf. er hat momentan anderes zu tun, als an seinem PC zu sitzen und nutzt diesen jetzt fast nur zum mailen, also kann ich noch etwas forschen. Da ich vom Kerberos-Authentifizierungsprozess zuwenig weiß, würde mich zuerst interessieren, wo auf dem Server wohl die Umdeutung der Benutzer-Anmeldung stattfindet. Die ersten drei Einträge im Sicherheitslog zeigen ja, dass der Client richtige Daten bei der Anmeldung einreicht, erst nach erfolgreicher Anmeldung (Ereignis 540) unter dem richtigen Benutzernamen findet die Rechte-Eskalation statt. Also: wo soll ich angreifen? Wo setzt man nun mit dem debuggen an? danke schon mal fürs hirnen heiner

hallo allerseits, hier eine härtere Nuß: Eine normale Benutzer-Sitzung , gestartet auf einem x-beliebigen Client der Domäne, läuft aus Sicht des Clients im richtigen Kontext des Benutzers also: der user bekommt sein servergespeichertes Profil runtergeschoben und alle settings, wie für ihn vorgesehen. ABER: aus Sicht der Servers läuft diese Sitzung im Kontext des Domänen-admins, d.h. mit Domänen-admin-rechten !!! legt nun dieser Benutzer eine Datei auf einem Netzlaufwerk an, hat sie den Besitzer: Administratoren und er darf auch überall hinschreiben, wo der Domänen-admin R/W-Rechte hat. Serververwaltung / Sitzungen: für den fragl. Client: Administrator dto. / offene Dateien: alle von diesem Client gerade auf dem Svr. bearbeiteten Dateien: Administrator Lesen/Schreiben klingt nach dem Ergebnis eines schier unglaublichen Exploits, deshalb, bevor wilde Spekulation um sich greift, bitte den Rest in Ruhe durchlesen. ich habe einige Tage nebenbei an dem Phänomen geforscht. System: w2k3 Std. SP2 ( Domain-ctrler, Fileserver, Druckserver ) kein exchg. SQL 2005 kaum GPOs definiert ( nur office , Desktop-Erscheinungsbild, IE-Startseite, "auf netzwerk warten" ). keine Delegation von Rechten NTFS-R/W-Rechte im Nutzdateisystem ( = die Dateien des Kunden ) sind ziemlich differenziert festgelegt. Clients : XP SP3 auf den Clients ist Standard-office-SW insta. dazu läuft der UHC ( user profile hive cleanup svc) alle user, ausser Domänenadmins haben server-basierendes Profil dazu ein Vista - Client, dessen einziger user KEIN server-basierendes profil hat. nur dieses eine zuletzt neu angelegte Benutzerkonto ( das auf einem XP-Client genutzt wird ) wird zum "manchmal-admin", alle anderen ca. 20 Benutzer in dieser Domäne sind bisher nicht betroffen. für diesen Nutzer wurde keine Sicherheitsgruppe neu angelegt, er ist wie andere Nutzer auch, in verschiedenen Sich.-gruppen Mitglied. und weil das allein noch nicht spannend genug ist, noch etwas mehr: von 10 An- /Abmeldungen dieses Benutzers an der Domäne, geht die erste am Tage - also nach Einschalten des Clients - fast immer auf "Administrator" und die weiteren bei schon eingeschaltetem Client meist auf den Benutzer. macht man das oft genug, dauernd hintereinander, kommt ein Verhältnis 80% Nutzer und 20% admin raus. es ist ab dem 2. mal aber Roulette, also nie verhersagbar. das habe ich durchgespielt, als ich völlig allein am Netz war. es sind keine offensichtl. fehler in irgendwelchen logs zu sehen. kein anderes problem mit dem ADS. ausser: gelegentlich wird bei benutzeranmeldung auf clients dort das profil des users ( betrifft alle user mit serverbasierenden Profilen und alle clients ) nicht in den schon vorh. ordner <username> repliziert, sondern es werden neue strukturen angelegt: <username>.<domäne> <username>.<domäne>.000 <username>.<domäne>.001 aber mehr als 4 solche Leichen/Benutzerkonto sind auch nach 3 Jahren Betrieb auf keinem Client drin. Das war schon früher oft so und man sieht das auch auf Clients in anderen Domänen. Im Sicherheitsprotokoll des Servers (Ereignisanzeige / Sicherheit) stehen bei erster Anmeldung des Benutzers am Tag die Ereignisse 576, 540, und 538 erfolgreich ganz normal unter diesem Benutzer drin und danach kommt in dieser Session nichts mehr von/unter diesem Nutzer, denn danach ist er Administrator und alles weitere in diesem Log passiert nur noch unter dem Admin-Konto, gerade für diesen Client, also auch die regelmäßige Auffrischung der Benutzeranmeldung. Weil hier der Patz nicht reicht, setze ich in der 1. Antwort fort.....