Shooting for the moon with this question here. In Windows if you join a client to an AD domain and later if you want to rename the computer object you can do so "seamlessly" without it breaking the AD membership of the client. I want to accomplish the same functionality with SSSD in Linux (RHEL in my case) for hosts joined with realm (or perhaps manually via net ads join).
But I want a way for the join to be persistent and versatile. It would be nice if this were automatic but is fine if I need to issue some local commands. My worry is that if I join and then change the computer object name that the information stored locally from the join will mismatch and break it.
SCENARIO
So for sake of a scenario, let's say that I want to rename HOST7_CLONE to HOST7. There are two versions of this scenario:
- Where only the computer object in AD named "HOST7_CLONE" is being renamed to "HOST7".
- Both the computer object in AD and the local linux hostname are renamed from "HOST7_CLONE" to "HOST7".
The first question is, does the local linux hostname need to change if the the computer object is renamed or are those separate considerations? Secondly, even if not needed but rather desired does #2 pose any additional challenges?
Assuming one does not need to rename the local linux host, to simplify things, let's say the local linux hostname stays the same (#1).
TECHNICAL DETAILS
So next, I noticed that if you run net ads status that there are some fields that might be relevant:
name: host7_clone
objectGUID: x
userAccountControl: 69632
codePage: 0
countryCode: 0
lastLogon: 132307605314743751
localPolicyFlags: 0
pwdLastSet: 132307506720641880
primaryGroupID: 515
objectSid: z
accountExpires: 9223372036854775807
logonCount: 14
sAMAccountName: HOST7_CLONE$
sAMAccountType: 805306369
dNSHostName: host7_clone.core.org
servicePrincipalName: HOST/host7_clone.core.org
servicePrincipalName: HOST/HOST7_clone
Particularly the objectGUID and servicePrincipalName look relevant. For objectGUID I would expect this to remain the same after a rename of the object, hopefully being an independent and unique value regardless of the AD computer object name. I looked for a way in krb5.conf and sssd.conf to specify a objectGUID you wanted to bind against explicitly, however, and couldn't find anything.
So then that led me to what I expect would be the main problem of having the servicePrincipalName update to the new computer object name accordingly. The best I could find to address this was a command I found to manually manipulate this using a kerberos command: kadmin rename_principal. However, this seems a bit esoteric and I'm afraid to start messing with the kerberos ticket.
As for the objectSid, is that the SID of the AD computer object itself? If so, would the objectSid be a better unique identifier than the object GUID?
Likely I'm over complicating this, but just wanted to brainstorm a bit. The key here is that I want to stay joined. Unjoining and rejoining would require manual intervention with authentication; whereas even if I need to issue some other manual commands (like kadmin) I could script and automate that without human intervention (hopefully; at least that's the goal).
In the end I still have no conceptual way forward for what procedure would need to be done to have the host stay joined to the domain even if renamed.
Suggestions would be much appreciated.
