Hi,

Le 16/07/2010 01:02, [email protected] a écrit :
I'm getting closer, thank you.

Now using 1.2.1, I can pull what I think is everything I need from AD,
however I have two new issues:

1) When I'm using -n for testing, I'm seeing the occasional error like:
Jul 15 15:49:42 - ERROR - Error while synchronizing ID
cn=rmckenzi,ou=People: java.lang.StringIndexOutOfBoundsException:
String index out of range: 3
dn: cn=rmckenzi,ou=People,dc=local
changetype: add
cn: rmckenzi
(by occasional I mean a handful in ~5000 records)

No visible errors in the Wireshark trace of the transaction.

This could be an error in one of your JavaScript methods from lsc.properties. It's hard to tell though - to find out you should set logging level to DEBUG in etc/logback.xml by setting DEBUG instead of INFO or WARN on these lines:

<logger name="org.lsc" level="DEBUG">
<root level="DEBUG">

2) When not using -n, I get a schema error (65) because it claims no
objectClass is set.  However when I add objectClass=posixAccount to
lsc.tasks.FirstTask.dn or try to use
lsc.syncoptions.FirstTask.objectClass="posixAccount" or even
srcBean.getAttributeValueById("objectClass") (to echo the AD object
class), I still get the same error.

"objectClass" is an attribute like any other - use syncoptions to set it. Something like:

lsc.syncoptions.YourTaskName.objectClass.force_value = "posixAccount"
or
lsc.syncoptions.YourTaskName.objectClass.create_value = "posixAccount"

(depending on whether you want to add/change the objectClass or just set it for new accounts)

And make sure "objectClass" is listed in dstService.attrs.

However, IIRC, "posixAccount" is an auxiliary class, and won't work on it's own without a structural objectClass, or am I forgetting?

Any further suggestions would be greatly appreciated,
Jeff

P.S. Don't know if this is a bug, but lsc doesn't like embedded
backslashes in CNs even when it's not an attribute that's selected for
reading.  Not my fault, BTW, :)
java.lang.IllegalArgumentException: Not a valid attribute string value

I don't fully understand the problem from this description, but it doesn't sound right. Can you provide details, and if it is not functioning in the way you expect, open a bug report on http://tools.lsc-project.org ? Thanks.

Hope this helps,
Jonathan

On Mon, Jul 12, 2010 at 11:51 PM, Jonathan Clarke
<[email protected]>  wrote:
Hi!

Le 13/07/2010 01:19, [email protected] a écrit :

I've been trying to configure lsc-1.2.0 to sync from Active Directory
to OpenLDAP and have been running into problems.

Specifically, lsc seems to connect (and Wireshark confirms) ok to AD
and starts sucking out user records with:
lsc.tasks.FirstTask.srcService.filterAll =
(&(sn=*)(objectcategory=person)(objectcategory=user))

Isc is configured to operate in paging mode:
src.java.naming.ldap.pageSize = 1000

However, it immediately starts printing:
ERROR - Too many entries returned (base: "", filter: "(sn=somelastname)")
ERROR - Error while synchronizing ID cn=some full name,ou=People:
javax.naming.SizeLimitExceededException: Too many entries returned
(base: "", filter: "(sn=somelastname)")
where "somelastname" and "some full name" are different.

This is because your filter to return one entry is returning more than one.
Presumably several accounts in your AD have the same sn.

To better understand, here's a quick description of how LSC handles entries:

1) It gets a list of all entries to consider in the source by running a
search using the filter lsc.tasks.FirstTask.srcService.filterAll, and
reading only the pivot attributes (looks like "sn" in your case).

2) It reads each entry from the source one by one, by doing a search using
the filter lsc.tasks.FirstTask.srcService.filterId, and replacing individual
pivot values to form a valid search filter.

Simply put: you need to use a unique attribute (or set of attributes) as
your pivotAttrs. If "sn" is not unique, don't use it as a pivot. Since
you're syncing with AD, I suggest using "sAMAccountName". Other common
pivots are "mail", "cn" or a combination of "sn" and "givenName".

This is briefly described in:


http://lsc-project.org/wiki/documentation/1.2/configuration/service#simplejndisrcservice_simplejndidstservice_and_fulldnjndidstservice

Regards,
Jonathan

It looks like (from Wireshark) that a query is made for a page, then
multiple chunks (something like 2-3 users per chunk) are coming back
from AD until the page is complete.  Then lsc makes the request for
the next page until all records are successfully retrieved.

Any pointers at all where to start debugging would be greatly appreciated.

Thanks in advance,
Jeff Katcher
_______________________________________________________________
Ldap Synchronization Connector (LSC) - http://lsc-project.org

lsc-users mailing list
[email protected]
http://lists.lsc-project.org/listinfo/lsc-users


--
--------------------------------------------------------------
Jonathan Clarke - [email protected]
--------------------------------------------------------------
Ldap Synchronization Connector (LSC) - http://lsc-project.org
--------------------------------------------------------------

_______________________________________________________________
Ldap Synchronization Connector (LSC) - http://lsc-project.org

lsc-users mailing list
[email protected]
http://lists.lsc-project.org/listinfo/lsc-users


--
--------------------------------------------------------------
Jonathan Clarke - [email protected]
--------------------------------------------------------------
Ldap Synchronization Connector (LSC) - http://lsc-project.org
--------------------------------------------------------------
_______________________________________________________________
Ldap Synchronization Connector (LSC) - http://lsc-project.org

lsc-users mailing list
[email protected]
http://lists.lsc-project.org/listinfo/lsc-users

Reply via email to