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
Show replies by thread
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 <spikewhitetx(a)gmail.com>
Sent: Thursday, June 20, 2019 10:02 AM
To: End-user discussions about the System Security Services Daemon
<sssd-users(a)lists.fedorahosted.org>
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