戻る
-
タイトル
Is the DAADMIN services account needing to be a domain admin? -
説明
Need to know if the KACE Desktop Authority services account must be a member of the domain admin group. -
対策
Please review the information below with the details. If further information is required please Contact Support.
There is a knowledge article on our site called: What are the service names and their functionality? You will find some details about the services and their functionality.
Regarding your inquiry of whether it is necessary to use domain admin credentials in association with the configuration of KACE Desktop Authority (KDA). It is not necessary to use domain admin service credentials as long as the credentials that you are using have local administrator privileges on any server that you want to install the Desktop authority services to and local administrator privileges on any client workstation that you would like to manage with KDA.
I think the main concern for most people regarding this question is that they want to ensure that the domain admin credentials don’t get stored on the client machines. That is a legitimate concern, and one is a situation that we take affirmative steps to avoid. KDA only uses the domain admin service account credentials that you provided to configure the Desktop Authority Administrative Service on the domain controllers to run the Administrative service and replicate file changes to locations in SYSVOL on the domain controllers. The domain admin account service account also is used to add the domain user service account to the local administrator’s group on the client machines so that it can run any settings on the client machine as a local administrator. Therefore, the domain admin credentials never get cached on the workstations.
There are many questions associated with the way the KDA Administrative service functions:
The Desktop Authority Administrative Service is not only necessary in order for KDA 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.
Solution:
In order to centrally administer the desktop settings on client machines, the administrator must employ a suitable solution such as KDA 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 to accomplish this.
Configuring the service:
When configuring the KDA 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 KDA Administrative Service to both provision the machine for use with KDA 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.
Security:
The Administrative Service is configured in the Server Manager applet of KDA. 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 KDA 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.
Runtime:
When the script is run for the user at logon, the KDA 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 KDA 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.