[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 //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 //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 //www.freelists.org/archives/gptalk/
************************
Other related posts:
