LDAP Bind issue - LawsonGuru.com - LawsonGuru.com Forums

Name	Points
Greg Moeller	4184
David Williams	3349
JonA	3291
Kat V	2984
Woozy	1973
Jimmy Chiu	1883
Kwane McNeal	1437
Ragu Raghavan	1372
Roger French	1315
mark.cook	1244

John Costa

Veteran Member

Posts: 154

10/10/2008 2:39 PM

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.

Sam Simpson

Veteran Member

Posts: 239

10/10/2008 8:15 PM

Since your ldap is already bind. You have to use the network id and password.

John Costa

Veteran Member

Posts: 154

10/11/2008 1:25 PM

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 Henley

Posts: 3353

10/12/2008 4: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??)

John Costa

Veteran Member

Posts: 154

10/13/2008 12:07 PM

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 Costa

Veteran Member

Posts: 154

10/13/2008 3:56 PM

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 Henley

Posts: 3353

10/13/2008 4: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...

John Costa

Veteran Member

Posts: 154

10/13/2008 4: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 Costa

Veteran Member

Posts: 154

10/13/2008 7: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 Henley

Posts: 3353

10/13/2008 7: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??

John Costa

Veteran Member

Posts: 154

10/13/2008 7: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 Henley

Posts: 3353

10/13/2008 8:58 PM

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

John Costa

Veteran Member

Posts: 154

10/13/2008 9: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.