Making ESS available to WWW

We contacted Lawson support about the recommended settings for this and they replied that it is not documented and would need to be handled by their professioanl services group. From what I've found so far it seems too simple to warrant bringing in consultants. Has anyone doen this on there own?

We have done this... but we are configured a little different here. We use a Citrix farm and everyone is expected to run their sessions from Citrix.... the techs here have made the ESS application available as an external app so we just get connected (userid/password) then click an icon that launches Portal from our intranet. Then a different userid/password gets us to ESS.

<!-- Converted from text/plain format -->

It's really a matter of putting IIS in DMZ or outside the firewall and installing the Websphere plugin to point to that server.  Then using firewall/NAT to 1) route the inside and outside users to the correct web server address and 2) restricting the traffic flow to the websphere server to onlu be allowed to come from the IIS server.
John Henley

Thanks for the feedback. I'm assuming WAS can accept connections from both the inside and outside IIS instances. We wouldn't want to break production access. Our services vendor did this setup during our LSF migration - do  you know where is the WAS plugin install for IIS is documented?

<!-- Converted from text/plain format -->

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/tins_manualWebIIS.html
John Henley

Has anyone had issues with yahoo toolbar or google toolbar or other items causing users issues with access to ESS from off home? Or what browser xml patches, etc. does the home user need to install on their pc for this to work with ESS in LSF9 the xhrnet version.

Yes, we have had issues with esp the pop-up blocking features of these toolbars and even pop-up blocking from the OS. I think if you turn off pop-up blocking for the affected sites, you'll have a lot better luck.

What about any xml patches for IE? Are there any required for the home user to install?

We are bracing for the help desk calls since there are seemlingly infiite combinations of software versions and settings on home computers. There were a number of XML patches that addressed Portal issues a few years back and we had to patch many of our internal systems. I believe Microsoft has rolled these up for W2K and XP now so if the home users have windows updates turned on like we do at corporate they should be ok. I have not have to apply any patches to fix IE for Portal in 2 years now. Wonder how Vista Home edition will behave?

Has anyone had trouble with the redirect when referencing their external server by IP? We're getting the "Portal cannot load without a fully qualified URL" msg when we try to connect to the external IIS webserver instance via IP. If we try to connect to the external by server name it will only work from from inside our FW - outside the connection fails. The endpoint must be taking care of it as the redirect msg is not displayed if we user servername . I wanted to use IP rather than have our ISP add our servername in their DCHP list. Thanks.

I've seen that message, inside the firewall. We were in the habit of using a unqualified host name, and now we have converted to using the full hostname in the URL.

You need to have both the internal and the external IP resolve to the FQDN.

Thanks. The way we are currently set up, if we use IP to connect it tries to do the redirect to the lawson server FQDN but if we use server name is passes through to the SSO login screen without the redirect. We've asked our ISP to set up our servername to resolve to the external IP so we can connect by name from outside. Aside from the redirect being annoying, conencting by IP will never work from outside our domain - the redirect would fail since our lawson server name is not public. The next step will be to get HTTPS working. We have our cert installed and opened up the https port - is there anything needed on Lawson side for this to work?

We've almost got this working after alot of tinkering with the endopoints in ssoconfig. A Lawson KB article indicates that an https cert needs to be installed on both the internal and external webserver assumedly since the internal wil be using https for authentication only. We only bought one cert and installed it on both. The external works great, but portal connections to the internal now complain about an invalid cert (it does let you log in after that). Has anyone been able to get the internal webserver to inherit the cert from the external or are we faced with ordering another cert from verisign for our internal webserver even though we're not really using it for https connections?

An update for the group - To resolve the cert issue we removed the "shared" Verisign cert on the internal and created a user defiuned one (only the external needs to be certified). Then we pushed out a trust for the new cert to our corporate systems via GPO. As for HTTPS - since we changed the url's for both our internal and external webservers to https we decided to change the SSOP service to us "HTTPS always" rather than "HTTPS for login only" as directed in the Lawson KB article on configuring LSF9 for SSL and multiple webservers. By doing this we can fully block non https ports regardless of which iis server the user is connecting to.

Joe, we are planning to undertake this project at my organization as well. Did you only have to install IIS and WAS (application server or network deployment) on the external webserver? I know you would then add and configure the additional endpoints. Any info you have would be helpful.

Thanks,
Eric

Yes we had to install some of the Websphere components and IIS on the external machine. Do not underestimate this project - it sounds fiarly simple but can turn out to be a pain. We found that there are some quirks with ssoconfig and no way of listing the endpoints that were previously configured so if an incorrect endpoint was entered you you'll need to remember exactly what it was in order to remove it. I'm not sure if this is a bug or what but entering a corrected endpoint does not fix the bad one. We went around on this for some time before erasing all the endpoints and starting over to get it working properly. Once the endpoints are all set correctly we went back to https for login only so you can ignore my earlier comment on using https always on the internal - stick with the lawson recommended setting. HTTPS always will work, but nothing is cached so performance suffers on low bandwidth connections. There are also 2 env patches you may need. One for portal and the other is a large LSF9 rollup. We were getting redirected to https and getting a security error when internal users clicked logoff button. It took me a week and a half in LIS before the GSC told me about these. Good luck!

Joe, Did you look at just putting just the IIS web server on the external side vs. IIS -AND- WebSphere?

No, but let me clarify. It's my understanding that you need the websphere plugins on the external machine with IIS - not a full Websphere install. The other thing is how you handle the IIS homedir (webdocs) folder. Right now I have a copy of it locally on the external machine but I would like to change this to point back to the internal webdocs folder so I don't have to apply patches in both places moving ahead.

That is correct--WAS plugins on the external server. You only need one WAS ND.

---

From: forums-lsf-s3-sys-admin@lawsonguru.com
To: John Henley
Sent: Mon Nov 24 15:19:14 2008
Subject: RE: Making ESS available to WWW (729eab78-5f62-4506-9b36-901646d52a5e)

S3 Systems Administration Forum Notification
A message was posted to a thread you were tracking.

Joe O'Toole Posted:11/24/2008 6:19 PM

Subject: RE: Making ESS available to WWW No, but let me clarify. It's my understanding that you need the websphere plugins on the external machine with IIS - not a full Websphere install. The other thing is how you handle the IIS homedir (webdocs) folder. Right now I have a copy of it locally on the external machine but I would like to change this to point back to the internal webdocs folder so I don't have to apply patches in both places moving ahead.

---

You may reply to this thread via e-mail; please do not remove the message tracking number from the subject line, and do not include this message in your reply. To view the complete thread and reply via your browser, please visit:
https://www.lawsonguru.co...et/5553/Default.aspx

You were sent this email because you opted to receive email notifications when someone posted and/or responded to a message on this forum.
To unsubscribe to this thread please visit your user profile page and change your subscription options.

Thank you,
LawsonGuru.com

We would like to do the same thing, but we do not have IIS involved in our current process.  We have our portal on an AIX box... behind our internal firewall.  How can we do this to allow ESS access from WWW?  Do we put the plugin.cfg on an apache server in the DMZ and it will route the WWW traffic into the ESS on our portal server?  What about internal traffic, will it have to go through the apache server in the DMZ or will internal traffic just go directly to the current internal AIX portal server?

Thanks in advance
Dean-O

Ok, here is what we are trying to do (Dean and I work for the same company).

First thing we tried to do was to basilcy offload the SSL to a Citrix Netscaler 9.0 device. I created an external VIP (virutal IP) and assigned it a SSL certificate. I then pointed it to the internal WAS/LSF server. when I goto https://servername.domain.com/lawson/portal/, I get redirected to http://servername.domain.com/lawson/portal/, which wont work because we dont have a VIP for port 80, we need to run this over HTTPS.

My next thought would be to have the netscaler offload SSL traffic for both internal and external users. Create 1 VIP and have it use SSL, and point all internal and external users to it, and then reconfigure the WAS/LSF to use that host name on port 443. So, both internal and external people would goto https://lawsonportal.domain.com. The 2 problems we have are, 1 - we/I dont know where/how to change it from 'servername' to 'lawsonportal' and 2 - how to tell it to use https vs http.

I really think using another server in the DMZ is overkill. I dont really understand the WAS/LSF piece, but I would have to belive this cant be this complicated. I have a dozen other things that I offload the SSL using the Netscaler w/o a problem.

Somewhere is the site, its compairing the actual client URL to the configured URL.

Any help on this would be great!

Thanks!

Brian Danford

There is a Lawson KB article on this: http://kmcollections2.law...EXAMPLE_INFOPATH.HTM

I don't think it's exactly what you're trying to do, but I think it gives you an idea...probably that you need to re-configure the endpoint to be SSL only.

We used this article as well, it's not very detailed in some repsects, but  the smoketests are invaluable for determining if you have SSO configured correctly. I'm not sure if it works the same way on AIX and Windows, but one of the biggest problems for us was getting incorrect endpoints out of the definition. I would recommend documenting what is typed in so you can easily remove them. We found out the hard way that updating them is not the same as removing and re-entering the values.

I would recommend putting the HTTPS webserver in the DMZ and not use redirects. Anything that exposes your internal server name or IP to the outside world is an open invitation to hackers not to mention what the auditors will say. Does SSOConfig work on AIX? If so, the endpoints you define will take care of what traffic is going https vs http on the internal and external (or virtual in your case) webservers.

We got it to work by using Microsof't's ISA server to securely route requests from an outside name to the application server.  It works well.  I've also repackaged the ESS javascript js and htm files in to an iframe page the removes the requirement for the portal from home.  This way it works well from any browser and is less intensive on the system.

Making it work with the SSO LSF9 security was a bit tough but it's working.  I wouldn't mind sharing if anyone is interested.

Is this thread still alive? I cannot get the smoke test to show the external server name? Has anyone else had that problem.

Did you run ssoconfig successfully to completion? If you post the syntax you are using for the smoketest I will compare it to mine.

 I run the /ssoconfig/CfgInfoServlet on the internal server and get the internal server login and http URL.  Then I run /ssoconfig/CfgInfoServlet  on the external server (the endpoint) and still get the login and http URL of the internal server.  Is this the info you're asking about?

For ssoconfig, I have configured my primary service (SSOP) with the http and https url of the internal server.  I have it configured for https at login only.  This is the URL that is returned for both servers during the smoke test.  Whatever I set this URL to is what is returned.  It's like it doesn't even care about the endpoint.

HTTPS for login only is the correct setting, however you need to make sure you have the server name, http or https and ports set correctly for both servers in all the url strings defiuned in ssoconfig. If set up correctly, when you run the infoservlet smoketest using http and the internal server name it should return the https address on the loginurl and the http address on the httpurl. If you run the smoketest on the internal using https it will always return https for both urls. When the smoketest is run using https and the external sever name it should return https for both urls as well. There is a Lawson KB article on Multiple Endpoint Configuration - have you reviewed this?

Hopefully this thread is still sort of monitored, because we're in a similar spot here.

We want to make ESS available externally for our users, however, we'd like it to be opt in.  We'd also like to limit the external access to ESS/MSS only leaving portal/rss/etc available internally only.

Now I've got HTTPS running just fine, and we're only using a single webserver right now (all Lawson components run on seperate servers so the box only has IIS/WebSphere Plugins installed).  Our current webserver is sitting in our DMZ as well so from a logistics standpoint, I'm hoping we're ok.

Does anyone have external access deployed in their environment for only ESS/MSS and, if they do, has anyone figured out a way to make it opt-in for employees that only want to have their access available externally?

Next...

Apparently some webserver issues going on - see next post...

Posted By Joe O'Toole on 03/26/2009 02:30 PM

Posted By Joe O'Toole on 03/26/2009 01:57 PM

There are 2 different issues here. First I would make sure you really want to run "everyone" through the DMZ webserver. There are numerous reasons I would not - a few in no particular order: 1) security - if one is breached all your web access is gone. 2) patches / maint on external webserver will take all your web access down 3) Traffic - why route your internal users through the DMZ? 4) Throughput - assuming you have full HTTPS running (and this is a MUST) on the external, why force all your internal portal traffic to be encrypted with no caching when all you need is HTTPS for login only?

Some of these could be less of an issue if your application users only run LID, but sooner or later most shops will have some portal app users plus anyone using ESS/MSS must go through portal. Controlling what functionaliy they have based on point of access would also be aother tough thing to tackle since content is assigned based on user. We assign fixed content to our "ESS/MSS only" users and lock them out from changing their content through default.xml mods. In LSF I think this can be done from an admin screen as well.

As for opt-in, you would need some intercept or a different front end before the user hit portal where they could log in and agree to the terms and conditions. Then the next time they hit it it would let them through if the flag was set. We thought about doing this but decided it was not necessary at this point. Have you considered puting a disclaimer stating "by clicking on this link I understand and agree to the terms and conditions of remote access"? Good Luck!

Joe,

How do you limit external webserver only serve ESS?

We are in the spot to make Vendor self service available to WWW. Please share your experience if you have.

We are looking into using netscaler for ESS web access and saw the post from Brian and Dean.  Can I get an update on how that is working for you company.  Also, is any one else using this solution or have abandoned the idea of using it?  Thanks....

We are also getting ready to do this, but using ISA server to publish the ESS site. I have v8 working, but I am having problems with v9 and the url error message that appears.

What we are doing is using an external SSL VPN, and then the ISA to publish the webserver so it will not be directly on the internet. I see that user schlenk has got this to work and would be very interested in what he did with ISA.

 We are considering implementing ESS now as well, and I have a question along the lines of this thread that I have not seen explicitly addressed.  

We are LSF9, NT, SSO- ADAM.  All of our managers using MSS have an account on the AD (~500 users), but line-level employees all have a generic login to the AD based on their bases (65 locations).  We would prefer to not provide the other 4000 employees individual access to the AD (our helpdesk/infrastructure guys are adamantly against it), but I don't see how we can make this work with SSO.  Any suggestions?

Are you using ldapbind (i.e. SSOP password authenticates against your corporate AD)?

If so, then you will have to have new AD accounts for all of the users, as each RM ID will require a unique SSOP identity as well as XXX_EMPLOYEE identity.

Yes, we are.  I was afraid that would be the answer.  The going price for 4000 NT licenses is an expense we weren't looking forward to...

Thanks, as always for your insight.

Do you actually need to buy windows licenses to create a user in AD? They really aren't "logging in" to Windows server, are they?

I did go back and read the fine print, and you do need to obtain the licenses, based on my interpretation of the license being required for "authenticating to the server".

Hello Joe.

We've not taken this leap of faith yet and still retain all ESS access from inside the network. However, our HR group would very much like us to allow external access.

I know it's been over a year now, but how is this setup working out for you? I wonder if you would mind if I contacted you to bounce some questions on this topic off of you at some point in the future, since you've already done it and it sounds like your configuration is simialr to our own? We too have the IIS web server, Websphere, SQL and Lawson (and I believe that like yours, they too are) all on the same Windows 2003 server. Thank you.

It has worked great for us and taken some load off of our already stressed network. Many users "at home" broadband connections are faster than our private frame relay WAN and they prefer working in the the pricvacy of their own home. Security concerns are limited to employees keeping their passwords private, which is a personal responsibility and holds true for an individuals login to any website. I will PM you my email address.

We have recently been down this road and I took a little different approach. We did not modify anything on the backend other than to create a separate folder under the /web of Lawson for the new ESS which includes a couple of pages created with info. posted from Mike Schlenk which remove ESS's reliance on IE and allow all browsers except the current Opera 10.x to work

We use an ASA on the outside doing a web based SSL VPN which is tied to AD with only a link to ESS. When the user clicks on this it pulls the data through a Netscaler which is offloading the SSL and rewriting the external and internal names of the Lawson server which then pulls the new ESS page into the end-users browser. They then authenticate with a different userid and password for ESS.

I would be happy to provide more specific information if anyone would like. We do this for 12 environments as we act as an ASP.

Mike,
I'm extremely interested in what you've done. We're trying to incorporate Lawson ESS time entry form into SharePoint and are looking to bypass the portal home. If it's still available I'd love to see your js and htm files as well as your SSO solution for LSF9. I've successfully retrieved the JSESSION and C.LWSN cookies remotely, but haven't been able to authenticate into the portal page. Ideally, we can get the cookies, and land our users through an iframe into the index.htm file.
Thanks!

-adam

I am definitely interested in having a discussion with you.  Since we have upgraded from V8 to V901; we cannot get EMSS to work externally.  In version 8 it allowed us to

published it on to the public internet by putting an Apache server in the DMZ to handle reverse proxy chores and used a Cisco ACE in front of that to handle SSL termination.

I have a document that shows how I fudged the html to deliver the ESS pages without portal.  I can send it to you.  Send me a private message on this site with your email address and I'll send it to you.

Hello,

I was wondering if anyone has restricted access to users connecting from home?  We have a VMWare solution that we are testing that allows access to our intranet and therefore our ESS.  However this will also allow users who have credentials to perform S3 applicaton work to have access to that while at home as well such as HR,AP,GL,SC,PU....  Our management would like to limit the capability such that we only provide individual Lawson personal HR benefit access to home users.  We are still on LAUA but will be migrating to LS9 over the next 12 months.  Has anyone restricted the Lawson access for at home users?

Cna you please send some documantion on how this done ?

The first time we tried to provide external access to EMSS was when we upgraded from version 8 to version 9. That attempt crashed and burned and we didn't try again for a year.

In 2012 we went outside and hired a consulting company to set this up for us. They set up a Windows server running IIS that acts as an external gateway for Lawson, which runs on an IBM i.

They sold us two packages. The first one provides front-end security to control who can access Lawson remotely. Ultimately, we chose not to use that package. The second package allows our home users to access Lawson using browsers other than IE.

We've been running this setup for 3 years and it works great.