In previous releases of Application Virtualization, we required admins to specify an SGBrowser account during install of the server. This account was used to READ Active Directory (AD) and resolve security groups on behalf of the user installing the Application Virtualization server. In 4.5, we remove this limitation and no longer require this account since we’re now using Windows Integrated Authentication.
When you install an App Virt Management server, you need an account (any account) with READ Access to AD. Chances are the account you’re using, to install the server, is in the Domain Users group so you have READ Access by default.
During the server install, you’re asked for a security group whose members will be allowed to administer the App Virt Management server and database. This is where you enter a previously created AD group which the user account you are installing under should be a member. The MS App Virt server performs a READ against AD to resolve the group (using the security context of the user installing the server). Then you’re asked what group of users are allowed to connect to the App Virt Management Server. This is the group that’s contained in the Provider Policy. The MS App Virt Management server, again, performs a READ against AD to resolve this group.
Ok, so now the server is up and is running under the Network Service account (changed from running as System to Network Service in 4.5). Customers have the opportunity of changing this to an AD service account if they wish. But let me be clear, the SERVER never uses this account to access AD. The App Virt Management Server service account is used to access the SQL config DB.
Now, when you bring up the App Virt Management console, you add your packages. During the ADD, you can set the AD security groups which are allowed access to this package. If you are now administering the App Virt server with a DIFFERENT account than you used to install the server, no problem. As long as the account your logged in with and managing the App Virt server is a member of the group allowed to administer the App Virt Management Server and has READ access to AD, you can set permissions on the packages via AD security groups. Once the administrator sets the proper permissions on the package, we store the Security Group SID in the SQL config DB. This becomes important when the user launches the app.
Now, when the user clicks on the icon to launch the app (after application publishing has occurred), the App Virt client sends the user’s security token to the App Virt Management server which contains ALL the security groups (listed as SIDs) the user is a member. The App Virt Management Server will take this token and lookup in the SQL DB to see if the user is allowed access to the application. If the SID assigned to the package in the DB is contained in the token the client is sending, the client launches the app.
To recap. The Application Virtualization Management Server never has to check AD (when authorizing users to access packages) since all the groups (stored as SIDs) acl’d to the packages are stored in the SQL DB.
PingBack from http://geeklectures.info/2007/12/18/what-happened-to-the-sgbrowser-account/
Surely this removes the ability to dynamically grant users access to applications while they're logged on? If you're basing it on their Security Token they'll have to log out and back in to get new apps.. If that's correct that sounds like a backwards step to me..