adcli delete-computer fails when run as root because of keytab access

[Andrew Klaassen]

I just came across a curious behaviour with adcli delete-computer where it doesn't work when run as root but does work when run as a regular user.

It turns out that it's because our Linux machines are joined to two different domains with two different keytabs.  Running a command like this:

$ adcli delete-computer --domain=$SECONDARY_DOMAIN --login-user=$ SERVICE_USER $MACHINE_NAME

...works fine.  Running it as root:

$ sudo adcli delete-computer --domain=$SECONDARY_DOMAIN --login-user=$SERVICE_USER $MACHINE_NAME

...fails with "adcli: couldn't connect to <SECONDARY_DOMAIN> domain: Couldn't authenticate to active directory: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Server not found in Kerberos database)"

Running both with KRB5_TRACE=/dev/stdout, there are a bunch of places where the sudo version is adding the name of our ~primary~ domain to the secondary domain queries and failing.  The regular user version doesn't do that.

Running both with strace, I see that the sudo version successfully opens /etc/krb5.keytab, which is the keytab for our primary domain, and gets domain info from it, which leads to the failure.  The regular user version isn't able to open /etc/krb5.keytab, so it respects the domain specified on the command line and succeeds.

I tried to get around the problem by using --host-keytab=/etc/krb5.keytab.$SECONDARY_DOMAIN, but of course delete-computer doesn't accept the --host-keytab option.

My short-term fix is going to be to run the command as a regular user instead of root, but I'm curious to know if this would be an easy fix.  I've noticed that this problem doesn't seem to happen for similar adcli commands like show-computer and preset-computer.

Thanks.

Andrew