Moving from LS/STS to ADFS

I am looking at this myself.  There is a lot of information in Infor Lawson Authentication Configuration Guide (LAUTHCG).  It does not look too bad.  My previous employer upgraded to the Cloud.  Setting up ADFS was difficult even though we engaged ICS.  There was a lack of documentation.  We had to go to a newer version of ADFS.  It took a couple months to work on ADFS.  I will be interested in the responses.

That doesn't sound to encouraging. Thank you for the response.

There is quite a bit to be planned to convert from LSasSTS to ADFS. First, you need to check what ADFS version would be supported by your AD. Your domain/forest version would determine that. Second, the box where you install ADFS will determine its version (e.g. - if the box where you put ADFS is Win2012, your ADFS version will HAVE TO be 3.0; but if your domain is still Win2008, you MUST update it to 20012R2 version or above, or implement schema extensions that will allow that). You also MUST have IFS installed on the same box where ADFS sits, so if you have ADFS somewhere already, it does not mean this will be the one that you will use. ADFS also must be based on SSL, so you need to plan which CA you will use for it. IFS will also create new DBs in SQL.
Bottom line - it's NOT that simple because it requires quite a bit of planning. It will change the way users login to Lawson a bit, and it will also add user maintenance (because you will also need to import users into IFS, and deal with additional identity if you use Landmark).
If interested in a process, let me know.

Thank you Alex for the information. I will pass it on.

Alex, Are there any differences converting from LS/STS to installing on a new system.  We are working on upgrading our Windows servers from 2008 to 2012 we are building brand new boxes and then will be migrating the data over.

There are some differences.

1. ADFS 2.0 (that's what you will get on Windows 2008) and ADFS 3.0 (that what you will get on Win2012R2) have somewhat different installation instructions and configuration with Lawson

2. If you have LSasSTS already, some of the items required by ADFS would be installed and configured on LSF servers already

Either way - you will be setting up a bunch of new things on multiple servers to make all of it work.

This seems to be a move to coerce non cloud customers to use ADFS for the convenience of Infor.
We just got done upgrading to V10 a year ago and after expending the effort on SharePoint for Ming.le it has already been kicked to the curb.
For my company the ADFS requirement will generate a large and costly project with no tangible return for our end users.
If there are benefits from a security perspective, there were never communicated to us by Infor, SAML is not mentioned anywhere but I assume that is what is being used.
There is also a good deal of misinformation being handed out by Info.
On different occasions I was told by Infor support that they do and do not support Hosted Authentication providers such as Azure and Okta and also that they do an do not support MFA.
We were also told we could and could not continue to use the Loadusers utility once on ADFS as the primary mechanism for provisioning new accounts.
Aside from having an additional endpoint for EMSS to be accessible via public internet, we are a fairly simple shop using the S3 GL and HR modules.
Since we are bound to AD our users log into Ming.le (or Portal for EMSS) with their Windows accounts so I'm not seeing where all this single sign benefits will be occurring.
The announcement from Infor states that they will not be providing "discrepancy corrections", future environment cyclics are "expected" to support ADFS and that customers "run the risk of encountering issues" if they do not convert to ADFS which is vague and open ended.
Does anyone know what will happen if we simply do not install ADFS?
I am guessing that LS as STS will still work as it does today and would not be surprised to see a policy change by Infor if enough customers push back.
Alex, what is your take on this?

We already have ADFS set up for other applications so It should not be a big deal on that end. My understanding is you can still use LS/STS, but you would not be able to upgrade to the Environment version of 10.0.10. I assume this also means any newer version of Landmark. Because they also would not be providing patches it may be a problem if the issue is causing a lot of headaches. I have found in the past that they will continue to provide help for a short time, but eventually they will tell you to make the switch.

Our security team wants us to switch to ADFS because they said it would be easier to implement Two Factor Authentication. I didn't get into the details of why.

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

Thank you Alex, very good points!
I'm sure more information and guidance will become available as time passes and more users convert.

New question please.

We are planning on moving to ADFS too and our functional staffs (Payroll, Finance, etc, non-ESS) uses 2 active directory accounts. One to login to their PC and ESS. And a second account to login to work on Lawson (HR11, PR530 etc). Again both accounts are in AD.

We had a Kronos upgrade and the security uses ADFS. The issue is that, when you sign out of Kronos, you are presented by a login page. Unfortunately, it seems disabled. When I reached out to our admins, they recommend that if another AD account needs to login, the first account must Sign Out of the PC first and use the second account to login to the PC.

Our HR Benefits folks also uses just one PC to assist multiple employees come Open Enrollment. Unlike the current LS/STS where you just sign out and the login page is available to every employees. It would be a pain to sign out of the PC to sign in again. 

How can this be implemented?
Thanks

We recently had a review with Infor on ADFS and the main take away for us was that once authenticated the token is stored at the session level on the browser. Since we are V10 with S3 and Landmark our EMSS stradles both LTM and S3. With ADFS, employees will need to relogin when they move from LMK to LSF as this opens another IE tab\session. We are setup similar to you JudeBac with two different logins based on if the user is using ERP as just an employee or if they are a 'backend user. I followed up internally based of the concern that you highlight with having to logoff and back on for shared PCs or multipple AD accounts -which are scenarios we have. ADFS for an application can be configured to be either SSO or form based authentication. If that app is setup to be SSO then the credentials used to make the call for authentication are pulled from who is logged on to that PC. If it is form based then the user gets presented with a login screen. So form based would be the required setup for applications where shared PCs are used.

I have been told by the individual who handles ADFS for us that they have something in place for shared PC's that forces the individual to log in for applications that use ADFS. She didn't say what they did and we have yet to implement ADFS for Lawson so I don't know if this will work for Lawson applications. We will find out when we start our testing.

Thanks all, I will surely consider the Form Base once we start. The ICS also mentioned the possibility of "session timeout".

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.

 

We got quite a few ADFS inquiries lately.

So, I started a YouTube channel where I review some aspects of the ADFS implementation.

Here is direct link to the channel:
https://www.youtube.com/c...disable_polymer=true

Enjoy!

Also give suggestions for future podcasts (and I have a few mind mind already).

Hello,
I am trying to find documentation on configuring Lawson/Ming.le to use corporate ADFS servers. We are upgrading to 11.1 Does anyone have a link?

Thank you.

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.