LDAP issues with TS 6.5

We've run into a snag with our implementaion of LDAP with TS 6.5, we just can't seem to get it to log in the users via the front end. I've followed the instructions I've found for the configuration changes to iw.cfg, but it hasn't worked.

Once the changes to IW.cfg have been put up, a reset done, and the system user files renamed on the box a user is able to log into the box via SSH. This tells me the LDAP is acknowledging the password. But if you attempt to log into the GUI end of TS you get the Wrong username/password error. I'm wondering if we are missing a step here? Here's what we got:

TS 6.5
Solaris 9
LDAP box is Sun 1E 5.2

IW.CFG:
[authentication]
authenticate_by=ldap
ldap_server=172.17.200.10
ldap_port=389
ldap_dnbase=cn=proxyagent,dc=corp,dc=interval-intl,dc=com

Any ideas? Thanks.

Find more posts tagged with

Comments

nipper

It has been way too long since I did LDAP, but I do remember a couple of things. The LDAP server I used needed a login and password. IIRC, those were in the iw.cfg.

Also, can you have your admin turn on debug on the LDAP server ? I did that before and it was invaluable in debugging what failed.

nipper

Also try using the Solaris command ldapsearch and iwldapsearch to see if they can query the LDAP server.

dchristie

It has been way too long since I did LDAP, but I do remember a couple of things. The LDAP server I used needed a login and password. IIRC, those were in the iw.cfg.

Is it the LDAP server that needs the login and password, or is it TS that needs it for LDAP to login to it? Is this a generic UN and PW that needs to be created on the LDAP?

dchristie

I saw in an article:

[authentication]
authenticate_by=ldap
ldap_server=yourservername.yourdomain.com
ldap_port=389
ldap_dnbase=o=yourdomain.com
ldap_key=uid

We don't have the ldap_key=uid attribute in our iw.cfg. Is this where the user id goes? What about the pw attribute?

nipper

The LDAP server needs a login/password to respond to an applications request. So TS needs to know what to pass to the LDAP server.

nipper

OK, I found something that might be helpful, ask your LDAP admin if they support anonymous bind, this is from the 6.7 admin manual:

Configuring TeamSite and LDAP to Work Without an Anonymous Bind

In some installations, anonymous binds to LDAP are not permitted for security reasons. If you cannot use an anonymous bind to LDAP to read user names, you can establish a dedicated LDAP user account to use for user authentication. All searches for users’ Distinguished Names are done using this account instead of an anonymous bind. For this mode of operation, you must add two additional parameters to the [authentication] section of iw.cfg.

[authentication]

ldap_account=DistinguishedName

ldap_pwd=password

dchristie

Well, LDAP admin says:

Our LDAP setup will let anonymous binding

This means an anonymous user can read the rootDSE entry (i.e. the one with no DN).
Also a Bind request with out password also will work, currently, Directory Server cannot reject anonymous bind operations, but we set ACI rules so that anonymous users have no permissions to do anything.

So I'm assuming we do not need the un and pw account set up in iw.cfg. I was unable to run the iwldapsearch commad and get it to work:

./iwldapsearch -h 172.17.200.10 -b cn=proxyagent,dc=corp,dc=interval-in
tl,dc=com

it kept giving a "Segmentation Fault" error. I'm assuming the box is able to communicate with the LDAP server since I can ssh into the TS box using my LDAP credentials. Hmmmm....

nipper

Well when you see a seg fault from an IWOV application, then it is time to bring support in.

Off chance, did you try ldapsearch as well ?

dchristie

Well when you see a seg fault from an IWOV application, then it is time to bring support in.

Off chance, did you try ldapsearch as well ?

I did, it spit out:

ken-inwdev01>./ldapsearch -h 172.17.200.10 -b cn=proxyagent, dc=corp, dc=interval-intl, dc=com
ldap_search: Invalid DN syntax
Additional info: Invalid DN

I've got a ticket open with Interwoven support. I'm thinking this has something to do with the LDAP server and it's set up. Thanks for the help.

nipper

I did, it spit out:

ken-inwdev01>./ldapsearch -h 172.17.200.10 -b cn=proxyagent, dc=corp, dc=interval-intl, dc=com
ldap_search: Invalid DN syntax
Additional info: Invalid DN

That does not look good. You may want to get your LDAP admin to look at that.