Archive for category: News

You may have a report in LBI that you want to create historical instances of as well as refresh data from time to time. Let’s go over how to do this.

1. Login into LBI as an admin user and go to Reporting Services Administration
2. Go to Maintain Reports and open the report via the [Details] link next to the report name.
   
3. In the report under Scheduling, select New Schedule
   
4. Under Run Date and Time fill in the:
   • Name (schedule name)
   • Instance Name (name of generated report), you must manually re-schedule if you want to include specific unique information in the name like date.
   • Description
     
5. Under Time and Frequency:
   • Set the Scheduled Run Time (time of day)
   • Time and Frequency
     • Schedule for days in a Week – This will run for every day in the week you select regardless of date.
     • Schedule for days in a Month – This will run the day you select in a month. Please note that there are specific check boxes for First and Last day in the month. If a month does not have a day like the 30^th or 31^st, it will skip that month.
   • Effective Date Period
     • Effective start date: This date must be set after current date and time.
     • Expiration date: The report will no longer run this schedule after this date and time.
6. The remaining Schedule Options should typically mirror the report options. Any customizations will not change the base report.

Configuring Lawson and Landmark for LDAP Signing

Contents (Click on a Topic to Jump to Section)

• An Introduction to LDAPS
• Prerequisites
• LDAP Certificate – AD LDS
• 1 – Add the LDAP Certificate to the AD LDS Service
• 2 – Export Certificate (.cer) file
• 3 – Grant Permissions on Certificate Container
• 4 – Smoke Test
• LDAP Certificate – WebSphere
• LDAP Certificate – Java
• 1 – Add Certificate to OS Java (ikeyman example)
• 2 – Add Certificate to WebSphere Java (keytool example)
• Lawson Configuration Changes
• 1 – Update Authentication Data Store
• 2 – Update LDAP Bind Settings
• 3 – Smoke Test
• Landmark Configuration Changes
• 1 – Update LDAP Bind Settings
• 2 – Smoke Test
• Infor Federation Services (IFS) Configuration Changes
• Conclusion

An Introduction to LDAPS

LDAP Signing (LDAPS) provides a way of securing traffic between your applications and AD LDS or Active Directory.  In the second half of 2020, Microsoft plans to release a patch that will enforce LDAPS traffic by default.  You can get more information about the Microsoft KB here.

What does this mean for my applications?

Well, even if you are using AD FS for authentication, your applications will be impacted.  Some pieces of Lawson, such as BPM, are still going to be bound to LDAP, as is the Rich Client login for Landmark.  Also, Lawson still communicates with AD LDS, so that would be impacted as well.  Note that if you are using IBM’s Tivoli Directory Server (IBMTDS) for your Authentication Data Store, you will not need to make any changes to the Authentication Data Store.  However, you will need to make the LDAP Bind changes for any of your applications that use LDAP Bind.

What will happen if I don’t prepare?

If you don’t configure your Lawson and Landmark environments to accept LDAPS traffic, then you will experience some application failures in these areas:

• LASE will fail to start
• Logins that use LDAP bind will no longer be able to communicate
  • Lawson Security Administrator
  • BPM
  • Microsoft Add-ins
  • Landmark Rich Client
• IFS will no longer be able to sync users from Active Directory

 

When is this happening?

Microsoft has said they will release the patch that enforces LDAPS in the latter half of the year.  They already released a patch in March that includes additional auditing and logging, and allows for enforcement via Group Policy.  This update will not have a direct impact on your applications, and it is safe to take the update any time.

 

When should we make the configuration changes?

You can make the changes now, or any time before you take the LDAPS enforcement patch.  There is not a negative impact on your applications if you make the changes now, and in fact, it is recommended that you do them as soon as you can.

 

Are any other applications affected?

No, the only applications affected are those that use LDAP Bind, or communicate with AD LDS.  Applications like LBI or MSCM, which use DSP for authentication, will not be affected in any way.

 

What do we need to do?

Glad you asked!  Here is a step-by-step guide for configuring your Lawson and Landmark environments for LDAPS.  (NOTE: It is important that you follow these steps in order!!  All of the certificate work MUST be done before the Lawson/Landmark configurations are done.  Also, this document will indicate whether the work needs to be done in LSF only, Landmark only, or both.)

 

Prerequisites

Here is what you will need before you get started.

• SSL certificate for the AD LDS server with the private key (.pfx) included
  • Note: Certificate must contain a SAN (Subject Alternate Name)
  • Can be an existing wildcard cert, or the cert already installed on your LSF server (if it meets the requirements)
  • You will also need to know your private key password for the cert
• ssoconfig password
• LDAP Bind password
  • This is the password for the user in the LDAPBINDDN setting in your LAWDIR\system\install.cfg file
• Verify the port you are using for LDAPS (typically 636 or 3269)
  • 636 is the standard SSL, 3269 is the Global Catalog Port
  • Global Catalog is preferred when the LDAP servers support it
• Take snapshots of all your servers. Just do it!

LDAP Certificate – AD LDS

This procedure only has to be performed on the server that hosts AD LDS (most likely your LSF server).

1 – Add the LDAP Certificate to the AD LDS Service

1. Identify the AD LDS service instance in your Microsoft Services list
   1. Also make note of the account that is running the service for later use
      
2. Launch MMC (Microsoft Management Console)
3. Choose File > Add/Remove Snap-In
4. Add the certificates Snap-In
5. Choose “Service” account and click “Next”
   
6. Choose “Local Computer” and click “Next”
   1. If you are not on the computer hosting AD LDS, then chose “Another computer” and provide the server name
      
7. Choose the Service Account you identified above and click “Finish”
   
8. Right-click on the service that was added and select “All Tasks > Import”
   
   
9. Click next and browse to the .pfx certificate file. Click “Next”
   
10. Enter the private key password
    
11. Place the certificate in the Personal store for the AD LDS service
    
12. Click Next then Finish
    

2 – Export Certificate (.cer) file

Export the certificate as a Base-64 encoded X.509 (.cer) for the OS and WebSphere Java updates.

1. In MMC, right click the certificate > All Tasks > Export and click Next
2. Do not export the private key
   
3. Choose Base-64 encoded X.509 (.cer) and click Next
   
4. Choose a location to save the file for later use
   
5. Click finish

3 – Grant Permissions on Certificate Container

This is where you will need the service account that is running the AD LDS service (you made a note of that earlier).  That user needs to be granted Read and Read & Execute permissions on the Unique Container file, as well as the Machine Keys directory.

1. From an administrator command window, run command certutil -store MY
2. Find the LDAPS cert(s) by comparing the cert hash to the thumbprints on the certificate properties in MMC
3. Make note of the Unique Container Name
   
4. Navigate to the “Keys” or the “MachineKeys” folder
   1. This can be found in multiple places depending on your server configuration
   2. Some possible locations: C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys or C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys or C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\Keys
   3. You could also do a file search for the unique container name
   4. Grant Read and Read & Execute permissions on the Keys/MachineKeys directory AND the Unique Container file
   5. NOTE: if you have a nested certificate, you may have more than one unique container file. Grant permissions on all of the containers related to your LDAP Cert.
      
5. Stop the LSF environment service
6. Restart the AD LDS service

4 – Smoke Test

1. Open the ldp.exe tool
2. Type the server FQDN, SSL port, and check the SSL box
3. Click “OK”
4. Make sure a connection is established, and the tool finds an entry
5. Do not proceed until you have a successful smoke test
   1. Hint: If the ldp.exe tool has any trouble connecting, there will typically be some helpful error messages in the Event Viewer
      

 

LDAP Certificate – WebSphere

This procedure needs to be performed for both the Lawson and Landmark instances of WebSphere.

In this procedure, you are going to update the Default Trust Store on both the Cell and the Node in WebSphere.  These instructions demonstrate how to get the LDAPS certificate into WebSphere using the “Retrieve from port” button.  It’s the simplest way, but you do also have the option of manually adding the certificate file (.pfx) in each store.

 

1. Access the WAS Admin Console and navigate to: Security > SSL certificate and key management > Key stores and certificates
2. Click the CellDefaultTrustStore > Signer certificates
3. Click the Retrieve from port button.
4. Host: <the server where your LDAPs certificate was added to the AD LDS service>
5. Port: <the port that your network team is using for LDAPS>
6. Alias: <give it a meaningful name>
7. Click Retrieve signer information.
8. Once you click “Retrieve signer information”, the bottom of the form will be populated with information about your certificate.
9. Click OK & save changes.
10. Synchronize the nodes
11. Perform these same steps for the NodeDefaultTrustStore
12. Remember to do this in your WebSphere environment for both Landmark AND Lawson!
    
    

LDAP Certificate – Java

This procedure needs to be performed on both the Lawson AND Landmark servers.

Adding certificates to the Java store can be done using either the ikeyman GUI utility, or the keytool command line utility.  The below instructions will demonstrate both methods.  Whichever utility you use, the procedure is the same for both OS Java and WebSphere Java.

 

1 – Add Certificate to OS Java (ikeyman example)

This is the Java instance that is used by LSF or Landmark.  Here is an example of updating cacerts using the ikeyman utility.

1. Set environment variables (<APPINSTALLDIR>\enter)
2. Run command “where java” to determine where LAW_JAVA_HOME is located
   1. NOTE: You may have multiple instances of Java, and you need to make sure you apply the cert to all of them!
3. Back up file LAW_JAVA_HOME\jre\lib\security\cacerts
4. Run the ikeyman utility at WAS_HOME/bin
5. Open the LAW_JAVA_HOME/jre/lib/cacerts file and select the Key database type of JKS
   
6. Type password “changeit”
   1. This is the default password for the Java certs files
      
7. Select “Signer Certificates” in the dropdown
8. Click “add” and navigate to the ldap certificate exported earlier
   
9. Give it a meaningful name
   

 

2 – Add Certificate to WebSphere Java (keytool example)

This is the Java instance that is installed with WebSphere.  Here is an example of updating cacerts using the keytool utility.  NOTE: You will most likely have more than one Java folder in the WebSphere install directory.  It is important to update all instances.

1. Find your WebSphere Java directories (may have multiple)
   1. Located at WAS_HOME
   2. “Base” java and version-specific java (i.e. WAS_HOME/Java and WAS_HOME/Java_1.7_64)
2. Make note of these directories
3. Back up the file(s) WAS_JAVA_HOME/jre/lib/security/cacerts
4. Add signer certs using keytool command line utility
5. Open an administrator command window
6. Get a list of the existing certs and validate using command
   1. keytool -list -keystore WAS_JAVA_HOME/lib/security/cacerts -storepass changeit > keytool_list_WS_before.out
7. Import the new cert using the command
   1. keytool -import -file <file path to your .cer file> -alias <meaningful name> -trustcacerts -keystore WAS_JAVA_HOME/jre/lib/security/cacerts -storepass changeit > out
8. Get the list of the existing certs and validate that the new cert was added using command
   1. keytool -list -keystore WAS_JAVA_HOME/jre/lib/security/cacerts -storepass changeit > keytool_list_WS_after.out
      
      
9. Compare your “before” list to your “after” list to make sure the cert was added correctly
   

 

Don’t forget to do BOTH Lawson and Landmark!!

Lawson Configuration Changes

This procedure is performed only on the LSF Server

1 – Update Authentication Data Store

1. Open an administrator command window or LID
2. Set the environment variables
3. Run the ssoconfig -c command
4. Choose option “Change Lawson authentication data store settings”
   
5. Update the protocol and port on the Provider URL
6. Leave the next two values the same
7. Enter the password for the LDAP user
8. Confirm the password for the LDAP user
9. Leave the last value the same
   
10. Run lsconfig -l to smoke test
    1. You should get some data back
    2. If you get an error, make sure you entered the correct password
       
11. Update the LAWDIR\system\install.cfg file with the new values so it will be ready for future patches
    

2 – Update LDAP Bind Settings

Export the LDAP Bind Service

1. From an administrator command window or LID, run ssoconfig –c
2. Select “Manage Lawson services” > “Export Service and identity info” > “NO”
3. Enter the name of your LDAP Bind service (such as LDAP_BIND_SVC)
4. Do not export the identities (NONE)
5. Provide a filename

Update the LDAP Bind Service

6. Open the exported file
7. Set the “Override” setting to “true”
8. Locate the LDAP provider line and update the protocol and port
   1. BEFORE: <PROVIDER>ldap://server.company.com:389</PROVIDER>
   2. AFTER: <PROVIDER>ldaps://server.company.com:636</PROVIDER>
      
9. Save the file

Upload the file to ssoconfig

10. Run ssoconfig –l <SSOCONFIG_PASSORD> <FULL_FILE_PATH> from a command window or LID
    
11. Restart the LSF server

3 – Smoke Test

1. Perform Lawson Authentication Smoke Tests
   1. https://server.company.com/ssoconfig/SSOCfgInfoServlet
   2. https://server.company.com/sso/SSOServlet
   3. Log into Lawson and perform a couple of inquiries/batch jobs
      
      

Landmark Configuration Changes

This procedure is performed only on the Landmark Server

1 – Update LDAP Bind Settings

1. Launch Rich Client for the gen data area
2. Search for Login in the search box
3. Double click the Login Scheme business class
4. Search for the LoginScheme that is associated with the LDAP Bind Service (you may have more than one)
5. Double click on the LoginScheme to open the properties screen
6. Click the LDAP Bind Properties tab
7. Click on the LDAP Bind Properties tab
8. Update the port and protocol on the Provider entry
   
9. Save the update
10. Restart the Landmark Server

 

2 – Smoke Test

1. Make sure you can still log into Rich Client using your AD username & password
2. If you use IPA, it is also a good idea to run some IPA Smoke Tests to make sure that the authentication/communication between Landmark and Lawson is still functioning
   1. Web Run Node
   2. System Command Node
   3. File Access Node
   4. Lawson Query/Transaction Nodes

Infor Federation Services (IFS) Configuration Changes

This procedure is performed only on the IFS Web Utility, and is only required if you are using AD FS for authentication

1. Ensure that a certificate for the AD server is present in your IFS Server’s Trusted Root Certificate Store
2. Update the AD Configuration in IFS
   1. IFS > Configure > Parameters
   2. Select your Active Directory configuration (not Bootstrap)
   3. Update the URL with your LDAPS port, but the protocol should still be LDAP
      
      
3. Make sure you can still synchronize users in IFS

 

Conclusion

And now you are ready to enforce LDAPS connections!  Be sure to also watch the webinar that we gave on this topic April 16, 2020.  You can find it in the education section on our website.

 

View Our Webinar “Configuring Lawson for LDAP Signing”

 

 

Traditionally LBI is setup with Lawson Groups such as the LBIUser which by default, communicates to LBI which users should have access.

There is another way to assign rights in LBI aside from adding more groups to users. LBI has its own native “Report Security Group” system.

1. To access this system, login into LBI as your admin user and access Reporting Services Administration.
2. Under Report Management, select “New Report Security Group” to create a new security group
   
3. Enter the name of the group and description, click Save
   
4. Now set the permissions similar to how you set permissions per report.
   
5. Go to Users and add the users you want to have access to this group, you can even set report overrides per user if needed
   
6. Now on an individual report, you can add the entire security group you just created to it:
   

You’ll still need to have Lawson groups to grant access to individual dashboards and modules but this helps add a new layer of security in an organized way.