Patrick,
Oh, I know the answer to that one!
if you're also binding in Samba to winbindd or equivalent, then when sssd
renews the machine account passwords monthly it also has to inform samba of
that new machine account password. So that it can stash it away in its
secrets store.
I believe that
On 10/7/21 12:01, Spike White wrote:
FYI -- update on this situation.
AD DC logs no help. They show the exact same response sent back to a
good machine account password renewal as for a failed renewal.
One of the AD administrators have identified a particular AD DC NIC
teaming
Grigory,
It's quite likely that it's something client-related like that. But I know
it's not exactly that; we turn off SELinux. in the verbose log of adcli
update on a failed renewal, it says:
! Cannot change computer password: Authentication error
adcli: updating membership with domain
Hi Spike,
I have once seen such an issue on RHEL7. It was caused by a wrong SELinux
context on /etc/krb5.keytab file. That is, SSSD updated the password in AD,
attempted to update /etc/krb5.keytab, and SELinux denied this attempt.
Audit log will contain a denied entry if that is the case. Maybe
FYI -- update on this situation.
AD DC logs no help. They show the exact same response sent back to a good
machine account password renewal as for a failed renewal.
One of the AD administrators have identified a particular AD DC NIC teaming
configuration that they state has caused problems with
Sumit,
Thanks. BTW, this occurs primarily on RHEL7, RHEL8, Oracle Linux 7 and
8. (We have very few RHEL6 servers left, but some of them are sssd
enabled.)
We verified (via tcpdump, wireshark) that *L7/8 use TCP exclusively for
this kpasswd operation. As we're aware of this UDP problem. So
Am Tue, Sep 28, 2021 at 03:18:06PM -0500 schrieb Spike White:
> All,
>
> We took Sumit’s advice and enabled sssd’s debug level 7 on the “domain”
> section of sssd.conf. On about 2300 non-prod Linux servers.
>
> FYI – beware if you do this! We found occurrences where that
>
All,
We took Sumit’s advice and enabled sssd’s debug level 7 on the “domain”
section of sssd.conf. On about 2300 non-prod Linux servers.
FYI – beware if you do this! We found occurrences where that
sssd_amer.company.com_log was 8 GB after 24 hrs. So you’ll likely have to
fine-tune your sssd
On 2021-09-08 at 14:18-0400 Todd Mote wrote:
> The $ at the end of the host name is for AD. $ is
> the actual name of the account in AD. The Kerberos utilities are
> just asking the KDC to renew tickets for accounts. Computer
> accounts in AD happen to have a $ appended to them under the
, September 8, 2021 11:05 AM
To: sssd-users@lists.fedorahosted.org
Subject: [SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host
Keytab Renewal’ with AD back-end….
Hi Spike -
Thanks for this clarification. Now I'm wondering what happens when you run
`kinit -k -R HOST$` which was our previous
Hi Spike -
Thanks for this clarification. Now I'm wondering what happens when you
run `kinit -k -R HOST$` which was our previous cron job solution to
linux machines losing their AD connections. Switching to
`msktutil --update --computer-name HOST`
Modulo my ongoing confusion about when
Am Tue, Sep 07, 2021 at 01:59:34PM -0500 schrieb Spike White:
> Sumit and others,
>
> Our level 1 server support team has identified 107 servers that dropped out
> of the domain in Aug.By far, that's their biggest burden with sssd --
> the automatic machine account renewal.
>
> Over the long
Sumit and others,
Our level 1 server support team has identified 107 servers that dropped out
of the domain in Aug.By far, that's their biggest burden with sssd --
the automatic machine account renewal.
Over the long weekend, our team ran a report that identified any pingable
candidates that
Patrick,
kinit -k acquires a new fresh TGT ticket.
kinit -R renews an existing TGT ticket (if it's not already expired). Even
if renewed, "renew until" doesn't change (usually 7 days).
None of these are updating any computer account password on AD. That's an
AD-specific requirement, that
On 9/6/21 4:49 AM, Sumit Bose wrote:
Am Thu, Sep 02, 2021 at 10:02:54AM -0500 schrieb Patrick Goetz:
On 9/2/21 12:49 AM, Sumit Bose wrote:
The reason is that 'kinit -k' constructs the principal by calling
gethostname() or similar, adding the 'host/' prefix and the realm. But
by default this
Am Thu, Sep 02, 2021 at 11:41:47AM -0500 schrieb Spike White:
> OK,
>
> That particular candidate seems like a very unusual end corner case. Where
> someone cloned an existing VM, renamed it, re-IP'd and (incorrectly)
> re-joined it to AD.
>
> I saw "incorrectly", because they did not clear the
Am Thu, Sep 02, 2021 at 10:02:54AM -0500 schrieb Patrick Goetz:
>
> On 9/2/21 12:49 AM, Sumit Bose wrote:
> > The reason is that 'kinit -k' constructs the principal by calling
> > gethostname() or similar, adding the 'host/' prefix and the realm. But
> > by default this principal in AD is only a
OK,
That particular candidate seems like a very unusual end corner case. Where
someone cloned an existing VM, renamed it, re-IP'd and (incorrectly)
re-joined it to AD.
I saw "incorrectly", because they did not clear the existing
/etc/krb5.keytab file prior to the re-join. Hence, the old bogus
On 9/2/21 12:49 AM, Sumit Bose wrote:
The reason is that 'kinit -k' constructs the principal by calling
gethostname() or similar, adding the 'host/' prefix and the realm. But
by default this principal in AD is only a service principal can cannot
be used to request a TGT as kinit does. AD only
Am Wed, Sep 01, 2021 at 11:39:30AM -0500 schrieb Spike White:
> So to respond to my own email, but a co-worker did finally find some
> references to that bizarre name ZZZKBTDURBOL8.
>
> [root@nwpllv8bu100 post_install]# klist -kte
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Timestamp
So to respond to my own email, but a co-worker did finally find some
references to that bizarre name ZZZKBTDURBOL8.
[root@nwpllv8bu100 post_install]# klist -kte
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp Principal
---
Ok, this is *very* illuminating!
I see this in sssd_amer.company.com.log"
(2021-09-01 3:44:46): [be[amer.company.com]]
[ad_machine_account_password_renewal_done] (0x1000): --- adcli output
start---
adcli: couldn't connect to amer.company.com domain: Couldn't authenticate
as machine account:
Am Tue, Aug 31, 2021 at 09:53:01PM +0200 schrieb Alexey Tikhonov:
> On Tue, Aug 31, 2021 at 6:47 PM Spike White wrote:
>
> > All,
> >
> > OK we have a query we run in AD for machine account passwords for a
> > certain age. In today's run, 31 - 32 days. Then we verify it's pingable.
> >
> > We
On Tue, Aug 31, 2021 at 6:47 PM Spike White wrote:
> All,
>
> OK we have a query we run in AD for machine account passwords for a
> certain age. In today's run, 31 - 32 days. Then we verify it's pingable.
>
> We have found such one such suspicious candidate today (two actually, but
> the other
Patrick Goetz
> > Sent: Monday, August 30, 2021 11:25 AM
> > To: sssd-users@lists.fedorahosted.org
> > Subject: [SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos
> Host Keytab Renewal’ with AD back-end….
> >
> > Todd,
> >
> > On 8/27/21
Goetz
Sent: Monday, August 30, 2021 11:25 AM
To: sssd-users@lists.fedorahosted.org
Subject: [SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host
Keytab Renewal’ with AD back-end….
Todd,
On 8/27/21 9:41 AM, Mote, Todd wrote:
We ultimately decided to deploy a cron job
: [SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host
Keytab Renewal’ with AD back-end….
Todd,
On 8/27/21 9:41 AM, Mote, Todd wrote:
> We ultimately decided to deploy a cron job with the install that ran
> periodically (less than the renewal period) to keep the keytab fresh
On 8/27/21 1:07 PM, Spike White wrote:
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
Todd,
On 8/27/21 9:41 AM, Mote, Todd wrote:
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.
nges are always initiated by clients, not the
> domain, even on windows.
>
> Todd
>
> -Original Message-
> From: James Ralston
> Sent: Thursday, August 26, 2021 10:31 PM
> To: End-user discussions about the System Security Services Daemon <
> sssd-users@list
, not the
domain, even on windows.
Todd
-Original Message-
From: James Ralston
Sent: Thursday, August 26, 2021 10:31 PM
To: End-user discussions about the System Security Services Daemon
Subject: [SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host
Keytab Renewal’ with AD back-end
Sumit and Gordon,
You have given me much to think on and digest. Thanks.
Gordon, we religiously patch monthly. Except for sssd in July, where a new
update sssd*-2.4.0-9.0.1.el8_4.1.x86_64 broke our env and we had to roll
back the update to previous version sssd*-2.4.0-9.0.1.el8.x86_64 . (We
On Thu, Aug 26, 2021 at 8:11 PM Christian, Mark
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
On Wed, 2021-08-25 at 21:00 -0700, Gordon uynt wrote:
> We had similar symptoms on CentOS systems at my previous employer,
> however, I'm mostly sure that they were resolved by an sssd update
> sometime in the last year or two. Are all of your systems fully
> patched?
At the risk of derailing
On 8/25/21 8:32 AM, Spike White wrote:
Because we are researching an ongoing problem reported by L1 server
ops. About 70 – 80 sssd-enabled Linux servers / month drop off the
domain. Out of our current sssd-enabled population of ~20K server,
that’s not horrible. But still it should be
35 matches
Mail list logo
