{"id":183,"date":"2020-08-17T13:00:00","date_gmt":"2020-08-17T13:00:00","guid":{"rendered":"http:\/\/10.171.10.16:10000\/?p=183"},"modified":"2022-01-16T17:15:16","modified_gmt":"2022-01-16T17:15:16","slug":"centos-kickstart-ad-joining","status":"publish","type":"post","link":"https:\/\/dannypayne.me\/?p=183","title":{"rendered":"CentOS kickstart: AD Joining"},"content":{"rendered":"\n

This is the forth (and probably final!) post in a series on building\/setting up\/improving a PXE boot server with CentOS.
By the end of this post, we’ll have modified our kickstart file to allow copying of scripts and files to automate the process of our VM joining Active Directory. We’ll also automate creation of an AD group to allow specific users sudo<\/code> access on our VM.
Why would we want to join our VM to Active Directory? For a number of reasons! Joining an AD Domain allows us to authenticate with an AD account on the VM instead of using local accounts on the VM. It also allows us to control who has sudo<\/code> access via AD security groups, which I’m going to cover in this post. <\/p>\n\n\n\n

A requirement for this to all work properly is of course a working Active Directory environment – we’ll need to have AD DS installed on a Windows Server VM, and DNS pointing towards our Domain Controller. We’ll also need an account within AD that is either a Domain Admin (not ideal) or<\/em> a service account with delegated permissions to create computer objects<\/strong> and create group objects<\/strong> (ideal). <\/p>\n\n\n\n

Creating our AD service account<\/h3>\n\n\n\n

To get things started, we’re going to want to create our AD service account for joining our VM’s to AD.
In my example, I’m creating a user with the username<\/strong> and full name<\/strong> set to LinuxADJoinService<\/code>. The user is created in the following location: ad.goatfarm.co.uk > Goatfarm Users > Service accounts<\/em>. The users password is set to not expire<\/strong> and the user cannot change password<\/strong>.
Make note of the users password, we’ll need that soon.<\/strong> I generally use passwordsgenerator.net<\/a> to generate passwords. <\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

Next, we need to delegate control so the LinuxADJoinService<\/code> account can create computer objects. Inside of ADUC, find or create your OU for where the VM’s computer objects will be placed, right-click it and select Delegate Control…<\/strong>
Click Next<\/strong> on the first step of the wizard, and when prompted, click Add<\/strong> and find the account you just created. Hit Next<\/strong> again.<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

When prompted to select Tasks to Delegate<\/strong> select Create a custom task to delegate<\/strong> and click Next<\/strong>.
On the next page of the wizard, select Only the following objects in the folder<\/strong>, and then tick Computer Objects<\/strong>. At the bottom of the wizard, select Create selected objects in this folder<\/strong> and then click Next<\/strong>. <\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

On the next page of the wizard, tick General<\/strong> and Creation\/deletion of specific child objects<\/strong>. Within the Permissions<\/strong> box, find and tick Create all Child Objects<\/strong> and click Next<\/strong>. <\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

Finally, click Finish<\/strong> and we’re done! We just need to do this one more time to allow creation of groups within our Security Groups OU – the process is the same, however instead of selecting Computer Objects<\/strong>, we select Group Objects<\/strong>.<\/p>\n\n\n\n

Modifying our kickstart file<\/h3>\n\n\n\n

Time to SSH into our PXE server! Once again, we need to modify our kickstart file. This time, we need to add the required packages for domain joining and authentication to the packages<\/strong> section. <\/p>\n\n\n\n

%packages\n@base\n@core\n...\n# Required for AD Authentication\nsssd\nrealmd\noddjob\noddjob-mkhomedir\nadcli\nsamba-common\nsamba-common-tools\nkrb5-workstation\nopenldap-clients\npolicycoreutils-python\n...\n%end<\/code><\/pre>\n\n\n\n
Next, we need to add a few lines to our post<\/strong> section to wget<\/code> our domain join script. 
In the previous post, we added a line to edit the root crontab – we need to remove this and replace it with another line to call our domainjoin<\/code> script instead. The buildcleanup<\/code> script will be added to the root crontab as part of the domainjoin<\/code> script. Our post<\/strong> section should look something like the below:<\/p>\n\n\n\n
\n%post --log=\/tmp\/post-build.log\n...\n#########################################\n# Copy our domain join script\nwget -O \/tmp\/build\/domainjoin.sh ftp:\/\/10.176.40.10\/centos7\/config\/domainjoin.sh\nchmod +x \/tmp\/build\/domainjoin.sh\necho \"@reboot sleep 60 && \/tmp\/build\/domainjoin.sh && \/sbin\/shutdown -r now\" > \/var\/spool\/cron\/root\n\n#########################################\n# Copy our build cleanup script\nwget -O \/tmp\/build\/buildcleanup.sh ftp:\/\/10.176.40.10\/centos7\/config\/buildcleanup.sh\nchmod +x \/tmp\/build\/buildcleanup.sh\n\n...\n%end\n<\/code><\/pre>\n\n\n\n
Create domain join script<\/h3>\n\n\n\n
We now need to create the domain joining script. 
The script is basically pre-creating the computer account within AD in the location specified in the domain-ou<\/code> option with the machine password specified by one-time-password<\/code>, and then verifying the location of the pre-created computer object with the computer-ou<\/code> option then completing the join. 
We then copy the sssd.conf<\/code> and domainsudoers<\/code> files. After this the domainsudoers<\/code> file gets edited via sed<\/code> with an entry for the security group that’s created so we can manage sudoers permissions via AD. 
Finally, the root crontab is modified to run the buildcleanup<\/code> script after the next reboot. 

Note that the adcli preset-computer<\/code> command requires the full<\/strong> OU path within AD (both <\/strong>the Organisational Unit<\/strong> and Domain Component<\/strong> parts), whereas the realm join<\/code> command only requires a partial<\/strong> OU path (Organisational Unit<\/strong> only).
Similarly, the adcli create-group<\/code> command requires the full<\/strong> OU path within AD (both<\/strong> the Organisational Unit<\/strong> and Domain Component<\/strong> parts)<\/p>\n\n\n\n
#!\/bin\/bash\n# Pre-create the computer account with a password\n\/sbin\/adcli preset-computer --domain-ou=\"OU=Colo,OU=Goatfarm Servers,DC=ad,DC=goatfarm,DC=co,DC=uk\" --login-user=LinuxADJoinService --stdin-password --one-time-password='SuperTempPassword' --domain=ad.goatfarm.co.uk $HOSTNAME.ad.goatfarm.co.uk <<< 'LinuxADJoinServicePassword'\n# Complete the AD join process with the one-time-password and place the computer account in a specific location\n\/sbin\/realm join --computer-ou=\"OU=Colo,OU=Goatfarm Servers\" --one-time-password='SuperTempPassword' ad.goatfarm.co.uk\n\nsleep 10\nsystemctl restart sssd\nsleep 10\n\n# Copy sssd.conf file\nwget -O \/tmp\/build\/sssd.conf ftp:\/\/10.176.40.10\/centos7\/config\/sssd.conf\ncp -rf \/tmp\/build\/sssd.conf \/etc\/sssd\/sssd.conf\n\n# Copy and fix our domainsudoers file\nwget -O \/tmp\/build\/domainsudoers ftp:\/\/10.176.40.10\/centos7\/config\/domainsudoers\nsed -i s^'HOSTNAME'^\"$HOSTNAME\"^ \/tmp\/build\/domainsudoers\ncp -rf \/tmp\/build\/domainsudoers \/etc\/sudoers.d\/domainsudoers\n\n# Create the AD sudoers security group related to this specific VM in a specific OU within AD\n\/sbin\/adcli create-group \"\"$HOSTNAME\" SUDOERS\" --domain=ad.goatfarm.co.uk --domain-ou=\"OU=CentOS Sudoers,OU=Goatfarm Groups,DC=ad,DC=goatfarm,DC=co,DC=uk\" --login-user=LinuxADJoinService --stdin-password <<< 'LinuxADJoinServicePassword'\n\n# Add our buildcleanup script back into the root crontab\necho \"@reboot sleep 60 && \/tmp\/build\/buildcleanup.sh && \/sbin\/shutdown -r now\" > \/var\/spool\/cron\/root<\/code><\/pre>\n\n\n\n
Our sssd.conf<\/code> and domainsudoers<\/code> files contain the following:<\/p>\n\n\n\n
[sssd]\ndomains = ad.goatfarm.co.uk\nconfig_file_version = 2\nservices = nss, pam\n\n[domain\/ad.goatfarm.co.uk]\nad_domain = ad.goatfarm.co.uk\nkrb5_realm = AD.GOATFARM.CO.UK\nrealmd_tags = manages-system joined-with-adcli\ncache_credentials = True\nid_provider = ad\nkrb5_store_password_if_offline = True\ndefault_shell = \/bin\/bash\nldap_id_mapping = True\nuse_fully_qualified_names = False\nfallback_homedir = \/home\/%u\naccess_provider = ad<\/code><\/pre>\n\n\n\n
%AD\\\\HOSTNAME\\ SUDOERS    ALL=(ALL)       NOPASSWD:ALL\n%AD\\\\CentOS\\ Sudoers\\ ALL    ALL=(ALL)    NOPASSWD:ALL<\/code><\/pre>\n\n\n\n
The sssd.conf<\/code> file is default apart from the fallback_homedir<\/code> value changed to not include %d<\/code> (domain). 
The domainsudoers<\/code> file is modified by the sed<\/code> command inside the domainjoin<\/code> script to point towards the VM specific AD group that the domainjoin<\/code> script created earlier, and also an overall CentOS Sudoers ALL<\/code> AD group that exists within my AD.
We could probably get away with sed<\/code>-ing the sssd.conf<\/code> file, however replacing the file with our modified one accomplishes the same thing. <\/p>\n\n\n\n
Bringing it all together<\/h3>\n\n\n\n
Once again, we’ve modified our kickstart a few times, so now would be a good time to run ksvalidator<\/code> against it to make sure there’s no errors.<\/p>\n\n\n\n
PXE boot a VM, give it a hostname and IP details, and wait for it to complete the build – the VM should reboot twice, and once everything has complete, we’ll receive an email containing the randomly generated root password, and also to say the build has completed. <\/p>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
We should also see a new AD computer object created within our specified OU, and a new AD group created within the specified OU named after the VM’s hostname.<\/p>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
If we now try and login to the VM with an Active Directory <\/strong>account we’ll successfully login and have our home directory created for us. 
After logging in, I’ve run the id<\/code> command to show that the user ad\\centosadmin<\/code> is in the CentOS Sudoers ALL<\/strong> group, and in theory should have sudo\/root permissions.  <\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
We can verify if we have sudo permissions by running sudo whoami<\/code>, if we have root<\/strong> returned, we’ve got sudo and everything is working as expected!<\/p>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
Similarly, if we was to login with an AD account that was in the B-PXEBOOT SUDOERS<\/code> AD group, we’d find that we also have sudo permissions. <\/p>\n\n\n\n
Wrapping up<\/h3>\n\n\n\n
In this post I’ve covered creating and delegating permissions to an AD service account, modifying our kickstart file once more to install packages required for AD authentication, and creating a script to automate the process of joining a CentOS VM to Active Directory. 
We’re now able to PXE boot a VM, select our kickstart file, feed it a hostname and IP details, and then leave it to build. Once the build has completed, we’re able to login via an AD account and gain sudo permissions (assuming the user is in the correct security group), and our randomly generated root password will be emailed to us. <\/p>\n","protected":false},"excerpt":{"rendered":"
This is the forth (and probably final!) post in a series on building\/setting up\/improving a PXE boot server with CentOS.<\/p>\n
Read moreCentOS kickstart: AD Joining<\/span><\/a><\/div>\n","protected":false},"author":1,"featured_media":217,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[12,6],"tags":[],"class_list":["post-183","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-archive","category-homelab","excerpt","zoom","full-without-featured","even","excerpt-0"],"jetpack_featured_media_url":"https:\/\/dannypayne.me\/wp-content\/uploads\/2020\/08\/2020-08-17-22_12_36-mRemoteNG-Homelab-MRemoteNG.xml-B-PXEBOOT.jpg","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/dannypayne.me\/index.php?rest_route=\/wp\/v2\/posts\/183","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dannypayne.me\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dannypayne.me\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dannypayne.me\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dannypayne.me\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=183"}],"version-history":[{"count":19,"href":"https:\/\/dannypayne.me\/index.php?rest_route=\/wp\/v2\/posts\/183\/revisions"}],"predecessor-version":[{"id":224,"href":"https:\/\/dannypayne.me\/index.php?rest_route=\/wp\/v2\/posts\/183\/revisions\/224"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/dannypayne.me\/index.php?rest_route=\/wp\/v2\/media\/217"}],"wp:attachment":[{"href":"https:\/\/dannypayne.me\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=183"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dannypayne.me\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=183"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dannypayne.me\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=183"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}