Jakub
That installed fine and early this morning I found this in the log:
(Mon Feb 8 00:17:48 2016) [sssd[be[austin.utexas.edu]]]
[ad_machine_account_password_renewal_done] (0x1000): --- adcli output start---
* Found realm in keytab: MY.DOMAIN
* Found computer name in keytab: MYHOST
* Found service principal in keytab: host/MYHOST
* Found service principal in keytab: host/myhost.my.domain
* Found host qualified name in keytab: host/ myhost.my.domain
* Found service principal in keytab: RestrictedKrbHost/MYHOST
* Found service principal in keytab: RestrictedKrbHost/ myhost.my.domain
* Using fully qualified name: myhost.my.domain
* Using domain name: my.domain
* Calculated computer account name from fqdn: MYHOST
* Using domain realm: my.domain
* Sending netlogon pings to domain controller: cldap://999.99.99.99
* Received NetLogon info from: dc.my.domain
* Wrote out krb5.conf snippet to /tmp/adcli-krb5-1gaOjP/krb5.d/adcli-krb5-conf-0Oeo62
* Authenticated as default/reset computer account: MYHOST
* Looked up short domain name: MY
* Using fully qualified name: myhost.my.domain
* Using domain name: my.domain
* Using computer account name: MYHOST
* Using domain realm: my.domain
* Using fully qualified name: myhost.my.domain
* Enrolling computer name: MYHOST
* Generated 120 character computer password
* Using keytab: FILE:/etc/krb5.keytab
* Found computer account for MYHOST$ at: CN=myhost,OU=myDN
* Retrieved kvno '3' for computer account in directory: CN=myhost,OU=myDN
* Password not too old, no change needed
* Modifying computer account: userAccountControl
! Couldn't set userAccountControl on computer account: CN=myhost,OU=myDN:
Insufficient access
* Updated existing computer account: CN=myhost,OU=myDN
---adcli output end---
What does it need to set when it's attempting the userAccountControl part? Does it
need to complete? Should I look at making sure that completes? The computer seems to be
authenticating as itself here, so I can look at permissions on the object in AD to see
what's there, but what is it trying to update?
Reading the 'update' section for adcli at
https://www.freedesktop.org/software/realmd/adcli/adcli.html leads me to believe that
it's a one stop update for both. How often will SSSD call adcli to try to update?
How does it determine that the "password is not too old" and that no change is
needed? Ticket renewable lifetime in sssd.conf is 7 days. Does it update kerb tickets
anyway if the password doesn't need to change?
Any way I could get an rpm for adcli 0.8 that works on RHEL 7? :D
Thanks, again. :)
Todd
-----Original Message-----
From: Jakub Hrozek [mailto:jhrozek@redhat.com]
Sent: Sunday, February 7, 2016 3:09 PM
To: sssd-users(a)lists.fedorahosted.org
Subject: [SSSD-users] Re: I'm new to everything!
On Fri, Feb 05, 2016 at 10:01:17PM +0100, Jakub Hrozek wrote:
> As it turns out I just happened to be tailing the log file and
saw the following. Does adcli need to be a particular version to have the update option?
When does the update try to happen, or am I just lucky I caught it? I see it's once a
day, does it try after service startup then schedules for each day after that?
Ah, I'm sorry, I didn't realize that you also need a newer adcli
version. I will try to package it to my test repo, so that everything
works..
Can you try to run yum upgrade while the 6.8 preview repo is enabled?
That should pull in adcli 0.8.1-1 which supports the renewal feature.
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org