On Fri, Feb 05, 2016 at 08:45:56PM +0000, Mote, Todd wrote:
Jakub
Thanks for those repos. That was MUCH easier to get installed.
Things seem much faster now as well, everything seems to be running
pretty well. if I turn the ignore users off login times are too long and I
get disconnected, but logging in again gets me in and groups have members,
yes, unfortunately, large group resolution is quite slow now. The good
news is that we know exactly what needs to be done..now we just need to
code it up..
how long does group member info stay in the cache? Haven't
decided yet if I
want to leave that on or off yet. Probably off if the cache expires and it
disconnects everybody every login the first login. That would get tiresome.
Unless you really require the output of getent group to contain members,
then you can ignore the group members. Please note that most access
control mechanisms work the other way around (ie rely on the output of
'id'), which follows a different codepath.
I am able now to get a consistent list of groups for the users I tried. There were some
differences between what 'id' returned and what was in AD Users & Computers,
but I tracked those down to either being groups with Category 'Distribution List'
and not 'Security', or groups in built-in containers. I went looking for one of
those specifically in the logs and SSSD does in fact find it, but it explains what's
up with it and why it's not included in 'id':
(Thu Feb 4 10:55:26 2016) [sssd[be[austin.utexas.edu]]] [sdap_get_primary_name]
(0x0400): Processing object Pre-Windows 2000 Compatible Access
(Thu Feb 4 10:55:26 2016) [sssd[be[austin.utexas.edu]]] [sdap_add_incomplete_groups]
(0x1000): Mapping group [Pre-Windows 2000 Compatible Access] objectSID to unix ID
(Thu Feb 4 10:55:26 2016) [sssd[be[austin.utexas.edu]]] [sdap_add_incomplete_groups]
(0x2000): Group [Pre-Windows 2000 Compatible Access] has objectSID [S-1-5-32-554]
(Thu Feb 4 10:55:26 2016) [sssd[be[austin.utexas.edu]]] [sdap_idmap_sid_to_unix]
(0x0400): Object SID [S-1-5-32-554] is a built-in one.
(Thu Feb 4 10:55:26 2016) [sssd[be[austin.utexas.edu]]] [sdap_add_incomplete_groups]
(0x2000): Group [Pre-Windows 2000 Compatible Access] cannot be mapped. Treating as a
non-POSIX group
Thanks for descriptive logs, they seem to be a luxury.
On my RHEL 6 vm with the preview installed, I've commented out my cron job to renew
the machine ticket. Is anything else required to have that happen or does
> krb5_renewable_lifetime = 7d
> krb5_renew_interval = 6h
cover machine tickets the same as user tickets?
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..
(Fri Feb 5 14:08:54 2016) [sssd[be[austin.utexas.edu]]] [be_ptask_execute] (0x0400):
Task [AD machine account password renewal]: executing task, timeout 60 seconds
(Fri Feb 5 14:08:54 2016) [sssd[be[austin.utexas.edu]]] [child_handler_setup] (0x2000):
Setting up signal handler up for pid [51099]
(Fri Feb 5 14:08:54 2016) [sssd[be[austin.utexas.edu]]] [child_handler_setup] (0x2000):
Signal handler set up for pid [51099]
(Fri Feb 5 14:08:54 2016) [sssd[be[austin.utexas.edu]]] [child_sig_handler] (0x1000):
Waiting for child [51099].
(Fri Feb 5 14:08:54 2016) [sssd[be[austin.utexas.edu]]] [child_sig_handler] (0x0020):
child [51099] failed with status [2].
(Fri Feb 5 14:08:54 2016) [sssd[be[austin.utexas.edu]]] [read_pipe_handler] (0x0400):
EOF received, client finished
(Fri Feb 5 14:08:54 2016) [sssd[be[austin.utexas.edu]]]
[ad_machine_account_password_renewal_done] (0x1000): --- adcli output start---
adcli: 'update' is not a valid adcli command. See 'adcli --help'
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This line tells me that the adcli version does not support the renew
command.
---adcli output end---
(Fri Feb 5 14:08:54 2016) [sssd[be[austin.utexas.edu]]] [be_ptask_done] (0x0400): Task
[AD machine account password renewal]: finished successfully
(Fri Feb 5 14:08:54 2016) [sssd[be[austin.utexas.edu]]] [be_ptask_schedule] (0x0400):
Task [AD machine account password renewal]: scheduling task 86400 seconds from last
execution time [1454789334]
Just realized this is password, not ticket. Nevermind. Still nice to see though. I
tried searching the log for 'kinit' but only found, I think, the kinit's for
the users logging in, but I'm not sure which context it's initing. Looks to be
the computer, I never see any mention of any users kiniting however. We'll see if my
user tickets get renewed later tonight.
The troubleshooting page was helpful, I'm not sure how I missed that one but it
helps.
Once again, thanks for the time.
Thank you very much for testing!