|Summary:||adcli join should not re-register, if the host is already known to AD|
|Product:||realmd||Reporter:||Mikhail T. <mi+freedesktop>|
|Component:||adcli||Assignee:||Stef Walter <stefw>|
|Status:||RESOLVED MOVED||QA Contact:|
|i915 platform:||i915 features:|
Description Mikhail T. 2016-07-20 22:04:40 UTC
We are trying to use adcli to obtain keytabs for hundreds of hosts. Most of the hosts are already registered (although we may not have their keytabs), but some aren't. It seems like the only way to obtain a host's keytab is by "join"-ing it (again) -- which updates AD changing the kvno, among other things. Is this really necessary? Can't the join simply use the existing record -- and its kvno -- to generate a new keytab?
Comment 1 Stef Walter 2016-07-21 07:41:37 UTC
> Is this really necessary? Can't the join simply use the existing record -- and its kvno -- to generate a new keytab? I wouldn't be against a patch that added an option. However ... that would be far from expected default behavior. Many (most?) AD deployments expect a new computer password change (the secret) on a regular schedule. That's why there's an 'adcli update' command in recent versions of adcli. It's very similar to join, with just a few tweaks.
Comment 2 Sumit Bose 2016-07-21 08:19:58 UTC
Afaik this is not possible because you cannot read the the host/maching account password from AD which is needed to generate the keys for the keytab. Samba's net utility has 'net ads keytab create' which looks like it can create a keytab from scratch but here the machine account password is stored in Samba's secret.tdb as well and used to generate the keytab. It is similar if you forgot your password, you cannot ask helpdesk to tell you your old password, it must be set to a new one. Maybe the preset-computer feature Stef describes in http://stef.thewalter.net/how-to-join-active-directory-domains.html might help in your environment?
Comment 3 Mikhail T. 2016-07-22 14:05:31 UTC
(In reply to Sumit Bose from comment #2) > It is similar if you forgot your password, you cannot ask helpdesk to tell > you your old password, it must be set to a new one. So, you are saying a new keytab can not be generated without changing the kvno and invalidating the old keytab... I thought, Sun's (Oracle's?) kclient script and friends: https://github.com/illumos/illumos-gate/tree/5a4ef21a18dfdc65328821a265582d03e85a97c9/usr/src/cmd/krb5/kadmin/kclient manage to do that... It seems, kclient.sh figures out the existing kvno and generates a keytab with that -- without changing the computer's record in KDC. Do you concur?
Comment 4 Sumit Bose 2016-07-22 14:43:10 UTC
Thank you for sharing the link to kclient.sh but if I read the code correctly a new password is generated for both cases (acount already exists or not) starting at line https://github.com/illumos/illumos-gate/blob/5a4ef21a18dfdc65328821a265582d03e85a97c9/usr/src/cmd/krb5/kadmin/kclient/kclient.sh#L1384 and is set in AD on line https://github.com/illumos/illumos-gate/blob/5a4ef21a18dfdc65328821a265582d03e85a97c9/usr/src/cmd/krb5/kadmin/kclient/kclient.sh#L1411 After that the kvno is read from AD an written together with the hashes of the new password to the keytab. This is what adcli does as well.
Comment 5 GitLab Migration User 2018-10-12 21:18:45 UTC
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/realmd/adcli/issues/5.