Hi all,
using Ubuntu Feisty 64, I tried my darnedest to get OpenLDAP server running with TLS on it; no dice. So I gave up after many days, and tried to set things back to normal for authentication. However I cannot sudo any longer as it comes up:sudo: pam_authenticate:Authentication information cannot be recovered
Which makes it nigh on impossible to do anything.
My nsswitch is back to compat, and the pam.d/common files are all factory standard too.

Help!

Well, the first place to look might be in a file like /etc/pam.d/sudo. (You might have to boot the machine from something like a Knoppix CD-ROM so that you can look at these files if you cannot login normally as root.)

As described in man pam, these are the files that tell PAM how to resolve various kinds of authentication requests.

Maybe it's premature to give-up quite yet, because I'll hazard a guess right now that what you're going to find in that file is some kind of rule that tells PAM to search for an LDAP server against which to authenticate the request. It's going to use pam_ldap to do that. (See: man pam_ldap et al.)

It may well be that the system is trying to authenticate against itself. A reasonable thing to do, but problematic if its own server is not working.

Commenting-out a few entries in this file might radically change things (for the better).

Thanks for the reply, but the /etc/pam.d/sudo file is fine, just referencing the common-auth and common-account. I don't want it to look for LDAP anymore, only authenticating against itself, but cannot find anyway of kicking it back into line.

I am able to login as root by choosing the fix-up mode at grub, as I had given root a password much earlier.

Pam_ldap has been removed via aptitude.

Any other ideas?

In /etc/pam.d/common-auth the line as follows:
auth required pam_unix.so nullok_secure use_first_pass
needed the the use first pass removed.
Able to do all that at command line, which is just as well, 'cos it's a RAID machine, and mounting those under a live cd is tricky.