ThinApp: Using Permitted Groups

An easy way to restrict who can access a given ThinApp (for example, for license compliance or even just to simplify the thinreg script) is with Permitted Groups. When you restrict a package to certain AD groups during the capture process, it simply adds a “PermittedGroup=XXXXX” line to the [Build Options] section of the Package.ini file. This means that all entry points for the ThinApp are restricted, only giving users in the defined group(s) the right to execute to execute. Alternately, you can set the PermittedGroup line under a specific entry point in your Package.ini file, in which case that restriction is only applied to that specific entry point. It’s important to note that this sort of restriction only applies to the entry point itself, not the actual executable within the package. What this means is that, if you create a command prompt entry point for a package, even though another entry point might be restricted a user, from that command prompt, could still invoke the application. As a rule of thumb, either do not include the command prompt or ensure that it is restricted as well.

In general, I prefer to specify my permitted group by SID rather than by name. I do this because it’s more reliable – if something goes wrong on the capture machine and its domain membership becomes questionable (for example, if it changes its machine password and then you revert to an older snapshot), using human friendly names may not work well. VMware has a great open source tool (an unofficial, use-at-your-own-risk tool) for getting AD Group SIDs at http://blogs.vmware.com/thinapp/2010/07/getting-the-group-sid-value.html (click the image of the “Get your Group SID” app to download it) that I’ve been using for a while. In order to keep my package.ini files readable, I just put a comment with the permitted groups in a human friendly format above the actual permitted group line.

As far as assigning groups to a given ThinApp goes, I favor the “1 group per 1 application” school of thought. What that means is that each time I create a package, I create a corresponding Active Directory security group. I add a permitted groups entry for that group in that application and add appropriate customer users and groups to that new group. For example, if I am ThinApp’ing Visio, I create a “thinapp_visio” security group. I prefer to do it this way, as it adds greater flexibility (removing someone from that thinapp_* group does not revoke any other access to the environment; conversely putting someone into that group is not going to grant them unexpected access). Even if the customer tells me that everyone in their Finance group needs access to Visio, I’d rather use this method (and put the Finance Group into the thinapp_visio Group, since nested groups are supported) than grant them access directly. This method provides me more flexibility in case something changes with Finance’s access to Visio or in case someone needs access to Visio without needing access to other Finance assets.

Here is an example of the lines that I use to for permitted groups. Remember, these lines can be added either directly under an executable entry point (to apply just to that entry point) or under the general [build options] section to apply to the whole package. The SID has been pared down here; you’ll want to replace everything after the = with the actual SID for the group that you make.

;PermittedGroups=domain\thinapp_application

PermittedGroups=S-1-5-11….

AccessDeniedMsg=You have not been granted permission to access this application. Please contact support if you are receiving this message erroneously.

The AccessDeniedMsg does exactly what you’d assume – it’s what pops up if you try to execute an entry point but do not belong to the correct group. An AccessDeniedMsg that is specified for a particular entry point will override a message that is inherited from the package’s general [build options].