grizzly999

TFTP ist generell unsicher, denn das ist der Unterschied zu FTP: keine Authentifizierung erforderlich grizzly999

Das geht meiner Erfahrung nach nicht, außer mit einer MultiLanguage Version vielleicht. Ansonsten Word-Dokument in kyrillischer Schrift anhängen. grizzly999

Mag ein bug sein, oder ein feature, dass der Haken nicht gesetzt ist, aber es geht trotzdem mit der GPO grizzly999

Der SBS hat keine Terminaldienste im Sinne eines Terminalserver, auf dem Benutzer arbeiten können. Er hat nur den Remotedesktop mit seiner Beschränkung auf 2 Sessions plus Konsolensession. grizzly999

Danke für das Lob :) Remotedesktop aktivieren: Richtlinie -> Computerkonfiguration\Administratve Vorlagen\windows-Komponenten\Terminaldienste\Remotedektopverbindungen mit Hilfe der Terminaldienste zulassen: aktiviert Remoteunterstützung aktivieren: Richtlinie -> Computerkonfiguration\Administratve Vorlagen\windows-Komponenten\System\Remoteunterstützung\Angeforderte Remoteunterstützung: aktiviert (und dann konfigurieren) grizzly999

Ja, das war exakt das, was ich meinte ;) OU = Organisational Unit = Organisationseinheit grizzly999

Natürlich nutzt du ein Zertifikat generell für die Authentifizierung und nicht für die Verschlüsselung. Meine Aussage bleibt aber stehen und bleibt korrekt: Für PPTP braucht der VPN-Server kein Zertifikat. Oder habe ich da was falsch verstanden in deinem Beitrag ?! Daher: Wo war Was für ein Zertifikat mit welchem Zweck für Wen ausgestellt, welches du gelöscht hast? grizzly999

Das es ein DC ist, reicht die Mitgliedschaft in der Remotedesktopbenutzer-Gruppe nicht aus. Es muss den Nicht-Admins zusätzlich das Benutzerrecht "Anmeldung: Anmeldung über Terminaldienste zulassen" gegeben sein. Zu finden, natürlich in den Benutzerrechten der entsprechenden Gruppenrichtlinie, hier also auf der OU Domain Controllers grizzly999

Wie, kein Contentfiltering gefunden Was verstehst du darunter? Der ISA hat das Tool URL-Sätze, er hat das Tool Inhaltstypen, und er hat einen konfigurierbaren HHTP_Webproxy-Filter der sich "von" schreibt und für jede einzelne Regel anpassbar ist. Ein guter Tip: kaufe dir das hier: http://www.amazon.com/exec/obidos/tg/detail/-/1931836191/102-0274640-5307377?v=glance grizzly999

Man MUSS es gar nicht machen, GC hat nichts mit Bertriebsmasterrollen zu tun. Du lässt also den Haken drin oder du machst ihn weg, dann hast du eben eienn GC weniger. grizzly999

Nun, die Root-CA sollte Sperrlisten verteilen, die man halt manuell in den CDP kopieren muss. Meist in deutlich größeren Abständen als bei einer ausstellenden CA, wie oft sperrt man auch eine Sub-CA?! Wenn man das nicht macht, oder die aktuelle Sperrlist ohne den Sperreintrag einer inzwischen gesperrten Sub-CA im Cache eines Rechners ist, dann bekommt er das nicht mit, das ist richtig. Das ändert nichts daran, dass das Root-zertifikat üblicherweise keine AIA unf CDP hat. grizzly999

... die Global Group in einem Single-Domain Modell aber auch nicht, wenn ich nicht irre ;) grizzly999

Nein, in einer Root-CA sind üblicherweise AIA und CDP leer. Denn da man das Root-Zertifikat nicht sperren kann, weil selbstsigniert, macht es auch keinen Sinn eine Sperrliste anzugeben, die es gar nicht geben kann. Ich sagte üblicherweise, denn wenn man z.B. einfach so plain eine Root-CA bei Windows Server aufsetzt, hat diese einen AIA und einen CDP. Will man die sinnigerweise raushaben, dann muss man vor dem Aufsetzen der Root-CA im %systemroot% eine Datei CApolicy.inf platzieren, die u.a. folgende einträge enthält: [CRLDistributionPoint] Empty=true [AuthorityInformationAccess] Empty=true AIA und CDP werden jedoch in den ausgestellten Zertifikaten, auch dem der Sub-CA, angegeben. grizzly999

GOOD NEWS: Es geht wieder weiter ... :) :) Der Voucher bleibt gültig bis zum 31.12.2005 grizzly999

Kann ich leider nicht bestätigen, bei mir funktioniert das prächtig unter XP, aber bei W2k geht das genauso grizzly999

Veto: in einem Single-Domain-Model werden sowieso sämtliche Änderungen repliziert, da entsteht durch eine (in dem Fall nicht vorhandene separate GC-Replikation) kein Byte mehr Traffiic. In einem Multi-Domain-Model wäre das was anderes, aber selbst da wird Replikatiionsverkehr zu sehr überschätzt, dieser GC-Repl-Verkehr sowieso. grizzly999

Veto. Das ist keine Sicherheitslücke, denn der Benutzer braucht Schreibrechte in seinem Profil, um berechtigte Änderungen vorzunehmen, miest über Tools im Arbeitsplatzbereich aber auch anderen. Und jedes Tool, dass irgendjemand mal schreiben würde, zu blockenund trotzdem dem Benutzer Schreibrechte zu gewähren, hm..... Wer das nicht will, der muss mandatory Profiles einrichten, dann ist's zwar nicht Schluss mit Schreiben aber mit Änderungen speichern. Und der Benutzer darf egal mit welchen Tools so gut wie nirgends in den wirklich sicherheitsrelevanten Teilen der Registry schreiben, also HKLM. Daher sehe ich das mit der Sicherheitslücke nicht so. just my 2 cents grizzly999

Korrekt, der Ansatz von DFS ist ein anderer, nicht der Hochverfügbarkeit der Daten, besodners nicht sich häufig ändernder Daten oder großen dynamischen Datenmengen. Wie lefg es schon sagte, ist die Intention vom Verteilten Dateisystem (man beachte den Namen!) im Netz verteilte aber zusammengehörige Freigaben in wenige Einstiegspunkte zusammenzufassen und von Servernamen in UNC-Pfaden unabhängig zu werden. Es bietet daneben auch Replikation an, aber eben nicht um ............ ;) @lefg: Eine Quasi-Loadbalancing gibt es schon, wenn mehrere redundante DFS-Links sich am selben Standort befinden. Die Lösung hatte lefg auch schon präsentiert: Clustering grizzly999

Leider bin ich da ratlos, den alle meine Erfahrung mit SUS zeigen, dass ein Nicht-Admin den Neustart nicht verhindern kann. Anybody else here, bei dem das geht? :suspect: grizzly999

Zuerst: Sperrlisten werden nicht unbedingt einmal am Tag veröffentlicht, sondern in dem Intervall, dass die Zertifizierungsstelle vorgibt. Standard bei 2003 ist hier: Baisis-CRL: 1 Woche Delta -CRL (wenn aktiviert): 1 Tag (kann nur von XP und 2003 ausgewertet werden) Zum zweiten: Der Server braucht für PPTP kein Zertifikat, und wenn er doch eines hat, dann ist das unnötigerweise da und es fehlt ihm auch nicht, wenn du es löscht. Daher ergab sich keine Änderung an dem Authentifizierungsverhalten und es wird sich auch morgen und übermorgen keine ergeben. grizzly999

Irgendwie liegt da ein Missverständnis vor. AD ist das eine und eine SAM das andere, beide haben nicht das geringste miteinander zu tun. Wenn man sich als Domänenmitglied an einem Rechner anmeldet, werden die "cached credentials" (zwischengespeicherten Anmeldeinformationen) in der Registry abgelegt, so dass man sich bei Fehlen des DC nach wie vor anmelden kann, aber keinen autorisierten Zugriff aufs Netzwerk hat. Wenn ich mich das nächste mal bei wieder erreichbarem DC anmelde, werden nach der Authentifizierung am DC die cached credentials auf dem Rechner aktualisiert. Ich sehe jetzt das Problem noch nicht so genau grizzly999

Nur ein Mitglied der loaklen Administratoren-Gruppe kann den Countdown zum Neustart abbrechen, so steht's auch im SUS-Deployment Guide, wlches es übrigens auf der selben seite zum Download gibt, wie den SUS ;) Demnach sind die einen lokale Admins und die anderen nicht, so meine Interpretation grizzly999

Ich kenne diese Empfehlung nicht Abgesehen davon: in einem Single Domain Modell könnte man rein theoretisch immer mit einem Benutzer-in-Gruppe-Modell->Resource Modell arbeiten. Wo wäre in dem beschriebenen Fall (UG) der Unterschied, ob ich die User in eine GG oder eine UG oder eine DL stecke und der Gruppe direkt die Berechtigung gebe?! IMHO nirgends. Die empfohlene Vorgehensweise ist auch bei MS bis dato, das AGDLP-Prinzip. Und bei Migrationen merkt man dann u.U. was man daran hat ;) grizzly999

Das ist korrekt, bis auf: "der DRA kann die Dateine lesen, besitzt also den Public Key" müsste heißen: " ......., besitzt also einen private key" Ich werde mich bemühen längere Ausführungen in kürzere Satze zu fassen ;) grizzly999

Was zeigt denn Client in der Routingtabelle als Stadardroute an? Da sollte er seine eigene dynamische IP, die er vom RRAS erhalten hat, drinstehen (10.1.1.182). Daher braucht er auch nicht die Option 003 vom DHCP Server. Wenn die Adresse nicht drin ist, dann muss entweder in den Eigenschaften der DFÜ-Verbindung das Häkchen "Standardgateway für das Remotenetzwerk verwenden" gesetzt werden oder die route in s Intranet von Hand eingetragen werden. grizzly999