Example: You are using multiple authentication sources (unix, radius, ...). To be able to login, even when the services on which the other modules depend on are inaccessible, pam_unix.so becomes the first of your authentication modules. This works fine, but since the update to pam-1.0.x pam_unix creates for every user from another authentication source a login failure entry in the system log, even when the login finally succeeds with the correct plugin. As the failure for the pam_unix module is expected you want to stop this behaviour as the message is not correct for the whole authentication and might cause other tools like denyhosts to fail (3 unsuccessful logins for only one failed und one correct login attempt). This also troubles auditing, because the number of "failed" logins increases because successful logins also create one failed login. Suggestion: Add a option to pam_unix to inform it that it should suppress the warning in case of failure, because it is not the last authentication module. The last authentication module (pam_deny) should create the failure message.
Uhm I'm not sure I follow you but if you want to log in with a non-default system, you usually put it as sufficient _before_ pam_unix and leave pam_unix at the end, so if _that_ fails, it means all the methods fail, which is why pam_unix records the login failure. Please provide an example of failing stack if you think this is still an issue. Thanks.
Thanks for your help. This seems to work (at least at the moment). The opposite order might be useful when i.e. the OpenLDAP server fails, because otherwise there could be a long delay (or even an error?) before you can log in locally when something fails (but in this order you will encounter the reported problems ...) Everybody following the (official?) LDAP howto will encounter the reported problems: See http://www.gentoo.org/doc/en/ldap-howto.xml
Hey LDAP guys you maintain the guide right? Sincerely I wouldn't care about the delay, especially considering the kind of requests it would have to be fixed (changing PAM iself). But you're perfectly right if our official documentation has the “wrong” line it should be fixed.
Okay, I'll close this one since pambase is now getting support for authenticating properly against other login services, and should give an idea on how properly doing it. The problem is still in the docs, but since I haven't integrated LDAP just yet it can't be fixed right away.
