We are starting to think about upgrading to LSF 9.0 so we can take advantage of the single sign on feature. We have consultants telling us that we can upgrade from 8.0.3 env to LSF 9.0 in 2-3 weeks. What little I've heard about 9.0 is that we will need to move from laua security in order to use the single sign on. We have close to 70 security classes. Do any of you think the upgrade can realistically be completed in 2-3 weeks or is it :bs:

Umm... If it is you and two other users, I would give it a cautious "maybe." I think a lot of this will depend on your circumstances.
-How many users?
-How many modules?
-How long have you been using Lawson (conversion of history factor)?
-How "vanilla" is your implementation?
-How much caffeiene can you tolerate?

To put it into context from our perspective... Even a technology/environment upgrade requires a full-blown integrated test of the applications. For us (20+ hospitals/foundations/research instutues) that testing, in and of itself, is at least two weeks (IF we can get dedicated resources), and it is usually closer to four weeks. From start to finish, our upgrade projects have run anywhere from three months (7.0.6 - 7.0.9) to OVER a year (7.2.4 - 8.0.3). I'll grant that our Environment upgrades have been shorter, but they are still much longer than three weeks.

Maybe I am misinterpreting the consultant's statement. If he or she is talking about the actual upgrade (the moment you commit), then I would see it being possible. But, from an operational perspective, can you be out of your system for 2 to 3 weeks? Our tolerance is less than three days.

One last consideration... LSF 9.x has yet to be truly "road tested." I, speaking only for myself, am not impressed with Lawson's QA record through the life of version 8. I am all for living on the bleeding edge, but can your company afford that risk?

Just my $0.02.

You could probably convert LAUA to the new and improved Lawson security tool in 2 weeks. But just that part. The technology and application upgrade will take much longer than (the larger and more custom your use of Lawson, the longer the time line).

Thanks for your thoughts.

We haven't received the final proposal from them to know what all they consider the 'upgrade' to be. I do know that they completely missed the boat when estimating the time it would take for our 8.0.1 to 8.0.3 app upgrade. When I heard that they were thinking 2-3 weeks I was rather surprised. I have alerted the powers that be that the laua change to the new & improved security model needs to be included in the estimate to get the single signon. I would think they might be able to get the env/ios components installed on both servers in that time, but changing security in that time also...maybe but not likely. I think it will probably take at least that long to agree on what it will look like then a while to do the actual changes.

We have approx 800 application users and will have around 16,000 ESS users.

We won't be upgrading the apps yet because we just went to 8.0.3 last month. I don't think we would survive another app upgrade so soon. We have a lot of customizations that we are going to review to see if we can replace any of them with vanilla lawson. We hope to do that before we begin the app upgrade. What we want now will be to get the env side upgraded and security set so that we can use single signon and deploy ESS at the same time.

I know what you mean about Lawson's QA record. I just tried to use the new product line copy tool and was less than impressed by it. The old way was far easier and faster. I ran into problems and GSC had me use the old way because the documentation wasn't up to date for 8.0.3 and they couldn't resolve my issues.

If it were my choice, we'd delay until a few more companies were up on LSF to let them work out some of the kinks. My management really wants ESS out there and doesn't want to have to set up 2 logins for the 800 app users. We've been live for about 3 years and ESS is something everyone has been waiting for. We were going to implement ESS with our 8.0.3 upgrade but we didn't want to have to use 2 logins for app & ess users. (something else our consultants missed) I just hope it goes smoothly.

Brenda

Hi,

Exactly what do you mean by single sign on?

Single sign on in the generic sense to me means, that you log into your workstation, your email, the corporate intranet, the internet proxy server and several other applications with the same user name and password. This is great for users and the helpdesk for ease of administration and the user doesn't need to remember many user account usernames and passwords.

Lawson's interpretation of SSO is that it has the ability to traverse many Lawson applications without being prompted to log in for each application. SSOCONFIG, the utility for configuring single sign on does have the ability to configure what they call grey box and black box solutions for potentially logging into external applications and there is the ability to use ldapbind for binding to your Active Directory or other user repository.

Be careful what you mean by single sign on.

Hope I'm not teaching to suck eggs, but I was shocked being new to Lawson products and not having a similar understanding of the term.

Regards,

AM

2-3 weeks is aggressive to say the least. :blink:
Have you/they actually used the new LS rule writing tool? It's not a walk in the park....even for the simplest of security setups.

I think a viable option is to install the new LS tool and migrate users from LAUA slowly.

Consider this:
First of all, in contrast to the LAUA tool, the new LS9 starts out completely locked down from everything. You'll have to create roles (typically based on job title) and security classes (typically tied to a specific function like Purchase Order entry for instance). You have to physically grant privaledges to all Data Areas, System codes, Programs, Forms, and tables that a class/function will need access to for each of those classes....individually. Then you have to write the rules against those classes to implement what we now know as data level security. Finally, you'll tie the classes to roles, the roles to users (which could be a one to many relationship)....I think you get the point. I'm guessing it could take 2-3 weeks to just map out the transition from LAUA to LS9.

Of course, this is all assuming you already have a LDAP repository in place, with users setup :nix:

With that said, don't assume that this new LS9 will take care of the multiple ID issue. I have had some conversation with Lawson regarding this issue, and while it does allow you to tie multiple functions/classes back to a user/role.....it would take some creative rule writing to keep a "dual purpose" user from accessing information that they do not need to see/edit.

I know everyone is thinking about the privaledged access flag not being as big of a deal under the new LS model, but forget about that and approach it from a different angle.

For example, one of the main reasons for multiple logins under the current env/security setup, is the need for ESS users to be granted access to HR11, HR13, etc. Typically, you create an ESS Portal userid without the searchbox in the top left so that they can't form transfer directly to these forms and make changes to their record. The only thing they have with this login is the ESS bookmarks. The second userid would allow the searchbox because as a normal PO Buyer (for example) they would need to form transfer. This is a Portal setup issue, not a security shortcoming. The new LS9 still won't address the fact that ESS requires HR/BN/PR form access for it's AGS calls, and that the searchbox would allow a direct transfer to these forms if the user had the presence of mind to type them in.

As andym already stated, SSO is a term being thrown around to be the be all/end all of lawson security issues everywhere and it just isn't so. The new LS model is nauseatingly flexible (almost too flexible), and will allow a single point of authentication maintenance for PF, SN, Portal, Application, ODBC, etc.....but it just might not solve the actual issue behind the multiple logins.

I'm sure that as people become more familiar with the rule writing abilities, that there may be other workarounds but I guess we'll have to wait and see.

Stay Tuned.....

When you do decide to go to 9.0 security You could probably implement the SSO portion of it within a short say 1mo time line. However, If you plan to govern you application form acces by utilizing Lawson Security 9, you've got to push that waaaay out. You can use LSF 9.0 to authenticate your users against AD, while still relying on you laua security classes for app security. At the point that you decide to completely implement ls9 security to govern your form and apps security....Get a few extra people on board to help. Re-creating your security classes can be a VERY tedios and time consuing process... Lucky you have the option of leaving the majority of your users on laua security, and then converting them a little at a time as you create your new "ROLES"...

I just skimmed many of the postings above, but here is my take:


****** SUMMARY ****
We did our project ourselves, using Lawson's new Customer Certified program. from inception to go-live was 4 months (May 25 approval and sign-up, Spet 29 go-live). Our project included:

MSP11 update (MSP10 or 11 required before LSF9)
new LSF9 Install
Migration from 8.0.3
keep existing laua security
~40 HR users
~5000 self-service users

2 weeks to install LSF9 and 1 week to migrate data and do post migration clean up. We're in a Windows clustered environment which added about 1 week of install complications. So, if you are a simple non-clustered environment, you could install and migrate in 2 weeks reasonably. Then you've got to test!

**** MORE THOUGHTS ****

TEST, TEST, TEST, TEST! If you have any custom apps that interact with Lawson, watch out. RD30 / WEBUSERS is gone, so anything that interacts with this will need to be revisited. There's also all kind of crazy special gotchas with the env change. For example, in env 8.0.3.7 you didn't have to have the "Allow Index Change" within dbdef to be set properly, but you do in LSF9 otherwise your programs crash if they try to change a key (even a secondary key). Also, programs that used to work being called from Process Flow might not work any more. Apparently if they pgmdef execution type isn't 4GL or Executable you get a funky error. All easy changes, but I wouldn't want to go live w/o catching them!

System support will be a new challenge. The IOS.log and other errors are a bit different, so getting used to the new errors and log behaviors will take a while. I'd suggest a few test cycles to be comfortable with that.

We had to upgrade our employee self-service to be compatible with LSF9, so that meant reapplying our heavy mods..... Also, some of our 4GL had hard coded paths and server names, which meant updating all of that code and re-testing.

LDAP is totally new. Wtih 16,000 users I'm betting you have some sort of automation going on with user creation and deletion. ***WATCH OUT!*** :banghead: Lawson offers no supported method to automatically delete your users from your LDAP. We had to write our own custom method using LDAP commands. We ended up corrupting our LDAP because we didn't do it right at 1st. Fixing that after go-live was not very fun. :beat: There *is* a supported method to load users, so that is good at least.

Finally, you're going to want a test / dev system ready to go before you go live so you can try to replicate and solve errors that will inevitably come up. Challenge number 1 - time to build it. Challenge number two, there is no supported method of migrating users from PROD to DEV or TEST, so be prepared to write your own and re-type them. (we're working on our approach now, after go live, so that's not good).

Best of luck, but plan on 3 - 4 months to make this upgrade happen.

One more thought re: SSO....

SSO in Lawson's view is somewhat easy to implement. The "bind" of your LDAP to a single user repository (e.g. Windows AD for authentication) was easy. The directions were wrong, but once we got last that it only took a few minutes. So, to bind to an existing user authentication directory is easy, thus "single sign-on".

You can also create "black box" services so that you can login to those apps / sites w/o rekeying your password. e.g. from portal you can login to support.lawson.com w/o typing a user ID or password. Theoretically you could do this with other reporting services, etc, etc.

This is definitely NOT that fancy. You still have to login to portal / LID. It can be the same user / pwd, but you still have to login. Other "black box" services utilize a hard coded user / pwd to know how to login. If that pwd changes you have to train the users how to update this in Lawson's SSO (prepare for the support calls!)

And, Lawson still does not deal well with expired or expiring passwords. For example, if you bind Lawson to the same authentication repository that you use for network access, occasionally your users will get a "Your password will expire in XX days. Want to change it?" message. If they say no and move on, Windows is fine. HOWEVER, Lawson portal freaks out a bit and since the return code from the authentication isn't clean, it assumes the password is bad and won't let you login to portal. Same thing for if you set the user record to "must change password at next login". Portal sees that return code as something other than "authenticated" and errors out.