Bug 145044
Summary: | support for pam_ccreds (cached credentials / disconnected operation) | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Rudi Chiarito <nutello> |
Component: | authconfig | Assignee: | Tomas Mraz <tmraz> |
Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | bojan, dkelson, katzj, k.georgiou, lists, pmatilai, redhat |
Target Milestone: | --- | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-10-01 09:52:31 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 173019 | ||
Bug Blocks: | |||
Attachments: |
Description
Rudi Chiarito
2005-01-13 21:56:57 UTC
For the most part, this is adding appropriate bits to authconfig and then it can be configured in firstboot when you do the user or network login setup. Will stay on the cc list so that I can see when the bits have been added (including the command line option) and add the relevant bit to kickstart at that point. *** Bug 142624 has been marked as a duplicate of this bug. *** John Dennis from RH hints that there already is a patch floating (probably RH internally) around to do this in authconfig in this mail: http://www.redhat.com/archives/fedora-devel-list/2004-September/msg01038.html Any chance to dig up the patch and make it available for people to test? Others may be trying to configure this by hand. This is what I put in /etc/pam.d/system-auth: auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so auth [authinfo_unavail=ignore success=1 default=2] /lib/security/$ISA/pam_krb5.so use_first_pass auth [default=done] /lib/security/$ISA/pam_ccreds.so action=validate use_first_pass auth [default=done] /lib/security/$ISA/pam_ccreds.so action=store auth [default=done] /lib/security/$ISA/pam_ccreds.so action=update auth required /lib/security/$ISA/pam_deny.so account required /lib/security/$ISA/pam_unix.so broken_shadow account sufficient /lib/security/$ISA/pam_localuser.so account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet account [authinfo_unavail=ignore default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_krb5.so account required /lib/security/$ISA/pam_permit.so password requisite /lib/security/$ISA/pam_cracklib.so retry=3 password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow password sufficient /lib/security/$ISA/pam_krb5.so use_authtok password required /lib/security/$ISA/pam_deny.so session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so session optional /lib/security/$ISA/pam_krb5.so session required /lib/security/$ISA/pam_mount_session.so It seems to work. The pam_ccreds alone is useful only for pam_krb5, because otherwise also the user/group information is stored remotely and it won't be available when disconnected. The nss_updatedb utility should be usable for that but it would have to be added to the distribution and properly configured (added cron job for updating the db) along with pam_ccreds. I don't think the FC5 target is real. nss_updatedb is NOT usable when you have thousands of users :-/ Nscd in FC3 and newer does persistent caching of user/group info so it should be possible to use that for offline operation - in theory at least. In practise I haven't gotten nscd to work in that scenario at all, but local user information + kerberos/ldap authentication works nicely with Michael's latest patch from #151914. Well, this makes the whole idea problematic. Why would you want to use local user account with remote password? Even more when you plan to use the system disconnected? My conclusion is that the whole idea of using pam_ccreds is not ready for general consumption and so it doesn't need a simple setup by authconfig. Authconfig should be now much more friendly to manually adjusted configuration (it doesn't overwrite files with unchanged settings) so it shouldn't be a problem for advanced users. Nscd + pam_ccreds has worked fine for me with a LDAP + Kerberos system for quite some time! When researching my options, several people recommended this to me. Nscd happilly caches LDAP NSS information and pam_ccreds caches passwords. The system has WORKED. When I submitted the pam_ccreds configuration in comment #4, I was using nscd to cache my LDAP information. Unfortunately, a bug in recent Raw Hide versions of nscd has broken my setup. See bug #173019. We just need to fix nscd. Ok. If you've actually gotten it to work, it means it's not impossible. I had already given up hope :) Was that with FC4? I've been only really testing with RHEL 4, perhaps there's some crucial difference there... Did you do any additional tweaks (nscd.conf, nsswitch.conf or such)? It's been a while but IIRC the problem was that while 'id <username>' worked just fine for cached users, trying to log in failed on some level with 'user not known to underlying authentication system' or such, I'll need to recheck to be sure though. Created attachment 122875 [details] Configuration for nscd, disconnected operation This and the following three attachments are the configuration files that I used to login (using /bin/login) to my computer while disconnected from my network. My computer uses kerberos for authentication and caches authentication data using pam_ccreds. My computer uses LDAP for NSS and caches NSS data using nscd. This setup allowed me to log in to my computer while disconnected and using Raw Hide as of 05 Jan 2006, with one caveat: nscd invalidates one of the items in its cache within a few seconds (see bug #173019 -- INITGROUPS.) As a result, one must log in on one terminal, disconnect from the network and log in using another terminal before the INITGROUPS cache item is expired. This is intended to demonstrate that pam_ccreds + nscd is a viable solution, though a few bugs need to be fixed before disconnected operation will work in a production environment. Created attachment 122876 [details]
Configuration for NSS, disconnected operation
Created attachment 122877 [details]
PAM configuration for login, disconnected operation
Created attachment 122878 [details]
PAM configuration, disconnected operation
Doesn't the high TTL mean that if the account info on server is modified it won't be propagated to the client machine till the TTL expires even if the machine is connected? This would be a big (even security) problem in some environments. This is an interesting problem. This probably requires some discussion across multiple packages, so I don't know if an authconfig bug is the place to effectively talk. Looking at the way this is handled with a PAM stack by pam_ccreds provides a model of how things should work. However, NSS does not provide such a flexible method of configuration. Could nscd be modified to monitor network/LDAP connectivity and maintain a seperate TTL if connected? Would this solve the problem? What are the implications of NSS data not propagating? I suppose a UID or GID could be reused after an account was removed, for example. How do other, similar computer systems work? I think the second TTL is a good idea. Would it work like "expire" in a DNS zone? Although, maybe there should be three values. A TTL for the individual "dn" and/or "refresh" and "expire" for the "ou","dc","o" levels. Actually I think a "dn" level TTL is overkill, and the TTL should just be defined at the "ou"/"dc"/"o" levels. Extend the schema a little to include "TTL" "refresh" and "expire" or whatever. That way the caching would be controlled by the directory. Plus the refresh idea only makes sense where refresh < ttl == Example logic for ttl and expire for "auth" if (t_now > t_cacheread + ttl) { if (try_to_update_cache() ) { /* cache update failed */ if (t_now > t_cacheread+expire) { /* expired so invalide the cache */ invalidate_auth_cache(); } } auth_status = check_auth_cache(); == Example logic for ttl, refresh and expire if ((t_now > t_cacheread + ttl) || (t_now > t_cacheread + refresh)) { if (try_to_update_cache() ) { /* cache update failed */ if (t_now > t_cacheread+expire) { /* expired so invalide the cache */ invalidate_auth_cache(); } } auth_status = check_auth_cache(); == the uid/gid to name mapping would work the same except that the equiv of check_auth_cache() would be {uid,gid}_map_cache(). The try_to_update_cache() should timeout very quickly if it doesn't see the directory, e.g. <2 seconds. My recollection of windows is that your credentials cache is good until your password expires (a domain level group policy). The machine account password expires every 30 days by default (or it used to), If the Netlogon service can't talk to a domain controller at least once every 30 days, domain access breaks (at least once you eventually connect to the network). I'v never tried the domain password offline after the machine account password expired, but I don't think it is expected to work, it shouldn't. Just my two unsolicited cents. Yes, this should be probably discussed on some mailing lists (glibc devel?) and an enhancement request against nscd should be opened. (The question is if the nss+nscd architecture allows implementing this at all.) Wow, what's with Ulrich Drepper? His response to my bug report over on the glibc Bugzilla was: > This is what the reload-count value is for. Stop reopening bugs. > This is no place to get free support for your non-existing knowledge. That's kind of rough treatment for a volunteer who has been working with the Fedora project since its inception! The reload-count feature is not documented in nscd.conf.5. See Bug #177368. At this point I can only assume Ulrich's reload-count solution is correct because I can't find any documentation about it. Does anyone else know if this solves the problem mentioned in comment #14? Wow, that's one rude response considering it's a completely undocumented feature :-/ A tiny shed of light from glibc NEWS doc: * nscd can now cache entries persistently. Expiring entries are reloaded. For speedups the cache can be shared in memory with client processes. Implemented by Ulrich Drepper. What the nscd sources say on the subject: /* Default limit on the number of times a value gets reloaded without being used in the meantime. NSCD does not throw a value out as soon as it times out. It tries to reload the value from the server. Only if the value has not been used for so many rounds it is removed. */ So I guess that basically translates to: raise reload-count (from the default of 5) instead of raising TTL for this purpose. Ulrich's solution of using reload-count does not seem to solve the problem. See http://sources.redhat.com/bugzilla/show_bug.cgi?id=2132#c4. Just created this page: http://fedoraproject.org/wiki/Features/DisconnectedOperation Wontfix for now as pam_ccreds currently doesn't seem to be the way how to get the proper disconnected operation. |