Theo Dor

Warum betrachtet Ihr das ADS nicht einfach als schon gegebene Datenbank auf der per default jeder User fast alle Informationen NUR-LESEN kann. Wenn Ihr also dem First Level Support die MMC "Benutzer und Computer" und den ESM zur Verfügung stellt, dann können die schon mal alles auslesen. Der ESM muss auch nur installiert werden, damit in der MMC die Exchange-Tabs angezeigt werden.

Also, die Einschränkung mit den Computern im Benutzerobjekt betrifft nur die interaktive Anmeldung und nicht den Zugriff auf Freigaben. Insofern kann ich Deine Frage nicht ganz verstehen. Wie erfolgt denn die Einwahl? Wo schlägt die auf? Steht die Verbindung schon und dann kann man nicht auf die Freigaben zugreifen oder kommt die Verbindung erst gar nicht zustande?

Ich glaube, das Attribut (Feld) heißt einfach nur "cn".

Schau mal ins BIOS, was Du da zu USB-Massenspeichern einstellen kannst. Bei einigen Kisten kann man einstellen, welche Emulation gefahren werden soll: Floppy, Harddisk oder CD-ROM. Wennn das auf "Auto" steht dann musst Du -soweit ich das testen konnte - den USB-Stick zwingend mit FAT12 formatieren. Dann wird er beim Booten als Floppy emuliert. Wie ist das eigentlich bei Windows 2008?

Äh... Tobit läuft auf Computer "MX". Und auf einem anderen Computer wurde ein lokaler User "MX$" angelegt? Sieht so aus als wollte da jemand erreichen, dass das lokale System-Konto von Computer "MX", welches eben "MX$" ist, auch auf den anderen Computer zugreifen kann (Peer-To-Peer). Sowas habe ich auch noch nicht gesehen ....

Wenn Du eine "nicht unerhebliche Anzahl an Servern" auf 2 bis 3 reduzieren willst, dann sparst Du am Ende eine Menge Heu. Rechtfertigt das nicht möglicherweise doch die Arbeit oder das Geld für eine entsprechende Softwarelösung oder externes Consulting?

Ich hoffe nicht!!

Poste mal die "ipconfig /all" aller Server.

Sorry, aber das halte ich für eine der faulsten Ausreden der Softwarentwickler überhaupt. Es gibt ganz wenig Anwendungen, die explizit Administratorberechtigungen abfragen und für den Negativfall den Start verweigern. Dann gibt es noch ein paar Anwendungen, die allgemeine Kompatibilitätsprobleme haben, weil sie für ältere Umgebungen erstellt wurden. Meistens aber liegt an den Zugriffrechten auf irgendwelche Resourcen: Dateien, Verzeichnisse, Registrykeys. Wenn man sich die Mühe macht, herauszubekommen, worauf welches Zugriffsrecht benötigt wird, dann kann man das fast immer bewerkstelligen, ohne Adminrechte zu vergeben. Schau dir mal REGMON und FILEMON aus den Sysinternals an. Damit kannst Du aufzeichnen, worauf das Programm wie zugreift, während Du als Admin angemeldet bist. Dann die Berechtigungen des Benutzers so anpassen, dass er genau so diese Zugriffe ausführen kann. Ich behaupte, das funktioniert in 95% der Fälle.

Überprüfe mal mit GPRESULT welche Gruppenrichtlinien für diesen Benutzer angewendet werden. Und dann schau in die GPO's, wo da Einstellungen für den IE vorgegeben sind. Vielleicht findest Du da was.

Schau mal http://www.mcseboard.de/windows-forum-ms-backoffice-31/w2k-active-directory-lastlogin-20036.html#post116623

Entweder machst Du den "Gast" zum "Benutzer" oder erlaubst den "Gästen" die lokale und interaktive Anmeldung. Hinweis: Standardmäßig sind der lokale "Gast" ist nicht Mitglied der "Benutzer" und der Domänen-"Gast" ist nicht Mitglied der "Domänen-Benutzer". Aaaaaaaber: "Gast" benutzt man nicht, nicht wirklich!

Habe es hinbekommen. <SID=0102000000000005200000002A020000> ist "Prä-Windows 2000 kompatibler Zugriff" der jeweils unten in der Eventlog-Meldung genannten Domäne DC=SUB1,DC=STRUKTUR2,DC=local <GUID=D0903C57-1F9E-469C-A59D-88A543F07B35> ist "Exchange Enterprise Servers" auch in der SUB1. Wir hatten kürzlich eine neue Domäne SUB3 mit eigenen EXS installiert. Aus irgendeinem Grund hat aber der RUSse es nicht geschaft, den neuen EXS zum Mitglied der beiden o.g. Gruppen zu machen, so wie es Standard ist. Habe das manuell nachgeholt und nun sind die Meldungen weg. Wen's interessiert: Für die Identifizierung der genannten SID und GUID's habe ich mir zwei VBscripte gebastelt. Diese am besten auf einem GC starten. '--- LDAPsearchBySID.vbs START-------------------------------------------------------------- on error resume next 'Hier die SID eintragen, so wie sie im Eventlog gemeldet wird. const SID = "0102000000000005200000002A020000" set Objekt = nothing set Objekt = GetObject("LDAP://<SID=" & SID & ">") Ausgabe = "" if not Objekt is nothing then Ausgabe = Objekt.Get("distinguishedName") else Ausgabe = "Kein passendes Objekt gefunden" end if msgbox Ausgabe '--- LDAPsearchBySID.vbs ENDE-------------------------------------------------------------- '--- LDAPsearchByGUID.vbs START-------------------------------------------------------------- on error resume next 'Hier die GUID eintragen, so wie sie im Eventlog gemeldet wird. const GUID = "D0903C57-1F9E-469C-A59D-88A543F07B35" set Objekt = nothing set Objekt = GetObject("LDAP://<GUID=" & GUID & ">") Ausgabe = "" if not Objekt is nothing then Ausgabe = Objekt.Get("distinguishedName") else Ausgabe = "Kein passendes Objekt gefunden" end if msgbox Ausgabe '--- LDAPsearchByGUID.vbs ENDE--------------------------------------------------------------

Auch die Freiheit hat ihre Grenzen ...;)

Das ist klar. Die Feuerwehr muß ja auch ran wenn der Brandstifter bekannt ist.;) Eine Frage der Persönlichkeit(en), denke ich.:cool:

OK. Das sind dann aber Anwenderfehler, die durch organisatorische Maßnahmen geregelt werden müssen. Ein geschulter Anwender ist ein besserer Anwender ... Abends ruft der Fuhrunternehmer einen seiner Fahrer an: "Wieso steht der Wagen nicht auf dem Hof?". Der Fahrer: "Ja, äh, das Tor war zu, ich konnte den Hof gar nicht sehen." "Ja und, wo ist jetzt der Wagen?". "Den habe ich auf der Straße geparkt". "Welche Straße?". "Äh das weiß ich nicht." "Wie Sie wissen das nicht? Sie müssen doch wissen wo Sie den Wagen geparkt haben." "Na ja, ich habe einfach den Wagen am Straßenrand geparkt und dann den Motor ausgemacht. Aber wo das war, das kann ich Ihnen jetzt nicht mehr sagen." -- Wie würde der Fuhrunternehmer das wohl behandeln? Eine Datei ist entweder ein Produkt oder ein Arbeitsmittel. Für beides ist der Arbeitnehmer gegenüber dem dem Arbeitgeber über den Verbleib Rechenschaft pflichtig. Wenn die ungeleiteten "Eigenen Dateien" gelöscht werden (der Ordner), dann sind auch die Daten darin weg. Die GPO legt den Ordner beim nächsten Login erneut an. Mittels Überwachungen kann man jederzeit nachvollziehen, wer wann was gelöscht hat. Es ist zwar etwas mühseelig das auszuwerten, aber es geht. Die Dasi kann IMMER sichern und wiederherstellen, wenn sie unter einem Konto läuft, was die Berechtigung "Sichern von Dateien und Verzeichnissen" inne hat, so wie standardmäßig die Gruppe der "Sicherungs-Operatoren". Ich seh das so: Ich bin Systemadministrator und kein Kindermädchen!

Als Du das Profil gelöscht hast, hast Du es da in der Freigabe UND auf allen Terminalservern gelöscht?

Wird denn lokal und auf dem Terminalserver die selbe Word-Version verwendet? Ist die Word-Installation identisch?

Welche Windows Version? Wieviele DNS-Server? Welche? DNS-Zonen im ADS integriert? DHCP-offenbar im Einsatz - welche Optionen werden verteilt? Wurde im Zuge des Ersetzen des DC etwas am DHCP geändert? Ist der alte Server immer noch Domänenmitglied?

Habe zwar keine Lösung für das Kernproblem, aber warum schließt Du diese beiden Dateien nicht erstmal aus der Sicherung aus? Es gibt immer ein paar Dateien, die man nicht oder nicht konsistent gesichert bekommt, wenn die damit verbundenen Prozesse gerade laufen.

Wie kann ein Benutzer auf seine Eigenen Dateien je zu viele Berechtigungen haben? Wenn Du verhindern willst, dass der Benutzer die Wurzel selbst löschen kann (hier das "Eigene Dateien") dann musst eine Ebene höher ansetzen. Setze auf den Ordner "Eigene Dateien" die expilziete Verweigerung des "Löschen" Rechts, aber "nur für diesen Ordner" (!). Das müsste funktionieren.

Du könntest im Password-Dialog den Haken zum Merken des Passworts setzen. --> Aber ist das wirklich empfehlenswert? Das mit der Passwortabfrage und dem DC ist zwar irgendwie richtig aber auch wieder falsch. Ohne dass ich mich jetzt auf irgendwelche Artikel beziehen kann, weiß ich folgendes (grob ausgedrückt): Beim Zugriff auf eine Resource muss sich der Benutzer authentifizieren. Dazu reicht Windows das Sicherheitstoken des Benutzers rüber. In diesem Token stehen alle SID's, welche der Benutzer direkt inne hat oder durch Mitgliedschaft in Gruppen "erbt". Wenn keine dieser SID's passt, dann wird - der Zugriff auf die Rosource verweigert, wenn die Resource in der selben Domäne wie der Benutzer oder in einer entsprechend vertrauten Domäne liegt - der Zugriff über eine Benutzer-Passwort-Abfrage ausgehandelt, wenn die Resource nicht in einer vertrauten Domäne (oder standalone) liegt. Bevor aber die Passwort-Abfrage erscheint versucht Windows den Benutzer mit dem zwischegespeicherten Benutzernamen und Passwort des aktuell angemeldeten Benutzers anzumelden. Das kommt noch aus Peer-To-Peer-Zeiten. Wenn also Benutzername und Passwort auf beiden Peers identisch sind, dann klappt der Zugriff auch ohne extra Passwortabfrage. Wenn nicht, dann kommt der Dialog. Auf DC kann dies auch funktionieren, weil DC's bei lokaler Anmeldung ohne expliziete Angabe des Domänennamens die Anmeldung in der eigenen Domänen annehmen. Insofern könnte also auch der Zugriff von Standalone-PC's auf Resourcen eines DC's ohne erneute Benutzer-Passwort-Abfrage funktionieren, wenn der lokale Benutzername + Passwort so identisch in der Domäne stehen. Nur ---- ist das dem Exchange Server egal, ob er nun DC ist oder nicht. Weil die Anmeldung in diesem Fall zwischen Client Software und Exchange Server ausgehandelt wird.

Noch einfacher geht's mit Eingebaufforderung (cmd.exe) dir {Dateiname oder Wildcards} /s Bsp: dir c:\*.log /s dir d:\text.dat /s dir d:\Daten\HierMussEsSein\*.doc /s

Haben denn auch die betreffenden PC's Zugriff auf die Freigabe (Leseberechtigungen)? Die Installation erfolgt ja unter dem Systemkonto des Computers ...

Läuft denn der Server-Dienst?