hgk74

hallo allerseits

und danke für erste antworten.

Sind die betroffenen Benutzer unter Umständen Mitglied der lokalen Administratoren-Gruppe? Siehe System objects: Default owner for objects created by members of the Administrators group .

und

Olc meint damit bestimmt die Domänenlokale Gruppe Administratoren im Container Buitlin auf dem DC

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.

- Hat dieser User ein oder mehrere Anmeldeskripts?

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.

- Hast du das mit diesem User auch von einer anderen Workstation aus versucht ?

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.

(BTW: keine gute Idee, einen DC als File und Printserver und SQL zu benutzen )

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.....