RWW en SSL

[Scheveningertje]

Geachte lezers,

Ik heb hier een SBS 2008 server draaien met IIS 7.
Ik heb de wens dat de mensen hier overal vandaan in willen loggen op Remote Web Workplace.
Dat is iets wat ik werkend heb, alleen ze willen daarbij ook gebruik maken van Terminal Services om hun computer over te kunnen nemen.... En daar begint het probleem...

De mensen willen dus overal ter wereld in kunnen loggen en op die manier hun pc overnemen.
Ik probeer dus onder een certificaat vraag of wat dan ook uit te komen maar dat is mij dus nog niet gelukt.
Daarbij gaat dit natuurlijk ook zwaar ten koste van de veiligheid.

Ik ben dus eigenlijk op zoek naar een manier dat mensen overalvandaan in kunnen loggen op RWW en ook gebruik kunnen maken van TS.

Hebben jullie ideeen of tips?

 

[dnties]

Plenty tips:
a. Als er meerdere computers zijn die via RDP/Extern Bureaublad overgenomen moeten worden, dan zul je in je Internet-router poorten moeten gaan portforwarden. Als die router ook poorttranslatie toestaat kun je het zo doen (voorbeeld):
poort 3389 TCP -> Poort 3389 TCP op LAN ip-adres van de server
Poort 3390 TCP -> Poort 3389 TCP op LAN ip-adres van werkstation1
Poort 3391 TCP -> Poort 3389 TCP op LAN ip-adres van werkstation2
etc.

Kan de router geen poorttranslatie aan, dat moeten de werkstations worden veranderd, zodat ze luisteren op een andere poort. De portforwarding wordt dan:
poort 3389 TCP -> Poort 3389 TCP op LAN ip-adres van de server
Poort 3390 TCP -> Poort 3390 TCP op LAN ip-adres van werkstation1
Poort 3391 TCP -> Poort 3391 TCP op LAN ip-adres van werkstation2
Hoe aanpassen/toevoegen van poorten voor TS toegang staat hier

De clients moeten bij de verbinding ook het te gebruiken poortnummer opgeven, dus stel dat je router op het Internet bekend staat als mail.mijndomein.com en ik wil via RDP verbinden met werkstation1, dan wordt de host om mee te verbinden: mail.mijndomein.com:3390

Je kunt in de RDP-client aangeven dat altijd verbinding moet worden gemaakt, onafhankelijk of er nu wel of niet een certificaat etc. ter authenticatie van de 'andere partij' moet worden getoond. Is een optie in de client, onder Geavanceerd (zie bijlage, blauw gemaakt pull-down menu).

Succes,

Tijs.

 

[Scheveningertje]

mm, dat is inderdaad waar ik zelf ook al over na heb zitten denken.....

Maar als ik op die manier ga handelen kom ik op een volgend probleem uit en dat is dat TS niet wordt toegestaan van buitenaf naar de werkstations.

Dit zal vast en zeker ergens een policy zijn maar ik heb hem nog niet kunnen ontdekken.

Mijn router ondersteund inderdaad port translation dus dat is het probleem niet.
Als ik hem intern dus naar een werkstation verwijs gebeurt er niets, althans ik krijg een melding dat de externe computer niet reageert.

Verwijs ik het interne ip adres naar de server, dan gaat het als een trein.... kun je me daar iets over vertellen hoe dat komt?

 

[dnties]

Je zult eerst Extern verbinden op de werkstations moeten toestaan. Daar is een computerpolicy voor, maar het kan ook via de Eigenschappen van de computer en dan Extern Bureaublad aanvinken in tabblad "Verbindingen van buitenaf" (hoe het tabblad heet is afhankelijk van de Windows-versie op de werkstations).

Dan is nog van belang wíe via Extern Bureaublad mogen verbinden met de werkstations. Als de gebruikers lokale Administratorrechten hebben, dan mag het in ieder geval. Is dat niet het geval, dan moeten ze worden toegevoegd aan de lokale groep "Remote desktop users" (of hoe die groep ook maar heet, afhankelijk van taalversie van Windows op die werkstations etc.) Staat in hetzelfde tabblad als in de eerste paragraaf: knop "Externe gebruikers selecteren". Ook dit is via een computerpolicy te regelen, desgewenst.

Verder kunnen firewall-instellingen op het werkstation ook nog roet in het eten gooien, als het niet voldoende blijkt om Externe toegang aan te zetten zoals aangegeven in de eerste paragraaf.

[Natuurlijk is (uit veiligheidsoverwegingen) een stevig wachtwoord verplicht voor iedereen die het recht heeft om via Extern Bureaublad te verbinden. Gebruikers zónder wachtwoord kunnen zowiezo niet inloggen.]

Tijs.

 

[Scheveningertje]

Mmm, wat vreemd is dat ik niet terug kan vinden wat ik jou hierboven zie typen.....
Is dat ook een policy die dat disabled? dit zou dan trouwens standaard moeten zijn want ik heb niets gewijzigd in die policy's......

ik kan wel gebruikers selecteren, maar het heeft totaal geen effect.... ik krijg totaal geen contact met het desbetreffende werkstation....

 

[dnties]

a. Het lijkt erop dat via een policy het al geregeld was m.b.t. inschakelen Extern Bureaublad
b. Vlgs. mij heb je geen seconde tijd besteed aan de volgende tip/informatie die ik je had gegeven:

Verder kunnen firewall-instellingen op het werkstation ook nog roet in het eten gooien, als het niet voldoende blijkt om Externe toegang aan te zetten zoals aangegeven in de eerste paragraaf.

Ik zie het icoontje van McAfee, en die heeft........ een firewall-component

Succes,

Tijs.

 

[Scheveningertje]

mm, mc affee is echt niet aanwezig op dit systeem.... NOD32 is de scanner op dit systeem, zonder firewall functie.....

windows firewall ingesteld maar 3389 wordt toegelaten.... meerdere poorten lijken mij niet nodig ?

Het is gewoon een apart verhaal dat als ik een port doorzet naar een werkstation dat de server zich daarmee bemoeit maar goed.... ik weet niet of je nog een idee hebt?

Firewall kan het gewoon niet zijn OF er moet meer dan die 3389 opengezet worden....

Bedankt iig voor je info tot dusver!

 

[dnties]

Toch staat McAfee erop (zie snelkoppeling op bureaublad)... Ik zou dus toch eens gaan kijken hoe die ingesteld staat. Als je 'm niet gebruikt, dan zou je kunnen overwegen het te deïnstalleren.
Dat NOD32 niet de boosdoener is neem ik direct van je aan.

In de Windows Firewall poort 3389 zou genoeg moeten zijn wat díe firewall betreft, maar dan blijft nog steeds McAfee...

Succes,

Tijs.

 

[Scheveningertje]

Tijs,

Mmm, Ook norton stond geinstalleerd.... vrij apart, heb ik niet gedaan... zoeken we ook nog uit ....

In ieder geval, MC Affee weg en Norton.... geen verbetering..... hij staat het gewoonweg NIET toe om RDP op te bouwen naar een client die lid is van het domein op mijn SBS2008........

Heb jij nog enige kennis hoe dit euvel te verhelpen is ?

 

[dnties]

Kijk eerst na of de Terminal Services service wel gestart staat op het werkstation. Start -> Uitvoeren -> services.msc
Daarna kun je kijken of er wel op poort 3389 TCP geluisterd wordt momenteel: Start -> Uitvoeren ->
cmd /k netstat -ano | find /i ":3389"

Verdere directe tips heb ik zo niet. Verder helpen zal neerkomen op een verbinding met het werkstation (bijv. via Teamviewer of Crossloop).
Ik moet daar dan wel geld voor vragen. Stel dat je dat op prijs stelt, klik dan op mijn schuilnaam (links van dit bericht) en kies voor "Verstuur e-mail".

Succes,

Tijs.

 

[Scheveningertje]

mm, oke bedankt voor het aanbod....

hoewel ik denk dat we het probleem op het werkstation niet gaan vinden.

Als ik VPN opbouw, en ik ga op intern ip naar de desbetreffende werkstation functioneert het WEL......

Moet dan wel in een policy zitten of wat dan ook.......

 

[dnties]

Van waaruit probeer je nu een RDP-verbinding op te bouwen dat het niet werkt? Welk ip-adres hoort bij die pc/server van waaruit je dat probeert?
En naar welk werkstation probeer je die RDP-verbinding op te bouwen? Welk ip-adres hoort daarbij?
Gebruik je IPSEC op je netwerk?

Tijs.

 

[Scheveningertje]

Ik zit nu op een andere locatie, ik werk constant op afstand om deze issue op te lossen.

IP werkstation = 192.168.44.14
IP server = 192.168.44.250

in de router staat 3389 door naar .14

ik tik dus extern binnen mstsc.exe het publieke ip adres in.......

Ik maak gewoon gebruik van de normale vpn mogelijkheden, dus gewoon ingeschakeld en er wordt ingelogd met de windows inloggegevens....

Zijn zo je vragen beantwoord?

 

[dnties]

Ok, even samenvattend:
a. VPN-server, router, server en werkstations bevinden zich (qua LAN-verbinding) allen in het 192.168.44.x netwerk
b. Als je een VPN verbinding opbouwt, en je vult 192.168.44.14 in in de RCP-client, dan werkt het.
c. Als je géén VPN hebt, en je vult het publieke ip-adres in van de Internet-router op het werk in in de RDP-client, dan werkt het niet, ondanks dat poort 3389 TCP is geportforward naar poort 3389 TCP op het werkstation.

Als dit allemaal klopt, dan lijken mij nog 3 dingen over te blijven als oorzaak:
a. Firewall instellingen in de router, dus afwezigheid van een WAN-to-LAN firewall regel die het gewenste RDP verkeer toestaat of (onwaarschijnlijk) packet-filtering op de router.
Dit geldt ook de andere kant op: Als LAN-to-WAN niet alles is toegestaan, dan de andere kant op (dus afwezigheid van een LAN-to-WAN regel (of packet-filtering) die het gewenste RDP verkeer toestaat).
b. Standaardgateway op het werkstation is niet het LAN ip-adres van de router
c. Firewall-regels op het werkstation. Is dat een XP werkstation, dan is alleen een simpele firewall aanwezig, dus in het geval van XP mag deze reden niet van toepassing zijn.

Meer kan ik van hieruit niet bedenken. Hopelijk helpt het wat verder.

Tijs.