PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 10/13/2008 5:35 PM by  John Costa
LDAP Bind issue
 12 Replies
Sort:
You are not authorized to post a reply.
Author Messages
John Costa
Private
Private
Veteran Member
(378 points)
Veteran Member
Posts:154


Send Message:

--
10/10/2008 10:39 AM

    I just completed an LDAP Bind using the guidance I found here:  http://www.slavo.biz/ldapbind.htm.&...; All of my company's users are in a single domain spread across multiple containers.  Prior to doing the LDAP bind, I ensured the Lawson-delivered accounts had already been set up in AD (lsadm, lsuser, lawson, and LAWDEV_System).  I completed the LDAP bind without error.

    Now for some reason my ordinary user accounts cannot log into Portal, although the Lawson user ID can (the boxes for user accounts turn yellow).  I logged into LSA under the 'lawson' user account using the AD password and I get in OK.  I then verified that my test user account has identities on the environment, employee self-service, and SSOP services.

    I'm not sure where to go from here.  Do I need to create an identity for each user on the SSOP_BIND service?  I wouldn't think so since the 'lawson' ID has no identity on this service.

    What else can I look at? Thanks in advance.

    _________________ John - Wichita, KS
    Sam Simpson
    Private
    Private
    Veteran Member
    (673 points)
    Veteran Member
    Posts:239


    Send Message:

    --
    10/10/2008 4:15 PM
    Since your ldap is already bind. You have to use the network id and password.
    John Costa
    Private
    Private
    Veteran Member
    (378 points)
    Veteran Member
    Posts:154


    Send Message:

    --
    10/11/2008 9:25 AM
    Thanks Sam, but that's the issue. The user accounts are valid and I'm typing in the correct domain passwords but Portal still comes back with yellow boxes. Any other suggestions?
    _________________ John - Wichita, KS
    John Henley
    Private
    Private
    Senior Member
    (9563 points)
    Senior Member
    Posts:3205


    Send Message:

    --
    10/12/2008 12:16 PM
    John, when you did the bind, did you select the "bind to multiple containers" option? I have found that if you *don't* select that option the bind doesn't work, even if you really only want to bind to a single container.

    Also, you might want to try using an LDAP browser and login with the searchbase/username/password you specified for the bind and see if you can query against the users that aren't working. Since it sounds like the bind itself is working (since you can login for some of the users/identities), it sounds like you might have the wrong search base (i.e. is the 'lawson' user in a different tree than the portal users??)
    Thanks for using the LawsonGuru.com forums!
    John
    John Costa
    Private
    Private
    Veteran Member
    (378 points)
    Veteran Member
    Posts:154


    Send Message:

    --
    10/13/2008 8:07 AM
    John,
     
    To answer your questions:
     
    (1) Yes, I did select the "multiple containers" option when creating the LDAP bind service. In fact, all of my users are in multiple containers so I knew I had to select this option anyway.
     
    (2) Yes, I am able to use a specified service account to browse my company's AD repository. The service account was created the same time as the other lawson service accounts.
     
    I agree with you that I may have the wrong search base specified but I'm not sure. For my search base, I specified DC=Pro1s,DC=Root,DC=ProtectionOne,DC=com. All of my user accounts are in multiple containers in multiple levels under this base using the following hierarchy / structure: OU = “Company”, OU = "Users", OU = “Departments”, OU = , OU = “Active Directory”, CN = .
     
    For instance, the user account I was testing (jcosta) is in the following container: CN=John Costa,OU=Active_Directory,OU=IT,OU=Departments,OU=Users,OU=Protection One,DC=Pro1s,DC=Root,DC=ProtectionOne,DC=com. 
     
    All of my company’s service accounts, including the Lawson account, are stored in the following container: OU=Service_Users**DO_NOT_DELETE**,DC=Pro1s,DC=Root,DC=ProtectionOne,DC=com
     
    Is it possible that the LDAP bind cannot traverse the steps through the hierarchy needed to reach a given user account?  I'd appreciate any further suggestions you might have.
    _________________ John - Wichita, KS
    John Costa
    Private
    Private
    Veteran Member
    (378 points)
    Veteran Member
    Posts:154


    Send Message:

    --
    10/13/2008 11:56 AM
    Well, I tried deleting all identities for my test user and then deleting the RM record.  I then stepped through the "Add user" wizard in the Lawson Security Administrator, recreating the RM record and three identity records, one for the environment, one for employee self-service, and one for SSOP.  Still no go.

    _________________ John - Wichita, KS
    John Henley
    Private
    Private
    Senior Member
    (9563 points)
    Senior Member
    Posts:3205


    Send Message:

    --
    10/13/2008 12:03 PM
    What is the DN for the user you specified to be able to do the search?

    Does that account have access to search *all* of containers? I'm betting that it doesn't...
    Thanks for using the LawsonGuru.com forums!
    John
    John Costa
    Private
    Private
    Veteran Member
    (378 points)
    Veteran Member
    Posts:154


    Send Message:

    --
    10/13/2008 12:48 PM
    John,

    The DN for user specified for searching AD is one of the service accounts created for me last week:

    CN=LSF9_LDAP_SRV,OU=Service_Users**DO_NOT_DELETE**,DC=Pro1s,DC=Root,DC=ProtectionOne,DC=com

    I have verfified that this user account has full read rights across my AD repository.  I confirmed this by using this account within my LDAP browser (Softerra LDAP Browser 2.5.3) and am able to browse all containers and classes.  I also tried using the same service account under ADAM adsiedit to see if I could browse AD that way, and I verified that I can access all containers and classes.
    _________________ John - Wichita, KS
    John Costa
    Private
    Private
    Veteran Member
    (378 points)
    Veteran Member
    Posts:154


    Send Message:

    --
    10/13/2008 3:16 PM
    OK, I figured it out through trial and error.

    I was trying to bind to the cn (common name) entry in my AD, making the false assumption that the value stored for each entry was equal to a user's domain user ID (first initial and last name).  This is not the case, at least not on my domain.

    On my domain, the cn attribute for each user conists of a person's full first and last name.

    What I had to do was re-run the LDAP bind.  When I got to the question asking what naming attribute to use when locating users in AD, I entered 'sAMAccountName' instead of using the default of 'cn'. 

    Lo and behold, I'm able to login via the Portal now!
    _________________ John - Wichita, KS
    John Henley
    Private
    Private
    Senior Member
    (9563 points)
    Senior Member
    Posts:3205


    Send Message:

    --
    10/13/2008 3:48 PM
    When you do the bind to AD, LDAP naming attribute should be [cn]: sAMAccountName LDAP structural object class [inetOrgPerson]: user Do you do it that way??
    Thanks for using the LawsonGuru.com forums!
    John
    John Costa
    Private
    Private
    Veteran Member
    (378 points)
    Veteran Member
    Posts:154


    Send Message:

    --
    10/13/2008 3:51 PM
    John,


    Yes, I specified a naming attribute of 'sAMAccountName' and the structural object class of 'user'.  What I was using previously was a naming attribute of 'cn'.
    _________________ John - Wichita, KS
    John Henley
    Private
    Private
    Senior Member
    (9563 points)
    Senior Member
    Posts:3205


    Send Message:

    --
    10/13/2008 4:58 PM

    So, you're saying you re-did the bind?

    Thanks for using the LawsonGuru.com forums!
    John
    John Costa
    Private
    Private
    Veteran Member
    (378 points)
    Veteran Member
    Posts:154


    Send Message:

    --
    10/13/2008 5:35 PM
    Yes, sir, exactly.

    The document I referenced at the top of this thread suggested that for AD I was to use the user attribute of common name or 'cn' when doing my bind.  It was only after I took a closer look at the entries for my users in AD that I found the cn attribute did not contain the value I expected. It contained a full user first and last name when I was expecting to find a first initial and last name.  In other words, I expected the cn value to match the domain user ID of each user and this is what I wanted folks to use when logging into Portal.

    Once I saw the cn attribute was not going to work, I started looking at what other attributes in AD might contain a user's network logon.  That's when I came across the 'sAMAccountName' attribute.

    So all I did was re-run ldapbind, specify "sAMAccountName" for the lookup attribute, and I was good to go.

    I appreciate your efforts in helping me try to resolve this issue.
    _________________ John - Wichita, KS
    You are not authorized to post a reply.