I checked the "secure" log file and found a number of log entry like:
Aug 27 18:28:40 server unix_chkpwd[14655]: password check failed for user (filippo)
Aug 27 18:28:40 server saslauthd[3035]: pam_unix(pop:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=filippo
I googled around and found that the problem was due to the fact that linux is first checking the user credential against the PAM system and then against the LDAP, the result is an error message for every request of authentication.
The workaround I found (thanks Setyadi Fazrie) consist in editing the file /etc/pam.d/system-auth changing it from:
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so
to:
auth required pam_env.so
auth sufficient pam_ldap.so try_first_pass
auth sufficient pam_unix.so nullok use_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
Before changing it, my question is: would this brake anything in the ClearOS system?
Moreover, the file system-auth is automatically generated, this means that sooner or later it may be overwritten. Is there any way to make the above changes permanent?
Thanks
Nello
Aug 27 18:28:40 server unix_chkpwd[14655]: password check failed for user (filippo)
Aug 27 18:28:40 server saslauthd[3035]: pam_unix(pop:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=filippo
I googled around and found that the problem was due to the fact that linux is first checking the user credential against the PAM system and then against the LDAP, the result is an error message for every request of authentication.
The workaround I found (thanks Setyadi Fazrie) consist in editing the file /etc/pam.d/system-auth changing it from:
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so
to:
auth required pam_env.so
auth sufficient pam_ldap.so try_first_pass
auth sufficient pam_unix.so nullok use_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
Before changing it, my question is: would this brake anything in the ClearOS system?
Moreover, the file system-auth is automatically generated, this means that sooner or later it may be overwritten. Is there any way to make the above changes permanent?
Thanks
Nello
Share this post:
Responses (23)
-
Accepted Answer
Well I finally got it to work (I think) and there are no more huge secure logs.
It worked when I applied the RedHat solution but changed forward_pass to use_first_pass (forward_pass wasn't recognised). My /etc/pam.d/password-auth-ac and /etc/pam.d/system-auth-ac now look like this:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth [default=1 success=ok] pam_localuser.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth sufficient pam_ldap.so try_first_pass
auth required pam_deny.so
account required pam_unix.so broken_shadow
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 1000 quiet
account [default=bad success=ok user_unknown=ignore] pam_ldap.so
account required pam_permit.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password sufficient pam_ldap.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
-session optional pam_systemd.so
session optional pam_mkhomedir.so umask=0077
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_ldap.so
Just to be clear I am using this on COS 7.2
Steve. -
Accepted Answer
Nick Howitt wrote:Did you change the rule order? It looks like you did but are you sure you had the correct password for user stephen? Did you also change both files (/etc/pam.d/password-auth-ac and /etc/pam.d/system-auth-ac)?
Yes to all, and as soon as I changed it back everything worked again. I don't understand why it did not work. -
Accepted Answer
It should not be logging a unix failure at all for imap transactions as imap should be authenticating through ldap first. You should have something like:
Did you change the rule order? It looks like you did but are you sure you had the correct password for user stephen? Did you also change both files (/etc/pam.d/password-auth-ac and /etc/pam.d/system-auth-ac)?auth required pam_env.so
auth sufficient pam_ldap.so try_first_pass
auth sufficient pam_unix.so nullok use_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet
auth required pam_deny.so
-
Accepted Answer
Many thanks for the replies Nick. I tried your solution from earlier in the thread and I lost email access, I ended up with:
Aug 14 13:11:03 server2 saslauthd[752]: pam_ldap(smtp:auth): failed to get password: Authentication failure
Aug 14 13:11:03 server2 saslauthd[752]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=stephen
Aug 14 13:11:04 server2 saslauthd[751]: pam_ldap(imap:auth): failed to get password: Authentication failure
Aug 14 13:11:04 server2 saslauthd[751]: pam_unix(imap:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=stephen
So this time instead of authentication occurring but a pam_unix error (which I accept can be ignored), I lost smtp and imap authentication (maybe it works on COS6 but not COS7 !?).
I'm gonna try the RedHat 'solution' with Nick's suggested amendment and report back.
Steve -
Accepted Answer
-
Accepted Answer
Tried it and it does not work. It gives a lot of errors:
and I can't authenticate my e-mail. Reverting to the other posted solution that I've been using for years.Aug 14 09:17:35 server saslauthd[4264]: PAM unable to dlopen(/lib64/security/pam_sss.so): /lib64/security/pam_sss.so: cannot open shared object file: No such file or directory
Aug 14 09:17:35 server saslauthd[4264]: PAM adding faulty module: /lib64/security/pam_sss.so
-
Accepted Answer
-
Accepted Answer
Sorry to reopen an old thread but I have just noticed that as soon as I started to access the IMAP and SMTP servers from an Android tablet I get a whole load of the following errors
saslauthd[752]: pam_unix(imap:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=
for both imap:auth and smtp:auth
As I have another 10 tablets to add with similar setups I suspect I am going to have a huge amount of errors generated in the secure log. So I would just like to ask if using the solution from RedHat website would mess anything up. It says:
Resolution
This is expected behaviour from pam_unix and the message is normal and harmless.
There is no configuration option within pam_unix to stop logging those messages.
The default pam configuration tries to authenticate a user using pam_unix first, then using pam_ldap.so module if authentication with pam_unix is failed.
If pam can't authenticate a user using pam_unix.so, it logs a message of auth failure and passes control to pam_ldap.so which authenticates the user successfully.
If you would like to remove these default failures errors from logging in /var/log/secure logs , we can do the following configuration changes.
Change auth section in /etc/pam.d/password-auth-ac and /etc/pam.d/system-auth-ac to :
auth required pam_env.so
auth [default=1 success=ok] pam_localuser.so <===== [1]
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.so forward_pass <===== [2]
auth required pam_deny.so
In change[1] pam_localuser will call pam_unix only when user exists in /etc/passwd .
Change[2] indicates that pam_sss should use the already entered password.
Cheers
Steve -
Accepted Answer
-
Accepted Answer
Nick Howitt wrote:
Have a read of this thread and see a bug has been filed. There has been no movement on the bug.
I saw that, and noted that it was several years old. Since I am only 4 days into the new version, I sent a complaint to the customer service guy who has been helping me with some other issues asking if they were going to fix it. I think, with 1,350 entries in this file, I am going to uninstall the feature. I was able to note some hijack attempts via SSH, but those have stopped since I closed the SSH port, so I think I am going to take my chances without the event notification until something is done about it. My system, while using the business version, is a home office situation and I monitor it closely anyway. Thanks for your comment. -
Accepted Answer
-
Accepted Answer
I hate to bring up an old issue, but this same thing is happening to me with version 7.1. Was any official fix ever posted. I've modified the suggested file and will have to wait a bit to see if the problem continues, but I have over a 1000 entries in the log file in three days of the new version. Thanks for any comments.
Geep -
Accepted Answer
I'm still running with the changes I posted earlier in the thread and I've not noticed any problems. If you are uncomfortable with my "suck it and see" method, it can be quite easy to filter messages out of /var/log/secure by setting a minimal .conf file in /etc/rsyslog/d. It would not stop the souce of the problem but it would hide the logs. -
Accepted Answer
-
Accepted Answer
I was looking at this a couple of weeks ago when I was poking around Samba 4. One difficulty is the fact that the /etc/pam.d/password-auth is managed by the authconfig command. It's not a show stopper, but it is a bit messy and it's a tiny tiny departure from upstream. The underlying ClearOS API would have to run "authconfig" and then fix the file after the fact. -
Accepted Answer
Bumping this thread as it is now 6.4beta time. I have now been running for 10 weeks with /etc/pam.d/password-auth looking like:
with no obvious negative side effects and a greatly reduced amount of authentication failure logging.#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
#auth sufficient pam_unix.so nullok try_first_pass
#auth requisite pam_succeed_if.so uid >= 500 quiet
#auth sufficient pam_ldap.so use_first_pass
# Order changed from the above.
# see http://www.clearfoundation.com/component/option,com_kunena/Itemid,232/catid,39/func,view/id,45410/
auth sufficient pam_ldap.so try_first_pass
auth sufficient pam_unix.so nullok use_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
account required pam_unix.so broken_shadow
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_ldap.so
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type=
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password sufficient pam_ldap.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session optional pam_mkhomedir.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_ldap.so -
Accepted Answer
-
Accepted Answer
I've tried a little look at the pam manual and I am not understanding. If, in the altered scheme, a normal user validates against pam_ldap, why is pam_unix even being tried?
Also, if anything in system-auth-ac is changed, what, if anything, needs to be restarted for the change to take effect?
Also is it significant that /etc/pam.d/imap has changed between 5.2 and 6.3. In 6.3 it reads:auth required pam_nologin.so
auth include password-auth
account include password-auth
session include password-auth
and in 5.2 it reads:
I am just trying the 5.2 version with the changes in the first post but this is pure hacking without much knowledge. It is looking OK at the moment with this rule order:auth required pam_nologin.so
auth include system-auth
account include system-auth
session include system-auth
By OK I mean that I am no longer getting messages in /var/log/secure and I can still access my mails but I don't know what I'm doing so I'd love some feedback.auth required pam_env.so
auth sufficient pam_ldap.so try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_unix.so nullok use_first_pass
auth required pam_deny.so
If I try the 5.2 /etc/pam.d/imap file without the changes to /etc/pam.d/imap above then I still get the messages.
[edit]
I think I understand a bit more. WIth the 6.3 /etc/pam.d/imap file it looks like you need to make the changes to /etc/pam.d/password-auth-ac and not to /etc/pam.d/system-auth-ac, but if you do my changes you will not be able to connect by ssh so is a non-starter. It is looking like the OP's changes may be working if made to this file.
[/edit] -
Accepted Answer
-
Accepted Answer
-
Accepted Answer
@Peter,
Do you know what is happening with this? I have tried the changes and now I am getting lots of:
These are from accessing webmail through Roundcube.Oct 29 16:54:38 server unix_chkpwd[28196]: password check failed for user (mail-user)
Oct 29 16:54:38 server saslauthd[3300]: pam_unix(imap:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=mail-user -
Accepted Answer
Sorry, I didn't specify it... Yes it's with cyrus-imapd.
To be sure the issue is limited to the cyrus-imapd, I made some other tests with Postfix and SSH, I got the following log in the secure file:
Aug 28 11:15:18 server unix_chkpwd[17022]: password check failed for user (filippo)
Aug 28 11:15:18 server saslauthd[3076]: pam_unix(pop:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=filippo
...
Aug 28 11:15:46 server unix_chkpwd[17050]: password check failed for user (lorenzo)
Aug 28 11:15:46 server sshd[17047]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.1.133 user=lorenzo
Aug 28 11:15:46 server sshd[17047]: Accepted password for lorenzo from 192.168.1.133 port 53227 ssh2
Aug 28 11:15:47 server sshd[17047]: pam_unix(sshd:session): session opened for user lorenzo by (uid=0)
...
Aug 28 11:19:57 server unix_chkpwd[17107]: password check failed for user (lorenzo)
Aug 28 11:19:57 server saslauthd[3071]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=lorenzo
It seems the issue is there also for other services
Thanks
Nello
Please login to post a reply
You will need to be logged in to be able to post a reply. Login using the form on the right or register an account if you are new here.
Register Here »