Windows 10, MSTSC.EXE, RDS en Logon to in AD

[bregweb]

In ons netwerk mag een gebruiker alleen maar op zijn eigen werkstations inloggen, daar gebruiken wij LOGON TO voor in AD. Ook hebben wij een paar (1000+) klanten die extern inloggen. Als zij problemen hebben, bellen ze de HelpDesk. De HelpDesk kon dan via MSTSC.EXE met de klantgegevens inloggen en precies zien wat er fout ging bij de klant. Dit werkt goed tot en met Windows 7.

Bij Windows 10 (en ik denk ook Win8) kan dit niet meer. Via speurwerk op Internet blijkt dat LOGON TO ook betekent LOGON FROM en KlantA mag natuurlijk niet inloggen vanaf het werkstation van de HelpDesk.

Dit kan ik omzeilen door de volgende key op de Server te wijzigen
HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-tcp "SecurityLayer"
Default is 1 (SSL). Set this to 0.

Nadeel 1 van deze methode is dat mijn klanten dan ook een ander scherm te zien krijgen en laten we het er op houden dat het computernivo niet hoog is en de wil om iets bij te leren nog minder.
Nadeel 2 is dat ik voor mijn gevoel het security level van mijn organisatie omlaag haal, maar ik weet niet precies hoeveel.

Ik kan ook alle externe klanten toe gaan voegen aan alle Helpdesk PC.s, maar dat weiger ik

Is er iemand die met dit probleem heeft geworsteld en een 3e oplossing heeft gevonden?

[Brahiewahiewa]

bregweb schreef op maandag 17 juli 2017 @ 12:44:
...Ik kan ook alle externe klanten toe gaan voegen aan alle Helpdesk PC.s, maar dat weiger ik

Nou, dat hoeft - op zich - niet zo'n probleem te zijn: een dump van de klanten-database bewerken en omzetten in een scriptje is nog wel te doen. Groter probleem wordt het bijhouden van de wijzigingen in het klantenbestand

Verder begrijp ik de procedure na drie keer lezen, nog steeds niet: Klant heeft een probleem, belt de helpdesk, helpdesk zegt: "doe het eens voor", en dan? Hoe raakt die klant ingelogged op die helpdesk PC? En waar staat die helpdesk PC eigenlijk? Staat hij bij de klant? Staat hij bij jullie? Is het gewoon de desktop PC van de betreffende medewerker?

[bregweb]

De klant logt niet in op de helpdesk pc. De klant belt de helpdesk en de helpdeskmedewerker start mstsc en logt in met de gegevens van de klant. Aangezien dit op een RDS gebeurt, ziet de helpdeskmedewerker precies hetzelfde als de klant.

[Squ1zZy]

Je laat de helpdesk toch niet inloggen met een account van de klant? Ik zou dat als klant nooit accpteren. Waarom niet de machine overnemen waarbij de klant kan meekijken? Vreemde oplossing dit.

[Dysmael]

Ja dat dus, gewoon meekijken via session shadow of remote assistance

[nelizmastr]

RolfLobker schreef op dinsdag 18 juli 2017 @ 11:07:
Ja dat dus, gewoon meekijken via session shadow of remote assistance

Precies. Wij gebruiken hier teamviewer voor. Dan krijgt de klant in ieder geval te zien als iemand mee wil kijken en kunnen ze zelf aangeven of dat op dat moment gewenst is. Uiteraard gebeurt dit 9/10 keer gelijktijdig met een telefoongesprek.
Desalniettemin is via mstsc inbreken niet de meest elegante optie.

[Dysmael]

Mja Teamviewer vind ik dan weer erg raar om te gebruiken.
Gaat om meekijken met sessies op je eigen apparatuur. Nogal onzin om daar Teamviewer voor te gebruiken.

[mrsar]

hier wordt vooral lync skype for business ervoor gebruikt, mochten we uac moeten invullen gaat het op een andere manier (op laptop/desktop) op citrix ook skype of shadow

[Turdie]

Op een RDS kun je ook naar sessies verbinden als je er zelf ook op zit.

[ Voor 69% gewijzigd door Turdie op 18-07-2017 11:58 ]

[jimbo123]

Shadow session is de oplossing inderdaad.
Tenzij je op Windows Server 2012 (dus pre-R2) zit, want dan mis je deze functionaliteit. Vanaf 2012 R2 is dit weer ondersteund, evenals in 2016.

[Verwijderd]

bregweb schreef op maandag 17 juli 2017 @ 13:54:
De klant logt niet in op de helpdesk pc. De klant belt de helpdesk en de helpdeskmedewerker start mstsc en logt in met de gegevens van de klant. Aangezien dit op een RDS gebeurt, ziet de helpdeskmedewerker precies hetzelfde als de klant.

Echt? Hoe krijgen jullie dit gladgepraat tijdens ISO 27001 / 9001 audits?

[HKLM_]

Verwijderd schreef op dinsdag 18 juli 2017 @ 13:16:
[...]

Echt? Hoe krijgen jullie dit gladgepraat tijdens ISO 27001 / 9001 audits?

Niet iedereen doet aan audits

[Verwijderd]

Downloader_NL schreef op dinsdag 18 juli 2017 @ 14:17:
[...]


Niet iedereen doet aan audits

Niet certificeren is ook een optie natuurlijk. Als je geen klanten hebt die het iets interesseert, kan dat.

Maar blijkbaar is er een DB net unencrypted passwords van alle klanten. Hoe zeker is het, dat die gegevens inmiddels niet op wat minder veilige plekken zijn opgeslagen? Of moeten alle klanten een nieuw password als er iemand ontslagen wordt?

Als ik hier een password van een willekeurig account opzoek (large randomized string), dan wordt dat al gelogd.

[ Voor 10% gewijzigd door Verwijderd op 18-07-2017 14:28 ]

[bregweb]

Er zitten voor- en nadelen aan onze methode. Met de huidige werkwijze hoef ik niets te doen op de PC's van de klanten, vaak zit die ook op een afgeschermde PC en mag deze geeneens software installeren.

Feit is dat er hierboven nogal wat aannames gedaan worden zonder van de exacte situatie op de hoogte te zijn.

Ik zal eens gaan kijken naar Shadow sessions.

[Felyrion]

Wij doen dit soort dingen ook altijd middels "meekijken" met de klant.
We hebben wel meerdere soorten omgevingen onder beheer, dus de methodiek kan verschillen van de teamviewer quicksupport (hier hoeven geen admin rechten voor aanwezig te zijn, en er wordt niks geïnstalleerd) tot Skype tot SCCM Remote Control.
Voor RDS machines kan gebruik gemaakt worden van RDS Shadow, zie bijvoorbeeld http://woshub.com/rds-sha...n-windows-server-2012-r2/

Punt is dat je als bedrijf absoluut niet in control moet willen (en vaak mogen) zijn van credentials van gebruikers.

[Killah_Priest]

bregweb schreef op dinsdag 18 juli 2017 @ 14:46:

Feit is dat er hierboven nogal wat aannames gedaan worden zonder van de exacte situatie op de hoogte te zijn.

Feit is dat jullie een werkwijze hanteren welke haaks staat op alles wat je leert over het beheer van omgevingen. Dat is de reden dat men met zulke aannames komt. En waarom zou men van de exacte situatie op de hoogte moeten zijn? Er is geen enkel excuus te bedenken waarom jullie op deze manier werken (ik zeg ook heel eerlijk : als ik dit bij een werkgever tegen zou komen dan zou mijn CV binnen een uur online staan, zo slecht zou ik daar tegen kunnen.)

Passwords van gebruikers behoren maar bij één persoon bekend te zijn : de gebruiker zelf. Als ik persé in de user sessie moet wezen zonder dat de gebruiker erbij is dan reset ik het wachtwoord wel. Ik zal nooit maar dan ook nooit een gebruiker om zijn/haar credentials te vragen noch zal ik deze ergens opslaan.
Het heeft ook te maken met het stukje bewustwording van een gebruiker : hoe moet ik een gebruiker wijsmaken dat deze nooit en te nimmer zijn credentials aan een ander moet verstrekken als ik er zelf wel om vraag?

Kortom : de zwakste schakel binnen de keten van security is doorgaans de gebruiker. Zodra het voor een gebruiker vanzelfsprekend is dat deze nooit en te nimmer zijn credentials af moet staan dan neemt het risico op een datalek al direct met 99% af.

[bregweb]

De password discussie is alleen al op tweakers al honderden keren gevoerd, laat staan daarbuiten.Dit is niet de thread om deze te herhalen

Binnen mijn bedrijf is dit volledig geaccepteerd, door ons en door de klanten. Om het nog erger te maken: klanten zijn in dit geval geen consumenten, maar andere bedrijven.

Geef ik je gelijk? Ja. Ben ik het eens met onze werkwijze? Nee. Is het voor mij reden tot ontslag/solliciteren? Nee. Is het een reden voor de klanten om naar de concurrent te lopen? Nee.

We hebben helaas geen R2, ik ga dus maar op zoek naar een andere methode om dit toch werkend te krijgen. bedankt voor jullie input en meedenken.

[Squ1zZy]

Het is niet dat ik niet wil helpen, maar ik heb grote moeite om een technische oplossing te vinden voor iets wat ik denk dat compleet anders aangepakt moet worden.

Als je het er niet mee eens bent en je wilt geen ontslag nemen, pak het dan op! Kom met een goed voorstel, zet het op papier en geef goede argumenten.

Ik kan me dan niet voorstellen dat een manager dan nog deze procedure wilt aanhouden.

Ik vind dat elke medewerker verantwoordelijk is voor het bedrijf. Daarbij ook data. Dit is een mooie kans om het goed op te pakken.

Mocht je daarmee aan de slag willen dan ben ik zeker bereid om mee te helpen of denken.

[Question Mark]

bregweb schreef op maandag 17 juli 2017 @ 12:44:
In ons netwerk mag een gebruiker alleen maar op zijn eigen werkstations inloggen, daar gebruiken wij LOGON TO voor in AD.

Even los van de wachtwoord discussie, maar is bovenstaande niet je hele probleem?

Waarom staat er ingesteld dat een gebruiker alleen maar op zijn eigen werkplek mag inloggen?

[bregweb]

Squ1zZy schreef op woensdag 19 juli 2017 @ 19:31:
Het is niet dat ik niet wil helpen, maar ik heb grote moeite om een technische oplossing te vinden voor iets wat ik denk dat compleet anders aangepakt moet worden.

Als je het er niet mee eens bent en je wilt geen ontslag nemen, pak het dan op! Kom met een goed voorstel, zet het op papier en geef goede argumenten.

Ik kan me dan niet voorstellen dat een manager dan nog deze procedure wilt aanhouden.

Ik vind dat elke medewerker verantwoordelijk is voor het bedrijf. Daarbij ook data. Dit is een mooie kans om het goed op te pakken.

Mocht je daarmee aan de slag willen dan ben ik zeker bereid om mee te helpen of denken.

OK, maar wat is dan een goede oplossing voor dit probleem? Als ik oplossingen zie, dan ga ik er ook voor ;-)

Logon to is een interne policy waarbij men (leidinggevenden en management) denkt veiliger te zijn, daar ga ik niet vanaf komen en voor een gedeelte moet ik ze gelijk geven.

Wachtwoorden van klanten: Geef ik je ook gelijk in, maar mijn klanten zijn dombo's en totaal niet geïnteresseerd in security. Computers zijn ondingen en ja, ik moet van mijn baas bij jou bestellen via een computer, maar waarom kan ik niet gewoon klikken en moet ik een wachtwoord gebruiken? Helpdesk? U heeft een computerprobleem? Ik verbind u door met IT

Ik wil hier niet al mijn frustraties uiten, maar theorie en praktijk liggen nu eenmaal ver uit elkaar

[TheVMaster]

bregweb schreef op Thursday 20 July 2017 @ 00:17:
[...]


OK, maar wat is dan een goede oplossing voor dit probleem? Als ik oplossingen zie, dan ga ik er ook voor ;-)

Logon to is een interne policy waarbij men (leidinggevenden en management) denkt veiliger te zijn, daar ga ik niet vanaf komen en voor een gedeelte moet ik ze gelijk geven.

Wachtwoorden van klanten: Geef ik je ook gelijk in, maar mijn klanten zijn dombo's en totaal niet geïnteresseerd in security. Computers zijn ondingen en ja, ik moet van mijn baas bij jou bestellen via een computer, maar waarom kan ik niet gewoon klikken en moet ik een wachtwoord gebruiken? Helpdesk? U heeft een computerprobleem? Ik verbind u door met IT

Ik wil hier niet al mijn frustraties uiten, maar theorie en praktijk liggen nu eenmaal ver uit elkaar

Als ik dit zo lees vraag ik me wel af wat er gebeurt als er gegevens van die klanten op straat komt te liggen. Volgens mij is het hele security verhaal (natuurlijk was dat altijd al belangrijk) nog een stuk belangrijker geworden na die nieuwe data-lek wet. Maar goed, heb ooit voor een werkgever gewerkt die ook gewoon rustig illegale software bij klanten installeerden (klant wilde dit, want waarom zou hij betalen als het ook gewoon gedownload kon worden?). Overigens snap ik leidinggevenden en management van die club waar jij werkt niet, als er iets gebeurt kan dat volgens mij een behoorlijke klap geld kosten. Maar op korte termijn heb je er waarschijnlijk geen last van, tja...dan bestaan dat soort problemen voor dat soort managers/leidinggevenden ook niet.