The Desktop Authority Administrative Service is not only necessary in order for Desktop Authority (DA) to function properly but is an integral component used to provision machines and to configure many other settings that the vast majority of users lack the permissions to configure.  Since the functionality of the service is seamlessly incorporated into the product and uses technology that most people are not acquainted with, it seems appropriate to attempt to explain the operation of this service in more detail. 


Users lack permissions to configure many settings on the client machine:

Unlike the Domain Users group, the Domain Admins group is automatically added to the Local Administrators group when a client machine is joined to the domain.  Therefore, any user logging on as a member of the Domain Admins group is expressly granted local administrator privileges on a client machine that has been joined to a domain.  However, recommended best security practices discourage the use of Domain Admin credentials to logon to client machines because the information is cached and the credentials could be compromised in the event of a security breach.  The result is that the overwhelming majority of users logging on to the domain are not members of the Local Administrators group of the client machines. 



In order to centrally administer the desktop settings on client machines, the administrator must employ a suitable solution such as DA which can used for the automation of those settings.  The solution must be relatively easy to configure, technically sound, and secure, while still maintaining the ability to set the settings ultimately desired by the administrator.  In addition, the solution must also have the capability to communicate with the active user session of the interactive logged on user and to configure settings requiring elevated permissions, without ever actually elevating the security privileges of that logged on user.  The service uses impersonation technology in order to accomplish this.


Configuring the service:


When configuring the DA Administrative Service for use, the administrator will be prompted for two sets of credentials commonly referred to as service accounts. These two sets of credentials must be members of the Domain Admins group and the Domain Users group, respectively.  These service accounts are used in tandem by the DA Administrative Service to both provision the machine for use with DA and to set the desired configuration settings created in, and published from, the DA management console. The domain admin account possesses the necessary privileges to run the Administrative Service on a domain controller.  As stated previously, the domain admin account also has the ability to administer the machines added to the domain because the Domain Admins group resides in the Local Administrators group of the machine. 




The Administrative Service is configured in the Server Manager applet of DA. When the service is pushed out to the servers in the list in server manager, they are signed with a digital signature that is unique for each installation instance of the DA management console. When the settings created in the manager console are saved to the database and then subsequently written to files and replicated out to the target domain controllers, the replicated files are also given the same unique signature. This security model guarantees that the settings requested at runtime, and the service contacted to possibly elevate the permissions on those settings, have both emanated from the same unique installation of DA.





When the script is run for the user at logon, the DA Agent and other executable files programmatically perform an evaluation to determine if the client needs to be provisioned with the DAClientInstall.msi file which inevitably installs the client service. The Domain Admin account, which was provided when configuring the service, possesses the necessary privileges to add the Domain User account, also provided for the service, to the Local Administrators group and installs the DA Client Service by installing the DAClientInstall.msi file in the security context of a Local Administrator. The agent and the client service both communicate with the server service securely through named pipes throughout the installation or update process. This remarkable process even includes the ability to provision the client machine with prerequisite files, such as .Net Framework 2.0 SP1 and Windows Installer version 3.1, if the client machine lacks these minimum prerequisites necessary to perform the installation of the DAClientInstall.msi file.

Once the client service is installed and running on the machine, any settings in the script that were requested by the administrator to be run with an admin flag are executed in the security context of a local administrator using impersonation technology to interface with the interactive logged on user session.



Additional considerations:

There is a common misconception that the domain admin credentials provided are used to run any settings which are set to run in the context of an administrator, but it is the domain user service account which is used for that purpose.  For instance, if there is an application launcher element set to run an executable as admin and the executable is located on a network share, then the only necessary adjustment to make, if any, is to ensure that the Domain Users Group or the domain user service account has Read/Execute permissions to that share.  As discussed above, the domain user service account becomes a local admin on the machine and therefore already possesses the necessary privileges to run any setting locally on the client machine.

Another consideration is that if the interactive logged on user is already a member of the Local Administrators group on the client machine, then the requested configuration settings will be performed in the security context of that user since the account already possesses the necessary administrative privileges to run any setting locally.   

Another aspect of the client service is that it idles as Local System but then transparently adds and removes the domain user service account respectively to and from the Local Administrators group as necessary.