olc

Hi, schau zusätzlich einmal hier hinein: Aktives Verzeichnis Blog : Hinweise zur Einführung bzw. Aktivierung von Kennwortrichtlinien Viele Grüße olc

Hi, läuft da vielleicht im Hintergrund irgend ein Script, welches zyklisch die Attribute ändert? Du könntest ggf. einmal die Objektüberwachung auf ein betroffenen Benutzerobjekt aktivieren und prüfen, wer oder was die Änderung durchführt. Viele Grüße olc

Hi Cypher, willkommen an Board, :) technisch ist - denke ich - alles schon gesagt worden. Aber mal eine Frage dazu: Das ist aber nicht Dein Ernst oder? ;) Falls doch: Du wirst als Azubi sicher nicht die Möglichkeit haben, das anzusprechen, aber ist Deiner Firma bzw. genauer gesagt den Geschäftsführern klar, was da passiert? Was, wenn Dein Ausbilder einmal schlechte Laune hat oder gekündigt wird? An dieser Konstellation sollte meines Erachtens zeitnah etwas geändert werden. Viele Grüße olc

Hi, dann schau einmal hier hinein: MSXFAQ.DE - E2K7:Zertifikate Viele Grüße olc

Hi, Du kannst (wenn es per "normaler" Kommandozeile passieren soll) ein "certreq -new" verwenden: CertReq -New [Options] [PolicyFileIn [RequestFileOut]] Create a new request as directed by PolicyFileIn Aber einmal anders gefragt: Was für ein Exchange System ist das? In 2003 kannst Du im Normalfall die IIS MMC für das Erzeugen eines Requests verwenden, ab 2007 sind eigene CMDlets dabei. Viele Grüße olc

Ist gewünscht. ;) :) Danke und Gruß olc

Hi, wie gesagt: Nicht submitten, sondern einen offline Request erzeugen und diesen dann manuell bei der CA einkippen. Meine Fragte hast Du auch nicht beantwortet. Ansonsten kannst Du dem Admin die Erforderliche Berechtigung auf die CLSID "{D99E6E74-FC88-11D0-B498-00A0C90312F3}" mittels "dcomcnfg" gewähren. Viele Grüße olc

Hi, ist die CA denn überhaupt eine "Enterprise" CA, also "AD integriert"? Ansonsten erstelle den Certreq Reuqest offline und übertrage die *.req Datei manuell zur CA, wo der Request dann auch ausgestellt werden kann. Viele Grüße olc

Hi, auch mir erschließt sich der Sinn nach Deinen Erklärungen noch immer nicht. 1. Unterschiedliche Benutzer sollten niemals, ich betone niemals, gleiche Konten nutzen. Das ist also kein "Argument". 2. Der Taskadmin ist hoffentlich kein Domänen-Admin o.ä. - falls doch, habt Ihr schwerwiegende Sicherheitsprobleme. Ganz ehrlich: Ja, der Wortlaut der Beiträge war an der einen oder anderen Stelle vielleicht nicht optimal. Aber das gesamte Konstrukt von Euch ist scheinbar vollkommen "broken by design" und Du würdest gut daran tun, darüber nachzudenken und nicht alle Hinweise als "nicht zielführend" abzuweisen. Kennst Du die Metapher vom Baumfäller mit der stumpfen Säge? Falls nicht, dann schau einmal hier unter dem Punkt "Keine Zeit": http://www.loesungswerkstatt.info/15.html Viele Grüße olc

Hi, ich habe das hier im Board schon ein, zwei Mal geschrieben - aber hier paßt es auch gerade wieder: Seid Ihr eine GmbH oder ähnliche Gesellschaftsform? Es folgt hier keine Rechtsberatung, nur ein Hinweis für die Recherche beim Anwalt Deines Vertrauens: Wenn Ihr eine GmbH o.ä. seid, dann erzähl Deinem Geschäftsführer einmal, wie das ganze seit ein paar Jahren für ihn aussieht: Wenn bei einem Malware Befall auf Euren Systemen in der Folge auch Dritte geschädigt werden und es liegt nachweisbar eine "Fahrlässikeit" auf Eurer Seite vor, dann haften auch die Geschäftsführer, nicht nur die GmbH. Und das sogar im Fall der Fälle mit Ihrem Privatvermögen. Und daß NT4 Systeme als sicherheitstechnisch zumindest als Fahrlässig gelten könnten, steht meines Erachtens außer Frage. Nachdem er das weiß, verzichtet er vielleicht einmal auf die Fahrt zur Ostsee mit dem Firmenwagen und stellt die Systeme lieber um. Was die Produktionssysteme betrifft: Klar, es gibt sogar noch DOS Systeme auf irgend welchen Produktionsanlagen. Aber wenn der Hersteller der Anlagen nicht dafür sorgt, daß seine Systeme up-to-date bleiben, dann solltet Ihr den Hersteller wechseln. Denn auch wenn Maschinen in einigen Bereichen teilweise über 10 Jahre abgeschrieben werden heißt das doch, daß der Hersteller für diesen Zeitraum Support anbieten muß. Und dazu gehört ganz klar auch das OS. Wie gesagt: Ich verstehe Dein Problem - ich will hier also nicht "belehren", sondern Dir nur ein paar Argumentationsgrundlagen mitgeben. :) Viele Grüße olc

Hi, die Zugriffe kommen von den Prozessen mit der ID 1144 und 1924. Also beides SVCHOST. Darunter liegen die Prozesse Webclient und RpcSs. Vermutlich greift also der Webclient noch irgendwo ins Netz zu (oder auf das System wird zugegriffen) und RpcSs ist das "Opfer". So zumindest einmal eine erste Annahme. Deaktiviere testweise einmal den Dienst "Webclient" und starte die Maschine neu. Danach prüfe, ob die Meldungen immer noch erscheinen. Deaktiviere nicht die RPC Dienste. Viele Grüße olc

Hi, nimm das 2008er Schema und nicht das 2003 R2 Schema. Alles andere macht m.E. keinen Sinn mehr. Dann sollte es auch wie schon angesprochen mit DFSR klappen. Viele Grüße olc

Hi, vielleicht ist es in den lokalen Richtlinien der Notebooks definiert? Check mal das lokale "gpedit.msc". Viele Grüße olc

Hi, zieh Dir vor der Abmeldung einmal ein "TASKLIST /SVC" und speichere es weg. Danach Abmeldung und Überprüfung des UPHClean Events - dort steht die Prozess ID. Dann schaust Du, was unterhalb des SVCHOST.EXE Prozesses läuft, ggf. gibt Dir das ja einen Hinweis auf die Ursache. Ansonsten kannst Du es mit dem UPHClean CALLSTACK Logging versuchen, aber da geht es schnell "ans Eingemachte", genauso wie der ProcMon. Viele Grüße olc

Hi, die Ereignisse sehen mir eher nach "Objektüberwachung" von AD Objekten aus, nicht nach Anmeldeereignissen. Was ist beim "Objektzugriff" derselben Policy Ebene definiert? Viele Grüße olc

Hi, zusätzlich zu den Hinweisen von Daim kannst Du auch einen Blick in den Branch Office Guide werfen: Download details: Windows Server 2003 Active Directory Branch Office Guide. Dort wird auch unter anderem über das Monitoring gesprochen. Neben geschätzten 1.000 Tools und Scripts zur Überwachung von AD Umgebungen kannst Du auch den BROFMON verwenden. Ist nicht optimal, aber ein Anfang, wenn Du dann weißt, was Du überwachen möchtest: Windows Server How-To Guides: AD Monitoring mit BROFMON - ServerHowTo.de Viele Grüße olc

Hi tqsystem, schön, daß es nun klappt. :) Vielen Dank für die Rückmeldung und viele Grüße olc

Hi Philipp, gut, daß Du nicht locker läßt. ;) :) Obwohl man dann aufpassen muß, den richtigen DN zu wählen: Wenn Du die Abfarge in einer Child-Domäne ausführst, müßten alle Global- und Domain Local-Groups mit dem DN der Child angegeben werden, die Enterprise Admins (Universal-Group) jedoch mit DN der Root. Aber gut, das wird jetzt zuviel des guten (Herumnörgelns). :p Viele Grüße olc

Hi, mal abgesehen von den reinen Audit-Fragen: Ich denke, daß - wenn Du diese LDAP-Filter Abfrage mit "memberOf" durchführst - die primary groups nicht beachtet werden. Das könnte wieder zum Problem werden. Die Geschichte mit dem AdminCount könnte man umgehen, indem man diesen vorher wieder auf "0" setzt und etwas abwartet (1h + Replikationslatenz). Ansonsten würde ich es für einen groben Überblick einfach mit den von Nils genannten Methoden versuchen - was natürlich nicht heißt, daß die Methode von Philipp nicht auch interessant wäre. ;) Viele Grüße olc

Hi, Du mußt diese nicht laden - wenn die Datei im Windows Verzeichnis existiert, wird sie automatisch herangezogen, wenn das Root Zertifikat erneuert werden soll. Viele Grüße olc

Moin, Ich weiß - bin ein Erbsenzähler. ;) Aber grundsätzlich ist es schon möglich, Registry Schlüssel auch per ADM / registry.pol zu löschen. Siehe dazu: Registry Policy File Format (Windows) Wird auch bei ein, zwei Einstellungen standardmäßig durchgeführt - AFAIR ist BitLocker so ein Beispiel. Viele Grüße olc

Hi, testen, testen, testen. ;) Viele Grüße olc

Hi, ich verstehe Deine letzte Aussage nicht. Der Server, der aus DFSN Sicht am "geeignetsten" ist, wird gewählt. Hier spielt die Site Konfiguration etc. eine Rolle. Was wird denn "falsch" angezeigt, wenn Du das DFSUTIL absetzt? Schildere doch noch einmal (inkl. der DFSUTIL Ausgabe), was in Bezug auf DFSN bzw. das Link-Target das Problem ist. Viele Grüße olc

Hi, Nein, das ist korrekt. Kann es sein, daß mehrere öffentliche Schlüssel im Benutzerprofil der Zielbenutzer veröffentlicht sind? Wenn ich mich richtig erinnere wählt Outlook dann unter Umständen das falsche Zertifikat und kann nicht verschlüsseln. Ggf. muß also das falsche Zertifikat von den Benutzerobjekten entfernt werden. Check das doch einmal ab. Im Normalfall legt Outlook automatisch auch das Zertifikat des Absenders mit in die Liste der Personen, die entschlüsseln können. Das sollte also klappen. Bringt uns auf die Frage, ob unter Umständen mehrere Zertifikate + private Schlüssel auch lokal im Benutzerprofil zur Verfügung stehen? Siehe oben - Outlook ist im Normalfall so intelligent, das transparent für den verschlüsselnden Benutzer zu regeln. Viele Grüße olc

Hi, das Script kann sicher mit wenig Aufwand und etwas VBScript Kenntnissen angepaßt werden. Ansonsten müßte das sicherlich auch über die W7 / Windows Server 2008 R2 PowerShell AD CMDlets bzw. Quest AD CMDlets lösbar sein. [EDIT] Nils war schneller. :) [/EDIT] Viele Grüße olc