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?
> 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.
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?
(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:
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?
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.
-- 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.