Guest powlaz Posted September 16, 2008 Posted September 16, 2008 We have an application or two that we run where the manufacturers recommends that any user be logged in as an administrator on the local PC. Being the good little lambs that we are we have always followed this rule. Anyway now that we are set up with a Terminal Server I am seeing, more than ever, why the need for each user to have local admin rights is such a concern. It looks to me like every user of the TS needs to be added to the local Remote Desktop Users group on the TS. In addition it seems I will need to make these users members of the Administrators group which unfortunately provides Admin rights to the Domain as well as the local PC. We don't use Group Policy yet. I'm interested in knowing what I"m supposed to do now. I certainly don't want these folks to have carte blanche on the network. Please help. MJ
Guest Lanwench [MVP - Exchange] Posted September 16, 2008 Posted September 16, 2008 Re: User Rights in TS powlaz <powlaz@discussions.microsoft.com> wrote: > We have an application or two that we run where the manufacturers > recommends that any user be logged in as an administrator on the > local PC. Being the good little lambs that we are we have always > followed this rule. Another (better) option, besides walloping the application vendor with a brickbat, is to find out where in the file system and/or registry their software expects access, and manually changing the permissions for same. ProcessMonitor (Sysinternals...now downloadable from MS) will help you do this. > > Anyway now that we are set up with a Terminal Server I am seeing, > more than ever, why the need for each user to have local admin > rights is such a concern. No idding! > It looks to me like every user of the TS > needs to be added to the local Remote Desktop Users group on the TS. Well, it's better to do this with an AD security group. I like to set up one called TSUsers. > In addition it seems I will need to make these users members of the > Administrators group which unfortunately provides Admin rights to the > Domain as well as the local PC. Then it sounds like your TS box is a DC - that's a big no-no. Your TS box should be a member server with no other roles. Don't let users log in to your DCs, ever. > > We don't use Group Policy yet. You'll want to. You need to lock down a lot. > I'm interested in knowing what I"m > supposed to do now. I certainly don't want these folks to have carte > blanche on the network. Absolutely! > > Please help. > > MJ I'm not a guru, but here's what I've learned along the way - Basics: you should be running Terminal Services on a dedicated member server with *no* other roles on the network. It should be set up in its own OU, with a policy specifically for TS (including loopback processing so that all users who log in get the same settings, regardless of their own inherited user policy settings). See KB 278295 for some good lockdown suggestions. Also see MVP Patrick Rouse's articles at http://www.sessioncomputing.com/articles.htm You'll still need to figure out what your rogue apps want access to, of course.
Guest powlaz Posted September 17, 2008 Posted September 17, 2008 Re: User Rights in TS Lanwench - thank you for the great answers. If I may, I have a couple of follow-up questions. I am aware of the things that require user permission changes relative to the two programs we have that require admin access. I wonder if there is a way to change the permissions of these directories and registry keys in a login script. Would you know? My TS server is not a DC. It is nothing other than a TS server. Although you did address another issue I have with exactly how I'm supposed to set up a subnet for the VPN that I am using for the TS (I guess making the TS a DC is out of the question). Anyway the statement I made about everyone being added to the local Admin group having full local and domain access is because this is the description of the group on the server. Seems pretty straight forward - if I add a user to this local group they will be local/domain admins. What don't I know? Is there some kind of automatic connection between the Remote Desktop Users group in AD and the TS server? Otherwise how does the TS Server know to authenticate the users in the AD group? Thanks for the reply and the help. Group Policy is the next project I tackle. Seems like a big one, especially since we've never had it and there are tons of policies. The sites you referenced should prove to be helpful. Thanks, MJ "Lanwench [MVP - Exchange]" wrote: > powlaz <powlaz@discussions.microsoft.com> wrote: > > We have an application or two that we run where the manufacturers > > recommends that any user be logged in as an administrator on the > > local PC. Being the good little lambs that we are we have always > > followed this rule. > > Another (better) option, besides walloping the application vendor with a > brickbat, is to find out where in the file system and/or registry their > software expects access, and manually changing the permissions for same. > ProcessMonitor (Sysinternals...now downloadable from MS) will help you do > this. > > > > Anyway now that we are set up with a Terminal Server I am seeing, > > more than ever, why the need for each user to have local admin > > rights is such a concern. > > No idding! > > > It looks to me like every user of the TS > > needs to be added to the local Remote Desktop Users group on the TS. > > Well, it's better to do this with an AD security group. I like to set up one > called TSUsers. > > > In addition it seems I will need to make these users members of the > > Administrators group which unfortunately provides Admin rights to the > > Domain as well as the local PC. > > Then it sounds like your TS box is a DC - that's a big no-no. Your TS box > should be a member server with no other roles. Don't let users log in to > your DCs, ever. > > > > We don't use Group Policy yet. > > You'll want to. You need to lock down a lot. > > > I'm interested in knowing what I"m > > supposed to do now. I certainly don't want these folks to have carte > > blanche on the network. > > Absolutely! > > > > Please help. > > > > MJ > > I'm not a guru, but here's what I've learned along the way - > > Basics: you should be running Terminal Services on a dedicated member server > with *no* other roles on the network. It should be set up in its own OU, > with a policy specifically for TS (including loopback processing so that all > users who log in get the same settings, regardless of > their own inherited user policy settings). See KB 278295 for some good > lockdown suggestions. Also see MVP Patrick Rouse's articles at > http://www.sessioncomputing.com/articles.htm > > > You'll still need to figure out what your rogue apps want access to, of > course. > > >
Guest Lanwench [MVP - Exchange] Posted September 17, 2008 Posted September 17, 2008 Re: User Rights in TS powlaz <powlaz@discussions.microsoft.com> wrote: > Lanwench - thank you for the great answers. If I may, I have a > couple of follow-up questions. > > I am aware of the things that require user permission changes > relative to the two programs we have that require admin access. I > wonder if there is a way to change the permissions of these > directories and registry keys in a login script. Would you know? Highly doubtful, as your users wouldn't have rights to make those changes, and the login script runs as the user. You'd need to make the file system & registry changes only once on the server anyway. > > My TS server is not a DC. It is nothing other than a TS server. That's good. > Although you did address another issue I have with exactly how I'm > supposed to set up a subnet for the VPN that I am using for the TS (I > guess making the TS a DC is out of the question). Yes, that's a bad idea. Why do you need a separate subnet, and VPN? > > Anyway the statement I made about everyone being added to the local > Admin group having full local and domain access is because this is > the description of the group on the server. If it's the local administrators group, no. > Seems pretty straight > forward - if I add a user to this local group they will be > local/domain admins. What don't I know? That would be true of the *domain* administrators group. A DC has no local groups, but a member server does. > > Is there some kind of automatic connection between the Remote Desktop > Users group in AD There isn't one by default > and the TS server? Otherwise how does the TS > Server know to authenticate the users in the AD group? The TS server needs to belong to the domain, and you would add the domain group "TS Users" (or whatever you create) to the *local* Remote Desktop Users group on the server. > > Thanks for the reply and the help. Group Policy is the next project I > tackle. Seems like a big one, especially since we've never had it > and there are tons of policies. The sites you referenced should > prove to be helpful. Definitely. Don't deploy this server til you've got that under your belt. > > Thanks, > > MJ > > "Lanwench [MVP - Exchange]" wrote: > >> powlaz <powlaz@discussions.microsoft.com> wrote: >>> We have an application or two that we run where the manufacturers >>> recommends that any user be logged in as an administrator on the >>> local PC. Being the good little lambs that we are we have always >>> followed this rule. >> >> Another (better) option, besides walloping the application vendor >> with a brickbat, is to find out where in the file system and/or >> registry their software expects access, and manually changing the >> permissions for same. ProcessMonitor (Sysinternals...now >> downloadable from MS) will help you do this. >>> >>> Anyway now that we are set up with a Terminal Server I am seeing, >>> more than ever, why the need for each user to have local admin >>> rights is such a concern. >> >> No idding! >> >>> It looks to me like every user of the TS >>> needs to be added to the local Remote Desktop Users group on the TS. >> >> Well, it's better to do this with an AD security group. I like to >> set up one called TSUsers. >> >>> In addition it seems I will need to make these users members of the >>> Administrators group which unfortunately provides Admin rights to >>> the Domain as well as the local PC. >> >> Then it sounds like your TS box is a DC - that's a big no-no. Your >> TS box should be a member server with no other roles. Don't let >> users log in to your DCs, ever. >>> >>> We don't use Group Policy yet. >> >> You'll want to. You need to lock down a lot. >> >>> I'm interested in knowing what I"m >>> supposed to do now. I certainly don't want these folks to have >>> carte blanche on the network. >> >> Absolutely! >>> >>> Please help. >>> >>> MJ >> >> I'm not a guru, but here's what I've learned along the way - >> >> Basics: you should be running Terminal Services on a dedicated >> member server with *no* other roles on the network. It should be set >> up in its own OU, with a policy specifically for TS (including >> loopback processing so that all users who log in get the same >> settings, regardless of >> their own inherited user policy settings). See KB 278295 for some >> good lockdown suggestions. Also see MVP Patrick Rouse's articles at >> http://www.sessioncomputing.com/articles.htm >> >> >> You'll still need to figure out what your rogue apps want access to, >> of course.
Guest powlaz Posted September 17, 2008 Posted September 17, 2008 Re: User Rights in TS OK - as far as setting those permissions goes, enabling full rights for the TSClients group on each directory is a piece of cake. However, granting those rights ito the registry keys is going to need to be done one user at a time, right? Or will it. Is it the entire registry that is created for each TS user or only the user-specific hives that are created? If the affected registry keys are Machine based this may be equally as easy. I am being instructed in multiple other forums to set my VPN up on a separate subnet from the LAN subnet because VPN clients are generally considered hostile. I am using the VPN because it is understood to be very secure, because my SonicWall Pro 2040 has it and because I have 10 free clients. I didn't bother reading about setting up an RDC session outside of a VPN so I have no idea how secure or reliable it is. I'm trying to get as close to the "Best Practices" way of doing things that I can. I'm certainly interested in anything you can contribute to this. Regarding the local Administrators group. I totally understand what you are saying. But I'm confused by the entry here: Computer Management > Local Users and Groups> Groups Administrator: Administrators have complete and unrestricted access to the computer/domain. It reads like everyone who is added to this group will have full domain access. Scares the bejesus out of me. Your saying that because they are not designated as Domain Admins on my DC then this is not the case, right? Microsoft should change the description. Regarding the TS server and AD link - thanks for your reply about adding TSClients group from AD to the local Remote Desktop User group. Brain fart . .. . Regarding deploying the server without Group Policy active. We currently don't use GP and have been OK. That's not to say we can't be better, but we've been OK. Will letting users work on the TS w/out GP in place be any different or worse than having evey other user on the LAN unrestricted by GPOs? To conclude this post I'd just like to comment about my qualifications for setting up TS and otherwise administering to the network. I don't have any. Business is down and there's a freeze on spending that includes paying the consultants who usually help with this stuff. I'm muddling through and I truly appreciate your guidance. MJ "Lanwench [MVP - Exchange]" wrote: > powlaz <powlaz@discussions.microsoft.com> wrote: > > Lanwench - thank you for the great answers. If I may, I have a > > couple of follow-up questions. > > > > I am aware of the things that require user permission changes > > relative to the two programs we have that require admin access. I > > wonder if there is a way to change the permissions of these > > directories and registry keys in a login script. Would you know? > > Highly doubtful, as your users wouldn't have rights to make those changes, > and the login script runs as the user. You'd need to make the file system & > registry changes only once on the server anyway. > > > > My TS server is not a DC. It is nothing other than a TS server. > > That's good. > > > Although you did address another issue I have with exactly how I'm > > supposed to set up a subnet for the VPN that I am using for the TS (I > > guess making the TS a DC is out of the question). > > Yes, that's a bad idea. Why do you need a separate subnet, and VPN? > > > > Anyway the statement I made about everyone being added to the local > > Admin group having full local and domain access is because this is > > the description of the group on the server. > > If it's the local administrators group, no. > > > Seems pretty straight > > forward - if I add a user to this local group they will be > > local/domain admins. What don't I know? > > That would be true of the *domain* administrators group. A DC has no local > groups, but a member server does. > > > > Is there some kind of automatic connection between the Remote Desktop > > Users group in AD > > There isn't one by default > > > and the TS server? Otherwise how does the TS > > Server know to authenticate the users in the AD group? > > The TS server needs to belong to the domain, and you would add the domain > group "TS Users" (or whatever you create) to the *local* Remote Desktop > Users group on the server. > > > > Thanks for the reply and the help. Group Policy is the next project I > > tackle. Seems like a big one, especially since we've never had it > > and there are tons of policies. The sites you referenced should > > prove to be helpful. > > Definitely. Don't deploy this server til you've got that under your belt. > > > > Thanks, > > > > MJ > > > > "Lanwench [MVP - Exchange]" wrote: > > > >> powlaz <powlaz@discussions.microsoft.com> wrote: > >>> We have an application or two that we run where the manufacturers > >>> recommends that any user be logged in as an administrator on the > >>> local PC. Being the good little lambs that we are we have always > >>> followed this rule. > >> > >> Another (better) option, besides walloping the application vendor > >> with a brickbat, is to find out where in the file system and/or > >> registry their software expects access, and manually changing the > >> permissions for same. ProcessMonitor (Sysinternals...now > >> downloadable from MS) will help you do this. > >>> > >>> Anyway now that we are set up with a Terminal Server I am seeing, > >>> more than ever, why the need for each user to have local admin > >>> rights is such a concern. > >> > >> No idding! > >> > >>> It looks to me like every user of the TS > >>> needs to be added to the local Remote Desktop Users group on the TS. > >> > >> Well, it's better to do this with an AD security group. I like to > >> set up one called TSUsers. > >> > >>> In addition it seems I will need to make these users members of the > >>> Administrators group which unfortunately provides Admin rights to > >>> the Domain as well as the local PC. > >> > >> Then it sounds like your TS box is a DC - that's a big no-no. Your > >> TS box should be a member server with no other roles. Don't let > >> users log in to your DCs, ever. > >>> > >>> We don't use Group Policy yet. > >> > >> You'll want to. You need to lock down a lot. > >> > >>> I'm interested in knowing what I"m > >>> supposed to do now. I certainly don't want these folks to have > >>> carte blanche on the network. > >> > >> Absolutely! > >>> > >>> Please help. > >>> > >>> MJ > >> > >> I'm not a guru, but here's what I've learned along the way - > >> > >> Basics: you should be running Terminal Services on a dedicated > >> member server with *no* other roles on the network. It should be set > >> up in its own OU, with a policy specifically for TS (including > >> loopback processing so that all users who log in get the same > >> settings, regardless of > >> their own inherited user policy settings). See KB 278295 for some > >> good lockdown suggestions. Also see MVP Patrick Rouse's articles at > >> http://www.sessioncomputing.com/articles.htm > >> > >> > >> You'll still need to figure out what your rogue apps want access to, > >> of course. > > > >
Guest Lanwench [MVP - Exchange] Posted September 17, 2008 Posted September 17, 2008 Re: User Rights in TS powlaz <powlaz@discussions.microsoft.com> wrote: > OK - as far as setting those permissions goes, enabling full rights > for the TSClients group on each directory is a piece of cake. Sure, although I'd set it to the built-in local Users group, probably > However, granting those rights ito the registry keys is going to need > to be done one user at a time, right? Or will it. Depends on where in the registry it is. If its HKCU, yes. > Is it the entire > registry that is created for each TS user or only the user-specific > hives that are created? It's the same as a workstation. The most important ones will be, HKLM, HKU, and HKCU. This depends entirely on the app. > If the affected registry keys are Machine > based this may be equally as easy. Yes. > > I am being instructed in multiple other forums to set my VPN up on a > separate subnet from the LAN subnet because VPN clients are generally > considered hostile. ] Eh? > I am using the VPN because it is understood to > be very secure, because my SonicWall Pro 2040 has it and because I > have 10 free clients. Sure, although I'd probably use a Sonicwall SSL-VPN appliance if I wanted VPN for TS. > I didn't bother reading about setting up an > RDC session outside of a VPN so I have no idea how secure or reliable > it is. Pretty darned secure and very reliable. > I'm trying to get as close to the "Best Practices" way of > doing things that I can. I'm certainly interested in anything you > can contribute to this. You can use VPN, but you don't have to... > > Regarding the local Administrators group. I totally understand what > you are saying. But I'm confused by the entry here: > Computer Management > Local Users and Groups> Groups > Administrator: Administrators have complete and unrestricted access > to the computer/domain. Ah. Well, domain admins *can*. A local user or group has *no* network privileges whatsoever. > > It reads like everyone who is added to this group will have full > domain access. No, these are local groups. > Scares the bejesus out of me. Your saying that > because they are not designated as Domain Admins on my DC then this > is not the case, right? Microsoft should change the description. That's the case. The group Administrators, as a word, could include domain administrators. > > Regarding the TS server and AD link - thanks for your reply about > adding TSClients group from AD to the local Remote Desktop User > group. Brain fart . . . No prob. > > Regarding deploying the server without Group Policy active. We > currently don't use GP and have been OK. That's not to say we can't > be better, but we've been OK. Will letting users work on the TS > w/out GP in place be any different or worse than having evey other > user on the LAN unrestricted by GPOs? You're running a huge risk by not locking down this server by group policy, because if you have multiple users logged in, and one user screws up something, it screws everyone. A workstation used by one user at a time is less of a concern. Read the docs & do set up policies to protect this server before you let people use it - it's important, and not that hard. You could also get a consultant in to help you out with it. > > To conclude this post I'd just like to comment about my > qualifications for setting up TS and otherwise administering to the > network. I don't have any. No worries ;-) > Business is down and there's a freeze on > spending that includes paying the consultants who usually help with > this stuff. You might remind your company management that it costs significantly more to re-do things that blow up, than to do them right the first time. How much would it cost for a couple of hours of expert consuling time for all this? $300? Seems like money well spent to me. Even if I have a limited budget for auto repair, and can change my own oil, I'm not going to attempt to rebuild my own transmission. I'm just saying. ' > I'm muddling through and I truly appreciate your > guidance. No problem. Download & install the group policy management console (GPMC) on your domain controller if you don't have it already. It's very handy for modeling/experimenting with settings. The main thing to do is ensure that you don't lock yourself (as admin) out when you're trying to lock out your users! Try subscribing to microsoft.public.windows.group_policy and perhaps check out http://www.amazon.com/Group-Policy-Fundamentals-Security-Troubleshooting/dp/0470275898/ref=sr_1_1?ie=UTF8&s=books&qid=1221689092&sr=1-1. > > MJ > > "Lanwench [MVP - Exchange]" wrote: > >> powlaz <powlaz@discussions.microsoft.com> wrote: >>> Lanwench - thank you for the great answers. If I may, I have a >>> couple of follow-up questions. >>> >>> I am aware of the things that require user permission changes >>> relative to the two programs we have that require admin access. I >>> wonder if there is a way to change the permissions of these >>> directories and registry keys in a login script. Would you know? >> >> Highly doubtful, as your users wouldn't have rights to make those >> changes, and the login script runs as the user. You'd need to make >> the file system & registry changes only once on the server anyway. >>> >>> My TS server is not a DC. It is nothing other than a TS server. >> >> That's good. >> >>> Although you did address another issue I have with exactly how I'm >>> supposed to set up a subnet for the VPN that I am using for the TS >>> (I guess making the TS a DC is out of the question). >> >> Yes, that's a bad idea. Why do you need a separate subnet, and VPN? >>> >>> Anyway the statement I made about everyone being added to the local >>> Admin group having full local and domain access is because this is >>> the description of the group on the server. >> >> If it's the local administrators group, no. >> >>> Seems pretty straight >>> forward - if I add a user to this local group they will be >>> local/domain admins. What don't I know? >> >> That would be true of the *domain* administrators group. A DC has no >> local groups, but a member server does. >>> >>> Is there some kind of automatic connection between the Remote >>> Desktop Users group in AD >> >> There isn't one by default >> >>> and the TS server? Otherwise how does the TS >>> Server know to authenticate the users in the AD group? >> >> The TS server needs to belong to the domain, and you would add the >> domain group "TS Users" (or whatever you create) to the *local* >> Remote Desktop Users group on the server. >>> >>> Thanks for the reply and the help. Group Policy is the next >>> project I tackle. Seems like a big one, especially since we've >>> never had it and there are tons of policies. The sites you >>> referenced should prove to be helpful. >> >> Definitely. Don't deploy this server til you've got that under your >> belt. >>> >>> Thanks, >>> >>> MJ >>> >>> "Lanwench [MVP - Exchange]" wrote: >>> >>>> powlaz <powlaz@discussions.microsoft.com> wrote: >>>>> We have an application or two that we run where the manufacturers >>>>> recommends that any user be logged in as an administrator on the >>>>> local PC. Being the good little lambs that we are we have always >>>>> followed this rule. >>>> >>>> Another (better) option, besides walloping the application vendor >>>> with a brickbat, is to find out where in the file system and/or >>>> registry their software expects access, and manually changing the >>>> permissions for same. ProcessMonitor (Sysinternals...now >>>> downloadable from MS) will help you do this. >>>>> >>>>> Anyway now that we are set up with a Terminal Server I am seeing, >>>>> more than ever, why the need for each user to have local admin >>>>> rights is such a concern. >>>> >>>> No idding! >>>> >>>>> It looks to me like every user of the TS >>>>> needs to be added to the local Remote Desktop Users group on the >>>>> TS. >>>> >>>> Well, it's better to do this with an AD security group. I like to >>>> set up one called TSUsers. >>>> >>>>> In addition it seems I will need to make these users members of >>>>> the Administrators group which unfortunately provides Admin >>>>> rights to the Domain as well as the local PC. >>>> >>>> Then it sounds like your TS box is a DC - that's a big no-no. Your >>>> TS box should be a member server with no other roles. Don't let >>>> users log in to your DCs, ever. >>>>> >>>>> We don't use Group Policy yet. >>>> >>>> You'll want to. You need to lock down a lot. >>>> >>>>> I'm interested in knowing what I"m >>>>> supposed to do now. I certainly don't want these folks to have >>>>> carte blanche on the network. >>>> >>>> Absolutely! >>>>> >>>>> Please help. >>>>> >>>>> MJ >>>> >>>> I'm not a guru, but here's what I've learned along the way - >>>> >>>> Basics: you should be running Terminal Services on a dedicated >>>> member server with *no* other roles on the network. It should be >>>> set up in its own OU, with a policy specifically for TS (including >>>> loopback processing so that all users who log in get the same >>>> settings, regardless of >>>> their own inherited user policy settings). See KB 278295 for some >>>> good lockdown suggestions. Also see MVP Patrick Rouse's articles at >>>> http://www.sessioncomputing.com/articles.htm >>>> >>>> >>>> You'll still need to figure out what your rogue apps want access >>>> to, of course.
Guest powlaz Posted September 18, 2008 Posted September 18, 2008 Re: User Rights in TS Lanwench, thanks to your help I'm moving along. I took care of the file and registry permission changes that I needed to make. The registry key that I needed to modify was an HKLM key (yeah!). Everything worked. Your comment "Eh?" regarding the direction I've been given to set up a different subnet for VPN clients is intriguing. Will you elaborate? Is it not a best practice or is it an old logic or an unecessary step to separate VPN subnets and LAN subnets??? Regarding you comment about one user ruining things for all users if something goes wrong in their session troubles me. I was working under the impression that TS on Server 2003 natively prevents one bad session from crashing or corrupting the others - not that Group Policy puts this protection into place. I have the GPO Management tool already installed on my DC. I also plan to explore the GPO Accelerator that Microsoft puts out because I like the idea of having 'Best Practices' level security in the click of a button. Is there such a thing as prepacked GPOs or a GPO exchange? I would love to be able to just import solid GPOs . . . I got approval for the book you recommended this morning - much obliged. MJ "Lanwench [MVP - Exchange]" wrote: > powlaz <powlaz@discussions.microsoft.com> wrote: > > OK - as far as setting those permissions goes, enabling full rights > > for the TSClients group on each directory is a piece of cake. > > Sure, although I'd set it to the built-in local Users group, probably > > > However, granting those rights ito the registry keys is going to need > > to be done one user at a time, right? Or will it. > > Depends on where in the registry it is. If its HKCU, yes. > > > Is it the entire > > registry that is created for each TS user or only the user-specific > > hives that are created? > > It's the same as a workstation. The most important ones will be, HKLM, HKU, > and HKCU. This depends entirely on the app. > > > If the affected registry keys are Machine > > based this may be equally as easy. > > Yes. > > > > I am being instructed in multiple other forums to set my VPN up on a > > separate subnet from the LAN subnet because VPN clients are generally > > considered hostile. > ] > Eh? > > > I am using the VPN because it is understood to > > be very secure, because my SonicWall Pro 2040 has it and because I > > have 10 free clients. > > Sure, although I'd probably use a Sonicwall SSL-VPN appliance if I wanted > VPN for TS. > > > I didn't bother reading about setting up an > > RDC session outside of a VPN so I have no idea how secure or reliable > > it is. > > Pretty darned secure and very reliable. > > > I'm trying to get as close to the "Best Practices" way of > > doing things that I can. I'm certainly interested in anything you > > can contribute to this. > > You can use VPN, but you don't have to... > > > > Regarding the local Administrators group. I totally understand what > > you are saying. But I'm confused by the entry here: > > Computer Management > Local Users and Groups> Groups > > Administrator: Administrators have complete and unrestricted access > > to the computer/domain. > > Ah. Well, domain admins *can*. A local user or group has *no* network > privileges whatsoever. > > > > It reads like everyone who is added to this group will have full > > domain access. > > No, these are local groups. > > > Scares the bejesus out of me. Your saying that > > because they are not designated as Domain Admins on my DC then this > > is not the case, right? Microsoft should change the description. > > That's the case. The group Administrators, as a word, could include domain > administrators. > > > > Regarding the TS server and AD link - thanks for your reply about > > adding TSClients group from AD to the local Remote Desktop User > > group. Brain fart . . . > > No prob. > > > > Regarding deploying the server without Group Policy active. We > > currently don't use GP and have been OK. That's not to say we can't > > be better, but we've been OK. Will letting users work on the TS > > w/out GP in place be any different or worse than having evey other > > user on the LAN unrestricted by GPOs? > > You're running a huge risk by not locking down this server by group policy, > because if you have multiple users logged in, and one user screws up > something, it screws everyone. A workstation used by one user at a time is > less of a concern. Read the docs & do set up policies to protect this server > before you let people use it - it's important, and not that hard. You could > also get a consultant in to help you out with it. > > > > To conclude this post I'd just like to comment about my > > qualifications for setting up TS and otherwise administering to the > > network. I don't have any. > > No worries ;-) > > > Business is down and there's a freeze on > > spending that includes paying the consultants who usually help with > > this stuff. > > You might remind your company management that it costs significantly more to > re-do things that blow up, than to do them right the first time. How much > would it cost for a couple of hours of expert consuling time for all this? > $300? Seems like money well spent to me. Even if I have a limited budget for > auto repair, and can change my own oil, I'm not going to attempt to rebuild > my own transmission. I'm just saying. > ' > > > I'm muddling through and I truly appreciate your > > guidance. > > No problem. Download & install the group policy management console (GPMC) on > your domain controller if you don't have it already. It's very handy for > modeling/experimenting with settings. The main thing to do is ensure that > you don't lock yourself (as admin) out when you're trying to lock out your > users! > > Try subscribing to microsoft.public.windows.group_policy and perhaps check > out > http://www.amazon.com/Group-Policy-Fundamentals-Security-Troubleshooting/dp/0470275898/ref=sr_1_1?ie=UTF8&s=books&qid=1221689092&sr=1-1. > > > > MJ > > > > "Lanwench [MVP - Exchange]" wrote: > > > >> powlaz <powlaz@discussions.microsoft.com> wrote: > >>> Lanwench - thank you for the great answers. If I may, I have a > >>> couple of follow-up questions. > >>> > >>> I am aware of the things that require user permission changes > >>> relative to the two programs we have that require admin access. I > >>> wonder if there is a way to change the permissions of these > >>> directories and registry keys in a login script. Would you know? > >> > >> Highly doubtful, as your users wouldn't have rights to make those > >> changes, and the login script runs as the user. You'd need to make > >> the file system & registry changes only once on the server anyway. > >>> > >>> My TS server is not a DC. It is nothing other than a TS server. > >> > >> That's good. > >> > >>> Although you did address another issue I have with exactly how I'm > >>> supposed to set up a subnet for the VPN that I am using for the TS > >>> (I guess making the TS a DC is out of the question). > >> > >> Yes, that's a bad idea. Why do you need a separate subnet, and VPN? > >>> > >>> Anyway the statement I made about everyone being added to the local > >>> Admin group having full local and domain access is because this is > >>> the description of the group on the server. > >> > >> If it's the local administrators group, no. > >> > >>> Seems pretty straight > >>> forward - if I add a user to this local group they will be > >>> local/domain admins. What don't I know? > >> > >> That would be true of the *domain* administrators group. A DC has no > >> local groups, but a member server does. > >>> > >>> Is there some kind of automatic connection between the Remote > >>> Desktop Users group in AD > >> > >> There isn't one by default > >> > >>> and the TS server? Otherwise how does the TS > >>> Server know to authenticate the users in the AD group? > >> > >> The TS server needs to belong to the domain, and you would add the > >> domain group "TS Users" (or whatever you create) to the *local* > >> Remote Desktop Users group on the server. > >>> > >>> Thanks for the reply and the help. Group Policy is the next > >>> project I tackle. Seems like a big one, especially since we've > >>> never had it and there are tons of policies. The sites you > >>> referenced should prove to be helpful. > >> > >> Definitely. Don't deploy this server til you've got that under your > >> belt. > >>> > >>> Thanks, > >>> > >>> MJ > >>> > >>> "Lanwench [MVP - Exchange]" wrote: > >>> > >>>> powlaz <powlaz@discussions.microsoft.com> wrote: > >>>>> We have an application or two that we run where the manufacturers > >>>>> recommends that any user be logged in as an administrator on the > >>>>> local PC. Being the good little lambs that we are we have always > >>>>> followed this rule. > >>>> > >>>> Another (better) option, besides walloping the application vendor > >>>> with a brickbat, is to find out where in the file system and/or > >>>> registry their software expects access, and manually changing the > >>>> permissions for same. ProcessMonitor (Sysinternals...now > >>>> downloadable from MS) will help you do this. > >>>>> > >>>>> Anyway now that we are set up with a Terminal Server I am seeing, > >>>>> more than ever, why the need for each user to have local admin > >>>>> rights is such a concern. > >>>> > >>>> No idding! > >>>> > >>>>> It looks to me like every user of the TS > >>>>> needs to be added to the local Remote Desktop Users group on the > >>>>> TS. > >>>> > >>>> Well, it's better to do this with an AD security group. I like to > >>>> set up one called TSUsers. > >>>> > >>>>> In addition it seems I will need to make these users members of > >>>>> the Administrators group which unfortunately provides Admin > >>>>> rights to the Domain as well as the local PC. > >>>> > >>>> Then it sounds like your TS box is a DC - that's a big no-no. Your > >>>> TS box should be a member server with no other roles. Don't let > >>>> users log in to your DCs, ever. > >>>>> > >>>>> We don't use Group Policy yet. > >>>> > >>>> You'll want to. You need to lock down a lot. > >>>> > >>>>> I'm interested in knowing what I"m > >>>>> supposed to do now. I certainly don't want these folks to have > >>>>> carte blanche on the network. > >>>> > >>>> Absolutely! > >>>>> > >>>>> Please help. > >>>>> > >>>>> MJ > >>>> > >>>> I'm not a guru, but here's what I've learned along the way - > >>>> > >>>> Basics: you should be running Terminal Services on a dedicated > >>>> member server with *no* other roles on the network. It should be > >>>> set up in its own OU, with a policy specifically for TS (including > >>>> loopback processing so that all users who log in get the same > >>>> settings, regardless of > >>>> their own inherited user policy settings). See KB 278295 for some > >>>> good lockdown suggestions. Also see MVP Patrick Rouse's articles at > >>>> http://www.sessioncomputing.com/articles.htm > >>>> > >>>> > >>>> You'll still need to figure out what your rogue apps want access > >>>> to, of course. > > > >
Guest Lanwench [MVP - Exchange] Posted September 18, 2008 Posted September 18, 2008 Re: User Rights in TS powlaz <powlaz@discussions.microsoft.com> wrote: > Lanwench, thanks to your help I'm moving along. I took care of the > file and registry permission changes that I needed to make. The > registry key that I needed to modify was an HKLM key (yeah!). > Everything worked. That's wonderful - now you can do the same thing on your workstations & revoke the admin rights there, too. > > Your comment "Eh?" regarding the direction I've been given to set up a > different subnet for VPN clients is intriguing. Will you elaborate? > Is it not a best practice or is it an old logic or an unecessary step > to separate VPN subnets and LAN subnets??? I guess I'm asking why use VPN at all. > > Regarding you comment about one user ruining things for all users if > something goes wrong in their session troubles me. I was working > under the impression that TS on Server 2003 natively prevents one bad > session from crashing or corrupting the others - not that Group > Policy puts this protection into place. Nope. It's a big fat shared workstation. Someone buggers up your software, it's a mess for everyone. > > I have the GPO Management tool already installed on my DC. I also > plan to explore the GPO Accelerator that Microsoft puts out because I > like the idea of having 'Best Practices' level security in the click > of a button. Is there such a thing as prepacked GPOs or a GPO > exchange? I would love to be able to just import solid GPOs . . . I'm not sure, honestly. Subscribe to m.p.windows.group_policy and ask there. > > I got approval for the book you recommended this morning - much > obliged. Glad to hear it. Have fun storming the castle! > > MJ > > "Lanwench [MVP - Exchange]" wrote: > >> powlaz <powlaz@discussions.microsoft.com> wrote: >>> OK - as far as setting those permissions goes, enabling full rights >>> for the TSClients group on each directory is a piece of cake. >> >> Sure, although I'd set it to the built-in local Users group, probably >> >>> However, granting those rights ito the registry keys is going to >>> need to be done one user at a time, right? Or will it. >> >> Depends on where in the registry it is. If its HKCU, yes. >> >>> Is it the entire >>> registry that is created for each TS user or only the user-specific >>> hives that are created? >> >> It's the same as a workstation. The most important ones will be, >> HKLM, HKU, and HKCU. This depends entirely on the app. >> >>> If the affected registry keys are Machine >>> based this may be equally as easy. >> >> Yes. >>> >>> I am being instructed in multiple other forums to set my VPN up on a >>> separate subnet from the LAN subnet because VPN clients are >>> generally considered hostile. >> ] >> Eh? >> >>> I am using the VPN because it is understood to >>> be very secure, because my SonicWall Pro 2040 has it and because I >>> have 10 free clients. >> >> Sure, although I'd probably use a Sonicwall SSL-VPN appliance if I >> wanted VPN for TS. >> >>> I didn't bother reading about setting up an >>> RDC session outside of a VPN so I have no idea how secure or >>> reliable it is. >> >> Pretty darned secure and very reliable. >> >>> I'm trying to get as close to the "Best Practices" way of >>> doing things that I can. I'm certainly interested in anything you >>> can contribute to this. >> >> You can use VPN, but you don't have to... >>> >>> Regarding the local Administrators group. I totally understand what >>> you are saying. But I'm confused by the entry here: >>> Computer Management > Local Users and Groups> Groups >>> Administrator: Administrators have complete and unrestricted access >>> to the computer/domain. >> >> Ah. Well, domain admins *can*. A local user or group has *no* network >> privileges whatsoever. >>> >>> It reads like everyone who is added to this group will have full >>> domain access. >> >> No, these are local groups. >> >>> Scares the bejesus out of me. Your saying that >>> because they are not designated as Domain Admins on my DC then this >>> is not the case, right? Microsoft should change the description. >> >> That's the case. The group Administrators, as a word, could include >> domain administrators. >>> >>> Regarding the TS server and AD link - thanks for your reply about >>> adding TSClients group from AD to the local Remote Desktop User >>> group. Brain fart . . . >> >> No prob. >>> >>> Regarding deploying the server without Group Policy active. We >>> currently don't use GP and have been OK. That's not to say we can't >>> be better, but we've been OK. Will letting users work on the TS >>> w/out GP in place be any different or worse than having evey other >>> user on the LAN unrestricted by GPOs? >> >> You're running a huge risk by not locking down this server by group >> policy, because if you have multiple users logged in, and one user >> screws up something, it screws everyone. A workstation used by one >> user at a time is less of a concern. Read the docs & do set up >> policies to protect this server before you let people use it - it's >> important, and not that hard. You could also get a consultant in to >> help you out with it. >>> >>> To conclude this post I'd just like to comment about my >>> qualifications for setting up TS and otherwise administering to the >>> network. I don't have any. >> >> No worries ;-) >> >>> Business is down and there's a freeze on >>> spending that includes paying the consultants who usually help with >>> this stuff. >> >> You might remind your company management that it costs significantly >> more to re-do things that blow up, than to do them right the first >> time. How much would it cost for a couple of hours of expert >> consuling time for all this? $300? Seems like money well spent to >> me. Even if I have a limited budget for auto repair, and can change >> my own oil, I'm not going to attempt to rebuild my own transmission. >> I'm just saying. ' >> >>> I'm muddling through and I truly appreciate your >>> guidance. >> >> No problem. Download & install the group policy management console >> (GPMC) on your domain controller if you don't have it already. It's >> very handy for modeling/experimenting with settings. The main thing >> to do is ensure that you don't lock yourself (as admin) out when >> you're trying to lock out your users! >> >> Try subscribing to microsoft.public.windows.group_policy and perhaps >> check out >> http://www.amazon.com/Group-Policy-Fundamentals-Security-Troubleshooting/dp/0470275898/ref=sr_1_1?ie=UTF8&s=books&qid=1221689092&sr=1-1. >>> >>> MJ >>> >>> "Lanwench [MVP - Exchange]" wrote: >>> >>>> powlaz <powlaz@discussions.microsoft.com> wrote: >>>>> Lanwench - thank you for the great answers. If I may, I have a >>>>> couple of follow-up questions. >>>>> >>>>> I am aware of the things that require user permission changes >>>>> relative to the two programs we have that require admin access. I >>>>> wonder if there is a way to change the permissions of these >>>>> directories and registry keys in a login script. Would you know? >>>> >>>> Highly doubtful, as your users wouldn't have rights to make those >>>> changes, and the login script runs as the user. You'd need to make >>>> the file system & registry changes only once on the server anyway. >>>>> >>>>> My TS server is not a DC. It is nothing other than a TS server. >>>> >>>> That's good. >>>> >>>>> Although you did address another issue I have with exactly how I'm >>>>> supposed to set up a subnet for the VPN that I am using for the TS >>>>> (I guess making the TS a DC is out of the question). >>>> >>>> Yes, that's a bad idea. Why do you need a separate subnet, and >>>> VPN? >>>>> >>>>> Anyway the statement I made about everyone being added to the >>>>> local Admin group having full local and domain access is because >>>>> this is the description of the group on the server. >>>> >>>> If it's the local administrators group, no. >>>> >>>>> Seems pretty straight >>>>> forward - if I add a user to this local group they will be >>>>> local/domain admins. What don't I know? >>>> >>>> That would be true of the *domain* administrators group. A DC has >>>> no local groups, but a member server does. >>>>> >>>>> Is there some kind of automatic connection between the Remote >>>>> Desktop Users group in AD >>>> >>>> There isn't one by default >>>> >>>>> and the TS server? Otherwise how does the TS >>>>> Server know to authenticate the users in the AD group? >>>> >>>> The TS server needs to belong to the domain, and you would add the >>>> domain group "TS Users" (or whatever you create) to the *local* >>>> Remote Desktop Users group on the server. >>>>> >>>>> Thanks for the reply and the help. Group Policy is the next >>>>> project I tackle. Seems like a big one, especially since we've >>>>> never had it and there are tons of policies. The sites you >>>>> referenced should prove to be helpful. >>>> >>>> Definitely. Don't deploy this server til you've got that under your >>>> belt. >>>>> >>>>> Thanks, >>>>> >>>>> MJ >>>>> >>>>> "Lanwench [MVP - Exchange]" wrote: >>>>> >>>>>> powlaz <powlaz@discussions.microsoft.com> wrote: >>>>>>> We have an application or two that we run where the >>>>>>> manufacturers recommends that any user be logged in as an >>>>>>> administrator on the local PC. Being the good little lambs >>>>>>> that we are we have always followed this rule. >>>>>> >>>>>> Another (better) option, besides walloping the application vendor >>>>>> with a brickbat, is to find out where in the file system and/or >>>>>> registry their software expects access, and manually changing the >>>>>> permissions for same. ProcessMonitor (Sysinternals...now >>>>>> downloadable from MS) will help you do this. >>>>>>> >>>>>>> Anyway now that we are set up with a Terminal Server I am >>>>>>> seeing, more than ever, why the need for each user to have >>>>>>> local admin rights is such a concern. >>>>>> >>>>>> No idding! >>>>>> >>>>>>> It looks to me like every user of the TS >>>>>>> needs to be added to the local Remote Desktop Users group on the >>>>>>> TS. >>>>>> >>>>>> Well, it's better to do this with an AD security group. I like to >>>>>> set up one called TSUsers. >>>>>> >>>>>>> In addition it seems I will need to make these users members of >>>>>>> the Administrators group which unfortunately provides Admin >>>>>>> rights to the Domain as well as the local PC. >>>>>> >>>>>> Then it sounds like your TS box is a DC - that's a big no-no. >>>>>> Your TS box should be a member server with no other roles. Don't >>>>>> let users log in to your DCs, ever. >>>>>>> >>>>>>> We don't use Group Policy yet. >>>>>> >>>>>> You'll want to. You need to lock down a lot. >>>>>> >>>>>>> I'm interested in knowing what I"m >>>>>>> supposed to do now. I certainly don't want these folks to have >>>>>>> carte blanche on the network. >>>>>> >>>>>> Absolutely! >>>>>>> >>>>>>> Please help. >>>>>>> >>>>>>> MJ >>>>>> >>>>>> I'm not a guru, but here's what I've learned along the way - >>>>>> >>>>>> Basics: you should be running Terminal Services on a dedicated >>>>>> member server with *no* other roles on the network. It should be >>>>>> set up in its own OU, with a policy specifically for TS >>>>>> (including loopback processing so that all users who log in get >>>>>> the same settings, regardless of >>>>>> their own inherited user policy settings). See KB 278295 for some >>>>>> good lockdown suggestions. Also see MVP Patrick Rouse's articles >>>>>> at http://www.sessioncomputing.com/articles.htm >>>>>> >>>>>> >>>>>> You'll still need to figure out what your rogue apps want access >>>>>> to, of course.
Recommended Posts