Go to previous topic
Go to next topic
Last Post 12/23/2013 2:02 PM by  Joe O'Toole
Lawson superuser account cannot log into Portal
 4 Replies
Author Messages
Joe O'Toole
Private
Private
Veteran Member
(802 points)
Veteran Member
Posts:312


Send Message:

--
12/11/2013 7:29 PM
    We are having an issue with the Lawson user id not being able to log into Portal. We rarely use this account but recently needed to get into the ProcessFlow administration screen and discovered it could not authenticate in Portal. The Environment record for this account is tied to the lawson AD account "domain_name\lawson" which is a domain admin account and runs many of our S3 services and jobs. This domain account can also log into LID just fine. We have a ticket open with Infor support, and they had us run some SSO Tracing logs but so far they cannot explain this behavior and their only suggestion is to change the Windows password. Unfortunately, we cannot easily do this due to it being tied to a number of production processes. I deleted and recreated the Environment record in LSF security admin, but this did not help. We are running LSF 9.019 in Windows environment and bound to AD. Has anyone encountered this before and solved it? Thanks.
    Alex Tsekhansky
    Private
    Private
    Veteran Member
    (276 points)
    Veteran Member
    Posts:92


    Send Message:

    --
    12/12/2013 12:19 AM
    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.
    Joe O'Toole
    Private
    Private
    Veteran Member
    (802 points)
    Veteran Member
    Posts:312


    Send Message:

    --
    12/12/2013 1:47 PM
    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?
    Alex Tsekhansky
    Private
    Private
    Veteran Member
    (276 points)
    Veteran Member
    Posts:92


    Send Message:

    --
    12/22/2013 10:14 PM
    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.
    Joe O'Toole
    Private
    Private
    Veteran Member
    (802 points)
    Veteran Member
    Posts:312


    Send Message:

    --
    12/23/2013 2:02 PM
    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.


    ---