LDAP Bind issue

Sort:
You are not authorized to post a reply.
Author
Messages
John Costa
Veteran Member
Posts: 154
Veteran Member

    I just completed an LDAP Bind using the guidance I found here:  http://www.slavo.biz/ldap....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
    Veteran Member
    Posts: 239
    Veteran Member
      Since your ldap is already bind. You have to use the network id and password.
      John Costa
      Veteran Member
      Posts: 154
      Veteran Member
        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
        Senior Member
        Posts: 3348
        Senior Member
          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
          Veteran Member
          Posts: 154
          Veteran Member
            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
            Veteran Member
            Posts: 154
            Veteran Member
              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
              Senior Member
              Posts: 3348
              Senior Member
                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
                Veteran Member
                Posts: 154
                Veteran Member
                  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
                  Veteran Member
                  Posts: 154
                  Veteran Member
                    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
                    Senior Member
                    Posts: 3348
                    Senior Member
                      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
                      Veteran Member
                      Posts: 154
                      Veteran Member
                        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
                        Senior Member
                        Posts: 3348
                        Senior Member

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

                          Thanks for using the LawsonGuru.com forums!
                          John
                          John Costa
                          Veteran Member
                          Posts: 154
                          Veteran Member
                            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.