Bug 145044 - support for pam_ccreds (cached credentials / disconnected operation)
support for pam_ccreds (cached credentials / disconnected operation)
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: authconfig (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Brian Brock
: FutureFeature
: 142624 (view as bug list)
Depends On: 173019
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-13 16:56 EST by Rudi Chiarito
Modified: 2008-10-01 05:52 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-01 05:52:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Configuration for nscd, disconnected operation (1.75 KB, text/plain)
2006-01-06 10:13 EST, W. Michael Petullo
no flags Details
Configuration for NSS, disconnected operation (1.69 KB, text/plain)
2006-01-06 10:15 EST, W. Michael Petullo
no flags Details
PAM configuration for login, disconnected operation (512 bytes, text/plain)
2006-01-06 10:16 EST, W. Michael Petullo
no flags Details
PAM configuration, disconnected operation (1.77 KB, text/plain)
2006-01-06 10:18 EST, W. Michael Petullo
no flags Details

  None (edit)
Description Rudi Chiarito 2005-01-13 16:56:57 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041109 Firefox/1.0

Description of problem:
Anaconda provides no mechanisms to activate cached credentials,
neither in the GUI nor in kickstart files. FC3 ships with pam_ccreds,
which is supposed to take care just of that. It's extremely useful for
server-based authentication, especially for mobile users.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
Stare at Anaconda's GUI very hard. Try to use your mind control powers
to make it grow a new "cached credentials" option. Give up when you
finally realise it's not going to happen.

Expected Results:  Another checkmark somewhere in the installer GUI
and yet another switch to kickstaart's auth/authconfig option.

Additional info:
Comment 1 Jeremy Katz 2005-01-13 16:59:51 EST
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.
Comment 2 Tomas Mraz 2005-01-17 10:10:40 EST
*** Bug 142624 has been marked as a duplicate of this bug. ***
Comment 3 Panu Matilainen 2005-04-21 08:17:13 EDT
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?
Comment 4 W. Michael Petullo 2005-06-03 20:44:04 EDT
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.
Comment 5 Tomas Mraz 2006-01-04 11:03:06 EST
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.
Comment 6 Panu Matilainen 2006-01-04 11:16:24 EST
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.
Comment 7 Tomas Mraz 2006-01-04 11:33:46 EST
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.
Comment 8 W. Michael Petullo 2006-01-04 12:05:28 EST
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.
Comment 9 Panu Matilainen 2006-01-04 12:25:12 EST
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. 
Comment 10 W. Michael Petullo 2006-01-06 10:13:57 EST
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.
Comment 11 W. Michael Petullo 2006-01-06 10:15:16 EST
Created attachment 122876 [details]
Configuration for NSS, disconnected operation
Comment 12 W. Michael Petullo 2006-01-06 10:16:43 EST
Created attachment 122877 [details]
PAM configuration for login, disconnected operation
Comment 13 W. Michael Petullo 2006-01-06 10:18:00 EST
Created attachment 122878 [details]
PAM configuration, disconnected operation
Comment 14 Tomas Mraz 2006-01-06 10:42:34 EST
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.
Comment 15 W. Michael Petullo 2006-01-06 22:44:06 EST
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?
Comment 16 Andrew Duggan 2006-01-07 11:29:51 EST
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.


 
Comment 17 Tomas Mraz 2006-01-09 04:59:03 EST
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.)
Comment 18 W. Michael Petullo 2006-01-09 18:24:50 EST
See also: http://sources.redhat.com/bugzilla/show_bug.cgi?id=2132.
Comment 19 W. Michael Petullo 2006-01-09 22:43:29 EST
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?
Comment 20 Panu Matilainen 2006-01-10 09:47:47 EST
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.
Comment 21 W. Michael Petullo 2006-03-19 21:57:06 EST
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.
Comment 22 Bojan Smojver 2008-03-26 05:00:13 EDT
Just created this page:

http://fedoraproject.org/wiki/Features/DisconnectedOperation
Comment 23 Tomas Mraz 2008-10-01 05:52:31 EDT
Wontfix for now as pam_ccreds currently doesn't seem to be the way how to get the proper disconnected operation.

Note You need to log in before you can comment on or make changes to this bug.