Changing JDE PSWD on Oracle

Jeremy M.

Jeremy M.

Well Known Member
I have changed the JDE password a dozen times on a Deployment Server - MSDE/SQL Server Express and Database Server - SQL 2005/2008 installs. This is my first time I am trying to change the JDE password on a Deployment Server - Oracle and Database Server - Oracle install and I am having no luck. My environment is E1 9.0 UL1, TR 8.98.2.3. Everything is Windows 2K8. I am following Doc ID 975565.1, and hit issues at step 15 and 16.

1.Stop all instances of JAS if running. Also, have all users exit any Development/Admin clients they may be working with. - Done.

2.End all EnterpriseOne services on all EnterpriseOne application/Enterprise servers. - Done.

3.Change the database user password. - Done.

4.Edit the Server JDE.INI file(s) to disable Security Server. - Done.

5.From an admin (Fat) client workstation, open the client JDE.INI and disable the use of Security Server for authentication. - Done, using deployment server

6.Login to the admin client. - Done.

7.Fast path to P98OWSEC. - Done.

8.Change the JDE System User password. - Done.

9.Change the JDE EnterpriseOne user security password. - Done.

10.Exit the admin client. - Done.

11.Update the JDE.INI on each EnterpriseOne application/Enterprise server with the new password in the [DB SYSTEM SETTINGS] and [SECURITY] sections. - Done.

12.For JAS, update the JDBJ.INI file (s) with the new password. - Done.

13.With services stopped and Security Server still disabled, ensure that PORTTEST is successful using the new JDE password. - Done.

14.Edit the server JDE.INI file(s) to enable Security Server. - Done.

15.Start EnterpriseOne services on the Application/Enterprise server. - Here is my first problem. As soon as I start the E1 service the JDE account gets locked due to too many failed login attempts. SQL Server dosn't do this so it is not an issue. What do you do to get around this issue?

16.Enable Security Server in the admin client JDE.INI and test logging in and submitting a UBE to the server. - Here is my second problem. Once I try to login to the deployment server it doesn't let me in because the local Oracle DB password doesn't match and it can't find the E1 Security Server.

Can anyone help me out here?
 
@ #7, were still using 8.12 but were using P980001 (Is it the same as P98OWSEC?) on the deployment server to change the JDE password.

@ #15, what oracle version are you using 11g? 11g passwords are case sensitive by default unlike the previous versions.

Oracle Version 10.1 and below : Default profile failed_login_attempts unlimited
Oracle Version 10.2 and up : Default profile failed_login_attempts 10

To change: (Set temporarily to unlimited or higher than default of 10 tries...)
ALTER PROFILE default LIMIT failed_login_attempts <value | UNLIMITED | DEFAULT>;

To unlock: (Need to unlock it before the account can be used...)
ALTER USER username IDENTIFIED BY JDE ACCOUNT UNLOCK;


@ #16, can you try to undo the changes?

Hope this helps.
 
Is there anything in the JDE.LOG that says LOGIN FAILED FOR USER 'SA'?
 
Jeremy,

Have you reviewed the logs on the Application server? It should give a little more detail as to where the security issue is happening. Perhaps even enable debug in the JDE.INI before starting the failing services.

And, not to be rude, just to point out the sometimes overlooked obvious (I've done it myself) -- Have you verified that you typed in the password the same everywhere?
 
I am not sure of all of your details but I was told unequivocably that at SP 8.97 and beyond you cannot change the JDE password in SQL or on your ES/DBS. JDE JDE has been hardcoded into DS programming.

This was a change from 8.96 and below.
 
Yea P980001, it is accessible in the form exit of P98OWSEC. That is what I am using to change the system user password. I am running 11G, I didn't actually know that is was case sensitive but I always act like it is case sensitive just in case, so that is not a problem.

I will try to temporarily set the failed login attempt to unlimited and see if I can get it to change. I am not quite sure if the Deployment server can't find the security server cause the account was locked on the 11G database or if it is because it can no longer connect to the local 10G database.

I don't even want to think about upgrading the local 10G database to the same level as my 11G. This local Oracle db seems to need a little more maintenance than a SQL Server Express.

Thanks for the feedback, I will update you on my progress.
 
Please see attached password change process - changing the password on the local database on the Dpeloyment Server should not be necessary.
 

Attachments

  • 156170-JDEdwards EnterpriseOne Password Change Procedure (Intel).pdf
    56.7 KB · Views: 259
Hi,
First, the security server should not be activated in the jde.ini of the deployment server, ever, as you must be able to log in to either jdeplan or dep900 environments even if the enterprise server(s) are down.

As connection to oracle database is normally via the schema user ids specified in the data sources, the only time that you access the database via jde user is via initial connect from the jde.ini/jdbj.ini/jas.ini files and these should only be modified via server manager for all the servers and, if specified only, in the jde.ini files on "fat" clients.

The normal sequence is:
1. stop all web and enterprise jde services via server manager.
2.change the jde password, in jde, from the deployment server.
3. change any initialisation passwords from server manager.
4. porttest enterprise server offline (only if jde user uses own user as system user)
5. start enterprise servers from server manager
6. check processes and logs from server manager
7. porttest enterprise server online
6. start web servers

your enterprise server logs, even without debug on, should tell you where your problem exists.

regards

Robin Wilson
 
This is not correct at all: "connection to oracle database is normally via the schema user ids specified in the data sources, the only time that you access the database via jde user is via initial connect from the jde.ini/jdbj.ini/jas.ini files".

So your subsequent conclusions may also be incorrect...
 
Big debate on the Security Server being active on the Deployment Server.

Yes you can activate it. For myself I NEVER ativate it and never have any of my clients have it active. Too many potential issues with not enough pay back.

However, I know several proficient CNC Consultants who swear by it and always have security server active on the Deployment Server.

Don't know why but everyone has their own opinion.

As for the connections to the Oracle Database...........this is what the proxy userid is for. Just chack the JDBJ runtime metrics in Server Manager.


Colin
 
Hi,
My apologies for the incorrect reply to your post that may have mislead you. Thank you to Alex Pastuhof for highlighting this.

Robin Wilson
 
I typically never activate the security server on the deployment server myself; however, I always did according to documentation in order to change the jde password. Once I got it changed I always turn it back off. I have noticed in the past that after I change the database password and the jde.ini that the first service start has jde password errors until I log in from the Deployment server using the Security Server with the new password. I always thought even though I changed the jde password with Security Server off that it didn’t actually change the value in the database; it only updated the local database until I logged on using the new password and using Security Server. Then the jde password errors went away and the next service start comes up clean.

I am trying again now to change the jde password so I will keep you posted. I will be sure to collect the logs from my attempts today if I still have no luck.

Thanks everyone!
 
I was able to change the JDE password. I did alter the failed login attempts to unlimited. Not sure if I needed to though.
 
Hi Jeremy,

My thoughts on JDE user account having a default limited password attempts is a sure way to halt our beloved EnterpriseOne system (due to account locked) from a disgruntled employee or unknowing kind of users...
grin.gif


regards.
 
Eh.....just a few thoughts.

If you follow the correct process for changing the passwords you will nt have any issues and all runs smoothly.

Secondly why would anyone ever what to use 'JDE' as the userid to start the system?

I NEVER use 'JDE" and simply throw it away otherwise as KENTOY pointed out you can just enter a bogus password 3 times and poof the system goes down. Now what king of security is that.

My thoughts are use something that noone will ever guess like 'JDELAUNCH' as the password to start the system and do all of the other tasks. If no one knows the user account that is being used to start the system then they can't lock the system out!


Colin
 
Back
Top