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 [email protected] https://lists.fedorahosted.org/admin/lists/[email protected]
