We’re pleased to announce a new feature in Windows Server 2008 R2: RemoteApp User Assignment. The RemoteApp User Assignment feature gives administrators the ability to show a customized list of RemoteApp programs specific to the logged-on user in RD Web Access and RemoteApp and Desktop Connections. This has been one of our most requested features since Terminal Services Web Access (TS Web Access) was released in Windows Server 2008.
In Windows Server 2008 TS Web Access, if two users with different application usage patterns log on to the website, they will both see the same list of RemoteApp programs. For example, a user from HR and a developer will see the same set of published applications. They will both have to dig through several published applications to access the ones that are relevant to them.
By using RemoteApp User Assignment, Windows Server 2008 R2 provides a solution to filter the applications based on the logged-on user. By using this new feature, the administrator can easily set up the system so that users will only see the applications they use. In our example scenario, the HR user will only see HR applications, and the developer will only see development applications. This feature makes it easy for users to find and run the applications that are relevant to them.
The RemoteApp User Assignment feature is implemented by adding an access control list (ACL) to every RemoteApp program. When a user logs on to RD Web Access, the list of applications that are viewable to this user is fetched from the RD Session Host (RDSH) servers. As we can see in the diagram below, when RD Web Access is configured to point directly to one or more RD Session Host servers, RD Web Access directly queries the servers and filters the retrieved list of RemoteApp programs based on the ACLs.
When RD Web Access is configured to point to an RD Connection Broker server, the Connection Broker server queries the RD Session Host servers and filters the list of RemoteApp programs, as shown in the diagram below.
When the RemoteApp program is first published, its default ACL allows all users to see the application. Through UI and Windows PowerShell™, the ACL can be configured to allow only certain domain users or entire domain groups to view the application. See the relevant sections later in this post for detailed configuration steps.
There are a few considerations when setting up this feature that I’d like to mention briefly.
1. The RemoteApp programs can only be assigned to domain users or domain groups, not local users or local security groups. If a user logs on to RD Web Access with a non-domain account, all RemoteApp programs will be displayed, as with Windows Server 2008 TS Web Access.
2. The computer that is actually performing the check of the user’s credentials against the RemoteApp program’s ACL (see the diagrams in the previous section) must be either a member of the domain’s Windows Authorization Access Group, or be joined to a domain running in Windows 2000 compatibility mode.
NOTE: RemoteApp User Assignment is not intended to be a security mechanism; rather it is a discoverability mechanism. There are already ways to secure access to an RD Session Host server, and the RemoteApp User Assignment feature does nothing to change or improve upon them. This feature only helps reduce the number of unnecessary applications that are otherwise displayed to users.
In RemoteApp Manager UI, a new tab, User Assignment, has been added to the RemoteApp Properties dialog box:
As you can see in the screenshot, this new tab allows administrators to specify which domain users and groups can view the RemoteApp program in RD Web Access and the RemoteApp and Desktop Connection feed.
To filter the applications, select the Specified domain users and domain groups option, and then click Add or Remove to modify the list of assigned domain users and groups. The screenshot below captures a configuration where the application is configured to be shown only to the members of the domain group RDVSTRESS\testgroup.
The feature can also be managed by using the Remote Desktop Services module for Windows PowerShell:
1. Click Start, click Administrative Tools, and then click Windows PowerShell Modules.
2. To switch to the Remote Desktop Services module for Windows PowerShell, type cd RDS:\.
3. Type cd RDS:\RemoteApp\RemoteAppPrograms and then press ENTER. A dir command at this container lists all the applications that are published.
4. Type cd .\<app>\UserAssignment and then press ENTER. A dir command at this container lists all the users and groups to whom the application is assigned.
5. To assign the application to a user 'testdomain\user2', type New-Item -Path RDS:\RemoteApp\RemoteAppPrograms\<app>\UserAssignment -Name user2@testdomain and then press ENTER.
6. To unassign the application to a user 'testdomain\user2', type Remove-Item -Path 'RDS:\RemoteApp\RemoteAppPrograms\<app>\UserAssignment\user2@testdomain' and then press ENTER.
7. Type dir and then press ENTER to see the user removed from the list of users.
Changes to the domain group membership can take some time to propagate into the user filtering logic. I expect that after some time, the filtering will "catch up" and show the correct results. You may also be able to speed this up by forcing RDWA to refresh its internal state (recycling the app pool is probably the easiest way).
Hope that helps.
I read the article (good one). But it seems te be not working on my side. All users can see all applications. Even if i just give the administartor right to a particular application all users can still see those applications. what is going wrong? It looks like filtering is not working. It shows all application to all users.
I have the exact same issue; did you manage to find a resolution to this issue?
Does anyone know if this WebApp works across a domain trust?
We can get the applications to show based on users in the local domain, once we add users from the remote domain (by group or actual user account), the users can authenticate but get no applications displayed.
Thanks for a great post, unfortunately I have done all this but still all users can see all apps.....I was hoping to make some active directory groups for example office 2010, corp apps and the put relevant users into these groups and assign the apps to these groups but users are seeing all apps.
Do you see any errors in the event logs on the RDWA server or the RD Connection Broker server? In certain failure modes when the user filtering cannot work, all apps will be displayed to all users. Any of those failures should cause an entry in the event log.
Also, keep in mind that if you are removing users from AD groups it can take some time for the changes to propagate into the user filtering logic.
Hope that helps,
So, if I have controlled who can run which programs, is there anyway a user can get around this filter? I don't even what users seeing each others apps. The names alone would be a security risk.
Yes there are ways around this filter. As I stated in the post, this is not intended to be a security mechanism. There are some error cases where the expected behavior is to display all apps and desktops to all users.
I have used Security Groups on all my applications, but when adding/removing a user the RDWeb page does not reflect the change for a long time. How can the group security permission be applied without have to issue an IISREST?
What version of the Server OS are you using? This was a known issue in Windows Server 2008 R2, but I believe we fixed it in Windows Server 2012.
If you are using Windows Server 2008 R2, there is unfortunately not a great workaround. Honestly, iisreset is probably your best bet if you don't want to wait.