[Windows server 2012] Remote Desktop Services

[tel2]

Hallo,

Ik wil heb een Windows 2012 Standaard server die ik wil configureren als terminal server. Dit wil ik doen zonder gebruik te maken van een certificaat, dus geen self signed certificaat en ook geen trusted certificaat.

Ik kan nergens vinden of dit mogelijk is. Het wordt alleen gebruikt door circa 10 mederwerkers die intern of via een vaste VPN verbinding gaan inloggen op de server.

Het is een erg korte vraag maar ik denk dat meer informatie niet nodig is. Mocht dit toch zo zijn dan hoor ik het graag.

[ Voor 6% gewijzigd door tel2 op 24-01-2014 09:40 ]

[hans_lenze]

Waar denk je een certificaat voor nodig te hebben?

[tel2]

hans_lenze schreef op vrijdag 24 januari 2014 @ 11:19:
Waar denk je een certificaat voor nodig te hebben?

Ik heb het een aantal maanden geleden op een test server geïnstalleerd maar ik heb het idee dat je niet om het certificaat heen kunt. Dat Microsoft het als het ware opdringt om dit uit veiligheidsoverwegingen te gebruiken. Maar ik kan er naast zitten.

[VreYseN]

Als het alleen voor intern gebruik is en je geen RDGateway gebruikt heb je niet persee een certificaat nodig.
Je zult afhankelijk van je RDP versie wel wat meldingen weg moeten klikken de eerste keer.

Is alleen niet de best practice. En SSL certificaten zijn al te bestellen voor 10 euro per jaar.

[tiguan]

Windows maakt toch zelf standaard al een certificaat aan. Dat is die melding die je krijgt als je voor het eerst inlogt op de betreffende server. Tijdens die melding kan je ervoor kiezen om het nooit meer te laten zien.

[tel2]

VreYseN schreef op vrijdag 24 januari 2014 @ 11:27:
Als het alleen voor intern gebruik is en je geen RDGateway gebruikt heb je niet persee een certificaat nodig.
Je zult afhankelijk van je RDP versie wel wat meldingen weg moeten klikken de eerste keer.

Is alleen niet de best practice. En SSL certificaten zijn al te bestellen voor 10 euro per jaar.

Ok bedankt, ik zal vanmiddag proberen te kijken hoe ver ik kom.

tiguan schreef op vrijdag 24 januari 2014 @ 11:30:
Windows maakt toch zelf standaard al een certificaat aan. Dat is die melding die je krijgt als je voor het eerst inlogt op de betreffende server. Tijdens die melding kan je ervoor kiezen om het nooit meer te laten zien.

Je hebt het nu over de client? Een certificaat wordt op de client volgens mij niet aangemaakt, maar het gaat nu even over het configureren van terminal services in Windows 2012 zonder certificaat.

[Jazzy]

Het idee achter dat certificaat is dat de gebruikers zeker weten dat ze op jouw server in gaan loggen en niet hun gebruikersnaam en wachtwoord aan een 3e gaan geven. De gedachte achter dit systeem is dat je gebruikers nooit moet aanleren om certificaatmeldingen weg te klikken maar juist op te letten als ze zo'n melding krijgen.

Zoals gezegd kost een trusted SSL certificaat tegenwoordig geen drol meer, doe het dus gewoon netjes en schaf er eentje aan.

[tiguan]

tel2 schreef op vrijdag 24 januari 2014 @ 11:41:
[...]


Ok bedankt, ik zal vanmiddag proberen te kijken hoe ver ik kom.


[...]


Je hebt het nu over de client? Een certificaat wordt op de client volgens mij niet aangemaakt, maar het gaat nu even over het configureren van terminal services in Windows 2012 zonder certificaat.

Nee op de server. Windows server maakt zelf al een certificaat aan.

[tel2]

tiguan schreef op vrijdag 24 januari 2014 @ 12:15:
[...]


Nee op de server. Windows server maakt zelf al een certificaat aan.

En dit certificaat wat hij aanmaakt moet je vervolgens op iedere cliënt installeren die verbinding wil maken?

[tel2]

Jazzy schreef op vrijdag 24 januari 2014 @ 12:12:
Het idee achter dat certificaat is dat de gebruikers zeker weten dat ze op jouw server in gaan loggen en niet hun gebruikersnaam en wachtwoord aan een 3e gaan geven. De gedachte achter dit systeem is dat je gebruikers nooit moet aanleren om certificaatmeldingen weg te klikken maar juist op te letten als ze zo'n melding krijgen.

Zoals gezegd kost een trusted SSL certificaat tegenwoordig geen drol meer, doe het dus gewoon netjes en schaf er eentje aan.

Het lijkt me vrij lastig je gebruikers zo op te voeden dat ze dit niet wegklikken
Je hebt wel gelijk en ik wil in de nabije toekomst ook zeker zo'n certificaat installeren maar het moet nu snel werken en voor iedereen intern toegankelijk zijn.

[Trommelrem]

VreYseN schreef op vrijdag 24 januari 2014 @ 11:27:
Als het alleen voor intern gebruik is en je geen RDGateway gebruikt heb je niet persee een certificaat nodig.
Je zult afhankelijk van je RDP versie wel wat meldingen weg moeten klikken de eerste keer.

Is alleen niet de best practice. En SSL certificaten zijn al te bestellen voor 10 euro per jaar.

SSL certificaten schijn je zelfs al gratis te kunnen krijgen voor particulier gebruik.

Maar met de juiste PowerShell commando's zou je o.a. NLA moeten kunnen uitzetten en RDP Security moeten kunnen inschakelen ipv Negotiate of SSL.

[Jazzy]

tel2 schreef op vrijdag 24 januari 2014 @ 12:26:
[...]
Je hebt wel gelijk en ik wil in de nabije toekomst ook zeker zo'n certificaat installeren maar het moet nu snel werken en voor iedereen intern toegankelijk zijn.

Okay, dan kun je het beste gewoon verdergaan met het volgen van de TechNet documentatie en het snel afmaken. http://technet.microsoft.com/en-us/library/hh831447.aspx

[Dennism]

tel2 schreef op vrijdag 24 januari 2014 @ 12:26:
[...]


Het lijkt me vrij lastig je gebruikers zo op te voeden dat ze dit niet wegklikken
Je hebt wel gelijk en ik wil in de nabije toekomst ook zeker zo'n certificaat installeren maar het moet nu snel werken en voor iedereen intern toegankelijk zijn.

tja, dan is het makkelijkst een keer de certificaat melding wegklikken op iedere client en het vinkje aanzetten om deze voor dit certificaat niet meer te laten zien. Kost een stuk minder tijd dan alternatieve oplossingen zonder dit self signed certificaat uit te zoeken, te implementeren en te testen of om het self signed certificaat op iedere client te installeren en aan te merken als trusted. Het certificaat is namelijk in een standaard implementatie alleen een waarschuwing, de connectie zal niet worden geblokkeerd omdat de client het certificaat niet kent tenzij dit expliciet geconfigureerd wordt.

[ Voor 17% gewijzigd door Dennism op 24-01-2014 13:08 ]

[tel2]

Dennism schreef op vrijdag 24 januari 2014 @ 13:06:
[...]


tja, dan is het makkelijkst een keer de certificaat melding wegklikken op iedere client en het vinkje aanzetten om deze voor dit certificaat niet meer te laten zien. Kost een stuk minder tijd dan alternatieve oplossingen zonder dit self signed certificaat uit te zoeken, te implementeren en te testen of om het self signed certificaat op iedere client te installeren en aan te merken als trusted. Het certificaat is namelijk in een standaard implementatie alleen een waarschuwing, de connectie zal niet worden geblokkeerd omdat de client het certificaat niet kent tenzij dit expliciet geconfigureerd wordt.

Bedankt dan installeer ik het in eerste instantie met een self signed certificaat.

[Question Mark]

Als je toch de keuze maakt om met self-signed certificaten aan de slag gaat, dan kun je deze natuurlijk met een paar muisklikken met een GPO deployen naar je domaincleints.

Die vijf minuten tijd die dat kost kan het probleem niet zijn.

[Dennism]

Question Mark schreef op vrijdag 24 januari 2014 @ 13:44:
Als je toch de keuze maakt om met self-signed certificaten aan de slag gaat, dan kun je deze natuurlijk met een paar muisklikken met een GPO deployen naar je domaincleints.

Die vijf minuten tijd die dat kost kan het probleem niet zijn.

Ligt er natuurlijk wel aan wat voor clients je hebt, als je bijv. TC's hebt voor lokaal gebruik die niet in het domain zitten, of thuiswerkplekken die niet in het domain zitten zal een GPO je niet ver helpen Als je allemaal in het domein opgenomen fat clients hebt dan kan ik me voorstellen dat je het wel even uitrolt inderdaad.

[Question Mark]

Daarom zeg ik ook bewust "domainclients"...

[tel2]

Ik heb de server geïnstalleerd maar het werkt nog niet, ik hoop dat jullie me kunnen helpen. Ik krijg de fout op de cliënt "Toegang tot de aangevraagde sessie is geweigerd" als ik inlog met een domein gebruiker.

Ik heb de volgende situatie:

SBS 2008 domein controller
Windows 2012 Terminal server

De Windows 2012 terminal server heb ik aangemeld in het domein en vervolgens de terminal services opties geïnstalleerd. De Terminal server heb ik in de OU SBSServers gezet op de SBS 2008 machine.

Bij het verbindingsautorisatiebeleid op de terminal server heb ik ingesteld dat de groep Domain Users verbinding mag maken.

Waar kan dit nog fout gaan? Is er een bepaald logboek waar ik kan zien waarop de verbinding geweigerd wordt?

Edit: Als ik de groep Domain Users toevoeg bij Instellingen voor externe verbindingen (Configuratiescherm\Systeem en beveiliging\Systeem), dan kan ik (logischerwijs) wel inloggen met een domein users. Als ik dan bij mijn gateway beheer kijk zie ik de verbinding van deze gebruiker niet bij actieve connecties staan.

[ Voor 17% gewijzigd door tel2 op 24-01-2014 17:28 ]

[Dennism]

Ik heb al even niet meer met een SBSserver gewerkt, maar waarom staat de TS server in de OU SBSServers als het geen SBSserver is. Mogelijk dat hier een goede reden voor is, maar het zou ook een foutje kunnen zijn.

Is de licentie server ook al geinstalleerd voor terminalservices, dat zou mogelijk ook nog een probleem kunnen zijn, al geloof ik dat je een 90 dagen grace periode hebt.

Check tevens even op op de Terminalservices connector of de rechten echt goed staan, en of de terminalservices niet in remote administrator mode staan.

[tel2]

Dennism schreef op vrijdag 24 januari 2014 @ 17:29:
Ik heb al even niet meer met een SBSserver gewerkt, maar waarom staat de TS server in de OU SBSServers als het geen SBSserver is. Mogelijk dat hier een goede reden voor is, maar het zou ook een foutje kunnen zijn.

Is de licentie server ook al geinstalleerd voor terminalservices, dat zou mogelijk ook nog een probleem kunnen zijn, al geloof ik dat je een 90 dagen grace periode hebt.

Check tevens even op op de Terminalservices connector of de rechten echt goed staan, en of de terminalservices niet in remote administrator mode staan.

Ik heb ergens op internet gelezen (site ben ik inmiddels kwijt) dat de server in deze OU moet komen. De licentie server is geinstalleerd al is er inderdaad nog geen licentie toegevoegd. Ik heb alle instellingen doorlopen maar kan echt geen rede vinden waarom de een domein gebruiker geweigerd wordt. Ik heb het idee dat het mogelijk te maken heeft met een group policy op de SBS maar misschien denk ik in de verkeerde richting.

Kun je aangeven wat je met onderstaande bedoel?
Check tevens even op op de Terminalservices connector of de rechten echt goed staan, en of de terminalservices niet in remote administrator mode staan.

[ Voor 8% gewijzigd door tel2 op 24-01-2014 18:33 ]

[hans_lenze]

Hoe maak je precies een verbinding? Kun je stap voor stap vertellen wat je op een cliënt uitvoert om de verbinding op te bouwen?

Het feit dat je het over 'gateway' hebt, geeft mij het vermoeden dat je meer wilt dan je tot nu toe hebt laten weten of dat je verkeerd zit te kijken naar de aangemelde sessies.

Eventuele foutmeldingen kun je, zoals altijd, terugvinden in het event log en in server manager bij de specifieke rol.

[tel2]

hans_lenze schreef op vrijdag 24 januari 2014 @ 19:54:
Hoe maak je precies een verbinding? Kun je stap voor stap vertellen wat je op een cliënt uitvoert om de verbinding op te bouwen?

Het feit dat je het over 'gateway' hebt, geeft mij het vermoeden dat je meer wilt dan je tot nu toe hebt laten weten of dat je verkeerd zit te kijken naar de aangemelde sessies.

Eventuele foutmeldingen kun je, zoals altijd, terugvinden in het event log en in server manager bij de specifieke rol.

Ik maak verbinding via een Windows XP client via Start > Uitvoeren > mstsc en login met gebruikersnaam: Domein\username en met het wachtwoord. Vervolgens klik ik op Verbinden en dan krijg ik de foutmelding; "Toegang tot de aangevraagde sessie is geweigerd".

Ik was van mening dat ik de gateway moest installeren om terminal services te kunnen gebruiken?

De gebruikers die in moeten kunnen loggen op de terminal server moeten die ook bij de instellingen voor externe verbindingen (Configuratiescherm\Systeem en beveiliging\Systeem) toegevoegd worden?

In de eventlog van de server manager zie ik geen fouten terugkomen. Zou het kunnen komen dat er iets mis is met het certificaat? Ik kan nergens vinden waar de optie om in te loggen via een certificaat uit te schakelen is.

Bedankt!

[Tadream]

Ik weet niet hoe dit onder SBS werkt en of je dit al geprobeerd hebt maar de gebruikers moeten ook lid zijn van de Remote Desktop Users groep.
Bij 2008/2012 te vinden bij de local users/groups.

[tel2]

Tadream schreef op vrijdag 24 januari 2014 @ 20:52:
Ik weet niet hoe dit onder SBS werkt en of je dit al geprobeerd hebt maar de gebruikers moeten ook lid zijn van de Remote Desktop Users groep.
Bij 2008/2012 te vinden bij de local users/groups.

Dit heb ik helaas al geprobeerd. Ik heb de groep Domain Users toegevoegd aan de groep Remote Desktop Users die te vinden is onder Active Directory and Computers > Domein.local > Builtin.

Bedankt voor het meedenken.

[Question Mark]

tel2 schreef op vrijdag 24 januari 2014 @ 17:18:
De Terminal server heb ik in de OU SBSServers gezet op de SBS 2008 machine.

Tien tegen één dat er nu een policy-setting actief is waardoor een gewone gebruiker niet interactief aan mag loggen. Dat kun je controleren met een resultant set of policy.

Eenvoudiger is het om even een nieuwe OU aan te maken, die geen bestaande Group Policy gelinked heeft, de RDS server daarheen te verplaatsen, en na het updaten van de Group Policy's even te testen.

[tel2]

Goedemiddag,

Ik heb al jullie opties geprobeerd maar zonder de groep DOMEIN\Users toe te voegen bij de instellingen voor externe verbindingen (Configuratiescherm\Systeem en beveiliging\Systeem) krijg ik geen verbinding. Ik heb de groep dus maar toegevoegd en dan kan ik inloggen met een domein user. Misschien moet dit ook wel maar ik kan dat nergens terug vinden.

Allemaal bedankt voor het meedenken.