On Wed, Sep 28, 2011 at 02:49:02PM +0800, Goff, Raal wrote:
> The only difference I know about is that the users who CAN change their 
> passwords have not got an expired password (so they can login and use kpasswd 
> from the shell), whereas those who CANNOT change their password need to reset 
> it before logging in (i.e., they get the 'your password has expired, reset it 
> now etc etc). I updated the kerberos libraries/tools on the CentOS 6.0 box 
> using the Continuous Release repository, and then edited the ldap 
> configuration to get around 
> https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=713525 and users 
> can now reset their passwords on that box during login and on the shell 
> (kpasswd). I'm not sure which of these actually fixed the problem (if any).

Ah, somehow I'd missed that you were running 6.0.  If your client
systems are using pam_krb5 instead of SSSD, then you're likely hitting
https://bugzilla.redhat.com/show_bug.cgi?id=690583, which was fixed in

> I'll continue to keep an eye on it for now. It may be as you say, a version 
> difference, although I'm unaware of any large differences in versions between 
> the machines, is kerberos very sensitive to version changes?

It's not supposed to be, and usually isn't.  Barring bugs, of course.

> > If you can get a packet capture of a client request, we can examine the
> > first few bytes to check what's triggering the failure.
> tcpdump says its a V5 packet. I have captured the entire login/reset failure 
> and can email it to you directly if you wish.

Sure.  The first four bytes encode the message length (the first two
bytes) and the protocol version number (the next two), so just that part
should actually be enough to verify.



Freeipa-users mailing list

Reply via email to