Remote Desktop Gateway Netwerk Design

zaterdag 29 maart 2014 16:11

Topicstarter

jvanhambelgium schreef op zaterdag 29 maart 2014 @ 10:54:
Bestudeer onderstaande poster eens

http://download.microsoft...omponent-Architecture.pdf

Voor zover ik zie is er voor de opzet van een gateway geen "AD" communicatie rechtstreeks tussen gateway & backend.

Bedant voor de link naar de PDF. De PDF is zeer nuttig

Echter, AD authenticatie is absoluut nodig op een RD Gateway. Ik heb een en ander opgezet in een testomgeving, dus ik weet waarover ik spreek. Als een remote cliënt verbinding opzet met een PC in het LAN wordt deze gevraagd op de RD Gateway naar AD logingegevens.

FF ter verduidelijking. Er wordt gewerkt met RDCAP en RDRAP op de RD Gateway. Remote desktop client authorization policys en Remote Desktop resource authentication policy's. Met de RDCAP kan je bepalen welke AD gebruikers de RD Gateway mogen benaderen. Je steekt dus gebruikers on groepen en deze groepen voeg je toe in een of meerdere RDCAP's.
Als een gebruiker de RD Gateway benadert, en zijn useraccount is toegevoegd in de RDCAP, kan deze verder naar PC's in het LAN. Vervolgens kan je aan de hand van RDRAP's bepalen welke gebruikers welke computers in het LAN mogen benaderen. Je maakt hiervoor groepen aan met computeraccounts, en bepaalt zo welke gebruiker geauthoriseerd is welke computer te benaderen.

Acties:

zaterdag 29 maart 2014 16:34

Topicstarter

sh4d0wman schreef op zaterdag 29 maart 2014 @ 15:34:
Niet direct een implementatie advies maar wel iets om even uit te zoeken:

Hebben jullie een CISO of ander Security gerelateerde persoon? Zo ja, probeer eens na te gaan of jullie een bepaalde security standaard geimplementeerd hebben b.v. ISO 27001.
DCS/PLC systemen zijn meestal niet bedoeld om een koppeling naar internet te hebben, hoe veilig ook.

Probeer er in ieder geval voor te zorgen dat je multifactor authenticatie kunt implementeren (b.v. RSA tokens) en zorg voor monitoring van netwerkverkeer zodat je verdachte zaken kunt signaleren.

DCS/PLC systemen zijn idd niet direkt bedoelt om een koppeling te hebben met het internet. Het is echter wel de vraag van het management. Dus wie ben ik dan om daar moeilijk over te gaan doen?

Het is idd de bedoeling van het management uit om 2 levels van authenticatie te bekomen. Daarom stel ik me de vraag waar ik de RD Gateway moet plaatsen in het netwerkdesign.

Opzet 2 zoals besproken in het TOPIC beantwoord hieraan. Eerst VPN authenticatie, daarna AD authenticatie op RD Gateway in LAN.

Weet iemand een manier om een tweede authenticatie te bekomen bij opzet 1. Waar de RD Gateway in DMZ staat? En waar geen VPN nodig zou zijn?

Alvast bedankt.

[ Voor 21% gewijzigd door Funzy83 op 29-03-2014 16:25 ]

Acties:

bigfoot1942

Funzy83 schreef op zaterdag 29 maart 2014 @ 05:02:
Opzet 1:Remote Desktop Gateway in DMZ
Deze opzet lijkt mij het simpelst qua implementatie. Ik stel me echter wel vragen bij de security. Aangezien er voor de werknemers die remote verbinden AD authenticatie moet gebeuren, moet deze RD Gateway lid zijn van het domein. Hiervoor moeten veel poorten worden opengezet in de firewall die het DMZ en het LAN met elkaar verbind.

Opzet 2:Remote Desktop Gateway in LAN en werknemer laten inbellen via VPN in DMZ
Dit is ook een mogelijkheid. Qua security lijkt me dit iets veiliger omdat er nu 2 vormen van authenticatie zijn. eerst authenticatie met VPN, daarna authenticatie AD op RD Gateway.

Opzet 3:Remote Desktop Gateway in LAN met Forefront TMG in DMZ.
Voor welk opzet zouden jullie gaan, en waarom?

Optie 3 voegt volgens mij weinig toe (anders dan complexiteit), het RDP verkeer is HTTPS encrypted ook zonder TMG.
Optie 2 is bruikbaar ook zonder RDG (als een gebruiker een secure VPN opzet, geen PPTP dus, is dit al veilig). 2 dingen over elkaar heen is dan weer toegevoegde complexiteit en weinig meerwaarde (anders dan security through obscurity).
Optie 1 is zoals MS het ook voor zich ziet. Valide optie. Wellicht is het handig ivm de domeintoegang te zorgen dat hij in een geïsoleerd stuk van de DMZ zit (dus niet naast een stelletje webservers in dezelfde DMZ).

[ Voor 22% gewijzigd door bigfoot1942 op 29-03-2014 16:34 ]

zaterdag 29 maart 2014 16:55

Acties:

zaterdag 29 maart 2014 17:04

Topicstarter

bigfoot1942 schreef op zaterdag 29 maart 2014 @ 16:34:
[...]

Optie 3 voegt volgens mij weinig toe (anders dan complexiteit), het RDP verkeer is HTTPS encrypted ook zonder TMG.
Optie 2 is bruikbaar ook zonder RDG (als een gebruiker een secure VPN opzet, geen PPTP dus, is dit al veilig). 2 dingen over elkaar heen is dan weer toegevoegde complexiteit en weinig meerwaarde (anders dan security through obscurity).
Optie 1 is zoals MS het ook voor zich ziet. Valide optie. Wellicht is het handig ivm de domeintoegang te zorgen dat hij in een geïsoleerd stuk van de DMZ zit (dus niet naast een stelletje webservers in dezelfde DMZ).

Dat klopt, optie 1 lijkt me ook ideaal, echter wil het management dubbel authenticatie. Ieman suggesties om bij opzet 1 dubbele authenticatie te bekomen?

Acties:

sh4d0wman

Attack | Exploit | Pwn

Multifactor is niet twee levels van authenticatie. Het vereist iets anders dan alleen een gebruikersnaam/wachtwoord of PIN.

Hoe verloopt je huidige VPN process? Gebruiker start client software met username/password en een certificaat? Zo ja, alles hiervan kan door malware onderschept worden.

Wat je zou kunnen doen is een token van RSA of een andere leverancier nemen. Dit werkt als volgt:
- Je koopt een x aantal tokens.
- Elke medewerker welke remote moet werken krijgt een token
- Software van RSA draait op een Windows server en praat met de VPN/Firewall/AD/whatever
- Gebruiker logt in met username en password + de code gegenereerd door het token

Voordeel is dat je gelijk ook een goede audittrail hebt van wanneer iemand is ingelogd, etc. Nadeel: het kost wel wat geld ...

This signature has been taken down by the Dutch police in the course of an international lawenforcement operation.

zaterdag 29 maart 2014 17:10

Acties:

zaterdag 29 maart 2014 18:22

Topicstarter

sh4d0wman schreef op zaterdag 29 maart 2014 @ 17:04:
Multifactor is niet twee levels van authenticatie. Het vereist iets anders dan alleen een gebruikersnaam/wachtwoord of PIN.

Hoe verloopt je huidige VPN process? Gebruiker start client software met username/password en een certificaat? Zo ja, alles hiervan kan door malware onderschept worden.

Wat je zou kunnen doen is een token van RSA of een andere leverancier nemen. Dit werkt als volgt:
- Je koopt een x aantal tokens.
- Elke medewerker welke remote moet werken krijgt een token
- Software van RSA draait op een Windows server en praat met de VPN/Firewall/AD/whatever
- Gebruiker logt in met username en password + de code gegenereerd door het token

Voordeel is dat je gelijk ook een goede audittrail hebt van wanneer iemand is ingelogd, etc. Nadeel: het kost wel wat geld ...

Bedankt voor de reactie. Ik heb de RSA optie bekeken. Is idd een goede optie. Echter een nadeel hierbij:

Heel zelden gebeurt het dat mensen die de productiemachines gebouwd hebben, toegang moeten krijgen tot deze machines, als niemand op het bedrijf de storing opgelost krijgt. Third party users dus.

Medewerkers van het bedrijf zelf voorzien van een RSA token is zo gebeurd. Third party users voorzien van een RSA token is iets moeilijker lijkt me

Een oplssing zou hier zijn deze gebruikers enkel via AD te laten auhenticeren, maar ze een account te geven die vervalt na x aantal tijd. Is zoiets te configureren naast elkaar? Werknemers van het bedrijf 2 phased authentication (AD en RSA). En third party users one phased authentication --> tijdelijke AD account?

[ Voor 10% gewijzigd door Funzy83 op 29-03-2014 17:21 ]

Acties:

zondag 30 maart 2014 00:10

Topicstarter

sh4d0wman schreef op zaterdag 29 maart 2014 @ 17:04:
Multifactor is niet twee levels van authenticatie. Het vereist iets anders dan alleen een gebruikersnaam/wachtwoord of PIN.

Hoe verloopt je huidige VPN process? Gebruiker start client software met username/password en een certificaat? Zo ja, alles hiervan kan door malware onderschept worden.

Wat je zou kunnen doen is een token van RSA of een andere leverancier nemen. Dit werkt als volgt:
- Je koopt een x aantal tokens.
- Elke medewerker welke remote moet werken krijgt een token
- Software van RSA draait op een Windows server en praat met de VPN/Firewall/AD/whatever
- Gebruiker logt in met username en password + de code gegenereerd door het token

Voordeel is dat je gelijk ook een goede audittrail hebt van wanneer iemand is ingelogd, etc. Nadeel: het kost wel wat geld ...

In het geval van RSA implementatie. Hoe verloopt de volledige workflow dan? Rekening houdend met het gebruik van de Remote Desktop Gateway. Waar en wanneer moet het verkegen wachtwoord ingegeven worden?

Moet het wachtwoord ingegeven worden via een webinterface? Kortom de samenwerking tussen de 2 authenticatiemethodes is me niet volledig duidelijk.

Acties:

pablo_p

Bij de third party users, vind ik het logisch om ze een tijdelijk account te maken waarmee ze een keer kunnen inloggen,, met een wachtwoord dat je via SMS verstuurt Dat vind ik sterker dan bv 4 uur lang hetzelfde account met een eerder gebruikt wachtwoord open te zetten.. En je kan bij de speciale procdure daarvoor ook bv een eis van een bekend IP adres opnemen. Dan is het zeker vergelijkbaar met 2 factor dmv user/ww + RSA token.

Bij het gedrijg waar ik tot voor kort voor werkte, hadden ze wel RSA tokens voor 3rd party. Er was een procedure om te aan te vragen en dan werden ze verstuurd. Ware volgens mij 250+ RSA tokens daarvoor.

zondag 30 maart 2014 08:02

Acties:

Linke Loe

Wij maken zelf gebruik van een read-only domain controllers in de DMZ. Zo hoef je maar voor 1 server de benodigde poorten open te zetten naar een domain controller, terwijl je wel geathenticeerd kan worden op servers die in je DMZ draaien.

http://technet.microsoft....rary/dd728034(WS.10).aspx

zondag 30 maart 2014 09:47

Acties:

zondag 30 maart 2014 10:55

Crew Council

#whisky #barista

* Equator gooit even een knuppel in het hoenderhok.

Optie 3 zou wat mij betreft juist de mooie oplossing zijn. Het feit dat een reverse proxy in het DMZ het verkeer kan inspecteren voordat het wordt doorgezet naar je RD Gateway zou ik persoonlijk de beste oplossing vinden.

Maar goed, ik hanteer dan ook altijd het principe dat er geen verbinding van buitenaf, rechtstreeks naar het interne LAN wordt doorgezet. Er dient altijd een punt van onderbreking te zijn.

TMG is echter ook bijna end of life. Ik zou daar op zoek gaan naar iets vergelijkbaars.

Voor wat betreft het aanmelden zou ik ook iets doen met One Time Passwords als RSA/SafeSign/SMSPAsscode/... als tweede authenticatie factor.
Voor de third party users kan je een aparte RSA token aan iemand toekennen (of op kantoor in de kluis leggen) en telefonisch de code doorgeven. Zo heb je ook nog eens in beeld wanneer die 3e partij inlogt op je systeem.

Acties:

Zoetjuh

Funzy83 schreef op zaterdag 29 maart 2014 @ 18:22:
[...]

In het geval van RSA implementatie. Hoe verloopt de volledige workflow dan? Rekening houdend met het gebruik van de Remote Desktop Gateway. Waar en wanneer moet het verkegen wachtwoord ingegeven worden?

Moet het wachtwoord ingegeven worden via een webinterface? Kortom de samenwerking tussen de 2 authenticatiemethodes is me niet volledig duidelijk.

Even een aanvulling. De huidige versie van de RSA "Beheer" Softwae (Authentication Manager), versie 8.1 is overigens een fysieke of virtual appliance (die alleen draait op ESX). Binnen 2 maanden zou wel de 8.2 versie uit moeten komen, waardoor er ook voor Hyper-V een virtual appliance is.

Verder, stel je zou RD Gateway gebruiken; deze kan NIET overweg met RSA tokens. Je zult in dat geval de RSA "client" software op de RDP/Terminal Server moeten zetten. Beetje verwarrend is dat men dan via de RD Gateway de Windows credentials moet gebruiken en op de server zelf alsnog de RSA token dingen.

Pin me hier niet aan vast (ik heb onderstaand nooit geïmplementeerd, maar destijds wel een beetje over ingelezen), maar ik meen dat TMG dit wel netjes kan/doet. Het stuk user+token zou dan door TMG worden afgehandeld, waarna je middels SSO door zou moeten kunnen naar de RDP/Terminal Server.

[ Voor 12% gewijzigd door Zoetjuh op 30-03-2014 11:02 ]

zondag 30 maart 2014 19:25

Acties:

zondag 30 maart 2014 21:01

Equator schreef op zondag 30 maart 2014 @ 09:47:
* Equator gooit even een knuppel in het hoenderhok.
TMG is echter ook bijna end of life. Ik zou daar op zoek gaan naar iets vergelijkbaars.

ARR http://www.iis.net/downlo...plication-request-routing

Newton's 3rd law of motion. Amateur moraalridder.

Acties:

HP ftw \o/

What about een remote access gateway:in de vorm van een UTM of en remote acces gateway. Deze zijn vssk te combineren met een two factor authenticator met een hardware of software (sms) token.

TMG is inderdaad al sinds eind 2912 niet meer verkrijgbaar via de meeste kanalen en lijkt mij een slechte keus. Ook UAG is eol.

zondag 30 maart 2014 22:48

Acties:

zondag 30 maart 2014 23:03

RDG in DMZ achter een ARR/TMG (reverse proxy) in (evt andere) DMZ is prima te doen. Zoiets komt zelfs PCI compliance door.
Het word interessanter hoe je je RAP inricht. Connectivity vanuit je DMZ naar een (RO)DC is prima te doen.

Newton's 3rd law of motion. Amateur moraalridder.

Acties:

maandag 31 maart 2014 20:01

Topicstarter

Razwer schreef op zondag 30 maart 2014 @ 22:48:
RDG in DMZ achter een ARR/TMG (reverse proxy) in (evt andere) DMZ is prima te doen. Zoiets komt zelfs PCI compliance door.
Het word interessanter hoe je je RAP inricht. Connectivity vanuit je DMZ naar een (RO)DC is prima te doen.

Het bedrijf in kwestie bestaat uit meerdere vestigingen. Er staat in het LAN van het bedrijf zelfs geen RODC, laat staan een DC. Alle AD calls gebeuren over een geconfigureerde site to site VPN oplossing, naar het hoofdbedrif, waar de DC's staan. Is dat een nadeel voor de plaatsing van de RD Gateway in het DMZ?

Mij lijkt het een groot voordeel, aangezien alle verkeer toch over de VPN tunnel gaat. Moet ik verder met weinig rekening houden, betreffende het openen van poorten an dergelijke.

Of zie ik hier vanalles over het hoofd?

[ Voor 14% gewijzigd door Funzy83 op 30-03-2014 23:09 ]

Acties:

dinsdag 1 april 2014 05:44

voordeel? uberhaupt een DC niet on-site hebben is een nadeel. Je DMZ wil je in principe niet in je proxy address lijst hebben voor je tunnel zodat dat verkeer juist niet je tunnel over gaat, maargoed...

overigens kwam ik er vandaag achter dat RDGateway en ARR niet samengaat

Newton's 3rd law of motion. Amateur moraalridder.

Acties:

dinsdag 1 april 2014 09:43

Topicstarter

Razwer schreef op maandag 31 maart 2014 @ 20:01:
voordeel? uberhaupt een DC niet on-site hebben is een nadeel. Je DMZ wil je in principe niet in je proxy address lijst hebben voor je tunnel zodat dat verkeer juist niet je tunnel over gaat, maargoed...

overigens kwam ik er vandaag achter dat RDGateway en ARR niet samengaat

Ik spreek toch nergens uit dat ik het een voordeel vind dat er geen DC on site is. Tuurlijk is dat een nadeel op verschillende vlakken. Ik spreek over een voordeel dat ik geen poorten moet openen tussen DMZ en LAN, omdat alle AD calls naar de andere site gaan, dus over de VPN tunnel.

Acties:

HP ftw \o/

Als je er uit bent welk scenario het gaat worden, kan ik je wel helpen met je licentievraag in je andere (gesloten) topic.

woensdag 2 april 2014 07:53

Acties:

woensdag 2 april 2014 09:02

Topicstarter

PcDealer schreef op dinsdag 01 april 2014 @ 09:43:
Als je er uit bent welk scenario het gaat worden, kan ik je wel helpen met je licentievraag in je andere (gesloten) topic.

Dat is altijd leuk natuurlijk

. Ik ben er min of meer uit ja welk scenario het zal worden. De implementatie zal voor volgende week ergens zijn. Ik heb me niet meer bezig gehouden met opzoekingswerk betreffende de licentieaanvraag. Ik was van plan dat in het weekend eens te bekijken.

Ik stelde me in eerste instantie de vraag of ik wel CAL's nodig heb voor mijn situatie. Het verbinden van remote cliënts, over een RD Gateway in DMZ, naar Windows 7 PC's in het LAN. Aangezien remote desktop services ingebakken zit in het Windows server OS. En aangezien ik geen gebruik maak van RD Session host servers.

In het geval dat CAL's wel nodig zijn, moet aan volgende zaken gedacht worden.

1. Remote desktop licensing role.
2. Nodige CAL's.
3. Configuratie van deze CAL's

Bedenkingen:

Call's aankopen per user, of per device? Het zou gaan om ongeveer 20 users die gebruik gaan maken van RDP. Het zijn 4 computers in het LAN die via RDP overgenomen zullen worden.

Plaats van de server role Remote desktop licensing. Plaatsen op en nieuwe server? Ofwel plaatsen op een andere windows server in het LAN? Ofwel bij op de RD Gateway in DMZ.

Zie k verder nog iets over het hoofd.

Alvast bedankt.

Acties:

HP ftw \o/

Mij te ingewikkeld. Even dat ik het goed begrijp:
- 20 gebruikers (hoe connecten zij?)
- 4 devices (volwaardige pc's) die overgenomen worden via rdp

Remote Desktop Services is een kwestie van de service activeren op de server, als de server reeds gelicenceerd is, zijn daar inderdaad geen aparte licenties voor nodig. Echter, voor de devices en/of users is er wel een RDS CAL benodigd. Sinds september 2012 zijn de prijzen voor de Users een stuk (20%) hoger dan voor de Devices. Dit omdat Microsoft op het standpunt staat dat gebruikers over steeds meer devices beschikken en daar is wel wat voor te zeggen.

Ik ben voorstander van het zoveel mogelijk uit elkaar trekken van rollen op een losse server. Zeker in een virtuele omgeving op basis van Windows Server Datacenter.

Kun je zeggen wat voor Microsoft contract er is? Open (Value (Subscription)), Enterprise (Subscription) Agreement? Wat voor omgeving is het?

[ Voor 11% gewijzigd door PcDealer op 02-04-2014 09:03 ]

woensdag 2 april 2014 13:35

Acties:

woensdag 2 april 2014 18:50

Crew Council

#whisky #barista

Als je niet gaat verbinden aan een Server met de Remote Desktop Role (Session Hosts) maar Windows 7 systemen eb je dus geen RDS licenties nodig. Heel officieel heb je per device wel de VDA licentie nodig omdat je een VDI benaderd.

Als het device een OS met active Software Assurance (SA) heeft, dan is de VDA licentie included.

Zie ook: http://searchvirtualdeskt...DA-Virtual-Desktop-Access

Acties:

woensdag 2 april 2014 18:53

Funzy83 schreef op dinsdag 01 april 2014 @ 05:44:
[...]

Ik spreek toch nergens uit dat ik het een voordeel vind dat er geen DC on site is. Tuurlijk is dat een nadeel op verschillende vlakken. Ik spreek over een voordeel dat ik geen poorten moet openen tussen DMZ en LAN, omdat alle AD calls naar de andere site gaan, dus over de VPN tunnel.

Dan las ik dat verkeerd. Maar mij ontgaat nog steeds elk voordeel gezien je hoe dan ook gaatjes moet boren in je firewall. Zo niet is je DMZ geen DMZ...
Of bedoel je dat je een global rule hebt voor spul over de tunnel en is je tunnel apparaat ook je centrale firewall?

[ Voor 9% gewijzigd door Razwer op 02-04-2014 18:53 ]

Newton's 3rd law of motion. Amateur moraalridder.

Acties:

HP ftw \o/

Goeie. Het nieuwste document is http://download.microsoft...%20VDA%20FAQ%20v3%200.pdf
Te vinden via: http://www.microsoft.com/...ating-system/default.aspx

Ook interessant: Plan for and deploy Virtual Desktop Infrastructure

Volume licensing brief: Licensing Windows desktop operating system for use with virtual machines

Licensing Microsoft’s Virtual Desktop Infrastructure Technology

Windows Licensing for VDI Quick Ref.

woensdag 2 april 2014 20:12

Acties:

Paul

Waarom zouden die Windows 7 machines VDI's zijn?

De details ontbreken maar uit de eerste alinea's maak ik op dat het fysieke machines zijn waar ze over het algemeen lokaal op aan het werken zijn; RDP wordt alleen gebruikt bij storingen...

"Your life is yours alone. Rise up and live it." - Richard Rahl
Rhàshan - Aditu Sunlock

woensdag 2 april 2014 20:54

Acties:

woensdag 2 april 2014 21:38

Crew Council

#whisky #barista

Of het systeem wat het cliënt OS draait nu fysiek is of virtueel maakt niet uit. Je verbindt met een remote desktop protocol aan een cliënt OS, dus is het voor Microsoft een VDI oplossing die dus volgens Microsofts ideeën gelicenseerd moet worden.

Acties:

Paul

Waar ligt die grens? Één keer met RDP naar een werkstation verbinden == voor de rest van zijn leven een 'VDI'? Dan is dus 50% van alle werkstations bij bedrijven die SBS gebruiken niet compliant, 80% van iedereen die privé een Pro-licentie heeft gekocht, 95% van alle werkstations van systeembeheerders....

Ik haal uit VDI / VDA FAQ niet dat bare metal Windows-installaties ook onder VDI valt, er staat _iedere_ keer 'virtual' of 'in the datacenter'. Desondanks vind ik het een hele smerige licentiemethode... Het is alleen per device, en ieder _access_ device moet een licentie hebben

Als ik dus vanuit huis inlog vanaf mijn laptop ben ik al $ 100 per jaar kwijt. Dan heb ik nog een PC waarmee ik af en toe thuiswerk, nog eens $ 100. Dan zijn we wel eens onderweg en hebben we alleen de laptop van mijn vrouw bij me, hoppa, nog een keer $ 100. Vervolgens ben ik in mijn eentje onderweg en word ik 's avonds gebeld over een probleem, geen probleem, ook op een tablet kun je remote desktoppen. Oeps, dat is de 4e keer dat ik $ 100 af mag tikken.

Vervolgens ben ik 1 van de 2500 medewerkers van mijn organisatie. Laat men gemiddeld maar vanaf 2 werkplekken thuiswerken, hoppa, MS is behalve dat we ons al scheel betalen aan CALs, Datacenter-licenties en 2500 werkplekken ook nog eens een half miljoen per jaar rijker.

Weet je zeker dat het geen 1 april is?

"Your life is yours alone. Rise up and live it." - Richard Rahl
Rhàshan - Aditu Sunlock

woensdag 2 april 2014 22:19

Acties:

donderdag 3 april 2014 08:38

Crew Council

#whisky #barista

Hmm nu ga ik ook twijfelen. In het door mij aangehaalde artikel benoemen ze zeer specifiek virtuele systemen. En ze geven zelfs aan dat het een vervanging is van het licentieren van het guest OS.

Ik moet het toch nog eens goed controleren.

In mijn idee was het nodig om remote te werken op een cliënt OS vanaf een device wat geen actieve SA heeft.

Acties:

HP ftw \o/

Algemeen:

Een RDS connectie op zich is geen VDI. Connecteren naar een virtuele machine wel. Zonder een Windows licenties is vda benodigd. Een RDS CAL (User of Device) is echter altijd benodigd indien gebruik wordt gemaakt van Terminal Server, Citrix of View.

Als de specifieke aantallen en wijze van connectie bekend zijn, duik ik er in voor je.

[ Voor 20% gewijzigd door PcDealer op 03-04-2014 08:39 ]

donderdag 3 april 2014 13:03

Acties:

Linke Loe

Als de specifieke aantallen en wijze van connectie bekend zijn, duik ik er in voor je.

Waarom bekruipt mij het gevoel toch dat je hier een commercieel slaatje uit wil slaan?

[ Voor 7% gewijzigd door Linke Loe op 03-04-2014 13:03 ]

donderdag 3 april 2014 14:21

Acties:

donderdag 3 april 2014 17:04

Crew Council

#whisky #barista

Hoezo

Misschien is PcDealer wel erg goed in licenties uitrekenen. Hij hoeft het toch niet meteen ook zo te willen verkopen?

Acties:

donderdag 3 april 2014 17:07

Topicstarter

Razwer schreef op woensdag 02 april 2014 @ 18:50:
[...]

Dan las ik dat verkeerd. Maar mij ontgaat nog steeds elk voordeel gezien je hoe dan ook gaatjes moet boren in je firewall. Zo niet is je DMZ geen DMZ...
Of bedoel je dat je een global rule hebt voor spul over de tunnel en is je tunnel apparaat ook je centrale firewall?

Het tunnel apparaat is een front end firewall, (de eerste firewall van het bedrijf, aan de kant van internet) die de tunnel opzet met de andere site.

Acties:

donderdag 3 april 2014 17:17

Topicstarter

Paul schreef op woensdag 02 april 2014 @ 20:12:
Waarom zouden die Windows 7 machines VDI's zijn?

De details ontbreken maar uit de eerste alinea's maak ik op dat het fysieke machines zijn waar ze over het algemeen lokaal op aan het werken zijn; RDP wordt alleen gebruikt bij storingen...

Idd het is geen VDI. Het zijn lokale (fysieke) Win 7 computers waarmee (bij storingen) de RDP connectie vanuit internet moet kunnen opgezet worden.

Acties:

donderdag 3 april 2014 17:25

Topicstarter

Beste vrienden, bedankt voor de nuttige info allemaal betreffende de licentieaanvraag. Ik heb contact opgenomen met de microsoft licensing servicedesk. Vervolgens men vraag gesteld aan een vriendelijke engels sprekende aziaat, en deze beste man bevestigde dat er geen licenties nodig zin voor het geen ik ik wil opzetten.

Er komen pas licenties bij in mijn opzet als ik gebruik maak van RD session host, die via RDP overgenomen worden en wanneer er Windows software beschikbaar gesteld wordt aan de remote cliënts, bv Office. Aangezien in mijn situatie de remote cliënts enkel de WIN 7 computer overnemen om van daaruit bedrijfssoftware (PLC/DCS) te manipuleren zijn er geen RD CAL's nodig.

Acties:

HP ftw \o/

Linke Loe schreef op donderdag 03 april 2014 @ 13:03:
[...]

Waarom bekruipt mij het gevoel toch dat je hier een commercieel slaatje uit wil slaan?

Lijkt me sterk: ik geniet een ww op dit moment. Ik ben echter wel MCTS gecertificeerd (70-671 en 70-672).

Ik weet waar de juiste informatie staat. Gezien het aantal licenties waar het mogelijk om gaat, zou het mijn werkgever (als ik in loondienst zou zijn) meer kosten dan opleveren als ik het op de klok zou doen

Funzy83 schreef op donderdag 03 april 2014 @ 17:17:
Beste vrienden, bedankt voor de nuttige info allemaal betreffende de licentieaanvraag. Ik heb contact opgenomen met de microsoft licensing servicedesk. Vervolgens men vraag gesteld aan een vriendelijke engels sprekende aziaat, en deze beste man bevestigde dat er geen licenties nodig zin voor het geen ik ik wil opzetten.

Er komen pas licenties bij in mijn opzet als ik gebruik maak van RD session host, die via RDP overgenomen worden en wanneer er Windows software beschikbaar gesteld wordt aan de remote cliënts, bv Office. Aangezien in mijn situatie de remote cliënts enkel de WIN 7 computer overnemen om van daaruit bedrijfssoftware (PLC/DCS) te manipuleren zijn er geen RD CAL's nodig.

Goed nieuws! Heb je ook de links gekregen naar de informatie en/of op e-mail de bevestiging ontvangen van hetgeen telefonisch is verteld? Altijd goed om je rug te dekken bij een SAM traject.

[ Voor 67% gewijzigd door PcDealer op 03-04-2014 17:28 ]

donderdag 3 april 2014 17:40

Acties:

donderdag 3 april 2014 23:09

Topicstarter

PcDealer schreef op donderdag 03 april 2014 @ 17:25:
[...]

Lijkt me sterk: ik geniet een ww op dit moment. Ik ben echter wel MCTS gecertificeerd (70-671 en 70-672).

Ik weet waar de juiste informatie staat. Gezien het aantal licenties waar het mogelijk om gaat, zou het mijn werkgever (als ik in loondienst zou zijn) meer kosten dan opleveren als ik het op de klok zou doen

[...]

Goed nieuws! Heb je ook de links gekregen naar de informatie en/of op e-mail de bevestiging ontvangen van hetgeen telefonisch is verteld? Altijd goed om je rug te dekken bij een SAM traject.

PcDealer schreef op woensdag 02 april 2014 @ 18:53:
Goeie. Het nieuwste document is http://download.microsoft...%20VDA%20FAQ%20v3%200.pdf
Te vinden via: http://www.microsoft.com/...ating-system/default.aspx

Ook interessant: Plan for and deploy Virtual Desktop Infrastructure

Volume licensing brief: Licensing Windows desktop operating system for use with virtual machines

Licensing Microsoft’s Virtual Desktop Infrastructure Technology

Windows Licensing for VDI Quick Ref.

Bedankt voor de nuttige links. Ik hou ze lekker bij, ze komen zeker nog van pas. Het opzetten van VDI is tegenwoordig niet meer weg te denken.

Ikzelf heb heel weinig ervaring met windows Licensing. Ik ben altijd bereid bij te leren van mensen die er wel iets van kennen.

PcDealer schreef op donderdag 03 april 2014 @ 17:25:
[...]

Lijkt me sterk: ik geniet een ww op dit moment. Ik ben echter wel MCTS gecertificeerd (70-671 en 70-672).

Ik weet waar de juiste informatie staat. Gezien het aantal licenties waar het mogelijk om gaat, zou het mijn werkgever (als ik in loondienst zou zijn) meer kosten dan opleveren als ik het op de klok zou doen

[...]

Goed nieuws! Heb je ook de links gekregen naar de informatie en/of op e-mail de bevestiging ontvangen van hetgeen telefonisch is verteld? Altijd goed om je rug te dekken bij een SAM traject.

Nee helaas niet. Nu ik het lees had ik dat best kunnen vragen, echter klonk de man zeer goed op de hoogte.

Acties:

donderdag 3 april 2014 23:45

Funzy83 schreef op zaterdag 29 maart 2014 @ 16:11:
[...]

DCS/PLC systemen zijn idd niet direkt bedoelt om een koppeling te hebben met het internet. Het is echter wel de vraag van het management. Dus wie ben ik dan om daar moeilijk over te gaan doen?

Uhm, juist jij bent de persoon om een riskassement uit te voeren en te overleggen met het management. Dit is gewoon bad practice. Het process control network en het business network hoort gewoon gescheiden te zijn (oftewel er hoort geen control uitgevoerd te kunnen worden vanuit het business network naar het pcd).

Ik weet niet hoe kritiek het is als het plat gaat of het process beinvloed wordt? Je wil niet dat iemand extern aan het process rommelt lijkt me.

Maar mocht je ook maar iets doen, zorg voor een bastionhost en configureer die juist in de firewall.

Acties:

vrijdag 4 april 2014 10:53

Freezerator schreef op donderdag 03 april 2014 @ 23:09:
[...]

Uhm, juist jij bent de persoon om een riskassement uit te voeren en te overleggen met het management. Dit is gewoon bad practice. Het process control network en het business network hoort gewoon gescheiden te zijn (oftewel er hoort geen control uitgevoerd te kunnen worden vanuit het business network naar het pcd).

Ik weet niet hoe kritiek het is als het plat gaat of het process beinvloed wordt? Je wil niet dat iemand extern aan het process rommelt lijkt me.

Maar mocht je ook maar iets doen, zorg voor een bastionhost en configureer die juist in de firewall.

zolang de rdgateway alleen bij het client subnet kan valt het wel mee en zijn de client computers de bastionhosts. Er vanuitgaande dat er tussen client subnet en server subnet ge-firewalled word...

Newton's 3rd law of motion. Amateur moraalridder.

Acties:

vrijdag 4 april 2014 13:21

Razwer schreef op donderdag 03 april 2014 @ 23:45:
[...]

zolang de rdgateway alleen bij het client subnet kan valt het wel mee en zijn de client computers de bastionhosts. Er vanuitgaande dat er tussen client subnet en server subnet ge-firewalled word...

De client waarmee je control doet op de PLC's? Lijkt me niet de bedoeling van het concept bastionhost

Acties:

vrijdag 4 april 2014 13:37

Crew Council

#whisky #barista

Hmm, security versus bruikbaarheid. Altijd een lastig dilema. Bruikbaarheid van dit systeem brengt dus enkele risico's met zich mee, en die moet je dan zo goed als mogelijk proberen te verlagen zonder dat je inlevert in bruikbaarheid.

Natuurlijk kan je dan dwars gaan liggen en het e.e.a. proberen tegen te houden, maar dan regelen ze het waarschijnlijk op een andere nog onveiligere manier.

[ Voor 25% gewijzigd door Equator op 04-04-2014 13:23 ]

Acties:

Question Mark

Moderator SSC/WOS

F7 - Nee - Ja

Freezerator schreef op donderdag 03 april 2014 @ 23:09:
[...]

Uhm, juist jij bent de persoon om een riskassement uit te voeren en te overleggen met het management. Dit is gewoon bad practice. Het process control network en het business network hoort gewoon gescheiden te zijn (oftewel er hoort geen control uitgevoerd te kunnen worden vanuit het business network naar het pcd).

Eens, het Ethernet to the Factory design is daar redelijk helder in (opgesteld door Cisco samen met Rockwell).

Koppelingen tussen KA-netwerk (laag 4) en Factory (laag 3 en lager) dienen via een tussenlaag te gebeuren.

Toevallig ben ik net bezig met het ontwerpen van een 3.5 laag om patching van processystemen mogelijk te maken.

MCSE NT4/2K/2K3, MCTS, MCITP, CCA, CCEA, CCEE, CCIA, CCNA, CCDA, CCNP, CCDP, VCP, CEH + zwemdiploma A & B

vrijdag 4 april 2014 15:01

Acties:

bigfoot1942

Functioneert een goed geconfigureerde RDG in een apart netwerk niet als laag 3,5 ?
Overigens heb ik de TS nog niet horen praten over een KA netwerk. Waar dat zit in het plaatje is mij niet duidelijk..

vrijdag 4 april 2014 15:11

Acties:

vrijdag 4 april 2014 16:55

bigfoot1942 schreef op vrijdag 04 april 2014 @ 15:01:
Functioneert een goed geconfigureerde RDG in een apart netwerk niet als laag 3,5 ?
Overigens heb ik de TS nog niet horen praten over een KA netwerk. Waar dat zit in het plaatje is mij niet duidelijk..

Ik vermoed dat die scheiding er (nog) niet is.

Acties:

vrijdag 4 april 2014 18:08

Topicstarter

Freezerator schreef op donderdag 03 april 2014 @ 23:09:
[...]

Uhm, juist jij bent de persoon om een riskassement uit te voeren en te overleggen met het management. Dit is gewoon bad practice. Het process control network en het business network hoort gewoon gescheiden te zijn (oftewel er hoort geen control uitgevoerd te kunnen worden vanuit het business network naar het pcd).

Ik weet niet hoe kritiek het is als het plat gaat of het process beinvloed wordt? Je wil niet dat iemand extern aan het process rommelt lijkt me.

Maar mocht je ook maar iets doen, zorg voor een bastionhost en configureer die juist in de firewall.

Ik begrijp jou reactie wel hoor. Het toegankelijk maken van zulke processen over internet is eigenlijk not done. Echter spreken we hier niet van een kerncentrale. Als het proces down gaat door gerommel van mensen met slechte bedoelingen, spreken we vooral van verlies in kapitaal omwille van geen produktie. Geen milieu rampen of dergelijke.

Ik ben in het bedrijf maar een van de IT medewerkers, de opdracht is gegeven door het IT management.

business systems network en proces control zijn gescheiden in het bedrijf. Ik zal later vandaag een schema van de structuur online zetten.

Er zitten in totaal 3 firewalls tussen internet en proces control.

Internet --- firewall -- RD gateway -- firewall -- business systems network -- firewall -- proces control

Vanaf business systems network is het niet mogelijk om de Win 7 cliënts in proces control te bereiken, business systems network en proces control zijn volledig gescheiden. Mensen in het bedrijf doen enkel wijzigingen fysiek vanaf de Win 7 cliënts in proces control.

Om uiteindelijk de wijzigingen op de PLC/DCS sytemen te kunnen doen, moet iedereen nog een 2 phased authentication mechanism door. Het is dus niet zo dat een indringer die zich tot deze Win 7 machines weet te begeven, ook direkt alles zal kunnen aanpassen.

Ik ga niet beweren dat dit systeem waterdicht is. Maar je zal toch moeite moeten doen om uiteindelijk het proces te laten crashen, moest dat de intentie zijn.

Acties:

vrijdag 4 april 2014 19:10

Maar het plan is nu toch een gaatje te maken zodat er meteen toegang is tot process control? Dan maakt het niet uit hoeveel firewalls je hebt als je methodes gaat toepassen om toch toegang te krijgen tot layer 3? En ik zie dat jullie zeker de intentie hebben om ondanks dat het bad practice is, dit zo veilig mogelijk te doen, je toch moet denken om in de toekomst dit soort situaties te vermijden.

En ik maak me geen zorgen om mileurampen of dergelijke, ik ben maar een simpele financieel controller en het enige waar ik me druk om maak is verlies in kapitaal

Acties:

Paul

Freezerator schreef op vrijdag 04 april 2014 @ 18:08:
je toch moet denken om in de toekomst dit soort situaties te vermijden.

Hoe moet ik dat voor me zien? je kunt er nog meer firewalls en nog meer logins tussen stoppen, maar nu je al 3 firewalls en 3x inloggen hebt is dat gerommel in de marge.... Enige wat nog significant helpt is helemaal geen koppeling en dan weet je tenminste zeker dat je bij iedere storing 2 uur werk verliest in plaats van dat je het kleine risico neemt dat iemand alle lagen van beveiliging doorbreekt en 2 uur werk verprutst...

Ik verzin nu een paar getallen, iemand dichter op het vuur kan vast een beter risk assessment maken, maar het schijnt me toe dat er bij bedrijven waar niet 24/7 een engineer zit wel degelijk een break even is waar remote open stellen goedkoper is dan dicht laten

"Your life is yours alone. Rise up and live it." - Richard Rahl
Rhàshan - Aditu Sunlock

vrijdag 4 april 2014 19:38

Acties:

zaterdag 5 april 2014 01:24

Paul schreef op vrijdag 04 april 2014 @ 19:10:
[...]
Hoe moet ik dat voor me zien? je kunt er nog meer firewalls en nog meer logins tussen stoppen, maar nu je al 3 firewalls en 3x inloggen hebt is dat gerommel in de marge.... Enige wat nog significant helpt is helemaal geen koppeling en dan weet je tenminste zeker dat je bij iedere storing 2 uur werk verliest in plaats van dat je het kleine risico neemt dat iemand alle lagen van beveiliging doorbreekt en 2 uur werk verprutst...

Ik verzin nu een paar getallen, iemand dichter op het vuur kan vast een beter risk assessment maken, maar het schijnt me toe dat er bij bedrijven waar niet 24/7 een engineer zit wel degelijk een break even is waar remote open stellen goedkoper is dan dicht laten

De juiste mindset en awareness creeren zodat het MT ook begrijpt waarom je dit niet wil doen. Het schijnt nu een redelijk onschuldig process te zijn, maar in essentie wil je gewoon geen control van afstand hebben zonder toezicht. Je hebt gelijk dat er een goede risk assessment van moet worden gemaakt, want daarin beschrijf je deze risico's die je neemt en waarom je toch voor oplossing x kiest. Het is gewoon lastig om de juiste mix in usability en security te vinden, dus het is goed om hier goed over na te denken. Ik ben niet iemand die iets wil tegenhouden, maar het is wel belangrijk om het risico goed te begrijpen.

En als je voor deze oplossing kiest, er zijn bijvoorbeeld firewalls die alleen werken als iemand lokaal de sleutel op de firewall omzet en daarmee een sessie van xx minuten mogelijk maakt. Maar dan moet er dus lokaal in elk geval een operator bij zijn zodat je iets meer controle hebt over wat er gebeurt.

Acties:

zaterdag 5 april 2014 10:22

Freezerator schreef op vrijdag 04 april 2014 @ 19:38:
[...]
maar het is wel belangrijk om het risico goed te begrijpen.

Dat is het belangrijkste aspect van allemaal. Niets is onkraakbaar, maar je moet ook niets te makkelijk maken. Je moet ergens een grens trekken en dat is per situatie verschillend en (vaak) lastig. Risicos vaststellen is de belangrijkste stap. Risicos inperken is stap 2. Risicos accepteren is ook een onderdeel.

bigfoot1942 schreef op vrijdag 04 april 2014 @ 15:01:
Functioneert een goed geconfigureerde RDG in een apart netwerk niet als laag 3,5 ?

dus dat...

@Mark
Leg mij maar eens het verschil uit (security wise) tussen op een RDS server landen in een TerminalServer subnet via RDG vs op een client PC landen in een client subnet via RDG.
Je moet de beheerders eens op die koffie krijgen die die TS gewoon in het "server subnet" kwakken...
Ja je kan een RDS over het algemeen beter dichttimmeren per GPO. Maar dit is bijna altijd wel te omzeilen op een of andere manier. Ik ben nog geen TS tegen gekomen waar ik geen breakout op kon forceren op een of andere manier.

Op een RDS kun je wel een stukje two-factor auth software installeren (kan ook op client pc maar is minder handig en vaak duurder) maar dat moet je wel willen en geld voor hebben (in jargon: moet binnen de scope vallen).

[ Voor 49% gewijzigd door Razwer op 05-04-2014 01:36 ]

Newton's 3rd law of motion. Amateur moraalridder.

Acties:

HP ftw \o/

2 factor auth. kost een paar honderd, hooguit.

zaterdag 5 april 2014 11:51

Acties:

dinsdag 15 april 2014 13:07

PcDealer schreef op zaterdag 05 april 2014 @ 10:22:
2 factor auth. kost een paar honderd, hooguit.

Dat hangt totaal van de oplossing af, waar je het op toepast en hoeveel users. De laatste keer dat ik 2 factor aankocht voor 300 users was ik rond de 30k kwijt.

Newton's 3rd law of motion. Amateur moraalridder.

Acties:

Frogmen

Ik lees hier verschillende zeer complexe methodes maar wat is er mis met een VPN connectie naar een specifiek subnet waar deze windows7 machines in staan rdp connectie en vervolgens zal er ook nog ingelogd moeten worden op de software zelf. Ik zie hier al drie authentificaties. Zeker als je de VPN alleen toestaat vanaf voorgedefinieerde adressen. Ga in overleg krijg hier het gevoel van de kluis om de rolletjes snoep te bewaren.

Voor een Tweaker is de weg naar het resultaat net zo belangrijk als het resultaat.

dinsdag 15 april 2014 22:17

Acties:

Mark89

Wat we tegenwoordig gebruiken om bij klanten computers over te nemen aangesloten op een industrieel netwerk is een mGuard van Phoenix Contact.
Het is eigenlijk gewoon een router met firewall die we tussen het officenetwerk en het industrieel netwerk plaatsen. Het voordeel hier met is dat je er schakelaars of drukknoppen aan kan koppelen en deze dan kan configureren om onder bepaalde voorwaarden inkomende verbindingen te accepteren. (bv. een schakelaar)
Daarnaast moet je natuurlijk ook een verbinding van het officenetwerk naar buiten toe voorzien.

Wat we in ons bedrijf meestal toepassen, is het volgende:
We installeren een schakelaar in de controlekamer en configureren deze dat als deze aanstaat de mGuard verbindingen accepteert.
Daarnaast hebben we een VM draaien op de servers op het officenetwerk die een VPN verbinding maakt met de mGuard. Op deze VM staat dan VNC/mRemote/... waar alle PC's in geconfigureerd staan van het industrieel netwerk om deze gemakklijk over te nemen.
Indien we bij een storing een PC willen overnemen van thuis, zetten we een VPN verbinding op met het officenetwerk en nemen we de VM over. Van zodra de schakelaar in de controlekamer geschakeld is, maakt de VM een verbinding met het industrieel netwerk. Waarna we vanop de VM computers kunnen overnemen via RDP/VNC/...

Het is natuurlijk ook mogelijk om computers van verscheidene mensen te configureren om eens via VPN verbonden met het officenetwerk, rechtstreeks met de mGuard te verbinden, maar ik garandeer dat de moment dat het moet werken, het niet werkt. Vandaar dat we een VM gebruiken waar alle gemachtigde gebruikers op in kunnen loggen in geval van een storing.

Het is ook mogelijk om de VPN met de mGuard na een tijd te laten uitvallen enzo...

Deze manier van PC's zoals Engineering stations en SCADA servers/clients remote overnemen doe ik bijna dagelijks en heb ik nog niet weten falen.

dinsdag 15 april 2014 22:55

Acties:

woensdag 16 april 2014 08:54

@Mark89 Zo heb je tenminste mooie controle omdat iemand de schakelaar moet omzetten. Wordt verbonden naar een bastionhost waarvan verder de verbinding wordt opgezet. Zo staat er tijdelijk alleen het nodige open en heb je een redelijk secure oplossing.

Laatst hebben we ook een vertegenwoordiger gehad van Waterfall over hun producten, die hebben ook zoiets:
http://www.waterfall-security.com/waterfall-secure-bypass/

We merken dat bij onze klanten steeds meer het bewustzijn ontstaat om dit goed te doen. De imagoschade kost vaak al meer, productie buiten beschouwing gelaten

Acties:

HP ftw \o/

Razwer schreef op zaterdag 05 april 2014 @ 11:51:
[...]

Dat hangt totaal van de oplossing af, waar je het op toepast en hoeveel users. De laatste keer dat ik 2 factor aankocht voor 300 users was ik rond de 30k kwijt.

In dit geval gaat het totaal niet over 300 users....