Controlling Application Access with Active Directory

Administrators can control access to applications on physical systems and on the users groups that use Active Directory groups to access applications.

When you build an application package, ThinApp converts Active Directory group names to Security Identifier (SID) values. A SID is a small binary value that uniquely identifies an object. SID values are not unique for a few groups, such as the administrator group. Because ThinApp stores SID values in application packages for future validation, the following considerations apply to Active Directory use:

• You must be connected to your Active Directory domain during the build process. The groups that you specify in the application package must exist. ThinApp refers to the SID value during the build.
• If you delete a group and re-create it, the SID value might change. In this case, rebuild the package to authenticate against the new group.
• When the system is offline, the PermittedGroups parameter uses cached credentials to determine if the user has permission to start the application. If users can log in to their machines, authentication works. Use a group policy to set the period when cached credentials are valid.
• Cached credentials might not refresh on clients until the next Active Directory refresh cycle. Use the gpupdate command to force a group policy update on a client. This command refreshes local group policy, group policy, and security settings stored in Active Directory. You might log out before Active Directory credentials are recached.
• Certain groups, such as the Administrators group and Everyone group, have the same SID on every Active Directory domain and workgroup. Other groups you create have a domain-specific SID. Users cannot create their own local group with the same name to bypass authentication.
• Active Directory Domain Services define security groups and distribution groups. If you use nested groups, ThinApp can support only nested security groups.