5

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.

WarrenT
  • 4,502
  • 19
  • 27
Rudi Strydom
  • 334
  • 3
  • 12
  • My apologies for misunderstanding the situation. I added a phrase in the question to help ensure that nobody can make the misinterpretation mistake I did. (Idiot proofing, lol) And had I looked at your profile, I should have known better, eh? I'll delete my answer. – WarrenT Dec 11 '12 at 15:51

3 Answers3

3

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

Benny Hill
  • 6,191
  • 4
  • 39
  • 59
  • Thanks Benny, I have done exactly that. I now use both methods when validating a user's credentials: – Rudi Strydom Dec 10 '12 at 15:44
  • The reason for that is that AS400.validateSignon() updates the previous signon date when successful signon occurred, thereafter I call QSYGETPH (with the same credentials that just successfully passed authentication which in turn resets the invalidSignonAttemps indicator on the user. Thanks for the assistance. – Rudi Strydom Dec 10 '12 at 15:49
2

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

Hans Bornich
  • 21
  • 1
0

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?

David G
  • 3,940
  • 1
  • 22
  • 30
  • Hi, because if the user does 2 invalid signons and then a valid signon the counter should be reset; as per the method the as400 has always worked with its green screen logon. If this doesn't happen the next time he enters an incorrect password which could be in a couple of days with multiple successful logon in between he will still be disabled. – Rudi Strydom Dec 10 '12 at 15:54
  • OK, I see what you mean. It does seem odd that there's no way to clear invalid signon's. You might want to try posting a message to the JAVA400-L mailing list ... some of the JT400 dev's & SME's hang out there (http://mlists.org/java400-l). – David G Dec 11 '12 at 15:20
  • It seems that a PTF we loaded last month was the culprit that caused it. Removed the PTF and all is good. – Rudi Strydom Dec 12 '12 at 09:30
  • What PTF? Share the joy. :) – David G Dec 12 '12 at 14:29