Todd,
I confess I don't completely understand your solution. I get that
configuration management tools use the passwordlastset attribute with a
value that's greater than XX days to cull objects. My Windows server
engineering counterparts have a scheduled job that deletes all machine
accounts from their Windows OU where passwordlastset attribute > 60 days
and server not pingable. (Actually, it moves the machine account to an
archival OU and then deletes it from archival OU if a Windows SE hasn't
moved it back in 90 days).
Also, by policy our AD forest locks all machine accounts where
passwordlastset attribute > 40 days.
So I get that part.
But you said:
We ultimately decided to deploy a cron job with the install that ran
periodically (less than the renewal period) to keep the keytab fresh (kinit
-R -k $($hostname -s)).
I get what this is doing. Actually, sssd typically uses the service
principal 'host/<fqdn>@<DOMAIN>'. For example: host/
austgcore17.us.example....@amer.example.com. So I would do this:
kinit -R -k host/austgcore17.us.example....@amer.example.com
or (even simpler):
kinit -R -k
since kinit appears to assume this host/ service principal if you don't
specify it. What you're doing is refresh the host's Kerberos TGT ticket.
Actually, you're doing it for your cron job only -- sssd seems to store
its host credential in
cache FILE:/var/lib/sss/db/ccache_AMER.EXAMPLE.COM_VgdSdK or some such.
So you're renewing your host's TGT ticket. But by default, the max
lifetime for a TGT ticket is 24hrs (our AD DCs allow max 10 hrs -- that's
pretty std recommendation for AD). And your max renewal lifetime is 7 days
by default. After that, you'd have to get a fresh kerberos TGT ticket.
So are you completely disabling sssd's automatic machine account password
renewal (by setting ad_maximum_machine_account_password_age = 0)? And then
you're never changing your machine account passwords ever; your cron job
is just refreshing your host's TGT ticket every 9 hrs or so for 7 days?
I'm not fully following the explanation of your approach.
Also, machine account passwords are related to kerberos keytab entries.
For a machine account, a Kerberos keytab entry is the machine account
password (encrypted) with other relevant information, such as timestamp,
KVNO, service principal name and encryption type. The machine account
password stored in AD (with a particular msDS-KeyVersionNumber) must change
the corresponding /etc/krb5.keytab entry (with the same KVNO number).
That's how this client authenticates to Kerberos (AD) that it's who it
claims to be.
Spike
On Fri, Aug 27, 2021 at 9:41 AM Mote, Todd <mo...@austin.utexas.edu> wrote:
> As a follow on to that, to keep themselves clear of debris, configuration
> management tools use the passwordlastset attribute with a value that's
> greater than XX days to cull objects as well. We had similar issues when
> we first implemented SSSD several years ago too. We ultimately decided to
> deploy a cron job with the install that ran periodically (less than the
> renewal period) to keep the keytab fresh (kinit -R -k $($hostname -s)). We
> haven't had computers falling off the domain since we implemented that.
>
> Isn’t the issue that the keytab expires and is not renewed in time, then
> the computer can't change its password because the domain can't verify the
> keytab? Also, aren't machine passwords different from Kerberos keytabs?
> Related, because a machine can't change it's password if it can't prove who
> it is via Kerberos and the keytab. I just want to make sure those aren't
> being conflated. Similarly, a computer can't update it's DNS record in the
> domain with out Kerberos, so similarly, if the keytab is not kept fresh,
> little domain object maintenance can happen, because Kerberos is stale.
>
> Computer account password changes are always initiated by clients, not the
> domain, even on windows.
>
> Todd
>
> -----Original Message-----
> From: James Ralston <rals...@pobox.com>
> Sent: Thursday, August 26, 2021 10:31 PM
> To: End-user discussions about the System Security Services Daemon <
> sssd-users@lists.fedorahosted.org>
> Subject: [SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host
> Keytab Renewal’ with AD back-end….
>
> On Thu, Aug 26, 2021 at 8:11 PM Christian, Mark <mark.christ...@intel.com>
> wrote:
> > [W]hy bother with updating the machine account password?
>
> For sites that have a lot of machine churn, where machine accounts aren't
> reliably purged from AD when the underlying host is decommissioned,
> disabling and/or purging machine accounts with old passwords is essentially
> a garbage collection activity, to prevent stale machine accounts from
> continuing to exist in AD in perpetuity.
>
> Also, some sites must conform with security guidelines that *require*
> frequent changes of machine account passwords:
>
>
> https://www.stigviewer.com/stig/microsoft_windows_server_2016/2021-03-05/finding/V-225033
>
> Granted, that STIG rule applies to Windows machine accounts, not Linux
> machine accounts, but disabling any machine account in AD whose password is
> older than 30 days is one way to detect any Windows clients that are
> nonconforming with the STIG. And in many cases it's easier to apply that
> rule globally than on a per-OU basis (to exempt non-Windows machine
> accounts).
> _______________________________________________
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org To
> unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
> >> This message is from an external sender. Learn more about why this <<
> >> matters at https://links.utexas.edu/rtyclf. <<
> _______________________________________________
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
