adjoin fails for non-admins

Showing results for 
Search instead for 
Do you mean 
Reply
Participant II
Posts: 13
Registered: ‎07-29-2013
#1 of 3 126
Accepted Solution

adjoin fails for non-admins

When I join a computer to the domain with adjoin using the credentials of a Domain Admin, adjoin succeeds. This is the way we usually do it. But I want to give some users the ability to join computers to the domain, and if I run adjoin as a regular user (who has been given permission to join computers to the domain), it fails:

User cannot set the computer password
KDC Result Code=5 : Access denied
Cannot get computer credentials: Preauthentication failed
Error: <username>@<DOMAIN>  does not have permission to set the machine password.
Ask your system administrator to reset the computer account.

Adding the --verbose flag gives a little more detail:

Checking if the required permissions exist.
Set operatingSystemVersion to "6.1:7.0", so that KDC will issue service ticket using AES enctypes.
Set also msDS-supportedEncryptionType to "31"
Update OS information.  This requires computer object update rights...
Update Computer object OS information failed.
Check user write privileges on the operatingSystem and operatingSystemVersion attributes
This is not strictly required.  Continuing join
Setting machine password...
Setting get init cred callback before set password (rc=0).
User cannot set the computer password
KDC Result Code=5 : Access denied
Attempting to use computer account to change password
Cannot get computer credentials: Preauthentication failed
Error: <username>@,DOMAIN>  does not have permission to set the machine password.
Ask your system administrator to reset the computer account.

This is with CentrifyDC 5.5.0. Our domain controllers are running Windows Server 2016.

 

What am I missing? What password is it trying to set?

 

Thanks,

Dave

Centrify Guru I
Posts: 2,239
Registered: ‎07-26-2012
#2 of 3 120

Re: adjoin fails for non-admins

@guertin,

 

Hello and welcome back.

 

Moderation notice:  Always provide the operating system, version of Centrify DirectControl and if you're working in zone or autozone mode to give you a better answer.

 

Security notice:  Domain Admin membership IS NOT required to join systems to Active Directory (Windows or non-windows) and it's a general practice that Domain Admin membership should be monitored and/or assigned temporarily.  These are the best practices against advanced modern threats.

 

In your case:

The user does not have delegated rights to add computers to the target OU or Container in Active Directory.

 

Delegating Rights to Join Systems with DirectControl:

With Centrify, you can delegate the permissions required to join a system, depends on the operating mode: 

  • If you're in Auto Zone (workstation mode) all you need to do is delegate the right to join computers to the target OU.
  • If working in Zone mode, you need the above delegation and the delegated right at the zone level to "Add computers to the zone";  finally, if you plan to also add the system to a Computer role (teams of systems), you must also grant the delegated right to add users to the security group that the computer role is using as container.
    These steps are outlined below.

Also note, that an administrator can "pre-join" (it's called preparation) a system so a non-administrator or a program can do a "self-service" join.

 

 

*** Delegating in zone mode****

From: https://community.centrify.com/t5/TechBlog/DevOps-Creating-a-Kerberos-Keytab-to-Automate-DirectContr...

 

Delegate Permissions

There are 2 delegations needed to make sure the automation of joins/removals works.  The service account should be able to create/remove  computer objects in your designated AD container for UNIX/Linux or Mac systems, plus if you're using Centrify zones, the system has to have the ability to join, remove and modify computer profiles.

Optionally, there's a third delegation related to Computer Roles (contained in AD groups); for this you need to provide the "manage group membership" delegation to the target groups (or OU that contains the groups).

 

Let's illustrate the steps using this OU structure

oustruc.png

 In this scenario, I plan to add the UNIX/Linux computers to the Servers SubOU under Centrify; this means that I have to delegate at that level to preserve the least privilege principle.  In a real-world deployment, you may have a different layout (perhaps based on sites), in that case you have to delegate in multiple places.

 

To delegate the computer object in the target OU 

  1. In ADUC (as a privileged AD user), right click the Servers SubOU and select "Delegate Control"
  2. Welcome Page > Next
  3. Users or Groups > press Add, find the service account, select and press OK, then Next
  4. Task to Delegate > Select "Create custom task to delegate" and press Next
  5. Object Type > Select "Only the following objects in the folder"; check the Computer Objects box and check  Create and Delete.
    custom.png
  6. Permissions tab > Check "Full Control" under permissions and press Next.
    You can dial this down, however we have this scoped down to the OU and type of object.
  7. Completing page > Finish

 Now the service account can create/remove computer objects in the Servers container.

 

To delegate at the Centrify Zone level

You must know all the Centrify zones that the service account will be leveraged for automation.  In my example I have one zone (AWS). Centrify provides PowerShell to perform bulk delegations (see Set-CdmDelegation, in this link)

  1. Open Centrify DirectManage Access Manager
  2. If needed, open your target zone(s)
  3. Right-click the zone and select "Delegate Zone Control"
  4. Selected Objects > Press Add and find and select  your service account, press OK and Next
  5. Tasks to Delegate > check join and modify computer operations to the zone (3 check boxes)
    Access Manager - delegation of computer ops.jpg
  6. Completing Page > Press Finish.

At this point, if you're not using DirectAuthorize Computer Roles you are done.

Note:  You can always verify delegations by running the "Zone Delegation Report"

 

Optional:  To delegate for Computer Roles 

Computer Roles allow the grouping of systems as "teams of servers" this gives administrators the flexibility granting access/privileges to systems to  multiple user populations, the only operation required is the the system is a "Member" of the Computer role, and this can be accomplished any time or during system setup by automating add/removal of the computer account into the AD security groups that make-up the computer role.

 

In my example, I'm leveraging the Centrify recommended OU structure and all my AD Security groups for the purposes of Computer Roles are stored in the Computer Roles SubOU under the Centrify OU.  This means that I only need to make one delegation.  Based on your design, this may vary and you may have to perform multiple delegations.

 

  1. In ADUC (as a privileged AD user), right click the Computer Roles" SubOU and select "Delegate Control"
  2. Welcome Page > Next
  3. Users or Groups > press Add, find the service account, select and press OK, then Next
  4. Task to Delegate > Select "Modify Membership of a Group" and press Next
    ADUC - delegation membership group.jpg
  5. Completing > Press Finish

From this point on, the service account will be able perform add/removals of objects into any existing or new AD group in that container.

 

 

Some resources:

https://community.centrify.com/t5/TechBlog/Walk-through-of-procedures-for-joining-NIX-systems-to-a-d...

 

 

I hope this helps.

 

R.P

Want to learn more about practical Centrify examples? Check out my blog at http://centrifying.blogspot.com
Follow Centrify:
Participant II
Posts: 13
Registered: ‎07-29-2013
#3 of 3 111

Re: adjoin fails for non-admins

Thanks! That's fixed it. We're using zone mode, and it was the Delegate Zone Control step that I was missing. The users had permission in AD, but not in Centrify.

 

Dave