JDE System user password

[wainwrr]

It looks like we have one (at least) user with an incorrect system user password. Suddenly last friday after many years of no problem, the system user account got locked at the database level because of too many attempts to login with the wrong password.

We unlocked the account and all was well until Monday midday when the same thing happened. We currently have the expire after too many wrong passwords setting disabled so the system is running. DB auditing can only tell us that the problem is coming from our app servers; we're web client almost exclusively so there's no further traceback beyond where BSFNs get executed.

I don't like having the invalid password check off but I can't see a way past this at the moment. I believe we can set the system user globally bu thta seems a touch inelegant. Is the system password held against user records anywhere so we can look for an odd hsah value?

Any brilliant insights would be warmly welcomed.

 

[markdcci]

Do you have security history turned on? If so, try to match up who was logging in at around the time you see that JDE was disabled. It might help narrow it down.

 

[wainwrr]

That's a good idea but, looking at the records, I think it doesn't get far enough for there to be a recorded log on attempt. I'll try breaking it deliberately and see what happens in the F9312.
Thanks,

 

[brother_of_karamazov]

[ QUOTE ]
It looks like we have one (at least) user with an incorrect system user password. Suddenly last friday after many years of no problem, the system user account got locked at the database level because of too many attempts to login with the wrong password.

We unlocked the account and all was well until Monday midday when the same thing happened. We currently have the expire after too many wrong passwords setting disabled so the system is running. DB auditing can only tell us that the problem is coming from our app servers; we're web client almost exclusively so there's no further traceback beyond where BSFNs get executed.

I don't like having the invalid password check off but I can't see a way past this at the moment. I believe we can set the system user globally bu thta seems a touch inelegant. Is the system password held against user records anywhere so we can look for an odd hsah value?

Any brilliant insights would be warmly welcomed.

[/ QUOTE ]

So you have a system user password set incorrectly and you don't want to take the one step guaranteed to fix it because it would be "inelegant"?

I agree that rebooting a system because something is running slow is an example of taking a sledgehammer to a fly but fixing your system quickly, using a method that fixes the system, when it keeps failing seems like the right thing to do.

Life is too short to be right all the time, be happy with %50.

 

[SULLY1]

Maybe I'm missing something here but have you tried simply deleting that users security record and re-adding it? I remember many years ago I had a user with a similar problem. And re-adding the security record worked. I don't know why it got corrupted in the first place.

Patty

 

[janicej]

I think the problem is he doesn't know which user has the incorrect password.

 

[brother_of_karamazov]

[ QUOTE ]
I think the problem is he doesn't know which user has the incorrect password.

[/ QUOTE ]

That's why you change them all.

 

[janicej]

I totally agree that's the best solution. I was responding to Patty because she sounded confused about why he didn't just delete the one security record.

 

[brother_of_karamazov]

[ QUOTE ]
I totally agree that's the best solution. I was responding to Patty because she sounded confused about why he didn't just delete the one security record.

[/ QUOTE ]


Ahhh, that makes sense. I see what you mean now.

 

[wainwrr]

There are a couple of points here. The first is that we don't know for sure that that was the cause and finding a misaligned password would be some proof.
Next is that it follows that a global password reset might not therefore be guranteed to fix the situation.
Third is that a blanket approach doesn't allow for feedback to the agent that got the password wrong so that a similar event can be avoided in future.

 

[peterbruce]

I'm a little surprised the user who is experiencing the problem has not complained about not being able to log into JDE. If they do, then you have the user id.