Fixed.
It was a chain of things, nothing in particular stood out, but here's my
recollection based on the mess I've put into git during this period...
1. Permission of /etc/libnss_ldap.conf was too restrictive (but this did not
prohibit the login, just lots of annoying things like "whoami" break, as
expected.
2. Removal of use_authok (/etc/pam.d/common-password) for the password pam
mgmt group fixed this...
Enter login(LDAP) password:
passwd: Authentication information cannot be recovered
passwd: password unchanged
3. Removal of `pam_password_prohibit_message' from /etc/pam_ldap.conf - then
allowed user to change their password.
4. Re-addition of ldap to shadow: in /etc/nsswitch.conf, despite this
advice:
#. No LDAP here! - PAM LDAP takes over at this point. The `pam_ldap' module
#. from the libpam-ldap package logs into the LDAP server when checking
#. passwords. The pure pam_ldap solution allows limiting logins by how
users
#. are stored in the directory (e.g. only allow logins for users in a
certain
#. piece of the directory, require some attribute, etc). It also requires
less
#. access rights to the LDAP directory and does not expose password hashes.
...which I'm sure is good advice, in the hands of a novice (me), so I still
have much to learn here.
You may have noticed almost all of the above changes relate to the ability
of a user to change the password from the commandline, given that the passwd
db is in LDAP, and not in /etc/shadow.
The initial problem however was that the user could not even log into the
machine (nsswitch having AND not having "ldap" for "shadow" was tested at
that time, and made no differece).
So how the hell did I fix that problem?
....let me know too when you figure it out.
Nima
On Fri, Dec 11, 2009 at 4:43 PM, Nima Talebi <[email protected]> wrote:
> Thanks Daniel,
>
> I'll see what I can find out, and I'll let you when I resolve it.
>
> Nima
>
>
> On Fri, Dec 11, 2009 at 3:59 PM, Daniel Pittman <[email protected]>wrote:
>
>> Nima Talebi <[email protected]> writes:
>>
>> > Here's another clue...
>>
>> Sadly, you have hit the limit of my understanding: everything /looks/
>> right,
>> to me. I suspect it is something in the PAM stack.
>>
>> You might find that adding 'debug' options to the relevant modules, then
>> watching /var/log/auth.log sheds some light on what is returning "password
>> expired" or so?
>>
>> Alternately, maybe try setting "expires in 2099" in the LDAP directory,
>> see if
>> that fixes it? Maybe some broken software is just doing "expires < now"
>> rather than "expires > 0 and expires < now", and incorrectly reporting the
>> password as expired?
>>
>> Good luck. It all looks right to me, I fear. :(
>>
>> Daniel
>>
>> --
>> ✣ Daniel Pittman ✉ [email protected] ☎ +61 401
>> 155 707
>> ♽ made with 100 percent post-consumer electrons
>> --
>> SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
>> Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
>>
>
>
>
> --
> Nima Talebi
> web: http://ai.autonomy.net.au/People/Nima
> gpg: B51D 1F18 D8E2 B702 B027 23A4 E06B DAC1 BE70 ADC0
>
--
Nima Talebi
web: http://ai.autonomy.net.au/People/Nima
gpg: B51D 1F18 D8E2 B702 B027 23A4 E06B DAC1 BE70 ADC0
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
