I'm new to everything!

[Mote, Todd]

Hello all

I'm a Windows Domain Admin where I work and am working on using SSSD to get some
identity management consistency to our Linux RHEL 6 and 7 fleet, a long overdue state.

I've gotten pretty far, we're using the build that's been released from Red
Hat, 1.12.4-47 on RHEL 6 and 1.13.0-40 on RHEL 7.  I've joined them both with adcli
since realmd isn't available on RHEL 6.  I'm trying to keep things consistent
between OS releases.  I can log in, process group policy, even ssh using Kerberos (which I
found something weird concerning character case in the ticket cache with, but I think
that's more Kerberos and adcli and ssh, than sssd).  It's been a fun adventure for
this Windows guy. I've learned a lot about Linux through this process.  Hopefully,
this email isn't so long that it wears anybody out.

I have come across some things I wanted to get some advice about.  Our AD is VERY large. 
On the order of 7 million user accounts at this point.  I've had to overcome some
permission issues in AD, using a machine keytab, SASL and GSSAPI for lookups meant Domain
Computers had to have rights to read all of the necessary attributes on users.  We have
some FERPA and HIPPA issues to deal with, so a general Domain Computers - Read permission
won't work, and it seems that Authenticated Users isn't processed quite right for
Computer objects.  However, I got that worked out but turning up the logging to 9 and
seeing what attributes you are looking for from users. I applied Domain Computers - Read
to just those attributes and it was enough.  But am now having some problems getting the
right groups from users after they log in.  After lots of trial and error, I arrived at
the following sssd.conf which works pretty well.  we have a single forest, single domain
AD, and a security office that cringes at any number anywhere that has 9 digits in it. 
(in case you were wondering about the idmap range)

[sssd]
   config_file_version = 2
   debug_level = 9
   domains = austin.utexas.edu
   services = nss, pam, pac

[nss]

[pam]

[pac]

[domain/austin.utexas.edu]
   debug_level = 9
   id_provider = ad
   access_provider = ad
   ad_domain = austin.utexas.edu
   ad_server = dc01.austin.utexas.edu
   auth_provider = ad
   cache_credentials = true
   ldap_schema = ad
   ldap_idmap_range_min = 1000000000
   ldap_idmap_range_size = 20000000
   ldap_idmap_default_domain = austin.utexas.edu
   ldap_idmap_default_domain_sid = <ourdomainSID>
   override_homedir = /home/AUSTIN/%u
   default_shell = /bin/bash
   krb5_use_enterprise_principal = true
   krb5_renewable_lifetime = 7d
   krb5_renew_interval = 6h
   krb5_realm = AUSTIN.UTEXAS.EDU
#   ad_gpo_access_control = permissive
   ad_gpo_access_control = enforcing
   ad_gpo_cache_timeout = 5
   dyndns_update = true
   dyndns_update_ptr = false
   dyndns_refresh_interval = 86400
   dyndns_ttl = 3600
   ignore_group_members = true
   ldap_use_tokengroups = false
   ldap_group_nesting_level = 0

I ended up at ignore_group_members=true because Domain Users has LOTS of users in it, as
do other programmatically populated groups, not using token groups and setting nesting
level to 0 and am very close to replicating what I see on the memberof tab in ADU&C
for the user object.  I was having LDAP search time outs due to size and group
enumeration.  But the groups returned by 'id' are not quite complete and seems to
change between cache clears and service restarts.  I was reading about 1.13.3 and the
closed ticket about flaky group memberships and ignore_group_members and thought I might
give it a try.  Though I'm finding that to be a lot harder than I thought it would be.
 I downloaded the source from https://fedorahosted.org/released/sssd/ and unpacked it, but
I'm not sure of where to go from here, so I looked for an rpm, because I do at least
know how to yum install, but ran into a tangly mess of dependencies.

I guess my questions are thus:
Are there any instructions for the weak linux skilled windows admin to get 1.13.3
installed without a lot of trouble?  I looked in the BUILD.txt in the package and it lists
https://fedorahosted.org/sssd/wiki/DevelTutorials as a place for instructions, but the
link doesn't go anywhere.  The readme had this mailing list.  So here I am.

Second are there any general best practices with sssd and AD anywhere?  I've blindly
just come across stuff, like krb5_renew_interval for user ticket renewal, our machines
were falling off the domain after 7 days, so we also now have a cron job that runs every
so often to keep the computer's ticket refreshed.  (I see that is a RFE though!)

I could go on, but this is long enough, hopefully no one will throw tomatoes.  :)  Thanks
in advance for any time you spend on this.  SSSD will solve so many issues for us if we
can get it working reliably here.  I even have a colleague working on a puppet module for
joining machines to AD at build time!

Thanks.

Todd

[Jakub Hrozek]

On Thu, Feb 04, 2016 at 09:38:00PM +0000, Mote, Todd wrote:
>  Hello all
>  
>  I'm a Windows Domain Admin where I work and am working on using SSSD to get some
> identity management consistency to our Linux RHEL 6 and 7 fleet, a long overdue state.
>  
>  I've gotten pretty far, we're using the build that's been released from Red
> Hat, 1.12.4-47 on RHEL 6 and 1.13.0-40 on RHEL 7.  I've joined them both with adcli
> since realmd isn't available on RHEL 6.  I'm trying to keep things consistent
> between OS releases.  I can log in, process group policy, even ssh using Kerberos (which I
> found something weird concerning character case in the ticket cache with, but I think
> that's more Kerberos and adcli and ssh, than sssd).  It's been a fun adventure for
> this Windows guy. I've learned a lot about Linux through this process.  Hopefully,
> this email isn't so long that it wears anybody out.
>  
>  I have come across some things I wanted to get some advice about.  Our AD is VERY large. 
> On the order of 7 million user accounts at this point.  I've had to overcome some
> permission issues in AD, using a machine keytab, SASL and GSSAPI for lookups meant Domain
> Computers had to have rights to read all of the necessary attributes on users.  We have
> some FERPA and HIPPA issues to deal with, so a general Domain Computers - Read permission
> won't work, and it seems that Authenticated Users isn't processed quite right for
> Computer objects.  However, I got that worked out but turning up the logging to 9 and
> seeing what attributes you are looking for from users. I applied Domain Computers - Read
> to just those attributes and it was enough.  But am now having some problems getting the
> right groups from users after they log in.  After lots of trial and error, I arrived at
> the following sssd.conf which works pretty well.  we have a single forest, single domain
> AD, and a security office that cringes at any number anywhere that has 9 digits in it. 
> (in case you were wondering about the idmap range)
>  
>  [sssd]
>     config_file_version = 2
>     debug_level = 9
>     domains = austin.utexas.edu
>     services = nss, pam, pac
>  
>  [nss]
>  
>  [pam]
>  
>  [pac]
>  
>  [domain/austin.utexas.edu]
>     debug_level = 9
>     id_provider = ad
>     access_provider = ad
>     ad_domain = austin.utexas.edu
>     ad_server = dc01.austin.utexas.edu
>     auth_provider = ad
>     cache_credentials = true
>     ldap_schema = ad
>     ldap_idmap_range_min = 1000000000
>     ldap_idmap_range_size = 20000000
>     ldap_idmap_default_domain = austin.utexas.edu
>     ldap_idmap_default_domain_sid = <ourdomainSID>
>     override_homedir = /home/AUSTIN/%u
>     default_shell = /bin/bash
>     krb5_use_enterprise_principal = true
>     krb5_renewable_lifetime = 7d
>     krb5_renew_interval = 6h
>     krb5_realm = AUSTIN.UTEXAS.EDU
>  #   ad_gpo_access_control = permissive
>     ad_gpo_access_control = enforcing
>     ad_gpo_cache_timeout = 5
>     dyndns_update = true
>     dyndns_update_ptr = false
>     dyndns_refresh_interval = 86400
>     dyndns_ttl = 3600
>     ignore_group_members = true
>     ldap_use_tokengroups = false
>     ldap_group_nesting_level = 0
>  
>  I ended up at ignore_group_members=true because Domain Users has
>  LOTS of users in it, as do other programmatically populated groups, not
>  using token groups and setting nesting level to 0 and am very close to
>  replicating what I see on the memberof tab in ADU&C for the user object.
>  I was having LDAP search time outs due to size and group enumeration.
>  But the groups returned by 'id' are not quite complete and seems to change
>  between cache clears and service restarts.  I was reading about 1.13.3 and
>  the closed ticket about flaky group memberships and ignore_group_members
>  and thought I might give it a try.  
I think this must be https://bugzilla.redhat.com/show_bug.cgi?id=1212610
-- which was backported to RHEL-6.7's 1.12 version. Nonetheless, it
would be great to get some test results with packages from the repos
below.

>  Though I'm finding that to be a
>  lot harder than I thought it would be.  I downloaded the source from
>  https://fedorahosted.org/released/sssd/ and unpacked it, but I'm not sure
>  of where to go from here, so I looked for an rpm, because I do at least
>  know how to yum install, but ran into a tangly mess of dependencies.
>  
>  I guess my questions are thus:
>  Are there any instructions for the weak linux skilled windows admin to get 1.13.3
> installed without a lot of trouble?  I looked in the BUILD.txt in the package and it lists
> https://fedorahosted.org/sssd/wiki/DevelTutorials as a place for instructions, but the
> link doesn't go anywhere.  The readme had this mailing list.  So here I am. 
I have a test repo with the packages we're planning for 6.8:
    https://copr.fedorainfracloud.org/coprs/jhrozek/SSSD-6.8-preview/
and Lukas maintains a repo which tracks the upstream releases which also
includes EPEL-7 builds:
    https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-13/

If these don't help, it would be nice to describe the missing group
memberships and look into the logs for details. Hopefully the
troubleshooting page would help:
    https://fedorahosted.org/sssd/wiki/Troubleshooting

>  
>  Second are there any general best practices with sssd and AD anywhere?
>  I've blindly just come across stuff, like krb5_renew_interval for user
>  ticket renewal, our machines were falling off the domain after 7 days, so
>  we also now have a cron job that runs every so often to keep the computer's
>  ticket refreshed.  (I see that is a RFE though!) 
Yes, this one should be fixed in the 6.8 preview repo at least. Because
the ticket was only fixed after 1.13.3 was released, this feature is not
in the upstream repo yet, we only cherry-picked the patches to RHEL.

>  
>  I could go on, but this is long enough, hopefully no one will throw
>  tomatoes.  :)  Thanks in advance for any time you spend on this.  SSSD
>  will solve so many issues for us if we can get it working reliably here.
>  I even have a colleague working on a puppet module for joining machines
>  to AD at build time! 
Great, this would be nice to see!

[Mote, Todd]

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, 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.

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?

(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'
---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.

Todd





-----Original Message-----
From: Jakub Hrozek [mailto:[e-mail]] 
Sent: Friday, February 5, 2016 2:56 AM
To: sssd-users(a)lists.fedorahosted.org
Subject: [SSSD-users] Re: I'm new to everything!

On Thu, Feb 04, 2016 at 09:38:00PM +0000, Mote, Todd wrote:
> Hello all
> 
> I'm a Windows Domain Admin where I work and am working on using SSSD to get some
identity management consistency to our Linux RHEL 6 and 7 fleet, a long overdue state.
> 
> I've gotten pretty far, we're using the build that's been released from
Red Hat, 1.12.4-47 on RHEL 6 and 1.13.0-40 on RHEL 7.  I've joined them both with
adcli since realmd isn't available on RHEL 6.  I'm trying to keep things
consistent between OS releases.  I can log in, process group policy, even ssh using
Kerberos (which I found something weird concerning character case in the ticket cache
with, but I think that's more Kerberos and adcli and ssh, than sssd).  It's been a
fun adventure for this Windows guy. I've learned a lot about Linux through this
process.  Hopefully, this email isn't so long that it wears anybody out.
> 
> I have come across some things I wanted to get some advice about.  Our 
> AD is VERY large.  On the order of 7 million user accounts at this 
> point.  I've had to overcome some permission issues in AD, using a 
> machine keytab, SASL and GSSAPI for lookups meant Domain Computers had 
> to have rights to read all of the necessary attributes on users.  We 
> have some FERPA and HIPPA issues to deal with, so a general Domain 
> Computers - Read permission won't work, and it seems that 
> Authenticated Users isn't processed quite right for Computer objects.  
> However, I got that worked out but turning up the logging to 9 and 
> seeing what attributes you are looking for from users. I applied 
> Domain Computers - Read to just those attributes and it was enough.  
> But am now having some problems getting the right groups from users 
> after they log in.  After lots of trial and error, I arrived at the 
> following sssd.conf which works pretty well.  we have a single forest, 
> single domain AD, and a security office that cringes at any number 
> anywhere that has 9 digits in it.  (in case you were wondering about 
> the idmap range)
> 
> [sssd]
>    config_file_version = 2
>    debug_level = 9
>    domains = austin.utexas.edu
>    services = nss, pam, pac
> 
> [nss]
> 
> [pam]
> 
> [pac]
> 
> [domain/austin.utexas.edu]
>    debug_level = 9
>    id_provider = ad
>    access_provider = ad
>    ad_domain = austin.utexas.edu
>    ad_server = dc01.austin.utexas.edu
>    auth_provider = ad
>    cache_credentials = true
>    ldap_schema = ad
>    ldap_idmap_range_min = 1000000000
>    ldap_idmap_range_size = 20000000
>    ldap_idmap_default_domain = austin.utexas.edu
>    ldap_idmap_default_domain_sid = <ourdomainSID>
>    override_homedir = /home/AUSTIN/%u
>    default_shell = /bin/bash
>    krb5_use_enterprise_principal = true
>     krb5_renewable_lifetime = 7d
>     krb5_renew_interval = 6h
>  
>    krb5_realm = AUSTIN.UTEXAS.EDU
> #   ad_gpo_access_control = permissive
>    ad_gpo_access_control = enforcing
>    ad_gpo_cache_timeout = 5
>    dyndns_update = true
>    dyndns_update_ptr = false
>    dyndns_refresh_interval = 86400
>    dyndns_ttl = 3600
>    ignore_group_members = true
>    ldap_use_tokengroups = false
>    ldap_group_nesting_level = 0
> 
> I ended up at ignore_group_members=true because Domain Users has LOTS 
> of users in it, as do other programmatically populated groups, not 
> using token groups and setting nesting level to 0 and am very close to 
> replicating what I see on the memberof tab in ADU&C for the user object.
> I was having LDAP search time outs due to size and group enumeration.
> But the groups returned by 'id' are not quite complete and seems to 
> change between cache clears and service restarts.  I was reading about 
> 1.13.3 and the closed ticket about flaky group memberships and 
> ignore_group_members and thought I might give it a try.

I think this must be https://bugzilla.redhat.com/show_bug.cgi?id=1212610
-- which was backported to RHEL-6.7's 1.12 version. Nonetheless, it would be great to
get some test results with packages from the repos below.

>  Though I'm finding that to be a
>  lot harder than I thought it would be.  I downloaded the source from 
>  https://fedorahosted.org/released/sssd/ and unpacked it, but I'm not 
>  sure of where to go from here, so I looked for an rpm, because I do at 
>  least know how to yum install, but ran into a tangly mess of dependencies.
>  
>  I guess my questions are thus:
>  Are there any instructions for the weak linux skilled windows admin to get 1.13.3
> installed without a lot of trouble?  I looked in the BUILD.txt in the package and it lists
> https://fedorahosted.org/sssd/wiki/DevelTutorials as a place for instructions, but the
> link doesn't go anywhere.  The readme had this mailing list.  So here I am.
>  
I have a test repo with the packages we're planning for 6.8:
    https://copr.fedorainfracloud.org/coprs/jhrozek/SSSD-6.8-preview/
and Lukas maintains a repo which tracks the upstream releases which also includes EPEL-7
builds:
    https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-13/

If these don't help, it would be nice to describe the missing group memberships and
look into the logs for details. Hopefully the troubleshooting page would help:
    https://fedorahosted.org/sssd/wiki/Troubleshooting

>  
>  Second are there any general best practices with sssd and AD anywhere?
>  I've blindly just come across stuff, like krb5_renew_interval for user 
>  ticket renewal, our machines were falling off the domain after 7 days, 
>  so we also now have a cron job that runs every so often to keep the 
>  computer's ticket refreshed.  (I see that is a RFE though!)
>  
Yes, this one should be fixed in the 6.8 preview repo at least. Because the ticket was
only fixed after 1.13.3 was released, this feature is not in the upstream repo yet, we
only cherry-picked the patches to RHEL.

>  
>  I could go on, but this is long enough, hopefully no one will throw 
>  tomatoes.  :)  Thanks in advance for any time you spend on this.  SSSD 
>  will solve so many issues for us if we can get it working reliably here.
>  I even have a colleague working on a puppet module for joining 
>  machines to AD at build time!
>  
Great, this would be nice to see!
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/[e-mail]

[Jakub Hrozek]

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!

[Jakub Hrozek]

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.

[Mote, Todd]

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:[e-mail]] 
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/[e-mail]

[John Beranek]

On 4 February 2016 at 21:38, Mote, Todd wrote:
>  
[snip]
> I ended up at ignore_group_members=true because Domain Users has LOTS of users in it,
as do other programmatically populated groups, not using token groups and setting nesting
level to 0 and am very close to replicating what I see on the memberof tab in ADU&C
for the user object.  I was having LDAP search time outs due to size and group
enumeration.  But the groups returned by ‘id’ are not quite complete and seems to change
between cache clears and service restarts.  I was reading about 1.13.3 and the closed
ticket about flaky group memberships and ignore_group_members and thought I might give it
a try.  Though I’m finding that to be a lot harder than I thought it would be.  I
downloaded the source from https://fedorahosted.org/released/sssd/ and unpacked it, but
I’m not sure of where to go from here, so I looked for an rpm, because I do at least know
how to yum install, but ran into a tangly mess of dependencies.
>  
>  
>  
> I
guess my questions are thus:
>  
> Are there any instructions for the weak linux skilled
windows admin to get 1.13.3 installed without a lot of trouble?  I looked in the BUILD.txt
in the package and it lists https://fedorahosted.org/sssd/wiki/DevelTutorials as a place
for instructions, but the link doesn’t go anywhere.  The readme had this mailing list.  So
here I am.

You'd be better off looking at this mailing list post:

https://lists.fedorahosted.org/archives/list/[e-mail]...

Jakub is providing sssd 1.13.3 compiled for RHEl/CentOS 6 at least...

Cheers,

John

-- 
John Beranek                         To generalise is to be an idiot.
http://redux.org.uk/                                 -- William Blake