Question

When I use com.ibm.as400.access.AS400.validateSignon() to authenticate a user's credentials and they pass the validation, and have successfully connected, it does not reset the "failed signon attempts" to 0.

When entering an incorrect password the field "failed signon attempts" is incremented; when successfully signing on the "failed signon attempts" still maintains that there were invalid signons. Strangely enough the "previous sign-on" is updated with the correct date & time.

Here is a dump of DSPUSRPRF on the as400:

User profile . . . . . . . . . . . . . . . : BOB
Previous sign-on . . . . . . . . . . . . . : 12/12/05 21:34:08
Password verifications not valid . . . . . : 4
Status . . . . . . . . . . . . . . . . . . : *ENABLED

The only was I have managed to get the "failed signon attempts" to reset was by disabling and re-enabling the user using the toolbox. This is not a viable solution as this updates the change date & time on the user profile.

This behaviour is contradictory to the way that our green screen telnet session is handled, when a user logs into the as400 the "failed signon attempts" are zeroised.

Any suggestions and/or resolutions are gratefully accepted.

Was it helpful?

Solution

Can you use the QSYGETPH API instead? According to the documentation there it says "Resets the signon attempts not valid count to zero."

OTHER TIPS

This behaviour is fixed with the following PTF: V6R1 SI48759 V7R1 SI48761

JT400 doesn't use the normal signon mechanism when it connects ... so the behavior isn't something that surprises me. JT400 doesn't 'sign on' per-se ... it connects. Slightly different behavior.

The question I have is: Why is it important to reset the valid signon count when you connect via JT400?

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top