Bug 1547013

If you want to set SPNs even for a system which is already joined you can use

    adcli join --service-name=NFS --domain=<my domain>

But there is one pitfall, the --service-name option does not keep existing names, so you have to check either in the keytab or in the AD entry which names already exist. E.g. by default adcli uses 'host' and 'RestrictedKrbHost', to _add_ NFS you have to call

    adcli join --service-name=host --service-name=RestrictedKrbHost --service-name=NFS --domain=<my domain>


I agree that this is cumbersome and error-prone and I'll try to fix this together with the other ticket you opened (https://bugzilla.redhat.com/show_bug.cgi?id=1547014).

Well, this is cumbersome and does not reflect the man page either.
Man page suggests it should be possible to set SPN to an already joined system with "adcli update" (that what one would actually expect) - not adcli join.

So please fix this as well. "Adcli join" seems to me far too dangerous in this case - it looks and feels like it will actually overwrite an existing account.

Can you release the updated package for me to test?

Summary my problems (testing with adcli-0.8.1-3.el7, i.e. still the latest available):
1. "adcli --update --service-name=host/skynet18.mydomain.com --domain mydomain" does not work  - it appears to do nothing
2. adcli join mydomain.com does not populate the UPN and SPN attributes in AD in case the machine account already exists in AD. The error is:
 * Modifying computer account: userPrincipalName
 ! Couldn't set service principals on computer account CN=SKYNET18,OU=...,DC=com: 00002083: AtrErr: DSID-0315191D, #1:
	0: 00002083: DSID-0315191D, problem 1006 (ATT_OR_VALUE_EXISTS), data 0, Att 90303 (servicePrincipalName)
3. adcli join fills krb5.keytab only with host/`hostname -s`@REALM principals whereas "net ads join" also adds host/`hostname -f`@REALM principals
4. adcli join --service-name=host/myhost.mydomain.com does adds an incorrect principal in krb5.keytab in form "host/myhost.mydomain.com/myhost@REALM" which is not what I want

Is it realistic to expect all these 4 problems will be fixed in adcli-0.8.1-5.el7?

adcli-0.8.1-5.el7 is part of the RHEL-7.6 Beta (https://www.redhat.com/en/blog/red-hat-enterprise-linux-76-beta-now-available). Do you have access to the Beta release?

Please note a new option --add-service-principal was added to handle service principals more flexible.

Ok tried that. Seems like the problems I described above persists.
Most notably:
1. it seems adcli has problems updating serviceprincipalName attribute in case computer object already exists (getting the same error message as I mentioned above). "net ads join" does not suffer from this problem.
2. I think "host/FQDN" principal should be added by default (i.e. the same way 'net ads join' does) as it seems to me sshd uses 'host/FQDN' principals to verify tickets.

What do you think?

(In reply to Ondrej from comment #12)
> Ok tried that. Seems like the problems I described above persists.
> Most notably:
> 1. it seems adcli has problems updating serviceprincipalName attribute in
> case computer object already exists (getting the same error message as I
> mentioned above). "net ads join" does not suffer from this problem.

I guess you are using 'adcli update'. By default 'adcli update' uses the host credentials from the keytab and by default a host is not allowed to update its own attributes in AD. Please try to kinit as a user which is allowed to update host attributes and use the --login-ccache with 'adcli update'. If this still does not work please send the full command with the verbose output.

'net ads join' always asks for admin credentials so it will have sufficient permissions to update the attributes.


> 2. I think "host/FQDN" principal should be added by default (i.e. the same
> way 'net ads join' does) as it seems to me sshd uses 'host/FQDN' principals
> to verify tickets.
> 
> What do you think?

If the FQDN is set as the hostname, e.g. is the hostname command returns the FQDN, adcli will already use add the host/FQDN principal as well. There is https://bugzilla.redhat.com/show_bug.cgi?id=1595911 to handle the case where it doesn't.

HTH

bye,
Sumit

(In reply to Sumit Bose from comment #13)
> I guess you are using 'adcli update'. By default 'adcli update' uses the
> host credentials from the keytab and by default a host is not allowed to
> update its own attributes in AD. Please try to kinit as a user which is
> allowed to update host attributes and use the --login-ccache with 'adcli
> update'. If this still does not work please send the full command with the
> verbose output.
no I am using 'adcli join -v -U <admuser>' and entering my passwd. It still refuses to populate SPN on the AD side.

> If the FQDN is set as the hostname, e.g. is the hostname command returns the
> FQDN, adcli will already use add the host/FQDN principal as well. There is
> https://bugzilla.redhat.com/show_bug.cgi?id=1595911 to handle the case where
> it doesn't.
Right, that's it, indeed.

(In reply to Ondrej from comment #14)
> (In reply to Sumit Bose from comment #13)
> > I guess you are using 'adcli update'. By default 'adcli update' uses the
> > host credentials from the keytab and by default a host is not allowed to
> > update its own attributes in AD. Please try to kinit as a user which is
> > allowed to update host attributes and use the --login-ccache with 'adcli
> > update'. If this still does not work please send the full command with the
> > verbose output.
> no I am using 'adcli join -v -U <admuser>' and entering my passwd. It still
> refuses to populate SPN on the AD side.
> 

I tired to reproduce this an unfortunately I see an ATT_OR_VALUE_EXISTS error which is caused because adcli tries to add the servicePrincipalName value twice. Nevertheless I servicePrincipalName attributes on the AD DC with the --server-name values I gave on the command line.

Are you referring to the ATT_OR_VALUE_EXISTS error as well or do you see a different one?

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...."

So I still see 2 major issues there.

Question - what means Verified & release pending? To me the, the bug still does not seem to be fixed..

(In reply to Ondrej from comment #18)
> Question - what means Verified & release pending? To me the, the bug still
> does not seem to be fixed..

I will open a new ticket with your steps from comment #16 to cover them in the next release.

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-2018:3223

(In reply to Sumit Bose from comment #19)
> (In reply to Ondrej from comment #18)
> > Question - what means Verified & release pending? To me the, the bug still
> > does not seem to be fixed..
> 
> I will open a new ticket with your steps from comment #16 to cover them in
> the next release.

the follow-up ticket is https://bugzilla.redhat.com/show_bug.cgi?id=1644311. I already added you to CC, I hope you don't mind.

> I guess you are using 'adcli update'. By default 'adcli update' uses the
> host credentials from the keytab and by default a host is not allowed to
> update its own attributes in AD. Please try to kinit as a user which is
> allowed to update host attributes and use the --login-ccache with 'adcli
> update'. If this still does not work please send the full command with the
> verbose output.

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

I would agree with the original post that "adcli update --service-name=NFS" is appropriate for this and shouldn't require additional AD credentials on a domain joined host.

adcli join   - Requires credentials
adcli update - Uses machine credentials