Hi, Joe.

1. ADFS is not quite "all-or-nothing" setup (unlike regular BIND, for example).

There are some applications (most notably MSCM and LM Rich Client) that do not support ADFS. For those Infor made a special provision, so they can continue to use BIND. This is done by essentially setting us yet another set of web servers/endpoints in LSF and LM with special service types that use regular LDAP BIND, like I assume you use now.

In theory some of the items you mentioned can go over these special services and still login to Lawson via BIND. As an example, we were able to use  LSA to connect to that special endpoint, and it indeed logged in with the regular screens.

2. The main idea, however, is that ALL users, including EMSS, will use ADFS. That means ADFS web server used by Lawson will indeed need to be exposed to all users, including the ones logged in from the "outside" (if you allow login directly from the "outside").

3. The protocol is SAML 2.0. So you can definitely use non-ADFS user repositories, such as Azure, PingFederate and a few others, but there are additional requirements for these repositories. I suspect most people, if they have AD, will simply use ADFS.

4. I do not see any reasons of NOT using loadusers. HOWEVER, with ADFS you will get extra identities that you may need to load as well, and loadusers is not capable of handling those. So you will need to supplement it with ssoconfig loads (if you really need to do command-line user loads and not IPA, for instance).

5. Re announcement - here is my take on it:

In May, 2019 Lawson will stop testing or releasing any patches that are specific to LSasSTS. Nevertheless they will still support older ESPs that have this option. Note that Infor suports 3 last ESPs. So, since we have ESP10 out, Infor suports ESP 10,9,8.

Infor plans to release 1 ESP per year. So, in May 2020 when ESP12 comes out, they will drop support for ESP9, and that will be the actual end of LSasSTS.

In a mean time - after May 2019 if they determine that your problem is related specifically to LSasSTS and not something else, they may ask you to switch to ADFS to fix it. In my view it's an unlikely event, but anything can happen.

Re: benefits - the primary benefits of ADFS as I see them are:

1. Final fix for the timeout issues. As you might know, it is actually not technically possible to fix all of the timeout issues in LSasSTS in a complex installation that involves LSF, Mingle, LM, IPA, GHR, LBI and MSCM. There are specific situations when some components will timeout and others will not, thus resulting in WEIRD issues on the screen.

2. Lawson will not get/process passwords. You will be authenticating BEFORE you get logged in to Lawson

3. Two-factor authentication will be MUCH easier to do.

4. Some weird user-name-related issues will be gone, such as case sensitivity etc.

5. If you decide to host some applications with Lawson (e.g. CloudSuite financials) and keep some on-premise (e.g. GHR), you can use the same users and authentication to login to both.

Hi, Jim.

So far I believe there is no ADFS-only requirement for newer Landmark patches.

And yes, you CAN implement two-factor authentication with ADFS much easier.

HOWEVER - you may not want to use your existing corporate ADFS for this. You may want to install separate ADFS server software just for Lawson (e.g. on Mingle box).

There are quite a few factors that will push you in that direction. Contact me, if interested in details.

Windows people generally are not too happy about it, but once we go through the explanation, they usually agree with our point of view

New question please.

Hi, Alan.

ADFS authentication does a single-sign-on (SSO) for S3 and LM/LTM. We have it running in a lab this way with both Mingle 11 and Mingle 12.

As long as your S3 and LTM versions satisfy the minimum requirements, you definitely do NOT need to login to LM/LTM separately.

For all of this to work you need to have ISS/federation set for LM, and new ADFS-related services and identities set right in LSF and LM.

If interested to have a demo or a conference about it, please, contact me

Hi, Jude.

The answer is a bit complicated here.

For variety of reasons I do not recommend to use corporate ADFS with LSF. Some of the reasons include the necessity of installing IFS on the same box that runs ADFS (with Mingle 11), reconfiguring ADFS timeout to be "compatible" with LSF, and a need to have domain admin service user for the install and possibly on-going maintenance.

That means if you want other applications to have single-sign-on with S3, they need to use Lawson's ADFS.

Note also that Lawson does have an ability to logout from ADFS without logging out of Windows (depending on the ADFS configuration). So you do NOT need to sign out of the PC to login as a different S3 user into Lawosn that is set with ADFS. 

ADFS with Lawson definitely uses proper session timeout that must be set in ADFS, SSO and Mingle. There are KBs that govern what the timeout values need to be in each item.

Hello Alex

Could you please elaborate on the following statement?  Does this apply to a single-sign-on configuration of ADFS?  If so, could you please identify the ADFS configuration that will allow users to log off of ADFS and log back in as a different user without logging off of the PC?

"Note also that Lawson does have an ability to logout from ADFS without logging out of Windows (depending on the ADFS configuration). So you do NOT need to sign out of the PC to login as a different S3 user into Lawosn that is set with ADFS."

Thank you

Hi.

I indeed confirm that you CAN log off of ADFS and login as a different user without logging off of a PC.

To do so you need to have Form Authentication as the ONLY authentication enabled for ADFS.

Lawson requires Form Authentication, though you can use some of the other ones. That's why we usually recommend NOT using corporate ADFS for Lawson, but rather create a separate ADFS instance just for Lawson, so you can login into Lawson as a user of your choice. Note that you can have many ADFS instances in your AD (thought your Windows people may not necessarily like that approach).

Thanks.

Alex.

Alex, this is John.  Use to work with you at AIC.  I have a client that wants to run ADFS in one domain, and IFS and LSF, LMRK, Ming.le in another domain.  We also created the CA in same domain as ADFS to do Cert Request.  Can you tell me if this is possible?  Would it just require a Trust between the two domain controllers?

Hi, John.

You indeed can have ADFS in a domain different than LSF/LMK. Note, however, that with Mingle 11 IFS must reside on the same box where ADFS server is located. This requirement does not apply in Mingle 12.