22
Grundsätzliche Frage - Bekomme ich dieses Netzwerk überhaupt zum laufen?
Moin,
bevor ich mich nun dumm und dämlich suche, muss ich erstmal wissen, ob mein Vorhaben realisierbar ist und wenn ja, wie.
Ich habe zwei gemietete Server mit Windows Server 2003 R2 SP2. Auf dem ersten habe ich die Active Directory eingerichtet, den zweiten habe ich in die Domäne gehoben. Dieser dient im Prinzip nur dazu, dass ich mehr als 2 RDP-Sitzungen zur Verfügung habe. Das funktioniert auch soweit alles ganz gut.
Server A hat die IP-Adresse 178.xx.xx.xxx - Standardgateway 192.168.xx.xxx - Subnetzmaske 255.255.255.0
Server B hat die IP-Adresse 83.xxx.xx.xxx - Standardgateway 192.168.yy.yyy - Subnetzmaske 255.255.255.0
Änder ich am Server B die Standardgateway, ist diese nach dem nächsten Systemstart wieder auf die oben angegebene geändert.
Der Server hat eine Netzwerkkarte.
Wenn ich diese beiden Netze nun verbinden möchte, wie muss ich da vorgehen? Der Auslöser für das Vorhaben ist eigentlich nur, dass ich mich von Server A mit Server B verbinden möchte, um ggf. alte RDP-Sitzungen manuell zu beenden. Die AD funktioniert ja wunderbar (zumindest sieht es für einen laien wie mich so aus).
Edit: Achja. Wenn ich auf Server A unter "Gesamtes Netzwerk > Microsoft Windows Network" auf meine Domäne klicke, kommt die Meldung "Die Liste der Server in dieser Arbeitsgruppe ist zur Zeit nicht verfügbar". Da ist doch irgendwas faul. Das kann doch nicht richtig sein?!
Ich hoffe, mir kann jemand helfen!
Gruß
bevor ich mich nun dumm und dämlich suche, muss ich erstmal wissen, ob mein Vorhaben realisierbar ist und wenn ja, wie.
Ich habe zwei gemietete Server mit Windows Server 2003 R2 SP2. Auf dem ersten habe ich die Active Directory eingerichtet, den zweiten habe ich in die Domäne gehoben. Dieser dient im Prinzip nur dazu, dass ich mehr als 2 RDP-Sitzungen zur Verfügung habe. Das funktioniert auch soweit alles ganz gut.
Server A hat die IP-Adresse 178.xx.xx.xxx - Standardgateway 192.168.xx.xxx - Subnetzmaske 255.255.255.0
Server B hat die IP-Adresse 83.xxx.xx.xxx - Standardgateway 192.168.yy.yyy - Subnetzmaske 255.255.255.0
Änder ich am Server B die Standardgateway, ist diese nach dem nächsten Systemstart wieder auf die oben angegebene geändert.
Der Server hat eine Netzwerkkarte.
Wenn ich diese beiden Netze nun verbinden möchte, wie muss ich da vorgehen? Der Auslöser für das Vorhaben ist eigentlich nur, dass ich mich von Server A mit Server B verbinden möchte, um ggf. alte RDP-Sitzungen manuell zu beenden. Die AD funktioniert ja wunderbar (zumindest sieht es für einen laien wie mich so aus).
Edit: Achja. Wenn ich auf Server A unter "Gesamtes Netzwerk > Microsoft Windows Network" auf meine Domäne klicke, kommt die Meldung "Die Liste der Server in dieser Arbeitsgruppe ist zur Zeit nicht verfügbar". Da ist doch irgendwas faul. Das kann doch nicht richtig sein?!
Ich hoffe, mir kann jemand helfen!
Gruß
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 148475
Url: https://administrator.de/contentid/148475
Ausgedruckt am: 22.11.2024 um 18:11 Uhr
22 Kommentare
Neuester Kommentar
Hi,
der Ganze Aufbau ist sehr komisch!
1. Normal sollten Server im Netzewrk immer eine private IP bekommen!
2. Server und Gateway liegen nicht im gleichen Netz - warum? Funktioniert das ganze überhaupt mit Clients?
3. Entweder man lässt den 2. Server als Mitgliedserver laufen oder man setzt ihn als 2. Domain Controller ein! Wenn beide immer laufen, wäre das die bessere Lösung.
Was hast du überhaupt vor? Hast du nur Domain zum Spielen installiert? Allein die IPs kommen mir grad sehr spanisch vor! Kommst du überhaupt mit den Dingern ins Internet, etc.?
mfg Crusher
der Ganze Aufbau ist sehr komisch!
1. Normal sollten Server im Netzewrk immer eine private IP bekommen!
2. Server und Gateway liegen nicht im gleichen Netz - warum? Funktioniert das ganze überhaupt mit Clients?
3. Entweder man lässt den 2. Server als Mitgliedserver laufen oder man setzt ihn als 2. Domain Controller ein! Wenn beide immer laufen, wäre das die bessere Lösung.
Was hast du überhaupt vor? Hast du nur Domain zum Spielen installiert? Allein die IPs kommen mir grad sehr spanisch vor! Kommst du überhaupt mit den Dingern ins Internet, etc.?
mfg Crusher
Hey, danke für Deine schnelle Antwort.
Gruß
1. Normal sollten Server im Netzewrk immer eine private IP bekommen!
Die IPs kann ich leider nicht ändern, da diese von HostEurope so vorgegeben worden sind.2. Server und Gateway liegen nicht im gleichen Netz - warum? Funktioniert das ganze überhaupt mit Clients?
Ins Internet komme ich mit beiden Servern. Auch die Geschichte mit den Clients klappt ganz gut. Die IP kann ich wie gesagt nicht ändern. Die Gateway setzt sich nach jedem Neustart wieder auf den Ursprung zurück.3. Entweder man lässt den 2. Server als Mitgliedserver laufen oder man setzt ihn als 2. Domain Controller ein! Wenn beide immer laufen, wäre das die bessere Lösung.
Und dann müsste es gehen? Wenn ja, würde es sich ja lohnen, mich da einmal schlau zu lesen...Was hast du überhaupt vor?
Ich brauche die Möglichkeit, dass ich irgendjemand (egal von wo) als Client an dem Server anmelden kann. Aber halt mehr als zwei Leute gleichzeitig, und das ohne Terminallizenzen.Gruß
Was hat RDP mit Active Directory zu tun?
Hi,
aha so etwas dachte ich mir schon!
Wofür brauchst du die Dinger? Du hast einen 2. gemietet, nur um RDP zu machen?
Generell dürfte es erstmal nicht gehen! Mit Client meinst du doch jetzt Kiste die irgendwo im Inetnet hängt, oder? Ich meinte jetzt Firmen, Heimnetz mit Rechner die an einen Switch mit dem Server hängen.
Es gibt zwischen den Serven keine direkte Verbindung. Vermutlich sind sie nicht mal im selben Gebäude. Also mit Gateway wirst du nicht weit kommen!
Die einzige Methode ist VPN:
- Richte VPN Server ein und lass den einen Server sich beim anderen einwählen. **ACHTUNG: Standardgateway der Remote Verbindung darf nich verwendet werden! Sonst kommst du an den Server von Aussen nicht mehr ran, wenn er die Verbindung aufgebaut hat.
Im VPN Bereich - mal ganz einfach formuliert - kannst du private IP angeben und dann von der "RDP-Maschine" auf den Domaincontroller gehen.
192.168. sind öffentliche IPs! Das Gateway hier gepostet sollte also keine Hacker anlocken. ;)
mfg Crusher
aha so etwas dachte ich mir schon!
Wofür brauchst du die Dinger? Du hast einen 2. gemietet, nur um RDP zu machen?
Generell dürfte es erstmal nicht gehen! Mit Client meinst du doch jetzt Kiste die irgendwo im Inetnet hängt, oder? Ich meinte jetzt Firmen, Heimnetz mit Rechner die an einen Switch mit dem Server hängen.
Es gibt zwischen den Serven keine direkte Verbindung. Vermutlich sind sie nicht mal im selben Gebäude. Also mit Gateway wirst du nicht weit kommen!
Die einzige Methode ist VPN:
- Richte VPN Server ein und lass den einen Server sich beim anderen einwählen. **ACHTUNG: Standardgateway der Remote Verbindung darf nich verwendet werden! Sonst kommst du an den Server von Aussen nicht mehr ran, wenn er die Verbindung aufgebaut hat.
Im VPN Bereich - mal ganz einfach formuliert - kannst du private IP angeben und dann von der "RDP-Maschine" auf den Domaincontroller gehen.
192.168. sind öffentliche IPs! Das Gateway hier gepostet sollte also keine Hacker anlocken. ;)
mfg Crusher
Ein Anruf bei HostEurope war ähnlich deprimierend, wie meine bisherigen Versuche: Eine Änderung der IP-Adresse ist definitiv nicht möglich, auch besteht, wie Du schon richtig sagst, keine direkte Verbindung zwischen den Servern. Er wüsste auch nicht, wie man dort ein Netzwerk aufbauen könnte.
Was ich nicht verstehe:
1. Über \\COMPUTERNAME komme ich vom Server B problemlos auf die Freigaben von Server A. Über den Umweg über die Domäne klappt es jedoch nicht.
2. Die AD funktioniert, ist dieser ganze Aufwand wirklich nötig, wenn ich nur meine RDP-Sitzungen verwalten möchte? Es wird nämlich so sein, dass sich "fremde" Leute an dem Server anmelden. Wenn diese nun die RDP-Sitzung einfach schließen und sich nicht brav abmelden, vergeuden wir jedes Mal eine Sitzung. Dass die Sitzungen automatisch abgemeldet werden geht aber auch nicht, da die User auch die Möglichkeit haben müssen, bewusst die Sitzung über Nacht laufen zu lassen.
Ich könnte nun natürlich auf jedem der beiden Server jeweils eine RDP-Sitzung für administrative Zwecke frei halten, doch dann habe ich wieder nur zwei weitere Sitzungen zur Verfügung. Ich benötige jedoch mind. drei.
Nochwas: Stichwort Routingtabellen... oder komplett falscher Dampfer?
Gruß
Was ich nicht verstehe:
1. Über \\COMPUTERNAME komme ich vom Server B problemlos auf die Freigaben von Server A. Über den Umweg über die Domäne klappt es jedoch nicht.
2. Die AD funktioniert, ist dieser ganze Aufwand wirklich nötig, wenn ich nur meine RDP-Sitzungen verwalten möchte? Es wird nämlich so sein, dass sich "fremde" Leute an dem Server anmelden. Wenn diese nun die RDP-Sitzung einfach schließen und sich nicht brav abmelden, vergeuden wir jedes Mal eine Sitzung. Dass die Sitzungen automatisch abgemeldet werden geht aber auch nicht, da die User auch die Möglichkeit haben müssen, bewusst die Sitzung über Nacht laufen zu lassen.
Ich könnte nun natürlich auf jedem der beiden Server jeweils eine RDP-Sitzung für administrative Zwecke frei halten, doch dann habe ich wieder nur zwei weitere Sitzungen zur Verfügung. Ich benötige jedoch mind. drei.
Nochwas: Stichwort Routingtabellen... oder komplett falscher Dampfer?
Gruß
Sind die Freigaben jetzt für alle nutzbar? Heisst, wenn ich nur deine WAN IP hier rein Zimmer komme ich an deine Daten??
Wofür soll der Server denn überhaupt sein? RDP ist eh nich das sicherste. Schöne wäre VPN Verbindung für jeden Externen und sich dann über die mit dem Server zu verbinden.
Irgendwie bereitet mir dein ganzes Projekt gerade unbehagen! Wie viele sollen denn mit dem Server arbeiten?
/edit: Es sind 2 Webserver! Da hat eine AD normal eh nix verloren! Auch Firmenserver werden gehostet, aber die sind meist hinter starken Firewalls verborgen. Öffentlich ist nur die IP des Gateways.
So wie es jetzt aufgebaut ist, ist dein ganze Projekt eher fahrlässig! Auch wenn es laufen würde - wo ist dein Sicherheitskonzept?
Wofür soll der Server denn überhaupt sein? RDP ist eh nich das sicherste. Schöne wäre VPN Verbindung für jeden Externen und sich dann über die mit dem Server zu verbinden.
Irgendwie bereitet mir dein ganzes Projekt gerade unbehagen! Wie viele sollen denn mit dem Server arbeiten?
/edit: Es sind 2 Webserver! Da hat eine AD normal eh nix verloren! Auch Firmenserver werden gehostet, aber die sind meist hinter starken Firewalls verborgen. Öffentlich ist nur die IP des Gateways.
So wie es jetzt aufgebaut ist, ist dein ganze Projekt eher fahrlässig! Auch wenn es laufen würde - wo ist dein Sicherheitskonzept?
Ein super Gefühl habe ich dabei nun auch nicht 
. Aber ich denke für das, was ich vor habe, sollte es reichen:
Ich möchte gerne, dass potenzielle Kunden (die im Normalfall soviel Ahnung von Rechnern haben wie ich vom Stricken) auf dem Server ein Programm testen können, ohne, dass sie irgendetwas auf ihrem eigenen Rechner installieren müssen. So muss ich denen lediglich die IP und das Kennwort geben. Die User habe ich via GPO aufs Minimum beschränkt. Lediglich 1-2 Internetseiten gehen, eigene Dateien (Servergespeichert) und eben das Programm zum testen.
. Aber ich denke für das, was ich vor habe, sollte es reichen:Ich möchte gerne, dass potenzielle Kunden (die im Normalfall soviel Ahnung von Rechnern haben wie ich vom Stricken) auf dem Server ein Programm testen können, ohne, dass sie irgendetwas auf ihrem eigenen Rechner installieren müssen. So muss ich denen lediglich die IP und das Kennwort geben. Die User habe ich via GPO aufs Minimum beschränkt. Lediglich 1-2 Internetseiten gehen, eigene Dateien (Servergespeichert) und eben das Programm zum testen.
1. Normal sollten Server im Netzewrk immer eine private IP bekommen!
Nö, warum?
Idealerweise bekommt sogar jeder Rechner in einem Netzwerk eine öffentliche IP - das ist seit SPI-Firewalls garkein Problem mehr, da sind nur die Provider zu knauserig.
Vermutlich sind sie nicht mal im selben Gebäude.
Bei HE schon, die haben nämlich nur Eins
Normalerweise würde man jetzt beim Anbieter (HE) ein Private Interconnect beantragen, also die beiden Server z.B. auf einem VLAN untereinader geswitcht verbinden und dann einen Router nehmen, der vorgeschaltet ist und nur VPN durchlässt.
Das sind normalerweise alles Dinge, die ein Root Server-Anbieter täglich konfiguriert.
Danke auch Dir für die Antwort!
Habe eben mit denen telefoniert und denen mein Problem geschildert. Leider konnte mir der HE-Support bisher bei keinem Problem helfen. Auch meine Frage, ob eine direkte Verbindung der beiden Server möglich sein, verneinte der nette Herr.
Normalerweise würde man jetzt beim Anbieter (HE) ein Private Interconnect beantragen, also die beiden Server z.B. auf einem
VLAN untereinader geswitcht verbinden und dann einen Router nehmen, der vorgeschaltet ist und nur VPN durchlässt.
VLAN untereinader geswitcht verbinden und dann einen Router nehmen, der vorgeschaltet ist und nur VPN durchlässt.
Habe eben mit denen telefoniert und denen mein Problem geschildert. Leider konnte mir der HE-Support bisher bei keinem Problem helfen. Auch meine Frage, ob eine direkte Verbindung der beiden Server möglich sein, verneinte der nette Herr.
Welche Produkte hast Du denn bei HE angemietet? vServer, Root Server oder Managed?
Coder
Coder
hallo heisenberg
wenn die server sowieso "offen" im netz hängen, warum gehst du dann überhaupt über rdp-verbindungen?
du kannst auf die freigaben per \\ip\freigabe zugreifen und auch als netzlaufwerke mounten.
richte in deinem ad benutzer und passwörter so ein wie die clients bei deinem kunden lokal verwenden. die windows-clients geben beim ersten verbindungsversuch genau diese durch und die clients können auf die freigabe zugreifen, egal ob sie domänen-mitglied sind oder nicht.
die moralpredigt wie unsicher das alles ist was du da baust erspar ich dir
.
gruß,
epic
wenn die server sowieso "offen" im netz hängen, warum gehst du dann überhaupt über rdp-verbindungen?
du kannst auf die freigaben per \\ip\freigabe zugreifen und auch als netzlaufwerke mounten.
richte in deinem ad benutzer und passwörter so ein wie die clients bei deinem kunden lokal verwenden. die windows-clients geben beim ersten verbindungsversuch genau diese durch und die clients können auf die freigabe zugreifen, egal ob sie domänen-mitglied sind oder nicht.
die moralpredigt wie unsicher das alles ist was du da baust erspar ich dir
.gruß,
epic
Und HIER kam mir grad ehrlich gesagt mein Frühstück hoch!
Die normalen RDP-Verbindungen bei einem Standard-Server sind für Admins da - damit die den Server verwalten können! Da hat mit diesen Verbindungen NIEMAND ausser dem Admin was auf dem Server verloren!
Du gibst die Dinger an deine Kunden - klasse, und die haben dann erstmal schön Admin-Rechte?!? DAS nenn ich mal Vertrauensvorschuss!
Also nimms mir nicht übel - aber das Konzept ist keines!
Solltest du das aber wirklich so durchziehen wollen (hf&gl) dann reicht doch nen normaler Standard-Server. Du hast 2 RDP-Lizenzen für die Kunden - und kannst dich z.B. mittels Dameware, VNC oder was auch immer auf die normale Konsole schalten und dann via Fernwartung darauf arbeiten. Schon hast du deine 3 Verbindungen - zumindest bis zu dem Zeitpunkt wo der erste Kunde merkt das er Admin-Rechte hat und da mal Passwörter ändert o.ä. Spass treibt... ("ups, hab ich grad auf Runterfahren gedrückt?", "ups, hab ich grad die Datenbank gekillt?" usw...)
Die normalen RDP-Verbindungen bei einem Standard-Server sind für Admins da - damit die den Server verwalten können! Da hat mit diesen Verbindungen NIEMAND ausser dem Admin was auf dem Server verloren!
Du gibst die Dinger an deine Kunden - klasse, und die haben dann erstmal schön Admin-Rechte?!? DAS nenn ich mal Vertrauensvorschuss!
Also nimms mir nicht übel - aber das Konzept ist keines!
Solltest du das aber wirklich so durchziehen wollen (hf&gl) dann reicht doch nen normaler Standard-Server. Du hast 2 RDP-Lizenzen für die Kunden - und kannst dich z.B. mittels Dameware, VNC oder was auch immer auf die normale Konsole schalten und dann via Fernwartung darauf arbeiten. Schon hast du deine 3 Verbindungen - zumindest bis zu dem Zeitpunkt wo der erste Kunde merkt das er Admin-Rechte hat und da mal Passwörter ändert o.ä. Spass treibt... ("ups, hab ich grad auf Runterfahren gedrückt?", "ups, hab ich grad die Datenbank gekillt?" usw...)
Danke für das viele Feedback. Sehr interessant und vorallem wichtig!
So wie es jetzt aufgebaut ist, ist dein ganze Projekt eher fahrlässig!
Angenommen, wir geben dem Kunden nun die IP des Servers, den Benutzernamen und das Kennwort. Das gibt der Kunde dann direkt in RemoteDesktop ein und verbindet sich mit dem Server. Was könnte der User denn alles mit der IP anfangen? Ist es allein durch die IP möglich, dass irgendein Arsch*och ankommt und seine Kinderpornos auf dem Server lagert und wir dann die gelackmeierten sind? Durch die GPO ist es dem User theoretisch nur möglich auf Eigene Dateien zuzugreifen und unser Programm zu bedienen. Im IE habe ich localhost als Proxy hinterlegt und nur bestimmte Seiten als Ausnahmen definiert.Du gibst die Dinger an deine Kunden - klasse, und die haben dann erstmal schön Admin-Rechte?!? DAS nenn ich mal Vertrauensvorschuss! [...] Schon hast du deine 3 Verbindungen - zumindest bis zu dem Zeitpunkt wo der erste Kunde merkt das er Admin-Rechte hat und da mal Passwörter ändert o.ä. Spass treibt... ("ups, hab ich grad auf Runterfahren gedrückt?", "ups, hab ich grad die Datenbank gekillt?" usw...)
Das ist ja genau meine Frage. Theoretisch habe ich ja über die Benutzernamen und die GPO alles verboten. Die User können keine Passwörter ändern, den Rechner runterfahren, Dateien ändern/speichern/löschen (nur in Eigene Dateien), Rechtsklick, Tastenkombinationen, Ausführen etc. sind auch deaktiviert...richte in deinem ad benutzer und passwörter so ein wie die clients bei deinem kunden lokal verwenden. die windows-clients geben beim ersten verbindungsversuch genau diese durch und die clients können auf die freigabe zugreifen, egal ob sie domänen-mitglied sind oder nicht.
Wenn ich Dich richtig verstanden habe: Ich richte in der AD einen User Hansi ein mit Kennwort. Dem Kunden gebe ich dann die IP, den Benutzernamen und das Kennwort. Dieser loggt sich dann direkt mit den Daten ein. Wenn Du das meinst, dann habe ich das bereits so eingerichtet.Welche Produkte hast Du denn bei HE angemietet? vServer, Root Server oder Managed?
Zwei vServer mit W2K3 R2 SP2
Moin,
ok, erstmal kommt es jetzt auf die Art der Richtlinie an - es kann sein das du dir auch damit deinen Admin-Acc wegballerst.
Aber: Generell ist es schlecht wenn der Kunde auf der Kiste auch nur den IE öffnen kann und die Option hat das er Daten "frei" überträgst. Nicht mal unbedingt wegen Kinder-Pornos - das geht schon bei einfachen MP3-Downloads los. Und schon hast du ein erstes Problem. Denn wie weisst du nach das DIE Person wirklich zu dem Zeitpunkt auf dem Server war?
Was ich ggf. eher machen würde: Wenn es nur darum geht das die sich ne Software angucken können (und ich vermute mal du möchtest auch nicht das die Kopiert werden kann...): Einen Server bei mir vor Ort aufstellen. Hiervon nen Image machen (-> sicher ist sicher...) und dem Kunden da in der Kiste festtackern (per Firewall ist nur RDP auf der Kiste möglich - die kommt weder per HTTP, FTP noch sonstwie raus!). Ggf. sogar ne VM davon machen (per ESX) und eben für jeden Kunden da ne kopie der VM bereitstellen (sofern die überschaubar in der Anzahl sind). Denn DA kann ich dem wirklich Admin-Rechte geben. Soll er doch die Kiste zerschroten -> is ja seine Testumgebung die er grad platt macht... Dem 2ten Kunden intressiert das nicht mal - der arbeitet in einer völlig eigenen VM mit nem anderen PW usw... Der hat auch nen ganz eigenen Datenbestand, ... -> also überhaupt keine Probleme wenn da 2-3 Kunden gleichzeitig rumtoben...
Und selbst das es langsamer läuft is normal kein Problem: Es ist ja für die Kunden zum TESTEN! Da bringen die für Gewöhnlich dann auch Verständnis mit das die Leitung etwas langsamer ist...
Nebenbei hast du keine Probleme das die illegale Daten runterladen können (die kommen ja nicht mehr raus!), die können keine Daten einfach hochladen (die kommen gar nicht ran!) - und wenn du sagst der Testzeitraum von 1 Woche ist für den Kunden um dann stoppst du die VM und löscht die -> ruhe ist... Blanke VM wieder vom "Ur-Image" holen und der nächste Kunde darf rumtoben...
Halte ich persönlich für besser als nen Gefrickel auf nem Root-Server. Insbesondere dann wenn der keine Firewall hat und/oder sogar noch nen Domänen-Controller is (das kannst du dir bei den VM-Servern ja schenken - die Domäne is völlig latte!)
ok, erstmal kommt es jetzt auf die Art der Richtlinie an - es kann sein das du dir auch damit deinen Admin-Acc wegballerst.
Aber: Generell ist es schlecht wenn der Kunde auf der Kiste auch nur den IE öffnen kann und die Option hat das er Daten "frei" überträgst. Nicht mal unbedingt wegen Kinder-Pornos - das geht schon bei einfachen MP3-Downloads los. Und schon hast du ein erstes Problem. Denn wie weisst du nach das DIE Person wirklich zu dem Zeitpunkt auf dem Server war?
Was ich ggf. eher machen würde: Wenn es nur darum geht das die sich ne Software angucken können (und ich vermute mal du möchtest auch nicht das die Kopiert werden kann...): Einen Server bei mir vor Ort aufstellen. Hiervon nen Image machen (-> sicher ist sicher...) und dem Kunden da in der Kiste festtackern (per Firewall ist nur RDP auf der Kiste möglich - die kommt weder per HTTP, FTP noch sonstwie raus!). Ggf. sogar ne VM davon machen (per ESX) und eben für jeden Kunden da ne kopie der VM bereitstellen (sofern die überschaubar in der Anzahl sind). Denn DA kann ich dem wirklich Admin-Rechte geben. Soll er doch die Kiste zerschroten -> is ja seine Testumgebung die er grad platt macht... Dem 2ten Kunden intressiert das nicht mal - der arbeitet in einer völlig eigenen VM mit nem anderen PW usw... Der hat auch nen ganz eigenen Datenbestand, ... -> also überhaupt keine Probleme wenn da 2-3 Kunden gleichzeitig rumtoben...
Und selbst das es langsamer läuft is normal kein Problem: Es ist ja für die Kunden zum TESTEN! Da bringen die für Gewöhnlich dann auch Verständnis mit das die Leitung etwas langsamer ist...
Nebenbei hast du keine Probleme das die illegale Daten runterladen können (die kommen ja nicht mehr raus!), die können keine Daten einfach hochladen (die kommen gar nicht ran!) - und wenn du sagst der Testzeitraum von 1 Woche ist für den Kunden um dann stoppst du die VM und löscht die -> ruhe ist... Blanke VM wieder vom "Ur-Image" holen und der nächste Kunde darf rumtoben...
Halte ich persönlich für besser als nen Gefrickel auf nem Root-Server. Insbesondere dann wenn der keine Firewall hat und/oder sogar noch nen Domänen-Controller is (das kannst du dir bei den VM-Servern ja schenken - die Domäne is völlig latte!)
Hi,
naja über GPOs hast du kein Wort verloren! Kenn auch deine Vorkenntnisse nicht.
Du hast ja nur geschrieben, hab da 2 Server, will die verbinden... Leute drauf lassen.
Das meinte ich mit fahrlässig. Dein ganzes Konzept war ja nicht beschrieben. Generell sind alles Server die im I-net stehen angreifbar! GPOs spielen dann auch keine Rolle, wenn Angreifer andere Lücken nutzt und sich Zugriff verschafft. Und sei es nur Freigaben für Filme, etc. zu mißbrauchen.
Darum wäre so oder so Überwachung angesagt. Besser ist es aber schon so zu planen, dass nicht jeder auf den Server kommt. Auch keinen Verbindungsversuch unternehmen kann. Wenn eine Firewall vorgeschaltet ist und Kunde feste IP hat, könnte man z.B. nur Verkehr von der und der Quell IP zulassen.
Was genau soll der Kunde dort denn alles sehen? Was für eine Software? Um wie viele Kunden geht es denn dabei? Ist wirklcih 24/7 Zugang nötig?
mfg Crusher
naja über GPOs hast du kein Wort verloren! Kenn auch deine Vorkenntnisse nicht.
Du hast ja nur geschrieben, hab da 2 Server, will die verbinden... Leute drauf lassen.
Das meinte ich mit fahrlässig. Dein ganzes Konzept war ja nicht beschrieben. Generell sind alles Server die im I-net stehen angreifbar! GPOs spielen dann auch keine Rolle, wenn Angreifer andere Lücken nutzt und sich Zugriff verschafft. Und sei es nur Freigaben für Filme, etc. zu mißbrauchen.
Darum wäre so oder so Überwachung angesagt. Besser ist es aber schon so zu planen, dass nicht jeder auf den Server kommt. Auch keinen Verbindungsversuch unternehmen kann. Wenn eine Firewall vorgeschaltet ist und Kunde feste IP hat, könnte man z.B. nur Verkehr von der und der Quell IP zulassen.
Was genau soll der Kunde dort denn alles sehen? Was für eine Software? Um wie viele Kunden geht es denn dabei? Ist wirklcih 24/7 Zugang nötig?
mfg Crusher
ok, erstmal kommt es jetzt auf die Art der Richtlinie an - es kann sein das du dir auch damit deinen Admin-Acc wegballerst.
Die Richtlinie habe ich natürlich nur auf bestimmte Organisationseinheiten angewandt. Der Admin darf weiterhin alles.Aber: Generell ist es schlecht wenn der Kunde auf der Kiste auch nur den IE öffnen kann und die Option hat das er Daten "frei" überträgst. Nicht mal unbedingt wegen Kinder-Pornos - das geht schon bei einfachen MP3-Downloads los. Und schon hast du ein erstes Problem. Denn wie weisst du nach das DIE Person wirklich zu dem Zeitpunkt auf dem Server war?
Also wir wissen schon wem wir wann welchen Account zum testen geben. Welche Internetseiten geöffnet werden können, bestimme ich. Ein/Zwei Seiten müssen frei sein. Wie könnte der User denn eine MP3 auf dem Server lagern? Das die lokalen Laufwerke gemappt werden können, habe ich unterbunden.Wenn wir uns hier einen Server hinstellen und die Kunden darauf testen lassen, wird das abartig langsam werden, da die Telekom mit dem Ausbau nicht hinterher kommt. Ausserdem können wir dann keine Serverumgebung simulieren.
Darum wäre so oder so Überwachung angesagt. Besser ist es aber schon so zu planen, dass nicht jeder auf den Server kommt. Auch keinen Verbindungsversuch unternehmen kann. Wenn eine Firewall vorgeschaltet ist und Kunde feste IP hat, könnte man z.B. nur Verkehr von der und der Quell IP zulassen.
Es ist die Windo*of-Firewall vorgeschaltet und alle Ports sind gesperrt. Du meinst, wir sollten, wenn möglich mit einer Whitelist arbeiten? Keine schlechte Idee... Das werde ich mal prüfen, in wie weit das möglich sein wird.Was genau soll der Kunde dort denn alles sehen? Was für eine Software? Um wie viele Kunden geht es denn dabei? Ist wirklcih 24/7 Zugang nötig?
Aktuell kann der Kunde Eigene Dateien sehen, im Startmenü kann er sich nur abmelden, das Programm starten, den IE starten und Outlook Express (leider nötig um das Programm in vollem Umfang nutzen zu können). Es geht nicht um viele Kunden. Und 24/7 wäre schön. Ansonsten kann ich das ja über die AD-Benutzer und Computer regeln...
Das sind virtuelle Server in einem Virtuozzo Container die IP etc. kannst Du nicht ändern genauso ist VPN nicht möglich. Ich würde auch nicht zu stark an den Einstellungen schrauben. Die Windows Server 2003 Webserver Version ist eine angepaßte Version für die VMs. Du solltest auch nicht das Windows Update nutzen das kann dir die VM zerballern, Updates spielt HE ein.
Der Server hat einige Einschränkungen, nicht mal einen Virenscanner kann man installieren bis auf ClamWIN.
Der Server hat einige Einschränkungen, nicht mal einen Virenscanner kann man installieren bis auf ClamWIN.
Hi,
mal ne ganz andere Frage:
Du willst mehr als 2 RDPs, hast also 2 Server, also 4 RDPs (demnach gehen die Kunden auf beide Server?)
wenn Du das alles nur machst (Server A & B sollen sich sehen), um von A aus auf B eine hängene RDP
abzuschiessen (auch umgekehrt?), wieso gehst Du selber dann nicht per VNC o.ä. direkt auf die Server um das zu tun ?
(Ich glaube darauf bezog sich Deine Ur-Frage..)
Gruss
Ralf
mal ne ganz andere Frage:
Du willst mehr als 2 RDPs, hast also 2 Server, also 4 RDPs (demnach gehen die Kunden auf beide Server?)
wenn Du das alles nur machst (Server A & B sollen sich sehen), um von A aus auf B eine hängene RDP
abzuschiessen (auch umgekehrt?), wieso gehst Du selber dann nicht per VNC o.ä. direkt auf die Server um das zu tun ?
(Ich glaube darauf bezog sich Deine Ur-Frage..)
Gruss
Ralf
Hallo Ralf,
ja darauf wird es nun hinauslaufen. Zwar (erstmal) nicht per VNC sondern per TeamViewer Host, aber das Ergebnis wird das selbe sein. Vielen Danke für die vielen Antworten! Werde das Thema, wenn es soweit ist, als gelöst markieren. Vielleicht kommen ja noch ein/zwei Ideen.
Schönen Montag!
ja darauf wird es nun hinauslaufen. Zwar (erstmal) nicht per VNC sondern per TeamViewer Host, aber das Ergebnis wird das selbe sein. Vielen Danke für die vielen Antworten! Werde das Thema, wenn es soweit ist, als gelöst markieren. Vielleicht kommen ja noch ein/zwei Ideen
.Schönen Montag!
Ein weiteres Problem hat er dennoch...
Wenn ich die Windo*of-Firewall einschalte, kann ich mich nicht mehr über den zweiten Server an der AD anmelden. Habe schon alle gängigen Ports (die ich im Bezug auf RDP und AD gefunden habe) durchprobiert:
135 tcp rpc-portmapper
389 tcp + udp ldap
636 tcp ldap ssl
3268 tcp ldap gc
326 tcp ldap gc ssl
53 tcp + udp dns
88 tcp + udp kerberos
445 tcp smb
137-139 tcp + udp (smb für Windows NT)
Irgendwelche Ideen?
Beste Grüße!
Wenn ich die Windo*of-Firewall einschalte, kann ich mich nicht mehr über den zweiten Server an der AD anmelden. Habe schon alle gängigen Ports (die ich im Bezug auf RDP und AD gefunden habe) durchprobiert:
135 tcp rpc-portmapper
389 tcp + udp ldap
636 tcp ldap ssl
3268 tcp ldap gc
326 tcp ldap gc ssl
53 tcp + udp dns
88 tcp + udp kerberos
445 tcp smb
137-139 tcp + udp (smb für Windows NT)
Irgendwelche Ideen?
Beste Grüße!
Hi,
445 UDP fehlt noch
Evtl. noch Port 3389 auf der RDP-out-Seite ?
Die SMB 137-139 weiss ich nicht, im Zweifel zulassen
Gruss
Ralf
445 UDP fehlt noch
Evtl. noch Port 3389 auf der RDP-out-Seite ?
Die SMB 137-139 weiss ich nicht, im Zweifel zulassen
Gruss
Ralf
Guten Morgen!
Ich habe nun (eigentlich nur zum testen) ALLE angegebenen Ports als "Ausnahme" definiert. Es klappt trotzdem nicht. Stelle ich die Firewall ganz aus, klappt es. Es muss also etwas mit der Firewall zu tun haben...
Edit: Nun sagt er mir beim Anmelden, der RPC-Server sei nicht verfügbar. Ohne Firewall klappt es aber weiterhin.
Edit2: mit dem Befehl netsh firewall set service REMOTEADMIN enable in der Eingabeaufforderung hat es nun geklappt. Leider dauert das Anmelden mit Firewall nun ca. 10 Minuten?! Das Abmelden dauert ebenfalls ewig.
Gruß
Ich habe nun (eigentlich nur zum testen) ALLE angegebenen Ports als "Ausnahme" definiert. Es klappt trotzdem nicht. Stelle ich die Firewall ganz aus, klappt es. Es muss also etwas mit der Firewall zu tun haben...
Edit: Nun sagt er mir beim Anmelden, der RPC-Server sei nicht verfügbar. Ohne Firewall klappt es aber weiterhin.
Edit2: mit dem Befehl netsh firewall set service REMOTEADMIN enable in der Eingabeaufforderung hat es nun geklappt. Leider dauert das Anmelden mit Firewall nun ca. 10 Minuten?! Das Abmelden dauert ebenfalls ewig.
Gruß
