What account are you joining the computer with and what rights does it have on the OU where you’re putting it? I overwrite existing objects all the time and I’ve not done anything different. It seems like it might be the rights of the account performing the join on the OU where the join is happening to me? I also do the join a little different, I use adcli in our solution (because we still have RHEL6 where there is no realmd)
adcli join --domain="$DOMAIN" --login-user="$JOIN_USER" --domain-controller="$DOMAIN_LDAP_HOST" --stdin-password --service-name='host' --service-name='RestrictedKrbHost' --os-name="$OS_NAME" --os-version="$OS_VERSION_FULL " --domain-ou="$OPT_CONTAINER" --show-details I’m not sure what realmd abstracts or not from this, but this join overwrites the object with the new info, increments the knvo in the keytab and on the object in AD. In doing testing I can have the knvo version on the object in AD be in the double digits and each time I join to the same object the knvo in the keytab on the client matches it. The join user has full control over objects in the OU where adcli performs the join. Todd From: Spike White <[email protected]> Sent: Thursday, June 20, 2019 10:02 AM To: End-user discussions about the System Security Services Daemon <[email protected]> Subject: [SSSD-users] Have 'realm join' overwrite host credentials if AD machine object already exists.... All, We have a certain end condition that's troubling. I'm guessing we can just throw a flag to realm join, or put a setting in /etc/realmd.conf to fix. Let me explain. Here's the usual situation. New fresh build. We join the AD domain as so: realm join -v --automatic-id-mapping=no --computer-ou="OU=Servers,OU=UNIX,DC=$SUPPORTREGION,DC=COMPANY,DC=COM" --user-principal="host/`hostname --fqdn`@$JOINDOMAIN" $JOINDOMAIN Fresh build -- this works fine. This creates the machine object in AD, in our specific OU. Sets the hosts credentials in that machine object, saves these host credentials in /etc/krb5.keytab file. Life is good. When we re-image a server, hopefully we remember to do a 'realm leave <DOMAIN>' prior to re-imaging. That goes out, destroys the AD machine object in our OU, possibly other cleanups. Then we re-image. realm join (as above) finds no AD object, it does the usual. Life is good. Here's the end condition that isn't good. If we re-image and we've forgotten to 'realm leave <DOMAIN>', then a pre-existing AD object exists already in our OU. By the desired name. In that case, when we re-image the above 'realm join' invocation does not overwrite the host creds in this pre-existing machine object. And does not create an /etc/krb5.keytab file. Because it does not create an /etc/krb5.keytab file the 'realm join' does not fully successfully complete. We have experience with a previous (3rd party) AD integration product. In that product, if you have a pre-existing AD object, it informs you an AD object has been found, existing configuration will be overwritten. Then it updates the host creds in that pre-existing machine object and it lays down a keytab file with the host creds. That is, if it finds a pre-existing AD machine object it soldiers on anyway. We'd like to tweak our realm join to do that behavior. If pre-existing AD machine object detects, overwrite the host creds in that machine object and create /etc/krb5.keytab file with those same host creds. I.e., soldier on. What flag do we throw to realm join to do that? Or what setting in /etc/realmd.conf do we set? This is on RHEL7 (sssd version 1.16.2-13) and RHEL8 (sssd version 2.0.0-23). Spike
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
