MultiFoundation Security set up

[Chris Quinn]

I have JDE E1 e812 TR 8.98.21 WINNT Oracle 10g DB, WAS/OAS and am planning an upgrade to TR 8.98.30. The manual says that TR 8.98.30 password security differs from 8.97 so I should create a separate set of security tables so I can test the TR in DV/PY while allowing the PD users to log into 8.97. I changed the OCM mappings for the DV and PY environments for tables F98OWSEC, F98OWPU and F9312 to point to a new Data Source for the copies of the three security tables.

I cleared cache and as a test if I log in JPY812 on the web and create a new user the user is still stored in the original security tables in SY812.F98OWSEC. How do I get this to work so that the DV and PY environments use the copies of the security tables? I thought this would be straightforward. Any suggestions will be greatly appreciated. Thank you, Chris Quinn

 

[cncjunior1]

I believe the security change they are referring to is when they changed the password decryption algorithm way back in SP2 or around there. This shouldn't apply for you.

 

[ice_cube210]

Did you change the OCM mappings for the J environments in the Server Map also. Also clear security cache (Bouncing would be the best) , on the Enterprise Server that acts as your primary security server

 

[Chris Quinn]

Hmm, the August 2008 manual JDE E1 Tools Release 8.98 Reference Guide for Microsoft Windows explains that the 8.97/8.98 password encryption schemes are not compatible. Once a user logs into 8.98 they would no longer be able to log into 8.97 (PD) without password maint. Thanks.

 

[Chris Quinn]

I did update the Server Map OCM mappings for the J environments. Cleared cache as well. I'll try bouncing the HTML Service and the E1 Service as well. Thanks.

 

[jstooge]

I agree...the security change was from far back...going from 8.97 to any of the 8.98 releases has had no security issues that I've ever seen.

 

[jstooge]

Keep reading the manuals. They are ALWAYS true. All I'm saying, is that the passwords work fine in all of my 8.97 to 8.98 Tools upgrades...of course, if you are doing multi-foundation, it would be easy to see and wouldn't affect your production system...but that's just me.

 

[tiradoj]

Hi Chris

I had E1 running in what I call parallel foundation or multifoundation mode for six months at a client site (unfortunately).

I found I had to create/use two entirely different databases to get it to work.

In other words I created a copy of JDE812 called it JDE812T for TEST and had separate data sources and mappings, tables, etc in effect I had two security servers-but also a second librarian data dictionary and server map tables. I probably didn't need quite all of it but this -in my humble opinion is not sufficiently clear in the JDE manuals that you have to go to this level.

Promoting code through the path code was a hassle because of the duplicate Object Librarian tables and maintenance was a bear but unfortunately, because of what they wanted to do, I had to do skips and jumps. I finally got them to cut over.

I posted this issue here a few months ago and I noticed the post has been viewed over 600 times I believe so I guess it struck a chord!

In my case, I was running 89721 on Production and 89820 in Test.

You might check my post here on Multi-Foundation and hit me up if you still need more info.

Regards,
Joe Tirado
Senior CNC Consultant

 

[sashton]

Agree. If you haven't already performed this, you should not need to worry about having separate security tables. I have multi foundation setup with 8.97 and 8.98 and I did not have to perform this step.

 

[Chris Quinn]

Thanks. You're correct, no additional security tables required for 8.97/8.98 Multi-foundation. Installed 8.98.31(DV/PY) along side 8.97.21(PD) and it's working fine.

 

[tiradoj]

Funny I discussed the issue with Oracle and they confirmed I had to do have two sets of security tables do what I wanted.

And two CNCs here said they were able to get a 898.X release talking to a 897.X release with security on huh?

On our system the 89820 SP for TEST server wouldn't play nice with 89721 SP in Production.

Joe Tirado
Senior CNC Consultant