Remember that LBI dashboards are accessed via a separate URL, even if they show in Portal directly (I assume by your question that you have Portal Integration with LBI). You can simply right-click on LBI dashboard, and you will see that.

If you'd like that setup to work, you will need not just a simple Reverse Proxy, but a Rewriting proxy that replaces LBI URLs in outgoing traffic to the ones that can be rewritten to the correct ones by a Reverse Proxy on the way in. Note also that this method may or may not work depending on the JavaScript code that deals with domains, and your URL. If I recall correctly, with your version of LSF and LBI you needed to modify servenv.js to ensure domain consistency. If that code runs in a browser, depending on your rewritten LSF and LBI domains you may get into the cross-site scripting situation. Note that this will not necessarily break LBI, even if it happens.

SSL brings even more interesting problem into play, as unlike "pure" web traffic, SSL requires a session of sorts to be established between a client and a server. Depending whether you offload SSL or not at the proxy, some proxies cannot do a rewrite if SSL Is enabled, or require certain ordering of the items in configuration for it to work properly (for instance, ARR supports conditional rewrite of SSL properly only in global rules). Apache, on the other hand, can do correct rewrite of SSL, but not with mod_rewrite (which cannot do conditional rewrite of outgoing traffic), though there is a module that can do it separately.

In summary, you CAN make LBI work in this environment, but there may be more work for you to do in proxy setup and configuration.

Re: the bug - the correct way to do so in SSOCONFIG is deleting the group, and then delete the endpoint if needed. If a group has more than one endpoint, you will need to recreate the group and re-add other endpoints to it. This workaround was needed since ESP6 or so. Bottom line - you CAN correct EP issues without direct LDAP modifications.

Thanks for the reply.  We'll give this a try now and report back. 

Using rewriting Proxy to translate server names from internal to external worked, sort of.

The base Lawson functionality works great.

Framework Services works as it is supposed to.

Reporting Services doesn't work for either the links that have https://servername/ers nor the FSRemote entries.

Our ESS instance has many links to other internal servers (i.e. Kronos, HR - Prolicy documents).  These links do not work from outside, unless we add them to the Reverse Proxy list and expose them to the outside world.

So, I'm now looking at putting a LBI/ESS instance in the DMZ.  Was trying to avoid the extra server and upgrades/maintenance.

Is it  just a standard LBI install?  I don't see documentation specific to this, but see the diagrams of this configuration.

Thanks for the direction with rewriting proxy.

Derek


----

So, the bug is in the documentation for End Points.  Standard programer answer.  :-)

So, it seems like the "Phase-1" (making LSF available to the "outside") is working

Now let's talk about LBI. Note that some LBI calls contain the server URL not only as part of the "main" URL, but also as part of GET call query (and possibly POST calls, though the latter might not be the case). So you will need to add outbound rewriting at least for queries in addition to the URL rewrite.

You CAN add rewriting for the internal documents in EMSS via "regular" URL proxy rewrite.

You can also move web server for LBI to DMZ (you do not actually have to do so with the whole LBI, by the way). But you will also need to change all of the LBI URLs. This can easily be done by adding external web server to LBI's WAS configuration, and putting the proper plugin there.