Computer accounts in Active Directory have the "Validated write to service principal name" permission assigned to "SELF".  This allows domain joined systems to manage their own SPNs.  On a domain joined client with proper Samba configuration I can obtain a ticket for the computer account and add an SPN as follows:

kinit -k <COMPUTER>\$@<DOMAIN>
net ads keytab add <SPN> -k

I can also create a new keytab file containing only the new SPN like this:
KRB5_KTNAME=FILE:/etc/service.keytab net ads keytab add <SPN> -k


Expected results:
adcli join - Require either username/password or valid Kerberos ticket to (re-)join a client to a domain and populate the system keytab with the computer account and the host SPN.

adcli update - Do not require credentials, but rather use the existing computer account from system keytab to update the account password and/or create new SPNs.  SPNs would be added to the system keytab by default, or optionally to a specified keytab file for use by services running as non-root users.

(In reply to Chris from comment #2)
> Computer accounts in Active Directory have the "Validated write to service
> principal name" permission assigned to "SELF".  This allows domain joined
> systems to manage their own SPNs.  On a domain joined client with proper
> Samba configuration I can obtain a ticket for the computer account and add
> an SPN as follows:
> 
> kinit -k <COMPUTER>\$@<DOMAIN>
> net ads keytab add <SPN> -k
> 
> I can also create a new keytab file containing only the new SPN like this:
> KRB5_KTNAME=FILE:/etc/service.keytab net ads keytab add <SPN> -k
> 
> 
> Expected results:
> adcli join - Require either username/password or valid Kerberos ticket to
> (re-)join a client to a domain and populate the system keytab with the
> computer account and the host SPN.
> 
> adcli update - Do not require credentials, but rather use the existing
> computer account from system keytab to update the account password and/or
> create new SPNs.  SPNs would be added to the system keytab by default, or
> optionally to a specified keytab file for use by services running as
> non-root users.

A similar sequence like the one you showed for net should already work:

    kinit -k <COMPUTER>\$@<DOMAIN>
    adcli update --login-ccache --service-name=xyz

Does this solve the issue for you?

bye,
Sumit

(In reply to Sumit Bose from comment #0)
> Description of problem:
> The following issues reported by ondrej.valousek are still open:
> 
> 
> 
> Exact steps to reproduce:
> 1. use "net ads join" to join computer to domain
> 2. Clear the ServicePrincipalName value via ADUC Attribute Editor
> 3. Clear local keytab: echo -e "\0005\0002\c" > /etc/krb5.keytab
> 4a. # adcli -v join <domain_name> -U <admuser>
> - receiving ATT_OR_VALUE_EXISTS error
> - servicePrincipalName remains blank
> 4b. # adcli -v join <domain_name> -U <admuser> --service-name nfs
> - receiving ATT_OR_VALUE_EXISTS error
> - servicePrincipalName remains blank
> - 'klist -k' shows the "nfs" service principal, but the "host" principal is
> gone. I think we should always insert "host" principal. Even the man page
> says "...Additional service name for kerberos...."

I think the ATT_OR_VALUE_EXISTS and the resulting empty servicePrincipalName attribute is a consequence of a short hostname and should be fixed by adcli-0.8.1-6.el7_6.1 (https://access.redhat.com/errata/RHBA-2019:0200). Can you verify this?

This would leave to always add host/... during join even with --service-name given.

bye,
Sumit

> A similar sequence like the one you showed for net should already work:
> 
>     kinit -k <COMPUTER>\$@<DOMAIN>
>     adcli update --login-ccache --service-name=xyz
> 
> Does this solve the issue for you?

Well it probably would, but I still think the cleaner solution would be if adcli performs the "kinit" automatically here and do not rely on user (relatively deep) knowledge of AD internals.

(In reply to Ondrej from comment #5)
> > A similar sequence like the one you showed for net should already work:
> > 
> >     kinit -k <COMPUTER>\$@<DOMAIN>
> >     adcli update --login-ccache --service-name=xyz
> > 
> > Does this solve the issue for you?
> 
> Well it probably would, but I still think the cleaner solution would be if
> adcli performs the "kinit" automatically here and do not rely on user
> (relatively deep) knowledge of AD internals.

Of course

    adcli update --service-name=xyz

would work as well since adcli in update mode will by default use the keytab to authenticate. I just got the impression that Chris was asking about using an existing credential cache.

bye,
Sumit

Hi all,

Both of the cases attached to this bug have been closed due to customer inactivity. I will provide the suggested use of adcli to both cases, but at this time I think this Bug can be closed.

Thank you for your help on this issue.

Corey Brown

Hi,
Not sure where is my activity needed/requested? Must have missed that...
Otherwise I am happy to test if it got fixed already.
Ondrej

(In reply to Ondrej from comment #8)
> Hi,
> Not sure where is my activity needed/requested? Must have missed that...
> Otherwise I am happy to test if it got fixed already.
> Ondrej

Hi,

please see comment #4. I'm pretty sure the ATT_OR_VALUE_EXISTS issue is fixed by the latest z-stream release but it would be nice if you can confirm this. But as said I will use this ticket to make sure host/... is always added during join.

bye,
Sumit

Not sure what z-stream actually means. Yum offers me version 0.8.1-6.el7_6.1.
Is that one sufficient?

(In reply to Ondrej from comment #11)
> Not sure what z-stream actually means. Yum offers me version 0.8.1-6.el7_6.1.
> Is that one sufficient?

Yes, this version should contain the fix for ATT_OR_VALUE_EXISTS.

bye,
Sumit

Ok just tried with 0.8.1-6.el7_6.1 and can confirm the ATT_OR_VALUE_EXISTS does not appear any more.
This leaves us with 3 issues still open:

1. adcli join --service-name=xyz omits the host principal(s)
2. adcli update --service-name=xyz does not work
3. adcli should actually add two versions of host/ principal (much like the `net ads join` does), one for `hostname -s` and second for `hostname -f` (which is currently missing). The lack of the long version means sshd can not validate TGT for incoming gssapi authentication for example so ssh asks for a password.

Ondrej

(In reply to Ondrej from comment #13)
> Ok just tried with 0.8.1-6.el7_6.1 and can confirm the ATT_OR_VALUE_EXISTS
> does not appear any more.

Thank you for testing.

> This leaves us with 3 issues still open:
> 
> 1. adcli join --service-name=xyz omits the host principal(s)

yes, this will be handled by this ticket.

> 2. adcli update --service-name=xyz does not work

What does not work? Can you send the verbose output of adcli? I just tried and the xzy service principal was added to the keytab and to the AD LDAP object.

> 3. adcli should actually add two versions of host/ principal (much like the
> `net ads join` does), one for `hostname -s` and second for `hostname -f`
> (which is currently missing). The lack of the long version means sshd can
> not validate TGT for incoming gssapi authentication for example so ssh asks
> for a password.

This it handled by https://bugzilla.redhat.com/show_bug.cgi?id=1595911.

bye,
Sumit

> 
> Ondrej

> What does not work? Can you send the verbose output of adcli? I just tried
> and the xzy service principal was added to the keytab and to the AD LDAP
> object.

Well it looks and feels it works:
[root@skynet18 ~]# adcli update -D <domain> -v --service-name=nfs
...
 * Enrolling computer name: SKYNET18
 * Generated 120 character computer password
 * Using keytab: FILE:/etc/krb5.keytab
 * Found computer account for SKYNET18$ at: <...>
 * Retrieved kvno '12' for computer account in directory: <...>
 * Password not too old, no change needed
 * Sending netlogon pings to domain controller: cldap://x.y.z.
 * Received NetLogon info from: XXXX
 * Added the entries to the keytab: SKYNET18$@<domain>: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: host/SKYNET18@<domain>: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: RestrictedKrbHost/SKYNET18@<domain>: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: nfs/SKYNET18@<domain>: FILE:/etc/krb5.keytab

but klist -k does not show any nfs principal in my keytab, only entries with older kvno (11).

(In reply to Ondrej from comment #15)
> > What does not work? Can you send the verbose output of adcli? I just tried
> > and the xzy service principal was added to the keytab and to the AD LDAP
> > object.
> 
> Well it looks and feels it works:
> [root@skynet18 ~]# adcli update -D <domain> -v --service-name=nfs
> ...
>  * Enrolling computer name: SKYNET18
>  * Generated 120 character computer password
>  * Using keytab: FILE:/etc/krb5.keytab
>  * Found computer account for SKYNET18$ at: <...>
>  * Retrieved kvno '12' for computer account in directory: <...>
>  * Password not too old, no change needed
>  * Sending netlogon pings to domain controller: cldap://x.y.z.
>  * Received NetLogon info from: XXXX
>  * Added the entries to the keytab: SKYNET18$@<domain>: FILE:/etc/krb5.keytab
>  * Added the entries to the keytab: host/SKYNET18@<domain>:
> FILE:/etc/krb5.keytab
>  * Added the entries to the keytab: RestrictedKrbHost/SKYNET18@<domain>:
> FILE:/etc/krb5.keytab
>  * Added the entries to the keytab: nfs/SKYNET18@<domain>:
> FILE:/etc/krb5.keytab
> 
> but klist -k does not show any nfs principal in my keytab, only entries with
> older kvno (11).

Sorry, can you be more specific? Feel free to send me the klist -k output directly instead of answering the questions below.

Do you mean there is none nfs entry at all or only nfs entries with kvno 11 while the current one is 12?

Does the keytab contain only entries with kvno 11 and none with 12? In this case a previous password update might have failed, i.e. updated the password on AD but didn't update the keytab.

bye,
Sumit

Sorry, yes. /etc/krb5.keytab remains intact - i.e. no nfs entries, all entries with kvno 11.
I can send you the output directly - but seems to me adcli is not doing what it is saying it is doing.
Ondrej

(In reply to Ondrej from comment #17)
> Sorry, yes. /etc/krb5.keytab remains intact - i.e. no nfs entries, all
> entries with kvno 11.
> I can send you the output directly - but seems to me adcli is not doing what
> it is saying it is doing.

I think I do not need the output. If there are only knvo 11 entries in the keytab the behavior can be explained. Since AD said the current kvno is 12 adcli is looking for an entry with kvno 12 in the keytab to copy the keys fir the new nfs entry. Since there is no entry with kvno 12 no new entry can be created. 'Added the entries to the keytab: nfs/SKYNET18@<domain>: FILE:/etc/krb5.keytab' message is wrongly displayed because an error condition was not propagated correctly. I will fix this.

I'm a bit puzzled why adcli can still authenticate with your keytab although the different kvnos indicate different keys. Did you by chance call 'adcli update' once with user credentials by using the -C/--login-ccache option? In that case you might have hit https://bugzilla.redhat.com/show_bug.cgi?id=1642546 "adcli exports kerberos ticket with old kvno" (sorry, private ticket). If that's the case can you sync AD and keytab by doing an adcli join again and then try to add the the nfs service again?

bye,
Sumit

> Ondrej

I was running the adcli update immediately after adcli join which I ran on a machine which was joined to domain with "net ads join", but I then cleared keytab (so technically "adcli join" was only used to repopulate keytab).
Also, running "adcli update -v update --service-name=nfs -C" (with my admin user creds) makes no difference (adcli says it is adding entry to keytab but reality is different).
Ondrej

(In reply to Ondrej from comment #19)
> I was running the adcli update immediately after adcli join which I ran on a
> machine which was joined to domain with "net ads join", but I then cleared
> keytab (so technically "adcli join" was only used to repopulate keytab).
> Also, running "adcli update -v update --service-name=nfs -C" (with my admin
> user creds) makes no difference (adcli says it is adding entry to keytab but
> reality is different).

Sorry, I meant if you have some time ago called adcli update with the -C/--login-ccache  at a time where the password was older than 30 days and adcli would have renewed it. In this case adcli would have written the news keys but with the old kvno into the keytab.

If you now call

    adcli update -D <domain> -v --computer-password-lifetime=0

(_no_ -C option) this would force an update of the computer password and update the keytab and the AD entry so that both will have the same kvno again. After that

    adcli update -D <domain> -v --service-name=nfs
 
should hopefully add the nfs entry.

bye,
Sumit


> Ondrej

right, yes.
running update --computer-password-lifetime=0 and then update --service-name=nfs does result in nfs principal in the krb5.keytab.
Does it mean I am hitting the internal bug you mentioned?
If so, will you keep us informed when is this resolved?
Thx,

Ondrej

(In reply to Ondrej from comment #21)
> right, yes.
> running update --computer-password-lifetime=0 and then update
> --service-name=nfs does result in nfs principal in the krb5.keytab.

Thank you for testing and confirming the behavior.

> Does it mean I am hitting the internal bug you mentioned?

yes

> If so, will you keep us informed when is this resolved?

It will be fixed in the next RHEL7 release.


So this ticket will be used to track:

> 1. adcli join --service-name=xyz omits the host principal(s)

bye,
Sumit

Upstream commits:
 - https://gitlab.freedesktop.org/realmd/adcli/commit/4987a21f4839ab7ea50e932c72df05075efb89b3
 - https://gitlab.freedesktop.org/realmd/adcli/commit/cd296bf24e7cc56fb8d00bad7e9a56c539894309

I'm digging into an issue that's been giving me problems for a while, and I'm uncertain if this bug covers this case. Reading through the comments, I'm still uncertain. The issue I've observed: if a short name is returned during hostname lookup, it is expanded to the FQDN - however while doing so, the servicePrincipalName is added again spuriously, causing an ATT_OR_VALUE_EXISTS error.

Does this (#1644311) issue intersect with this upstream issue? https://gitlab.freedesktop.org/realmd/adcli/issues/1

If it's unrelated and not already taken in from upstream, I'd be happy to file a new bug. (The referenced upstream bug there was closed with two merges approximately two months back.)

(In reply to Paul Bransford from comment #25)
> I'm digging into an issue that's been giving me problems for a while, and
> I'm uncertain if this bug covers this case. Reading through the comments,
> I'm still uncertain. The issue I've observed: if a short name is returned
> during hostname lookup, it is expanded to the FQDN - however while doing so,
> the servicePrincipalName is added again spuriously, causing an
> ATT_OR_VALUE_EXISTS error.
> 
> Does this (#1644311) issue intersect with this upstream issue?
> https://gitlab.freedesktop.org/realmd/adcli/issues/1
> 
> If it's unrelated and not already taken in from upstream, I'd be happy to
> file a new bug. (The referenced upstream bug there was closed with two
> merges approximately two months back.)

Not related to this ticket, I think what you are looking for is https://bugzilla.redhat.com/show_bug.cgi?id=1595911.

HTH

bye,
Sumit

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2019:2256