Dirk_privat

Hi, Du kannst eine neue Policy mit einem Filter erstellen und dann dort die Domain eintragen. Gruß Dirk

Hi Schau mal unter http://www.gangl.de da gibt es die OLX Tools, mit denen könnte sowas gehen. Falls nicht geht das auf jeden Fall: http://www.ontrack.de/powercontrols/ Gruß Dirk

Hi, mit der normalen Suche kannst Du im Exchange nicht in Unterordner suchen, dazu mußt Du die Indexierung einschalten. Mach das aber am Wochenende, weil der erste Index sehr viel Performance benötigt. Gruß Dirk

Hi, gibt es .adm files um Sicherheitseinstellungen (Zonen) für das DotNet 2.0 Framework per policy zu konfigurieren? Für .net Einstellungen habe ich bisher noch nichts gefunden. Gruß Dirk

Hi, natürlich kannst Du zuerst den das Windows SP1 installieren, das war ja auch zuerst released. Wenn ich mich nicht täusche, brauchst Du sogar das Win SP1 vor dem Exchange SP2, aber ich hab es nicht ganz genau im Kopf. Gruß Dirk

Dann kannst Du SSL gleich in das interne Netz weiterleiten ohne durch die DMZ zu gehen. Das spart Zeit und hat letztlich den gleichen Effekt. Wenn Du eine größere Sicherheit willst brauchst Du eine Application Firewall die auf Layer 7 arbeitet und SSL ent- und wieder verschlüsselt. Außer ISA und Checkpoint ist mir da nichts bekannt. Mit Linux und iptables kommst Du da nicht weit, da du innerhalb der SSL Verbindung nichts filtern kannst. Wenn Dein Exchange nicht auf einem DC installiert ist, hätte ich keine allzugroßen Bedenken den SSL Port nach intern zu forwarden. Das hängt natürlich von deinen Sicherheitsanforderungen und dem Budget ab. Bei einem größeren Unternehmen und unternehmenskritischen Daten hätte ich allerdings einige Kopfschmerzen. Gruß Dirk

Hi, Das OWA kannst Du meines Wissens mit Squid nicht emulieren. Du wirst keine andere Möglichkeit haben als SSL an Deiner Firewall freizuschalten. Mit dem ISA würde das gehen. Gruß Dirk

Ob Du die SSL Ports in das interne Netz forwardest oder die DMZ für den FE aufmachst macht keinen Unterschied. Ich bevorzuge den SSL zu forwarden und wenn Du Geld übrig hast kannst Du Dir einen ISA Server zulegen, dann ist die Lösung ziemlich sicher. Gruß Dirk

Hi Du hast geschrieben: !Die Mails sollen per MX EIntrag beim Provider direkt auf den Exchange geleitet werden". Ich nehme an auf Euren. Für dieses Szenario brauchst Du keinen FE Server. Die Mitarbeiter brauchen auch kein POP3. Laß die User mit OWA oder RPC over Https auf Deinen Exchange zugreifen der hinter Deiner Firewall im internen Netz steht. Anstatt einen FE würde ich lieber einen ISA kaufen und den Exchange publishen. Gruß Dirk

Hi, ich würde keinen Exchange in die DMZ stellen. Was benötigst Du genau und wie groß sind Deine Standorte? Wenn Du nur OWA brauchst, dann würde ich nur mit einem Exchange arbeiten. OWA kannst Du über SSL anbieten und wenn Du eine höhere Sicherheit willst, dann schau Dir den ISA Server an mit dem Du OWA publischen kannst auf Application Layer Ebene. Wenn Du kleinere Standorte hast mit nur 20 User oder so, dann würde ich mit Outlook 2003 und dem Cached Mode arbeiten, d.h. die Standorte bekommen keinen eigenen Exchange Server. Gruß Dirk

Hi, falls Du es nicht anders weg bekommst mußt Du das Profil neu machen. Gruß Dirk

Hi, Du brauchst für jeden User eine Exchange CAL, egal ob der Zugriff über einen TS erfolgt. Für den TS kannst du entweder User CAL´s oder Computer CAL´s lizenzieren. Wenn verschiedenen User von einem Rechner auf den TS zugreifen, ist es sinnvoller Computer CAL´s zu nehmen. Connecten die User aber von verschiedenen Rechnern auf den TS ist ein User Lizenz besser. Das mußt Du für Dich entscheiden. Gruß Dirk

Hi Christoph, habe es eben nochmal bei mir getestet. Du hast Recht, es geht nur teilweise. Bei manchen Wörtern erkennt er eine Logik und bei Nummern akzeptiert er sie fortlaufend sobald ein alphanumerisches Zeichen enthalten ist. Jetzt müßte man halt wissen nach welchen Kriterien MS die Komplexität betrachtet. Hier habe ich noch was interesantes dazu gefunden http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secmgmt/security/sample_password_filter.asp Gruß Dirk

Hi Christoph, das mit den Policies für Kennwörter ist so eine Sache. Aussage MS war immer das die Default Domain Policy nicht verändert werden sollte (best practise). Vor kurzer Zeit wurde noch empfohlen die Kennwortrichtlinien auf der DC Policy zu setzen was je eigentlich auch logisch ist, da nur die DC´s User authentifizieren. Neuerdings geht MS aber auch in die Richtung die Default Policy zu ändern. Ich habe jetzt eben mal bei uns nachgeschaut und die Richtlinien sind auf der DC Policy gesetzt und funktionieren. Die Komplexität ist schon seit Jahren konfiguriert und funktioniert nachweislich. Wenn der User "Mueller" heißt, ist ein Kennwort wie z.B. mueller1 nicht möglich, da das Kennwort den Username enthält. Nehmen wir also test.1, das ist zulässig, da alphanumerisch und/oder Groß- Kleinschreibung. Bei einem Wechsel kann test.2 nicht genommen werden, da eine Logik erkennbar ist. Also bei mir/uns funktioniert das einwandfrei. Gruß Dirk

Hi Christoph, eine zusätzliche .dll war nur bei NT nötig. Ab Windows 2000 reicht die Komplexitätsanforderung. Ich würde die Policy auf der Default Domain Controller Policy setzen, dann sollte es auf jeden Fall funzen. Gruß Dirk

Hi, Du mußt bei den Kennwortrichtlinien die Komplexitätsanforderung aktivieren. Gruß Dirk

Hallo, wieso willst Du den Usern das Recht geben? Die Uhrzeit bekommen die Clients automatisch Durch den Windows Time Dienst zugewiesen, die Benutzer brauchen kein Recht wie es früher bei NT4 war. Du solltest besser schauen das der Zeitserver (normalerweise DC) die aktuelle Uhrzeit hat. Wenn die User die Zeit ändern und Du hast eine größere Differenz als 5 Minuten, kann sich der User aufgrund von Kerberos nicht mehr am Nezt authentifizieren. Gruß Dirk

Hi, am einfachsten die Zone wieder erstellen, das sollte es gewesen sein. Die Rechner tragen sich automatisch neu ein. Starte mal den Netlogon (Anmeldedienst) neu damit die SRV Einträge neu generiert werden. Falls Du manuelle Einträge hast, solltest Du die noch eintragen. Gruß Dirk

Wenn Du keine lokalen Gruppen hast, dann ist es ein Domain Controller! Da darf sich nur der Admin lokal anmelden und keine User. Falls Du das ändern willst mußt Du die Default Domain Policy oder die Default Domain Controller Policy anpassen. Gruß Dirk

Hi, Ist es ein Member Server? Füge den User in die lokale Gruppe Remotedesktopbenutzer hinzu, dann sollte es gehen. Gruß Dirk

Hi, Das ist ein klassischer Fall von Adware, Malware, etc. Hiermit kannst Du es entfernen (MS Antispy) http://www.microsoft.com/downloads/details.aspx?FamilyID=321cd7a2-6a57-4c57-a8bd-dbf62eda9671&displaylang=en Gruß Dirk

Hallo Frank, ich kenne auch gemischte Umgebungen mit Deutsch/Englischer DC Installation und da gibt es keine Probleme. Der Administrator oder Administrators ist nur der Display Name und dahinter steckt eine SID mit der gearbeitet wird. Welche Sprache da im Vordergrund angezeigt wird, spielt eigentlich keine Rolle. Gruß Dirk

Hi, am einfachsten wird es sein deinen Usern das Lesen beizubringen;-) Wenn Du Gruppenrichtlinien im Einsatz hast, kannst Du es evtl. darüber lösen. Lade Dir mal die Outlook.adm vielleicht kannst Du das Format dort vorgeben. Gruß Dirk

Schau Dir mal die Variable %logonserver% an. Ich weiß zwar nicht was Du mit dem Script erreichen willst, aber so ist es eine Möglichkeit auf den aktiven DC zu connecten. Wobei Du noch lösen solltest was passiert wenn einer aufällt und User sind schon angemeldet! Gruß Dirk

Hi, Das würde ich mit DFS realisieren. Wenn Dir ein Server aufällt, kannst Du den DFS Stamm auf einen anderen Server umleiten. Anstatt über \\Server\Share gehst Du über \\domain.local\Share Du könntest die Shares sogar mit DFS synchronisieren, damit die Ausfallzeit minimiert wird. Gruß Dirk