When running adcli update and setting the service-name parameter to create an additional SPN entry on the computer account:
adcli update --service-name HTTP
no SPN entry is added to the computer account
no SPN entry is added to the keytab
no mention of the service principle is made in the verbose output
creating a SPNs during "adcli join" works.
Right now I'm fighting with adding Kerberos SPN for
other services and hit this bug.
So current approach is join domain with realmd to get setup of
necessary things on Linux machine in automated way, then leave with
adcli and then join again with adcli with --service-name parameter
having effect. It would be much more straightforward to be able to do
this with adcli update (or resort to setspn.exe from windows side).
I understand, that AD is strange blackbox, so if it is not possible to
solve it with reasonable amount of effort, we must face up that fact.
But if it is matter whether there are other users, who are affected
with it too - not only original bug reporter, they are ;)
By default 'adcli update ...' uses the host key from the default keytab (etc/krb5.keytab) to authenticate as the host against AD. Typically the host itself is not allowed to change any of its own attributes expect the password.
According to the adcli man page:
If used with a credential cache other attributes of the computer account can be changed as well if the principal has sufficient privileges.
$ kinit Administrator
$ adcli update --login-ccache=/tmp/krbcc_123
Did you try this? If you are not sure about what is your credential cache you can call 'klist' after 'kinit' and use what is printed after 'Ticket cache:' including any prefixes like FILE:, DIR:, KEYRING: etc.
-- 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/12.