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].

Comments

  1. No matter what I put in the PermittedGroups line, GROUP_NAME, DOMAIN\GROUP_NAME, or the SID....I'm getting access denied. If I comment out the line and rebuild, the ThinApp'd App works fine. Any suggestions?

    ReplyDelete
    Replies
    1. When you're logged in as an account that gets the "access denied" message, use "gpresult /r" at a command prompt. Amongst other things, it will show you which security groups your account is a member of. It may be something as simple as logging out and back in in order to refresh your group membership.

      Delete
  2. When you make changes to the package.ini and save, should it take effect immediately, or do you need to recompose your desktop pool first. I have added the PermittedGroups line under [Build Options] using the SID but it still lets all users access the app. Is there another step?

    ReplyDelete
    Replies
    1. Hi Ali - the package.ini file is only used when you build the ThinApp package, not when it's executed. You'll want to execute the build.bat file in the ThinApp's build folder (on a system with ThinApp installed) to generate a new portable executable. Once you have the new executable(s), you'll need to present those to your users as normal (either by a side-by-side update, appsync, or whatever). You will only need a recompose if your ThinApps are actually stored on the virtual desktop itself (which would be pretty inefficient would remove the major benefit of ThinApping, in my opinion).

      Delete
  3. Hi Jason,

    I am trying to track usage with a vb script but when I call GetBuildOption("PermittedGroups") I don't get any output. Is PermittedGroups an array or something so that you can put more than one group in it?

    ReplyDelete

Post a Comment

Sorry guys, I've been getting a lot of spam recently, so I've had to turn on comment moderation. I'll do my best to moderate them swiftly after they're submitted,

Popular posts from this blog

Orphaned VMDK Files

Migrating from one vCenter to Another, Improved

Copying VM Folders and Permissions from One vCenter to Another