Posts

Installing DSP for Authentication Against LSF

You may find the need to install or update DSP for your SSO applications, such as LBI or MSCM.  DSP allows these external web application to authenticate against Lawson for Single Sign-On.

Information you will need:

  • The password for ssoconfig
  • The passkey used to install your current DSP version (if applicable)
  • FQDN’s for your LSF server and the server that hosts the application for which you are installing DSP
  • Credentials for an admin account (usually lawson)

 

First, download the latest DSP jar file from InforXtreme.

It is best practice to back up your ldap instance before you begin the install.

On the server of the SSO application, open a command prompt as administrator.  Navigate to the directory where you saved the DSP install file.

Type command java -jar <DSP file>.jar.  This will open the install wizard.


Enter a new configuration passkey.  NOTE that if you are updating an installed DSP, you will need to know what passkey was used to install it.

 

Give your DSP instance a meaningful name

 

Set the location where you want the install files saved, and set the java location.

 

Mingle DSP install is a different process not addressed in this article.

 

Provide the FQDN of your LSF server.  The standard and secure ports can be found in your LSF install log.  Enter the password that you use to run ssoconfig.

 

Enter account information with administrative privileges in Lawson

 

Enter the appropriate values for the server that hosts your SSO application

 

Click Install

 

Update the JVM custom properties with the new install information (if necessary)

 

Install or update your security application in WebSphere.  The install file lawsec.ear can be found in <DSP install directory/jar/secondary

 

Run a smoke test against the new DSP install at http://<application base url>:<port>/sso/SSOConfig

Seven Myths About Implementing ADFS For Infor Lawson

On March 1, 2019, Infor will no longer support LS/STS authentication configuration for Lawson applications.  The Infor recommended configuration will be to use Active Directory Federation Services (ADFS) for Single Sign-On (SSO) authentication. To learn more about ADFS, check out our other articles on the topic:

What is ADFS?

Active Directory Federation Services is a Single Sign-On service provided by Microsoft.  It runs on Windows Server, and provides users with the ability to sign on with one set of credentials across applications.

How does ADFS work with Lawson?

 

Why change our authentication method?

Although there will be some work up front to modify your configuration from LS/STS to ADFS, using ADFS for SSO authentication is actually beneficial to your organization.  It is more secure because Infor applications will never have access to a user’s password.  It is also a bit easier to maintain your Infor users in ADFS, in that you can enable/disable the users right within Windows instead of having to do it in Lawson Security.  Additionally, implementing ADFS will open up other Microsoft security components, such as two-factor authentication.

 

Busting Myths

There are some common misconceptions revolving around the implementation of ADFS for your Infor Lawson application.  Hopefully these explanations will help dispel the confusion.

MYTH: We can use our organization’s current ADFS installation

Infor Federation Services (IFS) must be installed on the same server as ADFS.  So, you may need to have a dedicated server for ADFS for Lawson.  Also, your Infor Lawson applications cannot be hosted on the same server as ADFS.  If you are installing a new instance of ADFS, make sure that it is compatible with your current version of Active Directory

 

MYTH: We don’t need SSL to implement ADFS

ADFS requires all of your Infor Lawson applications to use SSL (Secure Socket Layer).  You will need to select a Certificate Authority (CA), and install certificates at each web endpoint.  If your current Lawson web applications are not using SSL, you will need to convert them before you begin the ADFS installation/configuration.

MYTH: Our organization has to begin using ADFS for everything

The ADFS implementation is limited to Lawson and does not need to be part of any other application in your organization. A Windows server will host ADFS solely for Lawson and can be segregated to just this specific use without affecting anything else within the organization.

 

MYTH: The change is transparent to users

The look & feel of your Lawson web applications will remain the same, but the way users log in will change.  LS/STS username format is currently “username”.  When you switch to ADFS, users will log in with format “username@domain.com”.  Also, keep in mind that if you have to update to a compatible ESP in any of your applications, there may be some slight changes in what the users see on the forms they use.  Make sure this is done well in advance so the ESP can be tested thoroughly.

 

MYTH: Infor won’t support us after March 1, 2019

As of March 1, 2019, Infor will no longer be releasing Lawson patches that take LS/STS authentication method into account.  This doesn’t mean your current versions of Lawson applications will stop working if you fail to move to ADFS at this time.  It just means that you won’t be able to upgrade past a specific ESP for each product (10.0.9 for Lawson).  When Infor sunsets the product versions that allow LS/STS, you will then be on an unsupported product version.  It is look like this will happen sometime early 2021.

 

MYTH: User maintenance in Lawson Security is going to change

ADFS is an Authentication Method, while Lawson Security is an Authorization Method.  So, you will continue to use Lawson Security Administrator (LSA) or Infor Security Services (ISS) to maintain users and roles.  The ADFS authentication will not impact these roles at all.

 

MYTH: We use IPA, so we will have to update Landmark too

Infor Lawson products are actually the only products that allow LS/STS authentication method.  So, you will not need to make any updates to your Landmark products, including IPA.

Contact us when you are ready for your move to ADFS.  Our expert installers at Nogalis can make the process simple and pain-free.

What is ADFS?

There has been a lot of confusion in the Infor client community lately over what ADFS is and what the impact of implementing it will be on the organization as a whole.
Active Directory Federation Services (ADFS) is a Microsoft solution created to facilitate Single Sign-On. It provides user with authenticated access to applications like Lawson without the need to provide the password information to the application.
ADFS manages user authentication through a service hosted between the active directory and the target application. It grants access to application users by using Federated trust. The users can then authenticate their identity through Single Sign-On without having to do so on the application itself. The authentication process is usually as follows:
1) The user navigates to the Lawson URL
2) The unauthenticated user is re-directed to the ADFS service
3) The user signs into ADFS
4) ADFS service authenticates the user via the Active Directory
5) The user is then given an authentication claim (in the form of a cookie) by the ADFS
6) The user is forwarded to the Lawson application with the claim which either grants or denies access based on the federated trust service
Note: The Lawson Server never sees the password information which in the case of external applications (like a cloud implementation) is a lot more secure.
 
What are some drawbacks of implementing ADFS?
 
Although ADFS is a new requirement, it comes with a few small drawbacks that you should consider:
– The additional server license and maintenance – You will need an additional server (likely one per environment) to host ADFS
– ADFS is actually somewhat complex and this new skill set can create a new challenge for smaller clients who aren’t already using ADFS for other applications
– A standard ADFS installation is not all that secure and several steps should be taken to ensure good security. Microsoft provides these best practices recommendations: https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/best-practices-securing-ad-fs
There is also a great free e-book published by Microsoft about claims-based identity and access control: https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ff423674(v=pandp.10)
To find out more about ADFS and how it can impact your organization, join our webinars or contact us.

Landmark Authentication Fails

After completing federation and restarting LSF and Landmark, landmark authentication fails.  The security authen log returns the following error:  sun.security.validator.ValidatorException: PKIX path building failed.

This can happen if secured ldap bind is being used.  With the secured ldap bind (using ldaps protocol and port 636), the certificates from the AD server are missing from the java keystore on the landmark server.  This can happen even if you are using SSOP on LSF for authentication.  To resolve the issue, export the certificates from the AD server and import them into the java keystore.  If LSF was bound to AD, the certificates should already be on the LSF box.  They can be copied over from LSF and imported to the keystore on the landmark server using the following example.

 

D:\JDK\bin\keytool.exe  -keystore D:\JDK\jre\lib\security\cacerts -importcert -alias ADca –file D:\cacert.cer

D:\JDK\bin\keytool.exe  -keystore D:\JDK\jre\lib\security\cacerts -importcert -alias ADroot –file D:\root.cer

 

 

Error:

 

Wed May 31 09:49:13.112 MDT 2017 – default-724934462: Error encountered while getting users DN. Please see logs for details[egn1ldmam2ike26udaqvs9rs2g]Could Not Bind With privileged identity. User [lawson]simple bind failed:ldap.domain.com:636

Stack Trace :

javax.naming.CommunicationException: simple bind failed: ldap.domain.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]

at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)

at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2788)

at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)

at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)

at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)

at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)

at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)

at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)

at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)

at javax.naming.InitialContext.init(InitialContext.java:244)

at javax.naming.InitialContext.<init>(InitialContext.java:216)

at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101)

at com.lawson.security.authen.LawsonLDAPBindLoginProcedure.getDNForUser(LawsonLDAPBindLoginProcedure.java:446)

at com.lawson.security.authen.LawsonLDAPBindLoginProcedure._authenticate(LawsonLDAPBindLoginProcedure.java:233)

at com.lawson.security.authen.LawsonLDAPBindLoginProcedure.authenticate(LawsonLDAPBindLoginProcedure.java:681)

at com.lawson.security.authen.LawsonLoginSchemeImpl.authenticate(LawsonLoginSchemeImpl.java:1701)

at com.lawson.security.authen.LawsonProgrammaticAuthenticatorImpl.authenticate(LawsonProgrammaticAuthenticatorImpl.java:198)

at com.lawson.security.authen.LawsonProgrammaticAuthenticatorImpl.authenticate(LawsonProgrammaticAuthenticatorImpl.java:100)

at com.lawson.rdtech.gridadapter.provider.LmrkSessionProvider.createGridPrincipal(LmrkSessionProvider.java:287)

at com.lawson.rdtech.gridadapter.provider.LmrkSessionProvider.validatePassword(LmrkSessionProvider.java:254)

at com.lawson.rdtech.gridadapter.provider.AbstractSessionProviderBase.logon(AbstractSessionProviderBase.java:134)

at com.lawson.rdtech.gridadapter.provider.LmrkSessionProvider.logon(LmrkSessionProvider.java:159)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:498)

at com.lawson.grid.proxy.ProxyServerImpl$ProxyRequestThread.invoke(ProxyServerImpl.java:2715)

at com.lawson.grid.proxy.ProxyServerImpl$ProxyRequestThread.processRequest(ProxyServerImpl.java:2502)

at com.lawson.grid.proxy.ProxyServerImpl$ProxyRequestThread.runThread(ProxyServerImpl.java:2425)

at com.lawson.grid.util.thread.PooledThread.run(PooledThread.java:137)

at java.lang.Thread.run(Thread.java:745)

Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)

at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)

at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)

at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)

at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1514)

at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)

at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1026)

at sun.security.ssl.Handshaker.process_record(Handshaker.java:961)

at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)

at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)

at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:747)

at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)

at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)

at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)

at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:426)

at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:399)

at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:359)

at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214)

… 30 more

Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)

at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)

at sun.security.validator.Validator.validate(Validator.java:260)

at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)

at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)

at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)

at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1496)

… 43 more

Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)

at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)

at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)

at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382)

… 49 more

 

Wed May 31 09:49:13.113 MDT 2017 – default-724934462: Error encountered while getting users DN. Please see logs for details[egn1ldmam2ike26udaqvs9rs2g]Could Not Bind With privileged identity.

Wed May 31 09:49:13.113 MDT 2017 – default-724934462: Failed to get DN for user: lawson