[29116] in Kerberos
Re: password expiry for a principal
daemon@ATHENA.MIT.EDU (Russ Allbery)
Sat Jan 19 15:29:48 2008
To: kerberos@mit.edu
In-Reply-To: <fmt45t$9cp$1@ger.gmane.org> (Markus Moeller's message of "Sat\,
19 Jan 2008 15\:14\:50 -0000")
From: Russ Allbery <rra@stanford.edu>
Date: Sat, 19 Jan 2008 12:28:55 -0800
Message-ID: <87wsq5blvc.fsf@windlord.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
"Markus Moeller" <huaraz@moeller.plus.com> writes:
> I did some work with Russ' module on OpenSolaris and Solaris 10 release
> 4 (which has Kerberos headers and libraries). I noted a small issue
> (crash of pam_krb5 when calling pam_setcred in cache_init_from_cache
> since for some reason the pointer to the old cache is NULL). There
> seems to be also a problem with retrieving the old token as the module
> will ask again for the current password ( although this is related to
> using Suns pam_authtok_get.so.1 to retrieve tokens/passwords)
Hm, I'm going to need more information in both cases to be able to track
this down. At least, the debug logging output is needed. Having a
pre-existing context without having a valid cache in that context is
something that shouldn't happen; pam_authenticate clears the context from
the PAM environment if it was unable to create a ticket cache.
Similarly, with obtaining the old authentication tokens, that code is very
straightforward and I don't know why that would fail. I need more
information on exactly what the return status for pam_get_item would be.
If you enable use_authtok instead of use_first_pass, you should get an
error message and an abort in the PAM stack if pam-krb5 can't retrieve the
authentication token.
Thank you for looking at this! I'd love to get it to work.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
