Lawson superuser account cannot log into Portal

I think you should try addressing the "original" issue first. If you need to go into ProcessFlow, there are other ways to do it. For instance, you can give another user rights to processflow. You can also make someone else able to go to LSA, so any security can be modified there. That can be done via ssoconfig export/import or loadusers.

Now, if you need to figure out why domain user "Lawson" cannot login, there are other things you should check. First, make sure that the role file is blank (or points to default.xml). Then make sure CheckLS for it is set to NO, and that this user has appropriate rights in LAUA. If it needs to be an LS-security user, make it LAUA one temporarily. Run listusermap and see if it's mapped correctly. Login into LID as that user and run LAUA, make sure that user is highlighted when LAUA comes up (if not, that means your user map is bad; you may simply need to refresh it).

But as I said, address the main issue (such as ProcessFlow configuration) first by other means, and then you can troubleshoot Portal login.

Hi Alex, thanks for your suggestions. Infor gave us a workaround on the PF admin access - a database field update that would provide this to another account so I am not really hung up on that. The LSF Sec check LS is set to NO and the role file is pointing to default.xml. In LID the "lawson" account is highlighted when we go into LAUA, the role is set to security officer and the security class is set to Admin. Any other ideas?

Hi, Joe. There are quite a few reasons why a user cannot login into Portal. If CheckLS is set to NO, and that user has Portal Admin set to YES, it's probably not related to security.

One common issue I've seen - you have more than one user named "lawson" in a system. That is possible if you bind to AD, your AD has multiple domains, and each domain has a user named "lawson". You can easily check for that with any LDAP tool, such as Softera LDAP browser or JXplorer.
Another common issue - a username in SSOP identity must be spelled the same way as you type it (if it's set to "LAWSON" in SSOP, you will not be able to login if you type "lawson" on Portal login screen).

If you really need to fix that, you can enable SSO logging (in one of the .properties files in the LAWIR/system - I think sso_trace.properties, or something similar). That will produce VERY detailed SSO login logs in LAWDIR/system. This will tell you if Lawson actually got the username right, and whether it was able to verify the password against AD if it's BINDed.

The other things to check - clear the LOCALE (if it's set to anything) in LAUA, clear the Portal Role file in the RM record (or put it to default.xml).

Let's start with these items and see where they get you.

I checked the SSOP record in LSA and it's set to "lawson", however it's possible there is some errant entry in LDAP I suppose. We still have an active ticket open with Infor on this and had previously sent them SSO tracing logs, but they did not seem to help them identify the cause. All I've gotten from Infor is to change the password on the account which we cannot do at the present time. We are using a customized PortalRole file, but it works fine for other accounts. I changed it back to default.xml for the lawson account just to test but that did not help. The other thing Infor asked was if the lawson account can log into LSA or MS-Addins and it does not work there either so whatever is broken is affecting these as well.