Single Sign On and LDAP

wow

For someone who hasn't commented on a thread for a few weeks, I'm getting a lot of press recently (!)

I actually have very little to say about SSO. If a customer requires it, then it should be implemented - personally I already have a gazillion user ID's and passwords, and having yet another one for the Enterprise system isn't that big of a deal for me. I personally feel that SSO shouldn't be implemented, since it just adds an extra level of complexity and attempts to get security maintenance out of JDE and back into the OS/network - but I also understand its a personal preference, and what do I know - right ?!

My comment was more of an homage than another more fawning comment. I do understand your point. Although, I must say I don't agree that the security maintenance is taken out of JDE and back into the OS/network in a pure play SSO configuration. That is what the LDAP integration does, to an extent.

For me, if for nothing else, SSO has virtually eliminated the "please reset my JDE password" requests and has reduced effort on my part when the access audits come around. Being able to say "SSO" checks off that box and they don't worry so much about the backend JDE insecurities. And what do I know? I know, not much, but I do know that I don't know it all.

Jon,
I tend to agree with you that SSO adds an overly complex addition for what on the surface seems to be a very simple feature.(I long for the days of Unified Login)

Charles,
Your level of knowledge on this subject is astounding. I have to read your posts 2 or 3 times to make sure I understand what you are saying. If you don’t mind I’d like to try to ask what may be a very over simplified question.

I’m working on an 8.12 install with an Iseries DB/enterprise server and a Red Hat Linux JAS servers running OAS 10.3.3.3.1

The goal: Minimize User ID management.

Option 1: “Basic LDAP integration” Would allow JDE to interact with MS Active Directory as long as user names and passwords don’t exceed 10 Char.

Option 2: “Oracle SSO” provides the same LDAP integration plus (among many other things) adds the ability to eliminate the 10 Char limitation. The downside is that SSO requires the addition of an Oracle SSO server and associated Oracle Database.

Is this an over simplification?
Is there a third or fourth option?

Sometimes I have to read my own posts a couple of times just to make sure they make a bit of sense, even to me. It is so easy to stream consciousness into words when discussing such arcane technology concepts...and for that I apologize.

So options:

You have at least a third option which is to buy Oracle Access Manager licenses.

Last time I checked it was not free but relatively inexpensive on a per user basis. It can be implemented with or without Oracle SSO. Just like Oracle SSO, Oracle Access Manager is preintegrated with JDE in the JAS code. Later tools releases from 8.97 on up allow some or most of this to be configured from within Server Manager.

OAM is a bundling of acquired products (Oblix/CoreID) and was designed to support heterogeneous environments. Oracle SSO was designed to support Oracle technology and applications, specifically, though it is somewhat extensible. Oracle has stated they plan to "fuse" them together starting with OracleAS 11g. We'll see....

Again - I haven't looked into eliminating the 10 character USER limitation with base Oracle SSO, but it may be possible. It definitely eliminates the 10 character password issue.

I've found that the Oracle database that is required for OID and thus Oracle SSO is really not very difficult to manage. Install Oracle Enterprise Manager Grid Control (the latest 10.2.0.4 is much improved) and you can point and click your way through a high number of complicated admin tasks. For instance, from a JDE perspective, I refreshed QA from PROD in a few hours without ever leaving the OEM Grid Control user interface.

I've never taken an Oracle DBA class. Everything I know about Oracle in general (an extremely broad topic I don't think anyone would argue), outside of a couple of CNC classes I was sent to over five years ago, has been information acquired by reading and doing and breaking stuff on purpose just to see what happens. Then I fix it and learn from the experience. Oracle Database is no exception. I've compared Oracle 10g R2 and SQL Server 2005 and, strangely enough I'm more comfortable with Oracle having stumbled through time with it (Metalink has been my friend for a couple of years), so my biased opinion should probably be taken for what it is worth. If a customer is choosing a technology platform and they don't have the luxury of limited use rights to the Red Stack with JD Edwards, Oracle is/can be twice as expensive as SQL Server from an upfront licensing perspective, so I definitely understand the apprehension.

For small shops, including my own, the Oracle DB included with OID can be a "set it and forget it" type of install with minimal administration. Setup daily or weekly exports or turn on archive logs and enable Oracle Recovery Manager (RMAN) for backups (or script a scheduled shutdown of the infrastructure for a cold backup) and you have a workable solution.

Also remember that the Oracle database requirement is not something you have to license separately if you have the appropriate OAS Standard Edition license and/or Red Stack license. OAS Enterprise Edition may be required if third party (non Oracle) apps are meant to be integrated with Oracle SSO, but at this point, if someone wants to do that, I'd suggest they look at the alternatives and wait for things to shake out with the middleware strategy.

Just remember that Oracle really focuses the Oracle SSO solution for Oracle technology and applications customers and preintegrates with Oracle eBusiness Suite, JD Edwards EnterpriseOne, etc. It can work outside of those confines, but they have a vision and it seems the acquisitions and integration projects ("fusion, fusion, fusion") is starting to play out in both marketing strategy and technology direction.

Thanks for the response.
So on your option 3: How does Oracle Access Manager help me? Does it require the extras Server/Oracle Database?

Here's a red piece from Oracle that summarizes how long user names and passwords can be used with E1 and SSO.

Thanks but Charles option three was to impliment Oracle Access Manager without having to install the complete OSS.

I remember that document - thanks for posting jdel. Actually, looks like that document shows how to do the long username mapping for either Oracle SSO or OAM.

One more thing - a fourth option would be an Oracle Portal or IBM Collaborative Portal install - that would give you a single sign-on into JDE via the portal. Not for the faint of heart.

As for Oracle OAM requiring an Oracle database, I believe it does not. I also looked and it seems to be just J2EE code compatible with many J2EE servers.

Regarding SSO in the more traditional sense - is there a simple, well documented way to integrate E1 JAS with SSO by WEBSign?

I keep 'reading' that the only SSO that is available is by using the Oracle Collaborative Portal or other Oracle technology. Am I also understanding correctly that SSO as it pertains to E1 is more of a persistent 'cookie' type of SSO and not SSO in the more traditional sense?

Please advise.

James

I am attempting to enable LDAP within EOne in preparation for the IBM Portal. The reason I need to enable in EOne is that the Active Directory user names are <firstname.lastname> and I need EOne to use the mapping table F00927 to bridge the 10 character to the AD 20 character names. Has anyone gotten EOne to use this table F00927? Any suggestions would be appreciated. I have LDAP enabled and can sign in as any EOne user who matches the AD username.
8.12/8.97.1.1 OS/400
WAS 6.0.2.21
WSP 6.0.1.1

Hi Folks,

I am so confused about what Oracle is saying and all things I can read here. Maybe I ask my specific question and hopefully you can help me with it.

We are currently migrating from 8.10 fat clients to 8.12 web environment on Oracle application server.

On 8.10 I had the Unified logon option, I only had to set some settings on the JDE.ini on the server and clients and "Unified Logon" was working.

All our current JDE usernames and active directory usernames are the same. I just want to achieve that the windows userid and password is used to login to JDE. If this is not possible a solution for me that the user types in his userid and windows password and that will be also the same for JDE.

What do I need to setup for this?

Thank you very much for your help

Ronald,

let me break it down in non-technical terms. Out of the box, your 8.12 users will need to provide a username and password to get in to 8.12. The solution that Charles Anderson was writing about is setting up Oracle single signon. Oracle sigle signon is a unified solution for all Oracle apps, JDE, hyperion, e-biz, etc. Once logged in to Oracle single signon for one app, you are logged in for all of the other Oracle apps as well. To enable single sign-on, you would need to set up a VERY complex set of services; Oracle Database, OAS, OID and a few others. It's possible to set up, but not for the faint of heart. Hats off to Charlie for figuring it out.

I lost track, but this long running thread seemed to spell out a few less cumbersome solutions to that as well. This seems to me to be an area where hiring a consultant would be a wise investment. From what I have seen in my OAS training classes and hands-on experience, this is not a "quick and dirty" solution to set up.

Gregg

Just to clarify:

With Unified Logon, your users JDE Windows' client authenticated against Active Directory. There wasn't a login window / splash screen. You do not need single sign-on per se, you just want JDE to authenticate against Active Directory again.

If this is what you are looking for, I went down the same path in 2007. This is what is known as basic LDAP authentication. Basic LDAP authentication is common among many other web apps. It was not directly supported until recent releases of JDE EnterpriseOne 8.12 / 8.9x.

Prior to the recent tools SP's (pre 8.97), the JDE limitation with LDAP was long account names and long passwords. JDE/Oracle's recommendation was to use Oracle Internet Directory (OID) with Oracle Single Sign-on and have an intermediary account. The big problem with that was that you had to put the OID / OSSO infrastructure in place and synchronize AD with SSO on a daily basis. This kind of defeats the purpose of LDAP AD integration. That is, a direct tie between your Windows domain account / password and your JDE account / password. I gave up on this effort since my company did not want a huge OID / SSO project.

If I understand correctly, recent enhancements to LDAP authentication have eliminated the need to have OID for authentication. You can get around the problem of long passwords too. Long account names are still a problem.

So, if you are 8.97+ and you don't have long account names (which won't be any different than with Unified Logon), you should be able to configure AD LDAP authentication without OID / SSO.

[ QUOTE ]
All our current JDE usernames and active directory usernames are the same. I just want to achieve that the windows userid and password is used to login to JDE. If this is not possible a solution for me that the user types in his userid and windows password and that will be also the same for JDE.

[/ QUOTE ]

In response to this, the answer is that you can achieve either or both. The simple answer is, you do have options. This includes implementing Kerberos on the web server and Windows Native Authentication ("WNA") for Internet Explorer (also known as "IWA" or Integrated Windows Authentication.)


If you go with Kerberos, you can have an experience as seamless as UnifiedLogon....and if you are moving from Citrix to PC based browser access, it is even more seamless. It is not as easy as setting up UnifiedLogon, make no mistake about that. Getting there isn't necessarily a "piece of cake", but do know that you won't be blazing any trails on your own, provided you know where to go for help. There can be some "gotchas", but properly evaluating the situation beforehand can help make the decision between Kerberos and straight LDAP for the HTML clients. I can possibly even assist to some degree.



Now, I've read through the latest posts and there is definitely some misinformation on this thread; some of it is just plain wrong. Some of what I have posted may also be misinterpreted, but this isn't a simple discussion to have - at least not as simple as describing UnifiedLogon and then implementing it in an hour or two (depending on whether or not a Windows Enterprise Server is already in place....)

First, UnifiedLogon wasn't designed to authenticate users against Active Directory or any other LDAP server for that matter. It was designed to search a list of users/groups for a matching domain user account, and when it found a match it sent the authentication request to the Security Server. I believe it was initially designed for and worked with NT 4.0, which didn't have an LDAP (Active Directory was introduced with Windows 2000), but a SAM (Security Accounts Manager) database. UnifiedLogon isn't Single Sign-On, but it does effectively serve the same function to the end user. You can accomplish this "behavior" with the HTML client on OAS, and I have done it, and I do understand there are other ways to go about it.

Oracle has offered BOTH Oracle Single Sign-On and Oracle Access Manager as "solutions" for the HTML client authentication dilemma when "Single Sign-On" is desired. This is in addition to standard LDAP (which works provided the LDAP server of any variety is compliant.) Oracle Access Manager does not require Oracle Internet Directory (OID) for its backend LDAP. The interesting thing about that is, for a spell, I felt they were pushing everyone over to Oracle Access Manager. The initial release of 8.97 made it an automatic config for OAM (within Server Manager) with no documentation for Oracle SSO - I had to set it up manually.

The document posted to this thread (Long username mapping between JDE and either Oracle SSO or Oracle Access Manager) could lead one to believe that, but that just isn't the case. That is just one of the supported LDAP servers. Oracle SSO does require OID, that is currently true. However, it is possible to "chain" OID to LDAP such that the synchronization (by seconds, minutes, hours, or whatever interval you choose) is not required. That is supported in Identity Management 10.1.4.2.

Now, LDAP integration with JDE has been possible since the release of EnterpriseOne 8.11 and Tools 8.94. It was, and is, configured at the technical foundation level of EnterpriseOne and is not dependent on an HTML client, an OID, or any other third party component service. A UBE runs in JDE to synchronize accounts from LDAP into JDE, etc. It is not at all like UnifiedLogon, and as you have learned, in fact there is no way to configure UnifiedLogon for the HTML client.

In fact, if configured, it is transparent to the HTML client provided you conform to the requirements of JDE. I'm not sure how many folks enabled it at that time (early on I heard, through the grapevine, there were some problems with the initial release.) JDE/PeopleSoft/Oracle never required a customer have an Oracle Internet Directory (OID) to get LDAP working with JD Edwards EnterpriseOne. As a matter of fact, an OID template didn't even exist (but there was a template for AD) and you had to create a configuration for OID. I'm not sure how that was translated into "OID required", but some folks have interpreted it that way over the years.

With all due respect, I think the latest poster posted his question because, all JDE award winning aside, the previous posts were glib and about as clear as mud.

As I have mentioned to you in other threads before, I know of few companies willing and able to invest in a huge OID / SSO project just to get authentication against AD. I understand what Rival is trying to nail down on this. LDAP authentication is the standard for web app authentication. Not Kerberos or IWA. Kerberos and IWA have implications for all intranet web sites, not just JDE. And, until JDE or Oracle clearly documents how to do it, I would not consider it a supported solution for E1 authentication.

[ QUOTE ]
First, UnifiedLogon wasn't designed to authenticate users against Active Directory or any other LDAP server ...

[/ QUOTE ]

Your point here is a question of semantics. You are correct that Active Directory is not the same term as SAM. However, does anyone refer Windows authentication as SAM anymore. No. The point is that there is an authentication store and that store is surfaced as Active Directory. Whatever...

[ QUOTE ]
Now, LDAP integration with JDE has been possible since the release of EnterpriseOne 8.11 and Tools 8.94.

[/ QUOTE ]

Point well taken and I actually caught it after I made my post. Rival is coming off of an 8.10 UnifiedLogon configuration to an 8.12 installation. So, he should be able to configure basic LDAP authentication with AD.

[ QUOTE ]
As a matter of fact, an OID template didn't even exist (but there was a template for AD) and you had to create a configuration for OID.

[/ QUOTE ]

Actually, there is neither a template for OID nor AD in the LDAP configurations app. It just so happens that JDE does explain how to set up the OID integration in the Security Admin guide. They don't explain how to set up AD integration. That is precisely why there is confusion on whether basic LDAP integration with AD is supported.

Let's not beat around the bush anymore. Noone that is running AD has any reason why they have to have LDAP integration for JDE. They certainly don't want to invest in a huge OID project if they have AD. If they want SSO, more than likely the JDE CNC guy is not going to drive that decision. SO it seems to me, the whole reason for muddying the waters is to help feed consultants with OID / SSO projects.

Well, it's hard to tell, and I think you're divining what the poster meant just a bit. Perhaps you are right. I read the question a few times and I could come up with a couple of different interpretations.

Thanks also for clearing up the confusion about the "standard" for web app authentication. I'll be sure to let Microsoft know so they can disable IWA and reduce functionality of SharePoint logins. If SharePoint isn't becoming a standard in the corporate world, I don't know what is...On that note, hey, they should not allow anyone to login to Outlook to access their Exchange mail without entering a password - just too risky. OK, I'm just razzing you. But I have a point.

I do believe my point about UnifiedLogon working with SAM is valid, for the simple reason that it is by virtue of backwards compatibility that the service still works. Nothing in the utility is directly LDAP aware, at least as far as I'm aware. It was built as a "point solution", required a Windows domain, and for AS/400 shops, some even installed or attempted to install it on their deployment server as they had no other Windows server to run the services. If that isn't complication...?

So, what I was driving at without being too terribly rude is that the utility is old school and can't be relied upon much longer (as far as most end user access is concerned) as customers continue to migrate to 8.12/9.0 and beyond. It was a purpose driven solution, served its purpose well, and now its time has come and a replacement must be found. I have offered advice on how to replace UnifiedLogon for the Web without reducing functionality.

The scenario I am thinking of when I recommend Kerberos is for shops with UnifiedLogon and a bunch of Citrix servers. They could be migrating their users from Xe/8.0/8.9/8.10 to the latest HTML only releases. They may have previously published the JDE app with Citrix Presentation Server, and then pushed the JDE icon to the users desktop, with no web signon required. Users would then see a splash screen with JDE logging the user in "automatically" via the UnifiedLogon facility. Thinking of manufacturing companies with lots of plants or remote sites. Then along comes the HTML server and the users now have to enter their credentials again and this can open up several cans of worms. An upgrade like this is a big enough problem on its own. I'm done arguing about the merits of SSO as a replacement for UnifiedLogon. I've done it and it works. Case closed for my customers...but I do understand your points and all of them are valid to some degree or in totality. Which is why I say look at OAM. I might.

I don't think straight "LDAP" authentication is the best answer for every situation. It should always be there for "fallback" authentication, that is when WNA/IWA fail for some reason (a good reason or an abend, whichever)...but it doesn't make sense in every case that it should be the "only" way.

Once you get 8 to 10 web apps requiring the same LDAP credentials, each hosted in the same data center, it really screams for an SSO solution. I'm of the opinion that you really only introduce "reduced signon" when you introduce "single signon", which is why there are a glut of "Enterprise SSO" solutions on the market.

I do recall installing an 8.12 sandbox environment and starting out with an LDAP template for AD - perhaps I was drunk. I will have to revisit that. I tend not to drink on the job, but allergies are a problem in these parts.

[ QUOTE ]
Let's not beat around the bush anymore. Noone that is running AD has any reason why they have to have LDAP integration for JDE. They certainly don't want to invest in a huge OID project if they have AD. If they want SSO, more than likely the JDE CNC guy is not going to drive that decision. SO it seems to me, the whole reason for muddying the waters is to help feed consultants with OID / SSO projects.

[/ QUOTE ]

Is it irony that I'm not sure I understand what you are trying to say? "No one that has AD has any reason why they have to have LDAP integration for JDE". That one really thows me for a loop - huh?

Seriously though, one more time beating this dead horse. I managed to implement SSO with OID. Not only because it was what I had a license for, and it wasn't too terribly difficult "all things considered", but because it was a way to introduce real honest to goodness "reduced sign-on" SSO, in conjunction with a separate Oracle Portal implementation, and would serve as a foundation to build upon as we rolled out additional Oracle applications (such as Hyperion products and Siebel Analytics or "OBIEE".)

Honest to God, I made the call on that, and at the time I was "just the internal CNC" on loan from the parent company. I wasn't a consultant, and didn't bring in a consultant to run an expensive OID/SSO project. We had someone working on Portal stuff (mostly PL/SQL programming) and I did bounce a few ideas off of him, but when it came down to it, Google was Gold. So is/was Metalink.

Sometimes, if you want to stand out in the crowd, or you just want to be noticed once in a while, you take risks. Wihout risk, where is innovation? I'm not a developer, so about the only way I can "innovate" is by doing things like this. Users do appreciate it, believe me. They've told me without solicitation. You run into those people from time to time.

I'm not a consultant, I just offer advice and I am willing to help those who are willing to learn. Perhaps someday I will go into consulting, either when my luck runs out or I just want a change of pace. I'm sure you meant someone else anyway (as in, Oracle pushing their own products as a means to an end.)

I've met a number of folks over the years at Quest/Collaborate/OpenWorld conferences who are technical and have enough say in the decision making process at their employer that an OID/SSO implementation could actually fly "under the radar" and not garner a million dollar budget...but perhaps I just ran into all of them by sheer luck.

Supported? Are you serious? Half the time I can't get "support" on "supported" products unless there is a glaring problem in the code. If folks don't want to implement something that "isn't supported" they might want to consider another career. Once again, a development manager from Oracle asked me to co-present with him a couple of years ago at a Collaborate conference, and I discussed our SSO implementation with Kerberos during his JDE Security session. I was the guy with the apparent hangover and the frog in his voice. Never once did they warn users that it wasn't supported. They do that quite a bit for other things, actually, but not at that session. See one of my prior posts for why it is supported through Oracle and Oracle|JDE.

Oh, someone told me the other day that running Outlook with a Personal Folder (PST) stored on a 'network drive' isn't "supported".

"Glib"...so you're Tom Cruise all of a sudden? I think you're right. I don't get paid to post these replies, so I don't take the time to properly prepare each one as if it were my last...but so be it. My motivation is not to drive consulting dollars my way. Maybe this post will be my last. Enjoy it while it lasts.

Hi Guys,

Thank you for your reaction. I was happy while reading, then I was confused again, and so on.

I understand it is possible what I want to achieve. Just basis LDAP or not?

Just imagine our users. They didn't have to login to JDE for years. They have a windows password they have to change evey month. They didn't need to login to JDE. Now we are upgrading from 8.10 (terrible release) to the new 8.12 tools release 8.98 with all new features. Also Imagine they must switch over from fat client to web......??. If this feature isn't working just gives a negative flow....

User will say "it is possible for years and now it doesn't work" How do I have to explain this? Implementing big changes in infrastructure is also not the way to go. All our effort goes in the project, making it technically and functionally work.

Can you point me in the direction to configure this "simple" unified logon option?

Windows user = RLS
JDE user = RLS

Password is changed and managed by the windows domain.

Creating a case at Metalink doesn't work. After weeks the only answer was to install collorative portal. I found out myself that you also had to login for this, and that JDE is automatically logged in. Wow.........

Thank you in advance for your reaction

Rival..
back from JDElist retirement (after 3 years of 8.10)

[ QUOTE ]
Just imagine our users. They didn't have to login to JDE for years. They have a windows password they have to change evey month. They didn't need to login to JDE. Now we are upgrading from 8.10 (terrible release) to the new 8.12 tools release 8.98 with all new features. Also Imagine they must switch over from fat client to web......??. If this feature isn't working just gives a negative flow....

User will say "it is possible for years and now it doesn't work" How do I have to explain this? Implementing big changes in infrastructure is also not the way to go. All our effort goes in the project, making it technically and functionally work.

[/ QUOTE ]

Yes, this is why I recommended Kerberos. As some have pointed out, Kerberos is an authentication system while LDAP is an access protocol. They can work together. The folks who responded to your Metalink request aren't necessarily aware of all of the options. You don't need a portal, collaborative or otherwise. UnifiedLogon is no longer an option with the "web" client. Making "big changes in the infrastructure" is pretty much required if you want the same functionality. It is what it is. I can't make any apologies for Oracle, and I don't have any reason to defend them, either. The UnifiedLogon service just isn't applicable any more with the "web only" releases. Change happens.

Kerberos solves this problem (users don't have to enter more than one password), but it is NOT as easy to setup as UnifiedLogon. You don't have to configure "base LDAP" with JDE to make it work. It is all done at the "web" client layer, not the EnterpriseOne technical foundation.

You may accept some solution in between after evaluating the Kerberos option. First you would need to evaluate it. Gregg recommmended you hire a consultant, wouldn't be a bad idea. A good bet if you do hire a consultant would be to work with someone who knows both OAS (with SSO) and JDE EnterpriseOne. You can go it alone, but once again, not as easy as UnifiedLogon. I don't automatically assume that everyone is technically challenged and that solutions are just too hard for them to figure out. Until you say otherwise, I'll assume you are technically adept and can handle it.

The brief rundown on what you can do to get a UnifiedLogon "like" configuration up and running for the "web" client is as follows:

Install OAS - Infrastructure home option. I recommend 10.1.2.0.2 at this point for JDE. This is Oracle Identity Management and includes a prebuilt Oracle database - no Oracle database installation knowledge is required to get it up and running. There are other options for the database (all Oracle options), but the included database is the easy method.

The Infrastructure home will provide Oracle Internet Directory (OID) and Oracle Single Sign-On. OID and SSO can be installed together at the same time, which is recommended for a first time install, or separately. This can either be in separate homes on the same server, or on separate servers. For instance, OID/SSO together in the same home, or OID on server1 - while SSO is installed on server2. It is also possible to have server3 hosting the db...won't get into that now. Doesn't sound like this is what you want (infrastructure sprawl) but I post this stuff for everyone, not just one.

Once you have the infrastructure up and running, you can then pull the Windows Active Directory accounts into the OID. There are some decent "howto" documents/whitepapers out on the Internet - I've written one for a JDE journal and they are in the process of publishing it in pieces.

The act of pulling the AD accounts into OID is the issue some others have been railing on about - how it shouldn't be necessary, etc., but the fact is it is necessary for Oracle Single Sign-On. I've posted before that perhaps in the future it won't be. (For an Oracle employees perspective on the SSO/OID requirement among other thoughts: http://blogs.oracle.com/mwilcox/2007/12/clarifying_questions_on_kerber.html)

Either way, it is not like installing a new ERP system in complexity, but it will take some level of attention/maintenance, more so than UnifiedLogon. It is the nature of the beast. A big ERP upgrade project should take risks like these into account. I am disappointed how so many technical consultants leave out the "little" things like user authentication when they lay out the overall project plan for the technical upgrade.

Once you have the accounts pulled in, you can turn on the AD external authentication plug-in for OID. This will authenticate users in OID against AD using their Windows password. This isn't required for Kerberos, but good to have in case Kerberos fails for whatever reason.

Once you have this configured, you can connect JDE "web" client to Oracle Single Sign-On. Once that has been verified as working, you can configure Kerberos on the Oracle SSO server. This can work if you are running OAS on any supported platform, it doesn't have to be running on Windows to work with the Windows implementation of Kerberos.

Once you have Kerberos working with SSO, users who are able to authenticate with Windows should no longer be required to enter their username/password for access to JDE. Again, no portal is required for this, and it is supported.

The detractors either haven't done it themselves, have and hated it, are worried you will struggle and blame JDEList or them personally, or just want to be or enjoy being detractors.

I am sorry you are going through phases of understanding, confusion, understanding, joy, discomfort, etc. This isn't an easy topic to discuss, due to the Oracle centric nature of the recommended solutions. I'm also not a full time professional journalist, and no one is here to edit my posts on JDEList. Again, sorry.

[ QUOTE ]
I am sorry you are going through phases of understanding, confusion, understanding, joy, discomfort, etc. This isn't an easy topic to discuss, due to the Oracle centric nature of the recommended solutions. I'm also not a full time professional journalist, and no one is here to edit my posts on JDEList. Again, sorry.

[/ QUOTE ]

Your editors at the "esteemed journal of all things JDE" would love to edit your posts, but they're a bit busy right now getting ready for Santa's big visit. I tossed out the idea of a consultant because there are so many variables out there, it's a bit overwhelming for us mere mortal CNCs. My environment is so darn big and complex, it takes me forty hours a week just to maintain it, not leaving a lot of time to expiriment with complex trial and error solutions. I'll take all the help I can get (and my boss is willing to spend money on).


Silly question - on Websphere I enabled cookies and set the cookie time out to 100 days. My JDE passwords are set to require a change every 90 days. With this combo, my XE web users only had to change their jdeweb passwords four times a year. Kind of a simplistic solution, but maybe that will work?

Gregg

I make no argument with hiring a consultant. Just hiring any old consultant is a bit risky, because then you might be learning alongside them as they charge you for their "learning experience". I've seen that more times than I can count.

I say go with whatever works for you.