By default, Active Directory allows any user to join EVO to the domain. In practice, few AD environments are left to default settings.
If an AD user has insufficient permission to create a computer object for EVO in AD, one can be created for it, but another obstacle may immediately follow:
The Challenge of Service Account Passwords vs. Security Policy
Many IT security policies mandate fewer privileges, as well as regular password changes for all user accounts to prevent unauthorized access.
However, applying this policy directly to service accounts—which are used by applications and systems rather than human users—often creates significant operational challenges. Attempts to circumvent this by implementing automated scripts or processes to regularly update service account passwords, while seemingly efficient, introduce new and substantial security risks. Such automation typically requires storing the service account's current password in a script or on a system, and defeats the very security principle that password rotation aims to provide, exchanging one risk for another and leading to service outages if the automated process fails.
The Secure and Preferred Solution: Least Privilege Delegation
A far more secure and robust solution is to embrace the Active Directory principle of least privilege through delegation. Instead of forcing password rotation, service accounts should be configured with static, highly complex passwords that are set to "never expire." This is made safe by granting these accounts only the absolute minimum permissions required for their specific function, rather than relying on broad group memberships like "Domain Users." By isolating permissions and explicitly defining what a service account can and cannot do, its attack surface is drastically reduced. This approach prevents service disruptions caused by expired credentials.
By default, any authenticating AD user can join 10 computers to the domain.
In that case, all EVO needs is the domain and user credentials to join automatically.
If the policy is set to 0 (a good practice), EVO can still be manually joined with control delegation.
If the AD account is unable to create its own computer object for EVO, then it temporarily needs the following permissions to authenticate a manually created computer object:
Read All Properties
Write All Properties
Validated write to DNS host name
Validated write to service principal name
Once EVO is authenticated, the permissions may be removed.
Configuring for least privilege delegation
- Set the primary (and optional secondary) AD domain controller IP address(es) for DNS resolution at EVO's Network page (/#/network).
- Confirm domain name resolution with the Ping test (custom test) on the Network page
- Important: Ensure clocks match. The most common issue encountered when attempting to join results from a time mismatch. It's generally a good practice to set the AD domain controller as the NTP server to preserve clock synchronization between devices.
- Make a note of EVO's host name, which will be needed by AD.
There are a number of ways to configure AD, and many options are available in both Active Directory Administration Center (ADAC) and Active Directory Users and Computers (ADUC).
For simplicity, the following example configuration uses only ADUC.
- Optionally create a new OU for the associated computer object and user
- Create a user within the OU
- Set a strong password, uncheck "User must change password at next logon" and check "User cannot change password" and "Password never expires", and then click "Next"
- By default, the user will belong to the "Domain Users" group, which includes a number of unneeded permissions. The account can instead be assigned to a primary group such as "Domain Computers", after which the original group membership can be removed.
- Right-click the user to access its Properties
- Navigate to the "Member Of" tab and click "Add..."
- Add the "Domain Computers" group
- Set the newly assigned group as Primary
- Remove "Domain Users"
- Click Apply
- Create the EVO computer object in the OU
- Enter EVO's host name in the Computer name field
- Click "Change..." to assign the service account user
- Add as many EVOs as needed in the same manner
- Right-click the OU and choose "Delegate Control..."
- Get welcomed and click "Next"
- Click "Add..." and enter the intended user account and click "Next"
- Choose "Create a custom task to delegate" and click "Next"
- Select "Only the following objects in the folder:"
- Check "Computer objects"
- Check "Create selected objects in this folder"
- Check "Delete selected objects in this folder"
- Check "Read All Properties"
- Check "Write All Properties"
- Check "Validated write to DNS host name"
- Check "Validated write to service principal name"
- Click "Next"
- Review permissions and click "Finish"
- It should now be possible to join EVO using the service account credentials
- Navigate to the Users page (/#/users) and choose External users or External groups from the dropdown menu
- Click AD/LDAP
- Enter the domain name and service account credentials
- Confirm connection
- It's now safe to revoke the temporary permissions granted to the service account
- Confirm "Advanced Features" is checked in ADUC
- Right-click on the OU and navigate to the "Security" tab, and then click "Advanced"
- When the view is sorted by "Principal", all four permissions granted to the service account are visible
- Select and click "Remove" for all four service account entries
- Click "Apply"
Now that EVO has been successfully authenticated to the existing computer object (rather than allowing the user to create one), it remains connected even while the account no longer has permission to connect computers.