If you have ever reset a password in the E-Business Suite for an FND_USER record, you know the typical password parameters required to get it to be accepted by the application. Yet what happens when you forget those rules, and try to reset the password using a script? Let me tell you, the results are not good!
Remember my post a few days ago about not jumping to conclusions? I wish I could tell you that I did not jump to a conclusion during our DR testing when I had just reset a password for a FND_USER record, and had a problem when logging into the account, but honestly I jumped right to the conclusion that the DR project must be part of the problem here. When I was logging in with the account, I would get the login prompt but when I should have been presented with the EBS application Navigation landing page all I received was an error message indicating that the page could not be reached. Of course I had logged into the DR environment with my credentials an hour or two ago, so of course something in DR had changed which is preventing me from logging in with the other account right? WRONG.
What was the problem? I reset the password for the account using a PL/SQL script that I really have not used a lot in the past, so I did not realize the same rules applied here when creating a password! What I did was to create a password with consecutive duplicate characters (for instance, the zz in pizza are consecutive duplicate characters so that word cannot be used in a EBS password), and since there was no application validation as I was using the script, it apparently saved but the EBS application did NOT like it one bit. After I had asked my co-workers about this problem, it was suggested I make the password contain no consecutive duplicate characters in a row, and after doing this with the script I was now able to log into the EBS application with the other account!
No comments:
Post a Comment