user group mebmership
by Ondrej Valousek
Hi List,
Just a strange cache-like issue. When I add user to a certain group, he does not see his group membership updated (via 'id -a') until he closes his X session (+ all processes terminated) and starts a fresh new one.
Probably not directly related to SSSD as I can see his groups updated in a matter of minutes.
Is there anything we could do to address this? Sometimes even starting new shell does not help - it is bit frustrating having to start a complete new session.
Thanks,
Ondrej
-----
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.
8 years, 2 months
I'm new to everything!
by 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
8 years, 2 months
Kerberos Cred Cache name with Active Directory
by Jay McCanta
I would like to change where sssd creates the krb5 credential cache when using AD for authentication.
It sets KRB5CCNAME as FILE:/tmp/krb5cc_<uid>_<random>.
We are running sssd v 1.11.5 (packaged with Ubuntu Trusty 14.04).
I have tried setting 'krb_ccachedir' and 'krb_ccname_template' but that didn't change where the cache got create. Below is the sssd.conf file. Is this possible with the AD provider?
Jay McCanta
F5 Networks, Inc.
[sssd]
config_file_version = 2
domains = example.com
services = nss, pam
debug_level = 3
[nss]
[pam]
debug_level = 3
[domain/example.com]
id_provider = ad
auth_provider = ad
access_provider = ad
ldap_id_mapping = False
krb5_ccachedir=/var/run
krb5_ccname_template=FILE:%d/krb5cc_%U
8 years, 2 months
autofs + sssd on CentOS 6.7
by Dan Cenafik
Hi,
There is something I have trouble to understand with autofs tied to sssd on redhat, do you know need any kind of settings to autofs ( /etc/auto* ) or just changing nsswitch.conf + setting up sssd is good enough? When I run automount --dumpmaps it's finding the map from the remote LDAP but then it tries to connect locally ( 127.0.0.1 ) to reach a LDAP server and obviously fails. Am I missing something?
Regards,
Dan,
8 years, 2 months
Double prompts for password for local user
by Magnus Therning
To configure my system I've followed the instructions at [1] but there
are two things not quite right:
1. All normal local users (i.e. not /root/) get prompted twice at login.
My testing shows that it's only the 2nd time the password must be
correct.
2. I can't use ~su~ to become root (though =sudo= works, so it's not the
end of the world).
My PAM-fu is rather limited, so I don't even know where I should start
looking to fix this. Maybe someone on this list can see right away
what's wrong with those instructions, or at least can offer me a pointer
on where to turn to figure it out?
/M
[1]: https://wiki.archlinux.org/index.php/LDAP_authentication#Online_and_Offli...
--
Magnus Therning, magnus.therning(a)cipherstone.com
Cipherstone Technologies AB
Theres Svenssons gata 10, 417 55 Gothenburg, Sweden
Sometimes I wonder whether the world is being run by smart people who
are putting us on or by imbeciles who really mean it.
-- Mark Twain
Clearly, it's the imbeciles. And they really mean it.
-- DBT
8 years, 2 months
ad backend missing entries from nested groups
by James Ralston
I'd appreciate some guidance on debugging this problem.
At least on RHEL7, with sssd-1.13.0-40.el7_2.1, we've noticed that the
ad backend doesn't always expand nested AD groups properly.
For example, we have group_1 with 5 members and group_2 with 7
members. One user is in both groups. The group_all group has two
members: group_1 and group_2.
But if I do "getent group group_all", sometimes only 10 members are
displayed, not 11. And the missing member is always the same user: me.
If I stop sssd, delete the cache files, and restart sssd, then "getent
group group_all" properly returns all 11 members.
For now, I've turned on full debugging (0xffff) for the domain. I'm
hoping that if I can catch the incorrect group expansion, the logs
will show me why the expansion is incorrect.
Is there anything else I should be looking at to debug this problem?
Thanks!
P.S.: I don't know if it's related, but I noticed that "getent group
'domain users'" no longer lists every single user as a member of the
'domain users' group. Was this a change for 1.13? Or is this another
problem?
8 years, 2 months
Setting a different $HOME for a specific LDAP user? (Or other solution for dev.)
by Magnus Therning
I've just come across SSSD and have managed to set it up for use against
our LDAP server. Yay!
We have LDAP set up for user and group management, and all users' homes
live on an NFS share. This is fine for me most of the time, except for
on the machine where I do development; I really don't like to run the
compiler against files on NFS!
I see three options
1. Use a local user, with a local $HOME, for development.
2. Create a local dir on the dev machine and use it for all development.
3. Give the LDAP user a local $HOME on the dev machine.
I looked into 3 a bit and found `override_homedir`. It works fine, but
then *all* users on the dev machine get a local $HOME. Is it possible to
override $HOME for a specific user only?
/M
PS I'd also be most interested in hearing if there are any other
solutions to this problem.
--
Magnus Therning, magnus.therning(a)cipherstone.com
Cipherstone Technologies AB
Theres Svenssons gata 10, 417 55 Gothenburg, Sweden
If our ideas of intellectual property are wrong, we must change them,
improve them and return them to their original purpose. When
intellectual property rules diminish the supply of new ideas, they
steal from all of us.
-- Andrew Brown, November 19, 2005, The Guardian
8 years, 2 months
heads-up: new code to fetch sudo rules from an IPA server coming to Fedora and RHEL-6
by Jakub Hrozek
Hi,
the sssd's code that fetches sudo rules from the IPA server got an
overhaul recently. The search would no longer be performed against the
compat tree, but against IPA's native LDAP tree. This would have the
advantage that environments that don't use the slapi-nis' compat tree
for another reason (like old or non-Linux clients) would no longer
require slapi-nis to be running at all.
We'd like to get some tests for this new code! If you're running Fedora ,
you can just upgrade to the packages from Fedora's update testing. If
you're running RHEL-6.7 and would like to see what is cooking for 6.8,
you can try this repository:
https://copr.fedorainfracloud.org/coprs/jhrozek/SSSD-6.8-preview/
RHEL-7 wouldn't receive this code until 7.3, so we don't have test
packages for el7 yet..
8 years, 2 months
