pam_authenticate with correct password doesn't reset the number of login tries with wrong password

Hello,

I set AUTH_MAXTRIES=7 in /etc/default/security. I use pam_authenticate() in the application to check account authentication.
1) I did 6 login tries (by pam_authenticate) with wrong password, and then 1 try with correct password.
2) Then I did another 2 tries with wrong password, the account is disabled.

So the problem is that the correct login cannot reset the number of tries with wrong password.
Btw, if I use telnet, after 6 wrong password + 1 correct passwork + 2 wrong password, the account is not disabled.

OS: HP-UX B.11.31

Can anyone know this problem and help? Thanks in advance.

16 REPLIES 16

Hello,

You could initiate a debug on the session management component and on authentication component. This is done by adding "debug" option at the end of the corresponding line from /etc/pam.conf.

Debugging info can be found in syslog, LOG_DEBUG level.

Best regards
Horia.

Best regards from Romania,
Horia.

Hello Horia,

Thanks for your advice.

After adding "debug" option at the end of the corresponding line from /etc/pam.conf, we don't find LOG_DEBUG info in syslog file. Do we need to restart any application or do anything else?

Regards
Yu Ping

Try this:

Edit /etc/syslog.conf and add the line:

*.debug /var/adm/syslog/debug.log

Save the file and exit vi.

Restart the syslogd server:

/sbin/init.d/syslogd stop
/sbin/init.d/syslogd start

Check the file:
/var/adm/syslog/debug.log

For debug messages from your system (all debug info would go there in that file)

Horia.

Best regards from Romania,
Horia.

Hello Horia,

I have followed the steps you provided, but there is no /var/adm/syslog/debug.log exist.

Please advise. Thank you.

Regards
Yu Ping

Do you have something in

/var/adm/syslog/syslog.log ?

You should check for new messages in this file.

Check if syslogd is running:

ps -ae |grep syslogd

Horia.

Best regards from Romania,
Horia.

Hi Horia,

I have checked the syslog.log file, but no useful info:

# cat /var/adm/syslog/syslog.log
Feb 9 15:00:42 HELIKE12 syslogd: restart
Feb 9 15:00:42 HELIKE12 syslogd: the kernel messages are already disabled: No such device or address
Feb 9 15:03:12 HELIKE12 sshd[8628]: SSH: Server;LType: Throughput;Remote: 10.0.127.33-47570;IN: 26928;OUT: 10784;Duration: 550.2;tPut_in: 48.9;tPut_out: 19.6
Feb 9 15:03:44 HELIKE12 ftpd[8657]: FTP session closed
Feb 9 15:04:25 HELIKE12 sshd[8842]: SSH: Server;Ltype: Version;Remote: 10.0.127.33-47939;Protocol: 1.99;Client: 3.2.9 SSH Secure Shell for Windows
Feb 9 15:04:32 HELIKE12 sshd[8842]: error: PAM: Authentication failed for root from 10.0.127.33
Feb 9 15:04:35 HELIKE12 sshd[8842]: Accepted password for root from 10.0.127.33 port 47939 ssh2
#

the syslogd server is running:
# ps -ae | grep syslogd
8775 ? 0:00 syslogd

The system is currently unavailable. Please try again later.

wpa-pl-wpaframework-10000

Best regards from Romania,
Horia.

Seems that more that one syslogd is currently running. Please kill all the syslogd processes and restart syslogd. (use kill -9 if necessary)

ps -ex |grep syslogd

should return no lines.

Best regards from Romania,
Horia.

Then start the service again and verify that you have only one syslogd running (the above command would return only one line)

Please copy&paste /etc/syslog.conf here.
Double-check the configuration. Be sure that you used TABs to delimit the parts from each line.

Horia.

Best regards from Romania,
Horia.

Hello Horia,

Please see attached file which contains pam.conf and command output. Is it useful for the problem troubleshooting?

Thank you.

Regards
Yu Ping

It troubles me why you do not get the file: /var/adm/syslog/debug.log

This is why I suspected that you do have some problems on syslogd configuration. Re-check /etc/syslog.conf (do you really have this line:

*.debug /var/adm/syslog/debug.log

? You should use TABs between debug and /var
) .

Did you restarted properly the syslogd. Log off and then log in on another terminal. You should get something on debug.log file.

Horia.

Best regards from Romania,
Horia.

Hi Horia,

In my previous message, the attached file contains debug.log. Please check it.

Thank you.

Regards
Yu Ping

According to:

http://docs.hp.com/en/B3921-60631/pam_hpsec.5.html

You must have installed the TrustedMigration product. This can be installed only on HP-UX 11iv2+ according to:

http://software.hp.com/portal/swdepot/displayInstallInfo.do?productNumber=StdModSecExt

So you should have HP-UX 11iv2 or v3 and you should have check if the product is installed:

swlist | grep TrustedMigration

Also, according to man security on v3:

http://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/security.4.html

This attribute does not apply to trusted systems. So on trusted system this AUTH_MAXTRIES would not work.

Horia.

Best regards from Romania,
Horia.

Hello Horia,

But AUTH_MAXTRIES works well for telnet. That means when customer tries to test telnet with wrong/correct password, AUTH_MAXTRIES works well.

Your comments please, thank you.

Regards
Yu Ping

Hello Horia,

Do you have any ideas and advices? Thank you.

Regards
Yu Ping

Hello Horia,

Do you have the update of this problem? Thanks.

Regards
Yu Ping