Just to confirm that the results are coming back from the source LDAP,
here is an example of a getOne operation, as seen over the wire.
Everything I need is in there.

Lightweight Directory Access Protocol
    LDAPMessage searchResEntry(82) "CN=Joe Jackson,OU=Users,OU=US
Scottsdale,DC=xyz,DC=net" [1 result]
        messageID: 82
        protocolOp: searchResEntry (4)
            searchResEntry
                objectName: CN=Joe Jackson,OU=Users,OU=US
Scottsdale,DC=xyz,DC=net
                attributes: 7 items
                    PartialAttributeList item objectClass
                        type: objectClass
                        vals: 4 items
                            top
                            person
                            organizationalPerson
                            user
                    PartialAttributeList item cn
                        type: cn
                        vals: 1 item
                            Joe Jackson
                    PartialAttributeList item sn
                        type: sn
                        vals: 1 item
                            Jackson
                    PartialAttributeList item description
                        type: description
                        vals: 1 item
                            QBE Re Claims Auditor
                    PartialAttributeList item givenName
                        type: givenName
                        vals: 1 item
                            Joe
                    PartialAttributeList item userAccountControl
                        type: userAccountControl
                        vals: 1 item
                            514
                    PartialAttributeList item sAMAccountName
                        type: sAMAccountName
                        vals: 1 item
                            Joe.jackson



On Wed, May 16, 2012 at 9:33 AM, Hugh Kelley <[email protected]> wrote:

> I am using yesterday's trunk snapshot from
> http://tools.lsc-project.org/projects/list_files/lsc.
>
> I'm putting Wireshark on the server right now to confirm that the
> attributes are coming back from the source, though ldifde.exe worked fine.
>
> Hugh
>
>
> On Wed, May 16, 2012 at 9:28 AM, Clément OUDOT <[email protected]>wrote:
>
>> 2012/5/16 Hugh Kelley <[email protected]>:
>> > I am using two AD domains, yes.
>> >
>> > The credentials are able to read the attributes.   The source binddn is
>> the
>> > same one I have been using for all of my testing.   I am running
>> against a
>> > different destination AD now, but the problem here appears to be
>> > source-side.
>>
>> It is strange, because I do not have this behavior. Which LSC version
>> are you using: 2.0rc2, 2.0-SNAPSHOT, trunk?
>>
>> Clément.
>>
>
>
_______________________________________________________________
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