[gptalk] Re: handling remote desktop
- From: rpo <rpo8373@xxxxxxxxx>
- To: gptalk@xxxxxxxxxxxxx
- Date: Wed, 19 Nov 2008 10:44:33 +1000
hi guys,
i appreciate all the suggestions. jerry your particular setup is just amazing.
although since our business is only 1000 workstations in size, i think
i will be sticking to a simpler setup and just use the restricted
groups via gpo.
on a side note, i must say that even after reading a few articles, i
can't figure out the point of domain local groups vs. domain global
groups. we don't use local groups here, only global.
daniel.
On 19/11/2008, Omar Droubi <omar@xxxxxxxxxxxxxxxxxxxxx> wrote:
>
>
>
> 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 L.. 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/
>
>
> ************************
>
>
>
***********************
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:
