Standard

Posted by

Posted on

March 23, 2016

Posted under

DevOps

Comments

2 Comments

Create a Least-Privilege account to perform domain joins

I’ve been working to automate joining linux machines to an Active Directory domain lately and I was surprised to find little documentation on creating an AD account just for the domain joins. I was able to piece things together by looking at umpteen documents and lots of trial and error. I’ve compiled what I found in the hopes that others do not have to struggle so much. This is just what I was able to find out – please let me know if you have a better way!

 

In a Windows Active Directory domain, it’s important to join computers to the domain. When the computer is joined, the computer account is created and lets it do things like send user authentication requests/receive responses, update it’s IP/name in DNS, and otherwise participate in the AD domain. This is a pretty fundamental and vital requirement, so Microsoft has made it easy for users to perform domain joins, but with some limits.

If a user is a enabled, a member of Domain Users, a member of the local Administrators group, and the correct authentication information is used, they are granted the ability to join any given computer to a domain. The key ms-ds-MachineAccountQuota is defined at the domain level with a default value of 10. Due to the quota, any random user can join 10 computers to the domain after which they will no longer be able to do so. Enabled members of Domain Administrators are exempt from both local Administrators membership and the quota and can join unlimited computers so long as the correct authentication information is used.

This works great with Windows machines, but presents a slightly different problem when joining non-Windows machines to a domain. In these cases, there is likely no local Administrators group, so regular users are never able to satisfy all of the requirements to join a machine to the domain. Domain Administrators can, but that violates the principle of least privilege and is not the best option for production environments. We want a non-administrator account who can join as many computers to the domain as is required. I found two steps were required to create this account.

Active Directory Delegation

In the Active Directory Users and Computers MMC snap-in, you can use the Delegate Control wizard to delegate the ability to create computer accounts to a user account. Unfortunately, I have not found scriptable commands that are an equivalent to this wizard, so we need to describe the GUI process.

  • Create an account, ex: domainjoin, in the appropriate hierarchy of your Active Directory. It is recommend that User cannot change password and Password never expires are selected so the account is always available. It will not have ability to log into a server or any elevated privilege.
  • Delegate the ability to manage computer objects to the user with the Active Directory Users and Computers snap in (from JSI Tip 8144 with tweaks).
    • Open the Active Directory Users and Computers snap-in.
    • Right click the container under which you want the computers added (ex: Computers) and choose Delegate Control.
    • Click Next.
    • Click Add and supply your user account(s), e.g domainjoin. Click Next when complete.
    • Select Create custom task to delegate and click Next.
    • Select Only the following objects in the folder and then check Computer objects and Create selected objects in this folder. Click Next.
    • Under Permissions, check Create All Child Objects and Write All Properties. Click Next.
    • Click Finish

Increase the MachineAccountQuota value

The second step is to increase the quota from the default value of 10. This appears to be done domain-wide, so all users will get the new quota. I somehow doubt that will be a problem, but if it is, you will have to do further research on how to proceed. To increase the quota, we just need a single command entered in an Administrative PowerShell terminal.

Set-ADDomain example.com -Replace @{"ms-ds-MachineAccountQuota"="10000"}

I used 10,000 because we have less than 100 nodes ready to join the domain. You can increase the value if your scale is a bit higher. I’m sure there’s a way to reset the quota, too, I just haven’t found it yet.

Joining your node to the domain

You’re now ready to join your node to the domain with your new least-privilege account domainjoin. I have created a puppet module, domain_join, to meet my personal needs. I’d love to hear how you’re tackling this issue, especially if the solution is better than mine!

2 thoughts on “Create a Least-Privilege account to perform domain joins”

  1. Hey Rob.

    This prompted me to share what I did. I have a puppet profile that automatically joins a node to Active Directory using a least privilege account that can only join computers to a specified OU. It takes care to check if the node is already joined to avoid repeat join commands. It also supports adding a HTTP principal to the keytab, a requirement for me.

    I agree with the lack of info on the matter. My hack is a combination of probably close to ten different sources around forums and stackoverflow.


    class profile::adjoin(
    $http_service_principal = false
    ) {
    if !defined(Class['::profile::kerberos']) {
    fail('::profile::kerberos needs to be defined for profile::adjoin to work')
    }
    $active_directory_domain = 'EXAMPLE.COM'
    $join_account = 'puppet-adjoin'
    $join_pwd = 'thepassword'
    $join_ou = 'Servers/Linux'
    validate_bool($http_service_principal)
    validate_string($active_directory_domain)
    validate_string($join_account)
    validate_string($join_pwd)
    validate_string($join_ou)
    package { 'samba-common':
    ensure => present,
    }
    file { '/etc/samba/adjoin.conf':
    ensure => present,
    owner => 'root',
    group => 'root',
    mode => '0640',
    content => template('profile/adjoin/samba-join.conf.erb'),
    require => Package['samba-common'],
    }
    exec { "adjoin to ${active_directory_domain}":
    command => "echo \${KINIT_PWD} | kinit ${join_account}@${active_directory_domain} && net ads join -s /etc/samba/adjoin.conf -U ${join_account}@${active_directory_domain} -n ${::hostname} createcomputer='${join_ou}' osName='${::operatingsystem}' osVer=${::operatingsystemmajrelease} -k",
    unless => "net ads testjoin -k -s /etc/samba/adjoin.conf | grep -q 'Join is OK'",
    provider => shell,
    user => 'root',
    environment => "KINIT_PWD=${join_pwd}",
    path => '/usr/sbin:/usr/bin:/sbin:/bin',
    require => [
    File['/etc/samba/adjoin.conf'],
    Class['::profile::kerberos'],
    ],
    before => Exec['destroy kerberos ticket'],
    logoutput => true,
    }
    if $http_service_principal {
    exec { "add HTTP service principal":
    command => "echo \${KINIT_PWD} | kinit ${join_account}@${active_directory_domain} && net ads -s /etc/samba/adjoin.conf -k keytab add HTTP",
    unless => [ "klist -kt /etc/krb5.keytab | grep -i HTTP/${::hostname}", "klist -kt /etc/krb5.keytab | grep -i HTTP/${::fqdn}", ],
    provider => shell,
    user => 'root',
    environment => "KINIT_PWD=${join_pwd}",
    path => '/usr/sbin:/usr/bin:/sbin:/bin',
    require => [
    File['/etc/samba/adjoin.conf'],
    Class['::profile::kerberos'],
    ],
    before => Exec['destroy kerberos ticket'],
    logoutput => true,
    }
    }
    exec { 'destroy kerberos ticket':
    command => 'kdestroy',
    onlyif => 'test -f /tmp/krb5cc_0',
    path => '/usr/sbin:/usr/bin:/sbin:/bin',
    }
    }

    view raw

    adjoin.pp

    hosted with ❤ by GitHub


    class profile::kerberos {
    # module Aethylred/kerberos
    class { '::kerberos':
    default_realm => 'EXAMPLE.COM',
    }
    kerberos::realm { 'EXAMPLE.COM':
    kdc => [ 'dc1.example.com', 'dc2.example.com', 'dc3.example.com' ],
    admin_server => 'dc1.example.com:749',
    default_domain => 'example.com',
    }
    kerberos::domain_realm { '.example.com':
    realm => 'EXAMPLE.COM',
    }
    kerberos::domain_realm { 'example.com':
    realm => 'EXAMPLE.COM',
    }
    kerberos::logging { 'default':
    key => 'default',
    value => 'FILE:/var/log/krb5libs.log',
    }
    kerberos::logging { 'kdc':
    key => 'kdc',
    value => 'FILE:/var/log/krb5kdc.log',
    }
    kerberos::logging { 'admin_server':
    key => 'admin_server',
    value => 'FILE:/var/log/kadmind.log',
    }
    }

    view raw

    kerberos.pp

    hosted with ❤ by GitHub


    [global]
    workgroup = EXAMPLE
    server string = Samba Server Version %v
    security = ads
    realm = EXAMPLE.COM
    kerberos method = system keytab

    view raw

    samba-join.conf.erb

    hosted with ❤ by GitHub

    Reply
  2. Pingback: Newsletter: March 26, 2016 | Notes from MWhite

Leave a Reply

Fill in your details below or click an icon to log in:

Gravatar
WordPress.com Logo

You are commenting using your WordPress.com account. ( Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. ( Log Out /  Change )

Cancel

Connecting to %s