[gptalk] Re: handling remote desktop

  • From: "Cruz, Jerome L" <jerome.l.cruz@xxxxxxxxxx>
  • To: "gptalk@xxxxxxxxxxxxx" <gptalk@xxxxxxxxxxxxx>
  • Date: Tue, 18 Nov 2008 09:25:30 -0800

Hi Daniel,

The following is, perhaps, not just for you alone, but for the entire 
readership... (just adding to the kinds of ideas that might be out there).

I'm not sure what kind of scale or security level of protection is required in 
your organization, but here are some additional 'alternative' ideas to consider 
for 'very' structured access providing a 'high level' of audit, visibility, and 
control:

*       For Admins: Pre-create a domain local security group for each device 
(yes... 'each' device) and use a Computer Startup script to make it a member of 
the local devices 'Administrators' security group. These groups are normally 
kept empty of members until needed.
*       For non-Admins: Pre-create a domain local security group for each 
device and use that same Computer Startup script to make it a member of the 
local devices 'Remote Desktop User' security group. These groups are normally 
kept empty of members until needed.
*       For groups of devices: Create a security group that provides 
'unlimited' access (even across the network) for any necessary service accounts 
(and to handle 'short-term' emergencies). Roll these 'unlimited' access groups 
into a single group that can be used for GPO purposes (to provide and maintain 
access)
*       Create all these groups in a protected area of Active Directory (so not 
just anyone can get access to them to change memberships).
*       Use a GPO to block "Across-the-network-access" to all members of the 
local 'Administrators' group including the local Administrator account (so just 
being an Admin doesn't allow un-audited and 'nearly invisible' access).
*       Use that same GPO to grant "Across-the-network-access" to all members 
of the 'unlimited' access roll up groups. Again, remember that there are 
normally only one or two service accounts (if even this many are necessary) in 
the groups.
*       Create a web application where your authorized support folks must go to 
'request' access (either Admin access or just Remote Desktop access). Have the 
web application manage adding and removing (automatically, say after 4 hours) 
the requestor's account from each devices access groups. [Note: Since 
membership in the access group controls across-the-network-access, then 'that' 
device can be accessed remotely, by that one support staff person, for the 
timeframe noted.] This web application can log all requests and everyone who 
needs to know can determine knows who requested access to which system and for 
how long they were granted the right to do so.

The elegance is that since the domain local groups are already on the devices, 
all that's needed is to grant the 'requestor' the ability to be added and 
removed to/from the group's membership (and that's under the control of the web 
app). This model does add a few minutes delay (< 3 minutes for us on average) 
while waiting for replication of the new group membership. But, once the 
support persons account is added to the correct group, the access request by 
the support person gets revalidated on-the-fly by the remote box and the new 
group SID membership is available for that 'remote' logon session. Therefore, 
neither the remote desktop/user has to reboot/re-logon, nor does the support 
person requesting have to do so.

Admittedly, this type of "system" takes a good while to test and set up. It 
also makes the most sense for either a large population of devices/users (and 
requirements must exist for 'down to the device' controls) or for auditable 
control and visibility for a very select number of devices/users requiring 
'high end' protection. We had both requirements and this is similar to what we 
can up with. [We actually do not have the requirement for non-administrators 
because our support personnel do not use "Remote Desktop" to access customer 
desktops ... we use another third party product for that. However, the concept 
is easily extendable.]

Jerry Cruz | Group Policies Product Manager | Windows Infrastructure 
Architecture | Boeing IT

-----Original Message-----
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On 
Behalf Of rpo
Sent: Friday, November 14, 2008 6:24 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: handling remote desktop

thanks omar, your feedback is appreciated.

daniel.


On 14/11/2008, Omar Droubi <omar@xxxxxxxxxxxxxxxxxxxxx> wrote:
> I would recommend that you do not mess with the Allow logon through terminal 
> services User right assignment.
>
> Instead for Remote desktop- I would be a proponent of your idea of creating a 
> domain GG and using GPO restricted groups to make the GG a member of the 
> local remote desktop users group.
>
> If you have a security concern- they you will need to address that by having 
> multiple domain GG groups and multiple RD GPO policies and segment your 
> computers with domain computer groups or in separate OUs
>
> As for remote assistance- I would try it out 1st to see how you like it- 
> Almost every time I tried to deploy remote assistance the performance was so 
> poor that we scrapped it. Anyway- if you do want to use it- RA is great on 
> terminal servers- but in a TS you can use TS remote control anyway- but that 
> is a different subject.
>
> Back to Remote assistance- I would use the Offer remote assistance setting in 
> a GPO and add a domain GG- just make sure you test it out as there is 
> something I can quite remember about it- like if you add groups 1,2 & 3 to 
> offer remote assistance that if you change it to groups 1 & 2 that 3 may 
> remain- but it has been while and that area of my brain is now archived.
>
> Also- don't forget to also use GPO to enable the RA for solicitation if you 
> desire that and to enable Remote desktop and then to make the necessary FW 
> modifications for both the domain and if necessary the standard FW profile 
> (or more for Vista) to allow for RA and RDP. RDP is easy- Remote Assistance 
> requires about 3 or 4 custom program and port rules in the FW policy to work.
>
>
> Omar Droubi
> omar@xxxxxxxxxxxxxxxxxxxxx
> 650-726-0300
> ________________________________________
> From: gptalk-bounce@xxxxxxxxxxxxx [gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of 
> rpo [rpo8373@xxxxxxxxx]
> Sent: Thursday, November 13, 2008 03:32 PM
> To: gptalk@xxxxxxxxxxxxx
> Subject: [gptalk] handling remote desktop
>
> hi all,
>
> i'm just curious how people here handle remote desktop and remote
> assistance in their organisation.
>
> we have a requirement for certain non-admin users to be able to remote
> desktop/offer remote assistance to machines on occasion.
>
> should i manually add the user to the local remote desktop users group
> on the machine, or should i enforce a policy? my issue with this is
> that it gives the user the ability to remote desktop to all machines.
> how risky is this?
>
> my plan was to create a domain group called 'rdp users' and modify the
> 'allow logon through terminal services' policy to incorporate this
> group. the domain group 'remote desktop users' in my understanding, is
> a builtin group and only applicable to dc's?
>
> as for remote assistance, i was simply going to create a 'remote
> assistance users' domain group and modify the offer remote assistance
> setting in the admin templates\system\remote assistance template.
>
> how does all this sound?
>
> daniel.
> ***********************
> You can unsubscribe from gptalk by sending email to 
> gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field OR by 
> logging into the freelists.org Web interface. Archives for the list are 
> available at http://www.freelists.org/archives/gptalk/
> ************************
> ***********************
> You can unsubscribe from gptalk by sending email to 
> gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field OR by 
> logging into the freelists.org Web interface. Archives for the list are 
> available at http://www.freelists.org/archives/gptalk/
> ************************
>
***********************
You can unsubscribe from gptalk by sending email to 
gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field OR by 
logging into the freelists.org Web interface. Archives for the list are 
available at http://www.freelists.org/archives/gptalk/
************************

Other related posts: