IThome

Hm, hast Du das schon mal probiert ? Ich denke nicht, dass das reicht, aber einen Versuch wäre es wert ...

Meines Wissens dürfen nur Administratoren Dienste installieren und ich kenne auch keinen Weg, es einer weniger privilegierten Gruppe zu erlauben (was natürlich nicht heissen muss, dass es nicht funktioniert) ...

Dieses Recht ist auf einem 2003er nicht notwendig. "Anmelden über Terminaldienste zulassen" ist das anzupassende Benutzerrecht. Ausserdem müssen die User in die Gruppe Remotedesktopbenutzer auf dem Rechner, der via RDP erreicht werden soll und nicht auf dem DC bzw. im AD (es sei denn, auch der DC soll so verwaltet werden, dann ist auch ein Anpassen des Benutzerechtes notwendig) ...

Ja, da ist so, da NSLOOKUP so arbeitet (der abgefragte DNS-Server kann nicht reverse aufgelöst werden). Wenn Berlin delegiert hat, dann sollte auch in NORD von Berlin aus richtig aufgelöst werden ...

Eben, würde mich wundern, wenn nicht ...

Hm, wahrscheinlich habe ich es falsch verstanden, aber warum verteilt sein Router die Adressen nicht ?

Im Zweifel den RRAS deaktivieren und neu konfigurieren. Oder hast Du das auch schon gemacht ?

Wenn er ganz oben steht, kann er nichts mehr weitergeben und ist deswegen ein (Firmen)Stammserver ... Schreibe mal auf, auf welchem Server Du welchen NSLOOKUP Befehl absetzt und welche Meldungen Du dann bekommst ...

Mal im Groben erklärt: Berlin delegiert die Zone NORD.IDEALTEC.DE an Bremen/Kiel. Er ist dann nicht mehr zuständig für diese Zone und löst aus ihr auch nichts mehr auf, sondern verweist nur auf die dortigen DNS-Server, die authoritativ sind. Die Server Bremen und Kiel erstellen eine bedingte Weiterleitung für IDEALTEC.DE, wo die IP-Adresse von Berlin eingegeben wird. Bremen und Kiel sind nur für NORD.IDEALTEC.DE authoritativ und nicht für IDEALTEC.DE. Daher leiten sie alles , was für IDEALTEC.DE bestimmt ist, bedingt an Berlin weiter. In den Zoneneinstellungen muss die z.B. Zonenübertragung erlaubt sein, damit der Secondary den Zoneninhalt erhalten kann. Schau auch mal hier oder suche mal im Board, es gibt ne Menge Erklärungen bezüglich DNS ... MCSEboard.de MCSE Forum - Einzelnen Beitrag anzeigen - DNS (70-291) Bedingte / Standard Weiterleitung

Ach ja, Google gibt´s ja auch noch :D

Ich kenne zwar weder Zyxel noch Netopia, aber Du kannst die externe Schnittstelle des Zyxel mit der internen Schnittstelle des Netopia verbinden (beide ne 30er Maske). Der Zyxel hat die interne Schnittstelle als Default Gateway, die Clients haben die interne des Zyxel als Default Gateway. Auf dem Netopia konfigurierst Du als DMZ-Host (oder wie auch immer das bei Netopia heisst) die externe Schnittstelle des Zyxel. Du kannst natürlich auch beide Router als Firewall benutzen ... Was is BluewinTV ?

Werden die Administratoren exzessiv überwacht (also z.B. auch Objektzugriffsversuche im Dateisystem) ? Laufen die Ereignisanzeigen (Sicherheit) förmlich über, wenn Ihr die User zu Administratoren macht und die dann arbeiten ?

Funktioniert ebenso, wenn der Haken "Windows-Anmeldedomäne einbeziehen" im VPN-Client angehakt wird. Es wird dann mit dem User zugegriffen, mit dem auch die DFÜ-Verbindung hergestellt wird. Diese Credentials werden für den Zeitraum der Verbindung unter "Gespeicherte Kennwörter und Benutzer" abgelegt und sind dort auch nicht veränderbar ...

Du hast also 2 Zonen, IDEALTEC.DE und NORD.IDEALTEC.DE ?! In dieser Konstellation konfiguriert man z.B. auf dem BERLIN.IDEALTEC.DE eine Delegation zu NORD.IDEALTEC.DE zu den Servern dieser Zone. Auf den Servern der Zone NORD.IDEALTEC.DE konfiguriert man eine bedingte Weiterleitung für IDEALTEC.DE zu dem Server BERLIN.IDEALTEC.DE. Achte darauf, dass in den entsprechenden Reverse Lookup Zonen auch Pointer für die Server vorhanden sind, da NSLOOKUP sonst Fehler ausgibt ... Wie hast Du konfiguriert (ich kenne dieses Szenario nicht) ?

Domaene\User oder User@Domaene klappt auch, man muss keine Domäne mehr auswählen ...

Erzeuge auf Deinem internen DNS eine Domäne, die wie die Webseite heisst (anwendung.domane.de). In dieser Zone erzeugst Du einen neuen Host, dem Du keinen Namen gibst, sondern nur die IP-Adresse Deines internen IIS ...

Mir wäre nicht bekannt, dass man den Port ändern könnte und im folgenden Artikel steht, dass der Port TCP 53 sein muss. A DNS zone transfer between a BIND DNS server and a Windows Server 2003-based DNS server does not work when the BIND DNS server acts as a primary server "The BIND DNS server must use the default port 53 to receive the query from the secondary Windows DNS server." Den einzigen relevanten Regkey für den DNS-Dienst, den ich kenne, ist "SendPort", der sich aber auf rekursive UDP-Querys bezieht ...

Das habe ich ja auch schon geschrieben ;) Genau gesagt funktioniert es so ... The Cable Guy - May 2004 Wird kein Suffix verteilt, wird zur Feststellung die Netz-ID benutzt. Was von beiden genommen wird, hängt davon ab, ob bei der letztmaligen Anwendung der Richtlinie (also bei Kontakt zum verwalteten Netzwerk) ein Verbindungssuffix beim Client anlag oder nicht. Lag er bei Anwendung der Richtlinie an, dann befindet sich der Client immer im verwalteten Netzwerk, wenn dieser Verbindungssuffix anliegt (fest eintragen ist da also kontraproduktiv). Liegt keiner an, wird die bei Anwendung der Richtlinie gültige Netz-ID dem verwalteten Netzwerk zugeordnet. Hat der Client also keine Adresse aus diesem Bereich, befindet er sich nicht im verwalteten Netzwerk und das Standardprofil gilt. Was als verwaltetes Netzwerk angesehen wird, ist als Regkey auf dem Client hinterlegt. HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\NetworkName

Ich denke, es hängt von vielen Faktoren ab, ob es Sinn macht, die Windows-Firewall anzuschalten oder nicht. Ich persönlich setze lieber ein Application Layer Firewall an der Grenze ein, vernünftigen Virenschutz und aktuelle Systeme. So erspare ich mir Ärger, besonders wenn die Windows-Firewall auf einem Server läuft (sicherlich ist da auch ein wenig Bequemlichkeit im Spiel ;)).

Mag sein, zumal man die Firewall bequem per GPO konfigurieren kann. Von welchen Angriffen von innen sprichst Du, die die Windows-Firewall (mit aktivierten Verwaltungs-Ausnahmen) unterbindet ?

Ich persönlich schalte die Windowsfirewall auf allen Systemen, solange sie sich im verwalteten Netzwerk befinden, aus (Domänenprofil). Befinden sie sich nicht im verwalteten Netzwerk (Standardprofil), wird die Firewall eingeschaltet (beispielsweise im Hotel). Diese Konfiguration kann man sehr einfach über Gruppenrichtlinien durchsetzen und sie funktioniert sehr gut zusammen mit vom DHCP-Server verteilten Verbindungssuffixen (die Entscheidung, ob man sich im verwalteten Netzwerk befindet oder nicht, hängt entweder vom beim ersten Anwenden der Richtlinie anliegenden Verbindungssuffix bzw. von der zu dieser Zeit gültigen Netzwerk-ID ab). In der Firma steht selbstverständlich ein Security Gateway, welches das Netzwerk schützt ...

Was genau hast Du wo eingestellt ? In welcher Gruppe Remotedesktopbenutzer sind die User enthalten (auf dem Terminalserver oder dem DC) ? Ist der TS auch DC ? Welches Benutzerrecht hast Du wo eingestellt ? Der Benutzer muss ... in der Gruppe Mitglied sein, die in der Terminaldienstekonfiguration im RDP-TCP Objekt berechtigt wird (in der Regel die Gruppe Remotedesktopbenutzer auf dem TS, falls der TS auch DC ist, dann in der Gruppe Remotedesktopbenutzer im Container Builtin). Er muss das Benutzerrecht "Anmelden über Terminaldienste zulassen" besitzen. Dieses Recht hat auf einem Member-TS u.a. die Gruppe Remotedesktopbenutzer, auf einem DC, der auch TS ist, nur die Gruppe Administratoren. Er benötigt auf einem 2K3 Server nicht das Benutzerrecht "Lokal anmelden zulassen". Dieses Benutzerrecht (Anmelden über Terminaldienste zulassen) ist in der lokalen Richtlinie vordefiniert ... Poste auch mal die genaue Fehlermeldung ...

Eigentlich wird das in BOOT.INI angegeben (/SAFEBOOT), was man in der Regel nicht tun muss, da NTLDR diese Option nach Drücken von F8 und Auswahl des entsprechenden Punktes bestimmt. Registry, hm, wüsste ich jetzt nicht, ob sowas dort hinterlegt wird. Dort kenne ich nur die Angabe für den Lastknowngood, Currentcontrolset usw. ...

Was passiert, wenn bei Benutzer B der Haken "Windows-Anmeldedomäne einbeziehen" aktiviert ist ? Sind die Rechner, die die VPN-Verbindung aufbauen, alle Domänenmitglieder ?

Melden sich denn einige VPN-Clients an ihren Rechnern mit Konten/Kennwörtern an, die auch in der Domäne existieren und andere eben mit Konten, die entweder so nicht existieren oder die ein anderes Kennwort in der Domäne haben ?