Christoph35

@onewayticket: schau dir mal die Hilfe zu der Policy an, diese Policy ist unter den Sicherheitsoptionen zu finden. Ist aber zugegebenermaßen nicht ganz eindeutig formuliert. Christoph

In AD Benutzer und Computer; bei einem dt. Server heißt der Tab wohl "Konto". Ich hab hier nur mit engl. Servern zu tun, sorry. Christoph

Ich hätte es präziser ausdrücken sollen: die Policy besagt, von wievielen Usern die Credentials gecacht werden, so dass diese sich erneut anmelden können, auch wenn keine Verbindung zum DC besteht. Christoph

Hi! Du hast 2 Möglichkeiten, dass zu erreichen. Einmal mit Auswahl aller Userkonten (Multi-select) und dann auf dem Tabreiter "Account", oder per Group Policy in dem du min. und max. Kennwortalter auf 0 setzt. Ich halte das allerdings nicht für sinnvoll, weil es die Sicherheit der Userkonten verringert, bei uns müssen z.B. die User alle 90 Tage ihr Kennwort ändern (also ca. 4x jährlich, das halte ich für zumutbar). Nur Konten, die für Dienste benötigt werden, sollten mit einem nicht ablaufenden Kennwort versehen werden. Christoph

Wozu sollte das gut sein?! Diese Zahl besagt, dass sich 10 User an dem Laptop anmelden können, ohne dass eine Verbindung zum DC besteht, und nicht dass sich ein User bis zu 10x am Laptop anmelden könnte. Christoph

Das Stichwort heißt "Vertrauensstellungen". Dann kann sich ein User aus Domain 1 an Rechnern in Domain 2 anmelden und, entsprechende Berechtigungen vorausgesetzt, auf ressourcen in Domain 2 zugreifen und vice versa. Christoph

Dann schau dir mal die Berechtigungen des Information Stores an. Ist der Dom-Admin-Account dort gelistet, mit ererbten (oder direkt zugewiesenen) Berechtigungen? Gibt es ggf. "Verweigern"-Einträge für den Account? Ich würde grundsätzlich auf die Sicherung der einzelnen Mailboxen verzichten und nur den/die Information Store(s) sichern. Geht einfach um ein Vielfaches schneller, und die nicht mehr benötigtenTransaction-Logs werden auch gelöscht. Christoph

Off-Topic: @lonzo: Dann solltest Du richtig verlinken ;) MSXFAQ.DE - Anbindung an das Internet Christoph

@Lonzo001: Was hat das mit dem Problem zu tun?! @7310588: Gibt es irgendwelche Einträge im Eventlog? Eventuell solltest Du im ESM mal in den Servereigenschaften das Diagnostic Logging einschalten, damit Eventlog-Einträge geschrieben werden. Christoph

Du musst den User dann mail-enablen, ihm aber keine Mailbox im Exchange zuweisen. Das sind 2 unterschiedliche Dinge, die man über die Exchange-Aufgaben erledigen kann. Wenn Du nicht so ganz fit bist, solltest Du Dich etwas einarbeiten. Z.B. mit dem Exchange Buch von Th. Joos (für Ex. 2003). Christoph

Was steht denn in den Eigenschaften der Website unter Dokumente als Default Content Page eingetragen? Nach einer frischen IIS-Installation ist das default.htm oder default.asp. Das müsstest Du dann ggf. anpassen. Christoph

Meiner Meinung nach sollten die Admins sogar strengeren PW-Richtlinien unterliegen, schließlich ließe sich mit diesen Accounts mehr Unheil anrichten. Mit Windows Server 2008 wird das auch möglich sein. Christoph

So, im Anhang mal 2 WireShark-Captures, 1x von einem XP-Client aus, 1x von einem W2K-Prof-Client aus. Im letzteren sieht man in einem Paket, dass W2K ein Update mitsamt Kerberos Daten und über TCP schickt, und dieses Paket lässt den Bind abstürzen, wenn er chrooted läuft. XP macht das nicht. Wir haben jetzt mal auf den W2K-Rechnern, die wir "erwischt" haben, dyn. DNS abgeschaltet und lt. Novell Artikel (s. Post #1) den BIND umkonfiguriert. Wenn jemand eine bessere Lösung anzubieten hat: nur her damit :) Christoph dnsupdate_chrooted.zip

Werd ich mal machen. Ich hatte eben darauf spekuliert/gehofft, dass vielleicht schon jemand die Antwort weiß ;-) Christoph

Hi, die Sysinternals Tools sind für sowas ganz gut geeignet. Z.B. Process Monitor: Process Monitor v1.25 Christoph

Muss dieses alte Thema noch mal hervorholen. Wir konnten inzwischen ermitteln, dass der BIND nur dann abstürzt, wenn der Update Request von einem W2K Client kommt. XP oder Server 2003 sind nicht betroffen. Also: was macht W2K beim Dyn. DNS Update anders als XP/2003?! Christoph

Ein passender MX Record muss natürlich vorhanden und im Internet bekannt sein, wenn diese E-Mail Adressdomäne publiziert wird. Aber warum soll das so gemacht werden? Christoph

Ja, geht natürlich auch mit replmon. Das eine ist halt commandline, das andere mit GUI. Du kannst auch auf beides verzichten, und die Repl. in AD Sites & Services anstoßen. Christoph

Hallo, zusammen, wir haben aktuell ein Problem, dass Clients versuchen, mittels TCP/IP Port 53 ein dynamisches DNS Update durchzuführen. Unserem BIND Server gefällt das nicht wirklich, sondern er stürzt ab. Das Verhalten ist auch unter Document ID 3665923 bei Novell dokumentiert. Siehe hier: Search Results Page Wir haben derartige Versuche jetzt an der FW blockiert, möchten aber auch unseren DNS Server weiter absichern. Deswegen haben wir eine virt. Testumgebung erstellt. Dort können wir das Verhalten aber nicht nachstellen, weil die dyn. DNS Updates per UDP vom XP Client an den Test BIND Server übermittelt werden, womit BIND keine Probleme hat. Kann man für Update Versuche TCP erzwingen und wenn ja, wie? Christoph

Ich nehme an, die Zone ist auf NonSecure und Secure eingestellt für Automatisches Update? Für die dyn. DNS Registrierung unter Linux schau vllt. mal hier: Dynamic DNS Updates with TSIG for Security Oder eben so, wie Velius es vorschlägt (vorausgesetzt natürlich, die LinuxRechner bekommen ihre IP von einem Win DHCP Server...) /edit: hier ist noch n Link zu nsupdate: nsupdate(8): Dynamic DNS update utility - Linux man page Christoph

Sorry, aber Du hast nur die Möglichkeit über SecureNAT Client (also ISA=Def. GW, bzw. über Def. GW erreichbar), oder FW-Client. Siehe auch: FTP client Christoph

Das kann man doch per DHCP Option 003 den Clients mitgeben?! Im übrigen braucht der ISA auch nicht selbst als Def. GW eingetragen sein, es reicht, wenn der Datenverkehr über das Def. GW zum ISA kommt. Habt ihr auch den Firewall Client ausprobiert? Dann braucht der ISA nicht als Default-Gateway herhalten. Christoph

Der Name des Zertifikats ist ja korrekt: Das Problem liegt hier: Das Root-CA Zertifikat (und ggf. Zertifikate von Intermediate CAs) müssen in den korrekten Cert.-Stores enthalten sein (hier die des Computerkontos). Christoph

Hi und willkommen an Board! :) Was ist jetzt deine eigentliche Frage? Wie die SRV-Records wiederherzustellen sind? Das steht in dem von dir verlinkten Artikel schon drin, nämlich durch ausführen von netdiag /fix. Netdiag ist Bestandteil der Support-Tools, die ggf. erst von der Win 2003 CD installiert werden müssen. Christoph

Hi, Aber gerne doch. Also: öffne eine MMC und füge das SnapIn "Zertifikate" hinzu. Beantworte die Fragen mit "Computer" und "Lokalen Computer". Dann erweiterst Du in der MMC den Baum bis du zu "Vertrauenswürdige Stammzertifizierungsstellen" und dann "Zertifikate" kommst. Mit Rechtsklick auf "Zertifikate", dann "Alle Tasks" und "Importieren" kommst Du zum Assistenten für das Importieren von Zertifikaten. Im Verlaufe des Assistenten wählst Du (hoffentlich noch vorhandene) Zert.-Datei aus, die du schon mal mit dem IE6 importiert hast. Wenns dann immer noch nicht klappt, müssen wir die Outlook Einstellungen für die RPC/HTTPS Verbindung überprüfen. Aber versuche jetzt erstmal das RootCA Zert. zu importieren. Zum Zitat von MSXFAQ.DE: Ja, das stimmt so, aber die Vorkehrungen werden ja in dem Artikel genau beschrieben. (Port 6001, 6002,6004 etc). Christoph