#3014 machine credentials renewal with adcli doesn't work as non-root
Closed: wontfix 5 months ago by pbrezina. Opened 4 years ago by jhrozek.

Noticed this while working on an unrelated issue:

(Tue May 17 08:36:55 2016) [sssd[be[win.trust.test]]] [ad_machine_account_password_renewal_done] (0x1000): --- adcli output start---
adcli: couldn't write new krb5.conf file: /tmp/adcli-krb5-52YFbz/krb5.conf: Permission denied
 ! Couldn't enumerate keytab: (null): Permission denied
 * Using fully qualified name: adclient.win.trust.test
 * Using domain name: win.trust.test
 * Calculated computer account name from fqdn: ADCLIENT
 * Calculated domain realm from name: WIN.TRUST.TEST
 * Sending netlogon pings to domain controller: cldap://
 * Received NetLogon info from: dc.win.trust.test
 ! Couldn't get kerberos ticket for machine account: ADCLIENT: Permission denied
adcli: couldn't connect to win.trust.test domain: Couldn't get kerberos ticket for machine account: ADCLIENT: Permission denied
---adcli output end---


user = root

in the [sssd] section made the renewals happy again.

This is expected and I'm sorry I didn't made this more clear before. Since only root access /etc/krb5.keytab adcli must be run as root to update the keytab.

I think it is not a good idea to set the SETUID or SETGID on adcli because adcli does various other jobs as well.

I can see various mid- to long-term solutions here which should be evaluated together with other task SSSD must run as root. Either one component of SSSD, maybe the monitor, which keeps running as root can receiver request from other SSSD components to start other processes as root. Maybe an oddjob based solution might be possible as well. In the keytab renewal case it might also be possible to use realmd with a matching policy-kit rules so that SSSD running as unprivileged users sends a DBus request to realmd which then calls sdcli to update the keytab.

cc: => sbose

oddjob sounds like a good idea, but out of scope of 1.14.

milestone: NEEDS_TRIAGE => SSSD 1.15 beta

Fields changed

rhbz: => todo

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD Future releases (no date set yet)

3 years ago

Metadata Update from @thalman:
- Custom field design_review reset (from 0)
- Custom field mark reset (from 0)
- Custom field patch reset (from 0)
- Custom field review reset (from 0)
- Custom field sensitive reset (from 0)
- Custom field testsupdated reset (from 0)
- Issue close_status updated to: None
- Issue tagged with: Canditate to close

5 months ago

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

5 months ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4055

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.