grizzly999

Hallo und willkommen im Board :) Es gäbe theoretisch mehrere Möglichkeiten, die aber von hier aus nicht alle verifizerit werden können. 1.) Wenn es die Drucker anbieten würden, denen eine Route ins 192.168.1.x Netz eintragen. Eher unwahrscheinlich. Aber stattdessen den Druckern in den IP-Einstellungen den WLAN- AP als Standardgateway eintragen. 2.) Den WLAN-AP Adressen aus dem 192.168.0.x Netz vergeben lassen, wäre wohl das einfachste. Er muss dann bridgen können. 3.) Irgendwie NAT einsetzen nuterwegs. Aber dazu liegen wieder viel zu wenig INformationen vor. grizzly999

DIe Ports leer, wie müssen wir uns das vorstellen? Da stteht überhaupt nix von PPT oder L2TP, also nicht mal diese Buchstaben, oder Anzahl auf Null? Vielelich tkannst du einen kleinen Screenschot von dem Ausschnitt machen, ein paar KB groß nur als JPG und hier anhängen?! grizzly999

Hallo und willkommen im Board :) bitte beschreibe dioch technisch etwas genauer "aber dann ist Schluss". Was kommt, ein Fehler? Schwarzer Bildschirm? Absturz? .... grizzly999

Eine Anwendung muss cluster-aware sein, um sie zu clustern, d.h. sie muss so installiert werden können (entweder durch "selber Anbieten" der Applikation oder in der Clusterverwaltung), dass sie die Quorum Disk für die relevanten Registryeintrage und andere Konfigurationsdateien nutzt, und die Shared Daten Disk zum Abelgen und Abrufen ihrer Daten. Dazu zählen bei Microsoft der Exchange, SQL, Dateiserver, Druckserver, DHCP und WINS. Sollte ich was vergessen haben, dann sorry. Aber der DC (mit seinen relevanten Diensten, Datenbanken und Logs) ist definitiv nicht cluster-aware. Drittherstellerprodukte können natürlich auch cluster-aware sein, müssen aber ausdrücklich dafür programmiert werden. Mit anderen Worten: man kann nicht alles Clustern. Und bei einem DC bräuchte man das ja auch gar nicht, die Hohe Verfügbarkeit erreiche ich schlicht durch den Einsatz von mehr al einem DC. Die replizieren ja ihre Datenbanken untereinander, sind immer online und bieten daher auch ohne Cluster eine hohe Verfügbarkeit: Allerdings: natürlich könnte man einen Cluster auf zwei DCs installieren (ohne den DC-Dienst selber zu clustern), also um dann darauf z.B. einen Exchange geclustert zu betrieben. Ohne eine Quelle nennen zu können, aber empfohlen von Microsoft und führenden Waschmaschineherstellern, ähh Consultants, ist das mit Sicherheit nicht. Wenn's nicht sein muss, mach ich auf einen DC ncht mal normal einen Exchange drauf, geschweige denn einen EX-Cluster :D Vielleicht meinten die ja aber mit dem Cluster der DCs zwei getrennte DCs, die halt Ausfallsicherheit bieten, aber ohne den Clusterservice selber zu erwägen. Keine Ahnung, aber selbst dann wäre es technisch daneben und ahnungslos das Wort Cluster in den Mund zu nehmen. Aber ich will mir kein Urteil erlauebn, ich war nicht dabei, und weiss nicht, wer was wie gesagt hat ;) grizzly999

Aber klar ist die Verbindung verschlüsselt, sonst wäre es kein Tunnel. Abgesehen davon, dass der NT-Hash des Kennworts insgesamt nur 16 byte lang ist, nein, das kennwort bekommt man nicht einfach raus, sofern es ein sicheres Kennwort ist. Ich weiss nicht, was du damit meinst. Der Server sendet auf die erste Anfrage eine 8byte Nonce. Und ... :suspect: grizzly999

Welches Zertifikat Ich habe da höchstens eines für EAP-TLS für die Benutzerauthentifizierung, wenn ich das einstelle, und das schicke ich jedem, der es haben möchte, gerne zu. Im Klartext ;) Und ansonsten wie gesagt, bei sicheren, komplexen Kennwörtern ist PPTP mehr als ausreichend sicher, außer man hat alle Geheimdienste dieser Welt gegen sich :D grizzly999

Nein, DC ist nicht clusterfähig grizzly999

Im Moment nicht, aber steht denn was im EreignisLog? Gibt es oder gab es Fehlermeldungen? MIt welchen Optionen hast du den RRAS eingerichtet? grizzly999

:thumb1: Genau. Ein ausgestelltes Zertifikat kann nicht länger laufen als das der CA selber Nein, das geht nicht, denn die bekommt ihr selbstsigniertes Zertifikat ja gleich beim Installieren ausgestellt. Nachträglich ist das nicht mehr änderbar. grizzly999

Hallo und willkommen im Board Hast du schon bei Kollege Dieter Rauscher auf msisafaq.de vorbeigeschut? Da sind enie Menge Anleitungen u.a. auch die hier: http://www.msisafaq.de/Anleitungen/2004/Konfiguration/Webauthentifizierung.htm grizzly999

Dachte ich mir, geht wohl nur über die Registry: http://support.microsoft.com/default.aspx?id=254632 Man beachte, das geht nur für Zertifkate einer untergeordneten CA, bei einer Root CA ist das nicht änderbar hart codiert. grizzly999

Bei Interesse Mail oder PN grizzly999

Spricht da der Experte?? :rolleyes: Da vertraue ich mal eher auf den Crypto-Ober-Guru Bruce Schneier, demnach ist der einzige Schwachpunkt ein schwaches Kennwort. grizzly999

Du hast eine 2000 CA?! Da muss ich nachschauen, für 2003 könnte ich es sagen, aber bei 2003 ist das ganze CA-Wesen deutlich verbessert worden, vor allem mit der Enterprise Edition. Ich melde mich wieder .... grizzly999

Nach der Microsoft'schen Empfehleung, und der vieler Consultants und Admins, empfiehlt sich für Berechtigunsgvergabe, dazu zählt auch so eine OU-Delegierung das AGDLP-Prinzip, also Konten werden gemäß gleichen oder ähnlichen Anforderungen in globale Gruppen gruppiert, Domänenlokale Konten erhalten die benötigten Berechtigugnen auf die Resource, und die Globalen Gruppen werden in der Domänenlokalen Gruppe Mitglied. Das ist wie gesagt eine Empfehlung, technisch funktionieren natürlich auch andere Praktiken wie das AGP- oder ADLP-Prinzip. Wenn es geht, bietet es sich natürlich an, vordefinierte domänenlokale Gruppen für das "DL" in dem AGDL-Prinzip heranzuziehen. Aber nur da wo die vordefinierten Rechte und Berechtigugnen der vordefinierten Gruppe auch Sinn machen. Also, wenn ich allen Leuten aus der Domäne auf einem Computer eingeschränkte Rechtre und Berechtigung geben will, dann bietet es sich an, die lokale Gruppe der Benutzer zu nehmen (im AD ist dies eine domänenlokale Gruppe). Da ist die Globale Gruppe der Domänen-Benutzer Mitglied, somit habe alle User aus der Domäne damit erledigt, ohne eine neue Gruppe erstellen zu müssen. Wenn ich Usern das Recht geben möchte, mit ntbackup.exe einen oder mehrere Rechner zu sichen und auch wiederherzustellen, dann erstelle ich eine Globale Gruppe, packe die Benutzer da rein und mache die globale Gruppe dann zum Mitglied der lokalen Gruppe Sicherungs-Operatoren. Die können das. Du möchtest die verwaltung auf eine oder mehrere OUs delegieren und dazu die Globale Gruppe "Supporter GG" hernehmen und sie in eine Domänenlokale Gruppe stecken. Vom Ansatz her völlig korrekt, aber warum in die Server-Operatoren? Dazu sollte man sich klarmachen, was für Rechte und Berechtigungen haben die Server-Operatoren von Haus aus?! Sie können sich an einem DC lokal anmelden, sie können den DC sichern und wiederherstellen. Sie können auf dem DC Datei- und Druckerfreigaben erstellen. Sie können auf dem DC die Uhrzeit ändern :shock: Frage: sollen das deine delegierten Verwalter alles können? Wenn nein, dann mache dir eine domänenlokale Gruppe, für die OU Verkauf beispielsweise eine Gruoppe names "DL_OUVerkauf_Administration" und gib ihr auf die OU die entsprechenden Berechtigungen. Dann stecke deine "Supporter GG" dort hinein, fertig ist die Delegation :) Ja, das ist der schnellste, einfachste und am besten zu verwaltende Weg. grizzly999

Nein, die _msdcs Zonen der untergeordneten Domänen enthalten nur die Hinweise auf die DCs und den PDC-Emulator der jeweiligen Subdomäne. Deshalb müssen die auch bleiben. Die _msdcs der Forest-Rootdomain, die enthält die GCs grizzly999

Die _msdcs Zone wird AD integriert gemacht und da kann ich den Bereich ja angeben. Dabei "Auf alle DCs der Gesamtstruktur replizieren" grizzly999

Ok, dann sage ich voraus, dass die Problem, auch wenn sie im Moment behoben scheinen, ohne den genannten Patch wieder auftreten können. Spiele ihn ein ;) Wegen VPN: weisst du, ob Euer Provider für die Standleitungen (von denen gehe ich mal aus) nicht Teile davon oder temporär komplett die Verbindung über VPN Strecken leitet? Die Fehlermeldungen und IDs sind typisch für dieses Problem, das hatte ich nicht nur einmal bisher, und zwar bei 2003SP1. Da wurden Sachen im TCP/IP Stack geändert (verschlimmbessert), die die Blackhole Detection betreffen, was hauptsächlich bei Remote-Verbindungen über VPN betreffen. Wie gesagt, Provider von solchen Verbindungen sind da manchmal sehr flexibel, wenn es darum geht, Leitungen mal über einen anderen Carrier zu leiten. Daher sind diese Fehler ohne den eingespielten Patch oftmals auch nur temporär. grizzly999

Du hast die Links und meine Ausführungen gelesen? Was soll ich noch mehr sagen? Oder redest du davon die Partitionsgröße nachträglich zu ändern? grizzly999

Haben die 2003 Server SP1 drauf? grizzly999

Ja, per VBScript, aber da steht der Distinguished Name drin, also mit Kontennamen, OUs usw. Solch ein Skript wäre dann für jeden Benutzer individuell zu erstellen. Zu finden im MS Technet Scripting Center. grizzly999

Ja, aber Sinn macht das keinen, da sich primäre Server nicht abgleichen können. Außer man hat den DNS auf DCs und macht die Zoenen, auch die RVS-Lookupzeonen, AD-integriert. grizzly999

Ah, wohl ein VPN dazwischen. Ich bin mir sicher, den von mir hier genannten Patch auf den Servern einspielen hilft: http://www.mcseboard.de/showthread.php?t=84460 grizzly999

Nein, das erste mal ruft er sie Sperrliste dann ab, wenn er sie benötigt, sprich, wenn er ein ihm vorgelegtes Zertifikat auf Gültigkeit und Sperrung zu checken hat. grizzy999