Configuring LDAP for Active Directory (Solved)

[ServerGuy]

Im trying to configure a second Namespace that uses LDAP pointing to an AD server. The Cognos server is on a different domain than the domain i am trying to configure the namespace for. Also i already have one namespace configured for active directory.

I have a bind user and can use an LDAP utility to read all users from the other domain.

I read the below articles for configuring the server but I must be confused on setting everything up because i cannot login even as the bind user after i restart services. Any help would be appreciated.

http://publib.boulder.ibm.com/infocenter/c8bi/v8r4m0/index.jsp?topic=/com.ibm.swg.im.cognos.ig_vpt.8.4.1.doc/ig_vpt_id1570bv_ldap_map.html

http://publib.boulder.ibm.com/infocenter/cbv/v10r1m0/index.jsp?topic=%2Fcom.ibm.swg.ba.cognos.ig_vpt.10.1.1.doc%2Ft_bv_ldap_prcss.html


Currently i have the following settings (I changed some names for domain and such)

Host & Port: example.local:389
Base Distinguished Name: DC=example,DC=local
user lookup: ${userID}
Use External Identity: False
Bind user DN and password: bindinguser@example.local 
Use bind credentials for search: true
Unique identifier: dn


I tried setting the user  lookup to (sAMAccountName=${userID}) and uid=${userID}, ou=example.local but to no avail.

Also tried changing Unique Identifier from dn to objectGUID with both of the above settings but again nothing.

Not sure if i just used a wrong combination but i must be doing something wrong.

Thanks!

[Grim]

Try the steps outlined here:
http://www-01.ibm.com/support/docview.wss?uid=swg21338901

PS. You will need to use samAccountName.

[ServerGuy]

I ran through the video a couple times. Which was a great help, however I tried logging in to Cognos using the binding user and still get an invalid logon failure.

Here are my new values for the namespace:

Type: LDAP
Namespace ID: Test
Host and Port: example.local:389
Base Distinguished Name: DC=example,DC=local
User lookup: (sAMAccountName=${userID})
Use external identity: False
Bind user DN and password: cn=BindingUser,cn=users,dc=example,dc=local
Use bind credentials for search: True
Allow empty password: False
Unique identifier: objectGUID
Data encoding UTF-8

Folder Mappings:
Object class: organizationalunit,organization,container
Description: description
Name: ou,o,cn

Group Mappings:
Object class: group
Description: description
Member: member
Name: cn

Account Mappings:
Account object class: user
Business phone: telephonenumber
Content locale:
Description: description
Email: mail
Fax/Phone: facsimiletelephonenumber
Given name: givenname
Home phone: homephone
Mobile phone: mobile
Name: displayName
Pager phone: pager
Password: unicodePwd
Postal address: postaladdress
Product locale:
Surname: sn
User name: sAMAccountName

[Grim]

I am only speculating here, but I would suggest talking to your AD admins. Run through the configuration with them. It seems that there may be some changes that were done to the default AD schema. As such you may and will most likely have to specify different object/cn names.

Just a wild guess though.

Oh...just thought of something else..
Is the Cognos server a trusted server on the other domain?

[ServerGuy]

I used performance monitor and used the build in data collector set for AD which gave me a print out of the LDAP query. I see the cognos server hitting the AD server via LDAP and they say successful. I went through each of the mappings to ensure all field names were the same and what is defined in the documentation and the video. They all matched and whats odd is it seems to authenticate as if i used invalid credentials in the bind user i get an invalid login on the namespace test.

Any ideas?

[ServerGuy]

Solved it. Everything on the LDAP side was correct however the "Restrict access to members of the built-in namespace" setting was set to True. I had to disable this, then I could login as the binding user and add users to a cognos group which then when i turn the option back on I was able to login successfully. Just placing this for any other users that might run into this as well.