[gptalk] Re: handling remote desktop

  • From: Omar Droubi <omar@xxxxxxxxxxxxxxxxxxxxx>
  • To: "gptalk@xxxxxxxxxxxxx" <gptalk@xxxxxxxxxxxxx>
  • Date: Tue, 18 Nov 2008 16:10:23 -0800

Domain Local Group to a workstation local group- slick- Didn't know that 
works-but it does- thanks for clarifying!

I always just followed the practice of users in global groups- global groups to 
local groups - and local groups applied to the resource permissions- but I 
always used member server local groups and added the GG to those- when say 
applying permissions to a folder or a printer- but your config works well and 
does help make tracking/auditing much easier- and it does scale and migrate 
well.

thanks

Omar

From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On 
Behalf Of Cruz, Jerome L
Sent: Tuesday, November 18, 2008 2:01 PM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: handling remote desktop

Hello Omar....

Domain local groups are only in the domain and only apply to domain controllers.
If you mean that it requires a "domain" using Active Directory (versus a 
Workgroup environment), then yes. However, in a "domain" environment, "domain 
local groups" can be created in Active Directory, applied 'locally' to any 
workstation or member server in your domain, and are local to that particular 
domain. I have > 400,000 domain local security groups applied to various 
thousands of workstations and members servers without issue of any kind (as 
well as many thousands of Domain Global groups).

If you want to create groups that will be made members of member servers and 
workstations- these will need to be domain global security or domain universal 
security group
I disagree, see comments above.

Not sure  how for your 'For Admins" section with local domain groups- how you 
can apply this properly.
They are added as members of each devices local 'Administrators' security 
group. Basically, the computer startup script looks for and adds the matching 
(by name) domain local security group and adds it to its own local 
Administrators security group (e.g. if the PC is named '123456', then it looks 
for a security group named '123456Admin', located 'only' in the "controlled 
access" OU in Active Directory.

Also- using a computer startup script- well- that will only apply at 
workstation or server reboot- if the machine is connected to the network when 
starting up- and it may even need to be set to wait for network- to apply this 
properly.
Absolutely. It took us about 6 months to get fully deployed to all our 
workstation devices. We do 'not' use this model for servers. [Note: We do 
indeed use the 'Wait for the network' setting engaged and have done so since 
deploying our first Windows XP devices. However, that would not prevent it from 
being applied. As to being connected... good catch... The connection to the 
network was indeed something that affected us early on. Because the OS does not 
support running Computer Startup scripts after booting up, logging on, and then 
establishing a VPN session, we did have to write and deploy a small service to 
look for this situation for all our client systems and run the appropriate 
GPO-based Computer Startup scripts targeted at the device. We have had this 
capability since 2001. Highly recommended! Can't share the code...sorry :(.. 
but I have spoken to the Group Policy Team a couple of times about provided 
this kind of capability...we'd love to stop coding...still waiting.]

Using Restricted groups gives much better application of local group membership 
on domain member servers and workstations as it will apply and reapply at the 
update intervals.
That is true, however, the requirements as I stated were for control and 
audit-ability down to the 'individual' device level. Using a Restricted Groups 
policy setting would require a single policy object for 'each' device in the 
domain under those conditions. The point here is to push ideas out to others if 
they have similar requirements. Our requirements 'vastly' exceeded what was 
available from a GPO standpoint, so we adapted GPOs using a variety of methods 
to make them fit.

I am interested in looking into the "Across-the-network-access" setting- as I 
am not familiar with that one-thanks,
Computer Configuration\Windows Settings\Local Policies\User Rights Assignment
Deny access to this computer from the network

Jerry

From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On 
Behalf Of Omar Droubi
Sent: Tuesday, November 18, 2008 11:22 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: handling remote desktop

Domain local groups are only in the domain and only apply to domain controllers.

If you want to create groups that will be made members of member servers and 
workstations- these will need to be domain global security or domain universal 
security group

Not sure  how for your 'For Admins" section with local domain groups- how you 
can apply this properly.

Also- using a computer startup script- well- that will only apply at 
workstation or server reboot- if the machine is connected to the network when 
starting up- and it may even need to be set to wait for network- to apply this 
properly.

Using Restricted groups gives much better application of local group membership 
on domain member servers and workstations as it will apply and reapply at the 
update intervals.

I am interested in looking into the "Across-the-network-access" setting- as I 
am not familiar with that one-thanks,

Omar

From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On 
Behalf Of Cruz, Jerome L
Sent: Tuesday, November 18, 2008 9:26 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: handling remote desktop

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: