Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

LDAP issue

Status
Not open for further replies.

madhuusa

IS-IT--Management
Oct 5, 2006
93
US
Guru's, I need some LDAP help. When we connect to LDAP server, we get the following error always.

Even if we adjust the search results page size in our LDAP param screen anywhere from 1 to 50000 the same error.

MS has a link at
Is the only way of solving this is to increase the limit on the LDAP side or is there something on livelink side we can do? Please help.

The synchronization completed with errors.
Please review the log below and contact Open Text Technical support if necessary.


--------------------------------------------------------------------------------

[Tue Jun 09 10:31:17 2009] : Connecting to ....
[Tue Jun 09 10:31:17 2009] : Synchronization started.
[Tue Jun 09 10:31:17 2009] : SynchronizeGroups [Pass: 1]
[Tue Jun 09 10:31:17 2009] : Asynchronous search initiated ...
[Tue Jun 09 10:31:17 2009] : Synchronization completed with error: Reached timeout limit of 1000.
 
You should contact OpenText support.I have synced more than 50000 users with livelink LDAP RO queries and have not seen this error.I have never understood what the "synchronous" flag does in code,it has always hung on me.Chris Wagg of OpenText is the person you need to ask for.He knows LDAP and DirSvcs like the back of his hand and usually rescues you almost immediately.BTW if you use LDP or active directory users & computers are you able to run your queries or does that get time out as well.I never use the livelink ldap interface to debug it is alawys better to use a tool that is deigned for that purpose.Hope that helps

Well, if I called the wrong number, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937
Certified OT Developer,Livelink ECM Champion 2008
 
Definitely helps Appnair. Our .NET engineer wrote a code to browse the ldap tree and that work correctly. Only from LL side we are having the issue. I will loop with OT on this.
 
I think we made a little progress. In search results page we made it 500K (although the guide tells 1 to 1000 is the range) and it went through. Now this error.

Does this indicate for this user there is something wrong with the way attributes are setup. INTemp is obviously not a 'user' but I guess something else.

[Tue Jun 09 23:50:10 2009] : Synchronizing User 'CN=INTemp,OU=Generic Users,OU=Users,OU=BDN,DC=inter,DC=com'
[Tue Jun 09 23:50:10 2009] : Updating user 'INTemp' in Livelink
[Tue Jun 09 23:50:10 2009] : Synchronizing User 'CN=562-909-1010,OU=Contacts,OU=Users,OU=KSS,DC=inter,DC=com'
[Tue Jun 09 23:50:10 2009] : Synchronization completed with error: User name is undefined, 'Log-in Name:' attribute may be incorrect.
 
Madhu,
How familiar are you with writing an AD query.As I said the first step in syncing users/groups into livelink is to use a tool that is designed for that purpose.If you go to your livelink server and type mmc /a and pick up active directory users and computers from the add snap in method then you have a really good interface to practice the query.Once you run that query all you have to do is to cut and paste the same query into livelink.If you type ldp.exe on that computer does it bring up anything.
Code:
The User Search Filter syntax: (&(objectCategory=Person)(objectClass=user)(|(memberOf=CN=IT,OU=CorporateUsers,DC=company,DC=com)))

In the Group filter (&(objectcategory=group)(cn=IT))

When the livelink process runs or for that matter any ldap query runs this is what it is doing.Give me the group that has the Common Name IT and in AD is catually a "group".
In the user this translates to Give me all users that are of
Person or User and is a memeber of the group called "IT" which happens to be in the "Organizational Unit Corporate users" in the domain controller Comapny ,in the domain controller com.

It is a tree based search so the operators look freaky but they are very easy to figure out once you understand the traversal.

Livelink LDAP svcs just runs the query and if it is gets results it tries to build users and groups.In your case what you managed to do is to get a user who is probably not a "user" or does not have a samaccountname hence when the LLdir svcs cannot proceed because in livelink you need a login name.So all livelink admins use a tool to formulate the queries and put that in the queries to execute.I am not sure how much you will get further using your method to debug every error the dir svcs interace throws :)

Try simple methods.There is a LDAP query forum in tek tips as well.

Well, if I called the wrong number, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937
Certified OT Developer,Livelink ECM Champion 2008
 
Looking at your error it looks like the User in your AD identified by

CN=562-909-1010,OU=Contacts,OU=Users,OU=KSS,DC=inter,DC=com

does not have a correct value for the property that you have mapped to Livelink login in your Synchronisation page, can you confirm this ?

Greg Griffiths
Livelink Certified Developer & ECM Global Star Champion 2005 & 2006
 
Excellent points AppNair.

I think Greg is pointing it out right. I think the CN information is wrong.

Can you query be used to restrict users only from particular CN.

I am also working on the other points that you have mentioned and loop shortly.

The User Search Filter syntax: (&(objectCategory=Person)(objectClass=user)(|(memberOf=CN=IT,OU=CorporateUsers,DC=company,DC=com)))

In the Group filter (&(objectcategory=group)(cn=IT))
 
If you are a starter( we all were one time) think of AD as a relational database(it is wrong semantically).It supports all the queries like in a RDB although the tree algorithm makes it much faster than a RDB.So one could theoretically query it for all attributes such as

select samaccountname from AD where CN="appu" only thing is you don't write the syntax like this.In the mapping page you are saying that in loginname fill it with samaccountname or uid(for sun's LDAP).

Unfortuantely you cannot bring users one by one like this so that is why we bring users belonging to a group but
YOU HAVE TO BE SURE YOU ARE ASKING FOR USERS in the right tree level that is all the OU stuff you are providing
as LL does not validate this info that your query is providing it.

The same considerations have to be done for groups as well.

AD is very powerful so are its query tools.It is very unlikely that a LL admin knows everything about the AD structure.I have done this many time over and I try to understand the ll process behind it which I am sharing.

You should see some of the queries we have developed goes like two pages long and is mind boggling but in the end it is a very simple concept.You have attributes(columns) in AD(table) as in a RDB.Hope that helps you somewhat .Don't be afraid to experiment on a test system and stay away from department mapping,it takes a Chris Wagg to do it not my kind of thing :)

Well, if I called the wrong number, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937
Certified OT Developer,Livelink ECM Champion 2008
 
AppNair/Greg, Can we in anyway via opentext.ini or something skip entries with the wrong CN. Meaning can we set the settings in such a way even if wrong CN entries come up, livelink should ignore the error and proceed onto the next LDAP user?
 
wouldn't it be better if you did a ldif export to csv and create your own users/groups with LAPI and just use the SSO authentication ?

Well, if I called the wrong number, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937
Certified OT Developer,Livelink ECM Champion 2008
 
By default LL assumes that your query is correct - which yours is not - it is possible that the code could be patched to skip some errors, but you'd have to define which ones were to be skipped and which were not. Overall, you would be better off fixing your LDAP query.

Greg Griffiths
Livelink Certified Developer & ECM Global Star Champion 2005 & 2006
 
Team, AppNair, Greg, the situation is resolved (but I do have a minor glitch). Thanks a ton. This forum is all because of you guys. I hope one day I can also be a contributor rather than an 'asker' :)

Here is the story.

I gave the search filter as below and that did the trick.

The User Search Filter syntax: (&(objectCategory=user)(objectClass=user))

Once it hit 1000 user count, it failed with "You have exceeded 1000 users per group"

OT recommendation for this is at
WIll this situation be resolved if I setup some thing like below in livelink LDAP department mapping screen.
LDAP Department : LDAP_KSS_XX_XXX
Livelink Group : RG: KSS_XX_XXX

If we create department mapping like above we need not bother about the 1000 or 3000 limit because I guess department count will be less than 1000 in our AD. (need to check on this though internally)

Note that the above mapping is to pull AD user into LL and to nest them in one of the base group. If a user needs to belong to several groups, then I think we need to manually add that user to several groups unless otherwise AD has it mapped and we give those mappings also as above. Is this true?

This is my approach below. Will this be okay approach.

1. Identify top level groups in Livelink(examples below)
RG: KSS: HR
RG: KSS: LEGAL
RG: KSS: IT
etc
etc

2. Identify related LDAP groups.

3. Create mapping in Livelink as per point 1 groups.

4. Sync up livelink with LDAP.

5. Now we will get almost all the users nested in the to groups of step 1. Rest goes to DefaultGroup in case no mapping is there.

6. Then to create the permission structure we will create Livelink groups and then add the users into these groups. Note that the step 1 groups are just the base groups to suck users into Livelink from AD into higher level Livelink groups. For example any Legal user in AD will have Legal base group. But for fine grained legal access (say Enterprise-->Legal-->NorthAmerica-->EastCoast) we need to create appropriate fine grained groups manually.

So in summary: Use AD to sync and pull in users nested in top level groups in LL. Then manually create groups (and assign members) and apply this groups to folders as per business needs.

I have asked for AD team to give me the user/group details in AD as to see whether they are cleanly maintained and also asked our business team to look into those mapping to see whether business groups are okay with the mapping. If business team is not okay then I guess I can use the above approach. That's the idea.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top