[5435] in Release_7.7_team
Re: Status update on replacing Athena login with PAM modules
daemon@ATHENA.MIT.EDU (Robert Basch)
Tue Mar 28 17:47:34 2006
In-Reply-To: <200603271825.k2RIP3bI007781@egyptian-gods.mit.edu>
Mime-Version: 1.0 (Apple Message framework v746.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <9EE9ADCF-18D1-458E-A7D1-13D270A05EAF@MIT.EDU>
Cc: release-team@MIT.EDU
Content-Transfer-Encoding: 7bit
From: Robert Basch <rbasch@MIT.EDU>
Date: Tue, 28 Mar 2006 17:47:22 -0500
To: Greg Hudson <ghudson@MIT.EDU>
X-Spam-Score: 1.217
X-Spam-Level: * (1.217)
X-Spam-Flag: NO
On Mar 27, 2006, at 1:25 PM, Greg Hudson wrote:
> Did you look into password-changing at all? I'm wondering if
> athena/bin/passwd still needs to exist in the new-world order (just to
> decide whether to run kpasswd or the native passwd program) or if that
> can all be done through PAM.
/usr/bin/passwd uses PAM; when you run authconfig to enable krb5
authentication, /etc/pam.d/system-auth will be updated to support
krb5 as well as local password-changing, e.g.:
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_krb5afs.so use_authtok
password required /lib/security/$ISA/pam_deny.so
In initial testing, I was successfully able to change the krb5 password
of a non-local test account running /usr/bin/passwd. However, I just
noticed an apparent problem -- when TGT verification is enabled,
password changing via pam_krb5 seems to fail reproducibly, with
"Authentication token manipulation error". I will look into this
further...
In the configuration above, passwd will first try to change the local
password, and then, if that fails, the Kerberos password. We would
presumably lose the functionality offered by the -k|-l options (i.e. to
force either Kerberos or local changing) in the Athena program,
as well as the automatic updating of /etc/shadow.local, in the local
case.
