TECH B
asked on
Terminal Server 2003 Group Policy - "to log on to this remote computer" - Security Groups
I'm trying to establish a second organizational group that contains a second Security Group (call them orgB and secB). But none of the users I set up in the new Security Group (secB) can log in to the Terminal Server.
There is an established organizational group and security group (call them orgA and secA) that works fine - any user set up in secA can log in fine - and the group policy tied to this organizational group is applied correctly. Below is the configuration chain for the working set up.
Organizational group (OrgA) => User added => User is Member of Security group (secA) => Then the security group (SecA) is a member remote desktop users. There is a GPO assigned to OrgA.
I have attempted to duplicate the settings of the set up that is working - except for different names on the organizational group, security group, and GPO. I'm creating new users and I can get them to log in successfully only when they are a member of the Security group A.
I'm running two boxes. The first is a domain controller running server 2003. The second is a terminal server running server 2003.
I've checked the common items that I've found in the knowledge base. Everything seems to be identical.
There is an established organizational group and security group (call them orgA and secA) that works fine - any user set up in secA can log in fine - and the group policy tied to this organizational group is applied correctly. Below is the configuration chain for the working set up.
Organizational group (OrgA) => User added => User is Member of Security group (secA) => Then the security group (SecA) is a member remote desktop users. There is a GPO assigned to OrgA.
I have attempted to duplicate the settings of the set up that is working - except for different names on the organizational group, security group, and GPO. I'm creating new users and I can get them to log in successfully only when they are a member of the Security group A.
I'm running two boxes. The first is a domain controller running server 2003. The second is a terminal server running server 2003.
I've checked the common items that I've found in the knowledge base. Everything seems to be identical.
ASKER
Yes I'm talking about OU's in AD.
I currently have 1 group of users organized within an OU. Also contained within the same OU is a Security Group with the same name as the OU. Inside that security group are all the users contained in the OU. The security group then ties those users to the remote desktop users. The OU also has the GPO. The GPO is controlling restricting access to certain functions when the users log in to the Terminal Server.
GPO is currently set to turn off things like active desktop, my documents, control panel, drive mapping, etc.
I want to create another group of users that will ultimately have a different set of restrictions controlled by a second GPO. Basically, I want all the same restrictions except I want to enable drives so that I can map the my documents folder to a specific location (thereby giving a short list of users access to a shared resource).
I currently have 1 group of users organized within an OU. Also contained within the same OU is a Security Group with the same name as the OU. Inside that security group are all the users contained in the OU. The security group then ties those users to the remote desktop users. The OU also has the GPO. The GPO is controlling restricting access to certain functions when the users log in to the Terminal Server.
GPO is currently set to turn off things like active desktop, my documents, control panel, drive mapping, etc.
I want to create another group of users that will ultimately have a different set of restrictions controlled by a second GPO. Basically, I want all the same restrictions except I want to enable drives so that I can map the my documents folder to a specific location (thereby giving a short list of users access to a shared resource).
Ok, this is going to be an interesting one...
To explain, it sounds to me as if currently, you have your Terminal Server computer account within the same OU that the policy is linked to (Org1), and that the policy has loopback processing mode enabled. (please confirm if this is correct, I think the setting is in Comp Config > Admin Templates > System > Group Policy and I think is called 'User group policy loopback processing mode' or something similar...
That's the way you ensure that when logging on to a specific machine (such as the TS), that the USER SETTINGS within the loopback policy (or another user config policy also linked to the OU with the TS comp account) take affect but only when users log on to the TS, instead of just applying to the user accounts regardless of what machine they're logging on to...
Loopback has two possible configurations - MERGE mode, and REPLACE mode. Merge mode will combine whatever settings are processed via loopback, with whatever settings apply to the user account normally. Replace mode will completely stop normal policy processing, so the only GPOs that will take affect for that user when they log on the machine that has loopback enabled, are those settings processed via loopback.
I'm still midly confused as to the whole point where users in SecB don't have access to log on to the TS in the first place - that should just be a case of making the SecB group a member of the Remote Desktop Users group on the TS, and that's that.
To achieve the different settings for different users, and in both cases have the settings from those policies apply on when the users log on to the TS could be tricky...
This is the way I'd do it - I'm going to have to ignore your current AD layout for ease of explanation, and explain as if I was setting up from scratch:
- Create a new OU that is specifically (and only) to house your Terminal Server computer object.
- Create 2 GPOs, and configure the 2 different sets of user settings you want for each of the 2 groups.
- Ensure that in both GPOs that the above mentioned loopback policy processing setting is enabled.
- In 1 of the policies, edit the security filtering (Security tab, Advanced) and remove the authenticated users security principle from the ACL.
- In it's place, add 2 entries: 1 that is just the computer account of the TS, ensuring it has Read and Apply rights. The other for the group you WANT to apply this policy, ensuring it has Read and Apply rights.
- In the second GPO, again edit the security filtering, remove authenticated users, and replace with the TS computer account again, granting Read and Apply, but this time, add an entry for the SECOND security group, granting it Read and Apply rights.
To review the steps so far, you have an OU (let's call it TS), in which the only object is your TS Server (TS1).
You have 2 GPOs (GPO1 and GPO2), and GPO1 is set so that ONLY TS1 and SecA can apply it, and GPO2 is set so that only TS1 and SecB can apply it.
Now, (and assuming SecA and SecB have the relevant users in, with NO cross over, i.e. users that are in both), all you should need to do is link both policies to the TS OU.
The result:
When your users log on normally (to any normal desktop or laptop), there normal policies (the GPOs have may have linked to the OUs that contain the actual user accounts) will be processed as normal, completely unaffected by the 2 GPOs we just created.
However, when a user from SecA logs on to the TS, loopback kicks in, and will attempt to apply the user settings from the 2 GPOs linked to the TS OU, but will only (because of the security filtering changes we made) be able to apply the user settings from GPO1.
The reverse is true for users in SecB - They will be able to apply the settings from GPO2, but do not have Read nor Apply rights to GPO1.
That is I believe, the only way to achieve what you're after. It's actually far less complicated than I've managed to make it look, so maybe once you start the 'doing' you'll see what I mean, if the above has just confused you.
Anyway, I'll shut up and let you digest, and post any questions you have on what I've (badly) explained above.
HTH
Pete
To explain, it sounds to me as if currently, you have your Terminal Server computer account within the same OU that the policy is linked to (Org1), and that the policy has loopback processing mode enabled. (please confirm if this is correct, I think the setting is in Comp Config > Admin Templates > System > Group Policy and I think is called 'User group policy loopback processing mode' or something similar...
That's the way you ensure that when logging on to a specific machine (such as the TS), that the USER SETTINGS within the loopback policy (or another user config policy also linked to the OU with the TS comp account) take affect but only when users log on to the TS, instead of just applying to the user accounts regardless of what machine they're logging on to...
Loopback has two possible configurations - MERGE mode, and REPLACE mode. Merge mode will combine whatever settings are processed via loopback, with whatever settings apply to the user account normally. Replace mode will completely stop normal policy processing, so the only GPOs that will take affect for that user when they log on the machine that has loopback enabled, are those settings processed via loopback.
I'm still midly confused as to the whole point where users in SecB don't have access to log on to the TS in the first place - that should just be a case of making the SecB group a member of the Remote Desktop Users group on the TS, and that's that.
To achieve the different settings for different users, and in both cases have the settings from those policies apply on when the users log on to the TS could be tricky...
This is the way I'd do it - I'm going to have to ignore your current AD layout for ease of explanation, and explain as if I was setting up from scratch:
- Create a new OU that is specifically (and only) to house your Terminal Server computer object.
- Create 2 GPOs, and configure the 2 different sets of user settings you want for each of the 2 groups.
- Ensure that in both GPOs that the above mentioned loopback policy processing setting is enabled.
- In 1 of the policies, edit the security filtering (Security tab, Advanced) and remove the authenticated users security principle from the ACL.
- In it's place, add 2 entries: 1 that is just the computer account of the TS, ensuring it has Read and Apply rights. The other for the group you WANT to apply this policy, ensuring it has Read and Apply rights.
- In the second GPO, again edit the security filtering, remove authenticated users, and replace with the TS computer account again, granting Read and Apply, but this time, add an entry for the SECOND security group, granting it Read and Apply rights.
To review the steps so far, you have an OU (let's call it TS), in which the only object is your TS Server (TS1).
You have 2 GPOs (GPO1 and GPO2), and GPO1 is set so that ONLY TS1 and SecA can apply it, and GPO2 is set so that only TS1 and SecB can apply it.
Now, (and assuming SecA and SecB have the relevant users in, with NO cross over, i.e. users that are in both), all you should need to do is link both policies to the TS OU.
The result:
When your users log on normally (to any normal desktop or laptop), there normal policies (the GPOs have may have linked to the OUs that contain the actual user accounts) will be processed as normal, completely unaffected by the 2 GPOs we just created.
However, when a user from SecA logs on to the TS, loopback kicks in, and will attempt to apply the user settings from the 2 GPOs linked to the TS OU, but will only (because of the security filtering changes we made) be able to apply the user settings from GPO1.
The reverse is true for users in SecB - They will be able to apply the settings from GPO2, but do not have Read nor Apply rights to GPO1.
That is I believe, the only way to achieve what you're after. It's actually far less complicated than I've managed to make it look, so maybe once you start the 'doing' you'll see what I mean, if the above has just confused you.
Anyway, I'll shut up and let you digest, and post any questions you have on what I've (badly) explained above.
HTH
Pete
ASKER
I've checked on the loopback.....and I did follow your logic on the explanation. However, Loopback is not defined on either my domain controller or on the Terminal server.
Let me explain that we DO NOT have users that log into the domain AND into the terminal server. We only log in locally on each desktop and from there we simply use remote desktop to access the terminal server (where we run a database application). I inherited this set up and I'm still figuring some things out so I appreciate your patience.
So I have one server called our app server where the domain and DHCP take place as well as where our SQL server is installed. We have a second server that is the Terminal Server that runs the application that accesses the database. The terminal server is part of the Domain and therefore get's it's GPO from the domain server. So we don't have to worry about loopback GPO issues at this time.
In regard to what you were saying about "that should just be a case of making the SecB group a member of the Remote Desktop Users group on the TS, and that's that."............I completely agree. That is why I'm so confused about why it isn't working. I've also forced the group updates to make sure. This may be a silly little something that I've overlooked........
Let me explain that we DO NOT have users that log into the domain AND into the terminal server. We only log in locally on each desktop and from there we simply use remote desktop to access the terminal server (where we run a database application). I inherited this set up and I'm still figuring some things out so I appreciate your patience.
So I have one server called our app server where the domain and DHCP take place as well as where our SQL server is installed. We have a second server that is the Terminal Server that runs the application that accesses the database. The terminal server is part of the Domain and therefore get's it's GPO from the domain server. So we don't have to worry about loopback GPO issues at this time.
In regard to what you were saying about "that should just be a case of making the SecB group a member of the Remote Desktop Users group on the TS, and that's that."............I completely agree. That is why I'm so confused about why it isn't working. I've also forced the group updates to make sure. This may be a silly little something that I've overlooked........
No problems at all!
Ok, I need to clarify a couple more things then...
You log on locally to the client, I assume you mean using individual local accounts that are configured on each individual client machine.
Then you RSP to a TS that is a domain member, and therefore I assume to log on to that server, the users have to enter an alternate domain user accounts credentials to log on there.
So to be clear, they log on to laptop/PC as LocalMachine\UserA, but when RDP'ing on to the TS server, they then have to enter something like Domain\UserA (or whichever domain account is assigned to them for logging on to the TS), at which point the domain group policy for that domain user account will be processed.
Does that sound correct?
So basically each user has 2 accounts, one to log on the PC, and the other to log on to the TS?
If so it makes things a lot simpler (and also most of what I said above irrelevant! lol). As all you'd need to do is separate your users into 2 separate OUs (as you did), with your original GPO still applying to the OU that contains one of the sets of user accounts, whilst creating a second GPO with the alternate user settings, and having that GPO linked to the second OU that contains the other set of users.
The actual '2' security groups are irrelevant in this scenario, as you don't need 2 separate SecA and SecB groups, as the sole purpose of the group(s) would be to grant access to log on in the first place. So ALL users that need to log on to the TS could be members of SecA, which would make the 'other' problem go away, as you've stated this works.
The group then allows them to log on in the first place, and the division of these accounts into 2 separate OUs with 2 separate GPOs linked to each of the OUs is all that's needed to get the user settings applying to the accounts as you want... In case you're not following - GPOs cannot EVER apply to security groups. They can only apply to user objects and computer objects, via the links you put in to the containers that contain those objects (OUs, Domains and Sites).
Unless my assumptions at the beginning of this post are wrong (again! lol), that should be that.
I'm off to bed now but will make sure I check back in the morning and see if you had any followups, at which point I'll respond again if you're still unable to get this all working how you want it.
Hope that helps?
Pete
Ok, I need to clarify a couple more things then...
You log on locally to the client, I assume you mean using individual local accounts that are configured on each individual client machine.
Then you RSP to a TS that is a domain member, and therefore I assume to log on to that server, the users have to enter an alternate domain user accounts credentials to log on there.
So to be clear, they log on to laptop/PC as LocalMachine\UserA, but when RDP'ing on to the TS server, they then have to enter something like Domain\UserA (or whichever domain account is assigned to them for logging on to the TS), at which point the domain group policy for that domain user account will be processed.
Does that sound correct?
So basically each user has 2 accounts, one to log on the PC, and the other to log on to the TS?
If so it makes things a lot simpler (and also most of what I said above irrelevant! lol). As all you'd need to do is separate your users into 2 separate OUs (as you did), with your original GPO still applying to the OU that contains one of the sets of user accounts, whilst creating a second GPO with the alternate user settings, and having that GPO linked to the second OU that contains the other set of users.
The actual '2' security groups are irrelevant in this scenario, as you don't need 2 separate SecA and SecB groups, as the sole purpose of the group(s) would be to grant access to log on in the first place. So ALL users that need to log on to the TS could be members of SecA, which would make the 'other' problem go away, as you've stated this works.
The group then allows them to log on in the first place, and the division of these accounts into 2 separate OUs with 2 separate GPOs linked to each of the OUs is all that's needed to get the user settings applying to the accounts as you want... In case you're not following - GPOs cannot EVER apply to security groups. They can only apply to user objects and computer objects, via the links you put in to the containers that contain those objects (OUs, Domains and Sites).
Unless my assumptions at the beginning of this post are wrong (again! lol), that should be that.
I'm off to bed now but will make sure I check back in the morning and see if you had any followups, at which point I'll respond again if you're still unable to get this all working how you want it.
Hope that helps?
Pete
ASKER
Okay - Let me think on this a little - sleep on it as they say. I will tell you that the first part is correct. We have basically 2 accounts, a local PC account that has nothing to do with the server and a TS account (at least from the end user's perspective).
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Oh and that was meant to say 'catch-all' in the second paragraph, not 'catch-call'! I really must start proof reading my posts more thoroughly...
ASKER
Okay - this seems to be working. I'm still in the dark as to why I couldn't have 2 Security groups working at the same time. But using SecA only seems to be working - and that's what I needed.
I will say that another reason I was trying to create a second security group was so that I could use folder redirecting. Advanced Folder redirection (under group policy, user config, windows settings, folder redirec) seems to only apply to security groups. And I didn't want to redirect security group A's folder (even though it couldn't been seen due to other GPO restrictions). But that really is a separate issue that I will deal with.
Thanks for the help. I'm bumping up the points on this one.
I will say that another reason I was trying to create a second security group was so that I could use folder redirecting. Advanced Folder redirection (under group policy, user config, windows settings, folder redirec) seems to only apply to security groups. And I didn't want to redirect security group A's folder (even though it couldn't been seen due to other GPO restrictions). But that really is a separate issue that I will deal with.
Thanks for the help. I'm bumping up the points on this one.
ASKER
Good Job
Thanks! I would've happily worked through the security group thing with you as well, just wanted to establish that the 'main' issue was resolved.
But, please note that having a second security group that contains your second set of users is still possible with regards to folder redirection anyway (I haven't got a chance to really look at these settings yet and confirm the requirements).
You'd just end up having SecA granting the permission to log on to the TS, and using SecB for your folder redirection policy... However I completely understand the need to figure out why it didn't work. Feel free to post the process you used to grant them perms and any other relevant details, I'll happily take a look (and that would include the process the end user is carrying out when attempting to log on to the TS).
Glad I could be of help,
Pete
But, please note that having a second security group that contains your second set of users is still possible with regards to folder redirection anyway (I haven't got a chance to really look at these settings yet and confirm the requirements).
You'd just end up having SecA granting the permission to log on to the TS, and using SecB for your folder redirection policy... However I completely understand the need to figure out why it didn't work. Feel free to post the process you used to grant them perms and any other relevant details, I'll happily take a look (and that would include the process the end user is carrying out when attempting to log on to the TS).
Glad I could be of help,
Pete
I'm a little confused - So you have your second group of users (SecB), and you're adding that to the Remote Desktop Users group on the Terminal Server, but they can't log on to it?
What does this GPO actually do? What settings are configured in it etc? Is it actually relevant?
Where is the Terminal Server computer object located in AD? (What OU is it in?)
Pete