Re: Can I create a role in syncope which will be propagated to opendj?

[Francesco Chicchiriccò]

Hi Nik,
let me try to provide some insight about your questions below.
First of all, OpenDJ is prosecution of dead Sun Microsystem's OpenDS, 
and even though not officially and not recently tested by me, it should 
be work fine with SYNC on the ConnId LDAP connector.

Anyway, you can safely use full reconciliation as first step then move 
to actual sync only if this works.

Then, about your main issue, I have found a couple of anomalies in your 
configuration (that quite match with the stacktrace reported, even 
though you haven't included the original cause):

 1. User mapping flags UserSchema firstname as AccountId: I'd rather 
start with Username (as in the blog post), it's easier for matching 
existing users during synchronization.

 2. you have a derived schema 'fullname' and a plain schema 'fullname', 
both assigned in the user template: please remove the latter, you just 
don't need it.

Regards.

On 26/04/2013 11:07, Nik wrote:
I think I might be beginning to understand why I dont succeed with a 
sync from syncope from opnedj now.

According to
https://connid.atlassian.net/wiki/display/BASE/LDAP

Supported Operations
:
Sync (only with Sun Directory Server Enterprise Edition)

I guess this excludes opendj by definition.
Am I correct, in the conclusion?

rgds,
Nik

Some further info.

When I run the CLI

[nik@anvil syncope-1.1.0]$ curl -u admin:password -H “Content-Type: 
application/json” -X GET 
http://10.0.0.123:9080/syncope/cxf/tasks/sync/list

I see many NPE (see attachment for full details)like:

<?xml version="1.0" encoding="UTF-8"?><tasks>
<syncTask>
<endDate>2013-04-25T14:31:00.504+02:00</endDate>
<excecutions>
<excecution>
<endDate>2013-04-24T11:53:08.296+02:00</endDate>
<id>92</id>
<message>While syncing on connector

org.quartz.JobExecutionException: While syncing on connector [See 
nested exception: java.lang.IllegalArgumentException: Must be a 
single value.]
at 
org.apache.syncope.core.sync.impl.SyncJob.executeWithSecurityContext(SyncJob.java:430)
at org.apache.syncope.core.sync.impl.SyncJob.doExecute(SyncJob.java:341)
at 
org.apache.syncope.core.quartz.AbstractTaskJob.execute(AbstractTaskJob.java:104)
at org.quartz.core.JobRunShell.run(JobRunShell.java:213)
at 
org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:557)
Caused by: java.lang.IllegalArgumentException: Must be a single value.
at 
org.identityconnectors.framework.common.objects.AttributeBuilder.checkSingleValue(AttributeBuilder.java:200)
at 
org.identityconnectors.framework.common.objects.AttributeBuilder.getSingleStringValue(AttributeBuilder.java:211)
at 
org.identityconnectors.framework.common.objects.AttributeBuilder.build(AttributeBuilder.java:184)
at 
org.connid.bundles.ldap.schema.LdapSchemaMapping.createAttribute(LdapSchemaMapping.java:304)
at 
org.connid.bundles.ldap.search.LdapSearch.createConnectorObject(LdapSearch.java:288)
at 
org.connid.bundles.ldap.search.LdapSearch.access$000(LdapSearch.java:67)
at 
org.connid.bundles.ldap.search.LdapSearch$2.handle(LdapSearch.java:165)
at 
org.connid.bundles.ldap.search.DefaultSearchStrategy.doSearch(DefaultSearchStrategy.java:76)
at 
org.connid.bundles.ldap.search.LdapInternalSearch.execute(LdapInternalSearch.java:70)
at 
org.connid.bundles.ldap.search.LdapSearch.getSingleResult(LdapSearch.java:159)
at 
org.connid.bundles.ldap.search.LdapSearches.findObject(LdapSearches.java:167)
at 
org.connid.bundles.ldap.sync.sunds.SunDSChangeLogSyncStrategy.createSyncDelta(SunDSChangeLogSyncStrategy.java:306)
at 
org.connid.bundles.ldap.sync.sunds.SunDSChangeLogSyncStrategy.access$000(SunDSChangeLogSyncStrategy.java:88)
at 
org.connid.bundles.ldap.sync.sunds.SunDSChangeLogSyncStrategy$1.handle(SunDSChangeLogSyncStrategy.java:178)
at 
org.connid.bundles.ldap.search.DefaultSearchStrategy.doSearch(DefaultSearchStrategy.java:76)
at 
org.connid.bundles.ldap.search.LdapInternalSearch.execute(LdapInternalSearch.java:70)
at 
org.connid.bundles.ldap.sync.sunds.SunDSChangeLogSyncStrategy.sync(SunDSChangeLogSyncStrategy.java:163)
at org.connid.bundles.ldap.LdapConnector.sync(LdapConnector.java:193)
at 
org.identityconnectors.framework.impl.api.local.operations.SyncImpl.sync(SyncImpl.java:63)
at sun.reflect.GeneratedMethodAccessor1296.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)


Maybe there will be clues in that to help troubleshoot the issue of 
not synchronizing.

rgds,
Nik
Hi Guys,

I have been using the url below [1] to verify that synchronization 
can occur from opendj ldap to syncope (and vice versa).
If I follow the instructions described for synchronization, as best 
I can. I cannot get ldap entries (including new ldap
entries) to synchronize back to syncope with my setup.I'm assuming 
(hopefully correctly) that this is a fundamental feature
of syncope and therefore, I'm messing something up in my config 
somewhere. Please help me!

details:
- check my resource is set up (NB specifying synchronization trace 
level set to ALL) [see a.png]
- define my user/role mappings[b.png,c.png]
- check my ldap connector is defined as per the blog [d.png, e.png]
- under tasks define how my synchronized ldap user is going to be 
presented in syncope [g.png,h.png,i.pn,gj.png]

[nik@anvil bin]$ ./ldapmodify -p 1389 -h 10.0.0.121 -D"cn=directory 
manager" -w welcome -a -f /tmp/user.ldif
Processing ADD request for uid=olive,ou=people,o=usharesoft
ADD operation successful for DN uid=olive,ou=people,o=usharesoft
[nik@anvil bin]$

[24/Apr/2013:16:21:40 +0200] CONNECT conn=4 from=10.0.0.123:40160 
to=10.0.0.121:1389 protocol=LDAP
[24/Apr/2013:16:21:40 +0200] BIND REQ conn=4 op=0 msgID=1 version=3 
type=SIMPLE dn="cn=directory manager"
[24/Apr/2013:16:21:40 +0200] BIND RES conn=4 op=0 msgID=1 result=0 
authDN="cn=Directory Manager,cn=Root DNs,cn=config" etime=1
[24/Apr/2013:16:21:40 +0200] ADD REQ conn=4 op=1 msgID=2 
dn="uid=olive,ou=people,o=usharesoft"
[24/Apr/2013:16:21:40 +0200] ADD RES conn=4 op=1 msgID=2 result=0 
etime=36
[24/Apr/2013:16:21:40 +0200] UNBIND REQ conn=4 op=2 msgID=3
[24/Apr/2013:16:21:40 +0200] DISCONNECT conn=4 reason="Client Unbind"
[24/Apr/2013:16:21:41 +0200] MODIFY REQ conn=-1 op=449 msgID=450 
dn="o=usharesoft" type=synchronization
[24/Apr/2013:16:21:41 +0200] MODIFY RES conn=-1 op=449 msgID=450 
result=0 etime=4

[nik@anvil bin]$ ./ldapmodify -p 1389 -h 10.0.0.121 -D"cn=directory 
manager" -w welcome -f /tmp/desc.ldif
Processing MODIFY request for uid=olive,ou=people,o=usharesoft
MODIFY operation successful for DN uid=olive,ou=people,o=usharesoft
[nik@anvil bin]$

[24/Apr/2013:16:29:40 +0200] CONNECT conn=13 from=10.0.0.123:40191 
to=10.0.0.121:1389 protocol=LDAP
[24/Apr/2013:16:29:40 +0200] BIND REQ conn=13 op=0 msgID=1 version=3 
type=SIMPLE dn="cn=directory manager"
[24/Apr/2013:16:29:40 +0200] BIND RES conn=13 op=0 msgID=1 result=0 
authDN="cn=Directory Manager,cn=Root DNs,cn=config" etime=2
[24/Apr/2013:16:29:40 +0200] MODIFY REQ conn=13 op=1 msgID=2 
dn="uid=olive,ou=people,o=usharesoft"
[24/Apr/2013:16:29:40 +0200] MODIFY RES conn=13 op=1 msgID=2 
result=0 etime=5
[24/Apr/2013:16:29:40 +0200] UNBIND REQ conn=13 op=2 msgID=3
[24/Apr/2013:16:29:40 +0200] DISCONNECT conn=13 reason="Client Unbind"
[24/Apr/2013:16:29:41 +0200] MODIFY REQ conn=-1 op=450 msgID=451 
dn="o=usharesoft" type=synchronization
[24/Apr/2013:16:29:41 +0200] MODIFY RES conn=-1 op=450 msgID=451 
result=0 etime=2



[nik@anvil bin]$

[nik@nik-laptop OpenDJ]$ bin/ldapsearch -p 1389 -D "cn=directory 
manager" -w welcome -b "" -s base '(objectClass=*)' changelog 
lastChangeNumber firstChangeNumber
dn:
changelog: cn=changelog
lastChangeNumber: 13
firstChangeNumber: 1

[nik@nik-laptop OpenDJ]$

[nik@nik-laptop OpenDJ]$ bin/ldapsearch -p 1389 -D "cn=directory 
manager" -w welcome -b "cn=changelog" 
"(&(objectClass=changeLogEntry)(changeNumber>=0)(changeNumber<=13))"
dn: changeNumber=1,cn=changelog
targetDN: uid=olive,ou=people,o=usharesoft
changeNumber: 1
changes:: 
cmVwbGFjZTogZGVzY3JpcHRpb24KZGVzY3JpcHRpb246IEEgbmV3IHVzZXIncyBlbnRyeQ
otCnJlcGxhY2U6IG1vZGlmaWVyc05hbWUKbW9kaWZpZXJzTmFtZTogY249RGlyZWN0b3J5IE1hbmFnZ 

XIsY249Um9vdCBETnMsY249Y29uZmlnCi0KcmVwbGFjZTogbW9kaWZ5VGltZXN0YW1wCm1vZGlmeVRp 

bWVzdGFtcDogMjAxMzA0MjQxNjQ1MzdaCi0K
changeType: modify
changeTime: 20130424164537Z
objectClass: top
objectClass: changeLogEntry

dn: changeNumber=2,cn=changelog
targetDN: uid=olive,ou=people,o=usharesoft
changeNumber: 2
changes:: 
cmVwbGFjZTogZGVzY3JpcHRpb24KZGVzY3JpcHRpb246OiBZV1JrY21WemN5QT0KLQpyZX
BsYWNlOiBtb2RpZmllcnNOYW1lCm1vZGlmaWVyc05hbWU6IGNuPURpcmVjdG9yeSBNYW5hZ2VyLGNuP 

VJvb3QgRE5zLGNuPWNvbmZpZwotCnJlcGxhY2U6IG1vZGlmeVRpbWVzdGFtcAptb2RpZnlUaW1lc3Rh 

bXA6IDIwMTMwNDI1MDgxNjI2WgotCg==
changeType: modify
changeTime: 20130425081626Z
objectClass: top
objectClass: changeLogEntry

dn: changeNumber=3,cn=changelog
targetDN: uid=olive,ou=people,o=usharesoft
changeNumber: 3
changes:: 
cmVwbGFjZTogZGVzY3JpcHRpb24KZGVzY3JpcHRpb246OiBZV1JrY21WemN6RWcKLQpyZX
BsYWNlOiBtb2RpZmllcnNOYW1lCm1vZGlmaWVyc05hbWU6IGNuPURpcmVjdG9yeSBNYW5hZ2VyLGNuP 

VJvb3QgRE5zLGNuPWNvbmZpZwotCnJlcGxhY2U6IG1vZGlmeVRpbWVzdGFtcAptb2RpZnlUaW1lc3Rh 

bXA6IDIwMTMwNDI1MDgxODIyWgotCg==
changeType: modify
changeTime: 20130425081822Z
objectClass: top
objectClass: changeLogEntry

dn: changeNumber=4,cn=changelog
targetDN: uid=olive,ou=people,o=usharesoft
changeNumber: 4
changes:: 
cmVwbGFjZTogZGVzY3JpcHRpb24KZGVzY3JpcHRpb246OiBZV1JrY21WemN6RWcKLQpyZX
BsYWNlOiBtb2RpZmllcnNOYW1lCm1vZGlmaWVyc05hbWU6IGNuPURpcmVjdG9yeSBNYW5hZ2VyLGNuP 

VJvb3QgRE5zLGNuPWNvbmZpZwotCnJlcGxhY2U6IG1vZGlmeVRpbWVzdGFtcAptb2RpZnlUaW1lc3Rh 

bXA6IDIwMTMwNDI1MDgxODQxWgotCg==
changeType: modify
changeTime: 20130425081841Z
objectClass: top
objectClass: changeLogEntry

dn: changeNumber=5,cn=changelog
targetDN: uid=olive,ou=people,o=usharesoft
changeNumber: 5
changes:: 
cmVwbGFjZTogZGVzY3JpcHRpb24KZGVzY3JpcHRpb246OiBZV1JrY21WemN6RWcKLQpyZX
BsYWNlOiBtb2RpZmllcnNOYW1lCm1vZGlmaWVyc05hbWU6IGNuPURpcmVjdG9yeSBNYW5hZ2VyLGNuP 

VJvb3QgRE5zLGNuPWNvbmZpZwotCnJlcGxhY2U6IG1vZGlmeVRpbWVzdGFtcAptb2RpZnlUaW1lc3Rh 

bXA6IDIwMTMwNDI1MDgxODQ1WgotCg==
changeType: modify
changeTime: 20130425081845Z
objectClass: top
objectClass: changeLogEntry

dn: changeNumber=6,cn=changelog
targetDN: uid=olive,ou=people,o=usharesoft
changeNumber: 6
changes:: 
cmVwbGFjZTogZGVzY3JpcHRpb24KZGVzY3JpcHRpb246OiBZV1JrY21WemN6RWcKLQpyZX
BsYWNlOiBtb2RpZmllcnNOYW1lCm1vZGlmaWVyc05hbWU6IGNuPURpcmVjdG9yeSBNYW5hZ2VyLGNuP 

VJvb3QgRE5zLGNuPWNvbmZpZwotCnJlcGxhY2U6IG1vZGlmeVRpbWVzdGFtcAptb2RpZnlUaW1lc3Rh 

bXA6IDIwMTMwNDI1MDgxODQ2WgotCg==
changeType: modify
changeTime: 20130425081846Z
objectClass: top
objectClass: changeLogEntry

dn: changeNumber=7,cn=changelog
targetDN: uid=olive,ou=people,o=usharesoft
changeNumber: 7
changes:: 
cmVwbGFjZTogZGVzY3JpcHRpb24KZGVzY3JpcHRpb246OiBZV1JrY21WemN6RWcKLQpyZX
BsYWNlOiBtb2RpZmllcnNOYW1lCm1vZGlmaWVyc05hbWU6IGNuPURpcmVjdG9yeSBNYW5hZ2VyLGNuP 

VJvb3QgRE5zLGNuPWNvbmZpZwotCnJlcGxhY2U6IG1vZGlmeVRpbWVzdGFtcAptb2RpZnlUaW1lc3Rh 

bXA6IDIwMTMwNDI1MDgxODQ3WgotCg==
changeType: modify
changeTime: 20130425081847Z
objectClass: top
objectClass: changeLogEntry

dn: changeNumber=8,cn=changelog
targetDN: uid=olive,ou=people,o=usharesoft
changeNumber: 8
changes:: 
cmVwbGFjZTogZGVzY3JpcHRpb24KZGVzY3JpcHRpb246OiBZV1JrY21WemN6RWcKLQpyZX
BsYWNlOiBtb2RpZmllcnNOYW1lCm1vZGlmaWVyc05hbWU6IGNuPURpcmVjdG9yeSBNYW5hZ2VyLGNuP 

VJvb3QgRE5zLGNuPWNvbmZpZwotCnJlcGxhY2U6IG1vZGlmeVRpbWVzdGFtcAptb2RpZnlUaW1lc3Rh 

bXA6IDIwMTMwNDI1MDgxODQ5WgotCg==
changeType: modify
changeTime: 20130425081849Z
objectClass: top
objectClass: changeLogEntry

dn: changeNumber=9,cn=changelog
targetDN: uid=olive,ou=people,o=usharesoft
changeNumber: 9
changes:: 
cmVwbGFjZTogZGVzY3JpcHRpb24KZGVzY3JpcHRpb246IEEgbmV3IHVzZXIncyBlbnRyeQ
otCnJlcGxhY2U6IG1vZGlmaWVyc05hbWUKbW9kaWZpZXJzTmFtZTogY249RGlyZWN0b3J5IE1hbmFnZ 

XIsY249Um9vdCBETnMsY249Y29uZmlnCi0KcmVwbGFjZTogbW9kaWZ5VGltZXN0YW1wCm1vZGlmeVRp 

bWVzdGFtcDogMjAxMzA0MjUwOTI5MzBaCi0K
changeType: modify
changeTime: 20130425092930Z
objectClass: top
objectClass: changeLogEntry

dn: changeNumber=10,cn=changelog
targetDN: uid=olive,ou=people,o=usharesoft
changeNumber: 10
changes:: 
cmVwbGFjZTogZGVzY3JpcHRpb24KZGVzY3JpcHRpb246IEEgbmV3IHVzZXIncyBlbnRyeQ
otCnJlcGxhY2U6IG1vZGlmaWVyc05hbWUKbW9kaWZpZXJzTmFtZTogY249RGlyZWN0b3J5IE1hbmFnZ 

XIsY249Um9vdCBETnMsY249Y29uZmlnCi0KcmVwbGFjZTogbW9kaWZ5VGltZXN0YW1wCm1vZGlmeVRp 

bWVzdGFtcDogMjAxMzA0MjUwOTI5NDNaCi0K
changeType: modify
changeTime: 20130425092943Z
objectClass: top
objectClass: changeLogEntry

dn: changeNumber=11,cn=changelog
targetDN: uid=olive,ou=people,o=usharesoft
changeNumber: 11
changes:: 
cmVwbGFjZTogZGVzY3JpcHRpb24KZGVzY3JpcHRpb246IEEgbmV3IHVzZXIncyBlbnRyeQ
otCnJlcGxhY2U6IG1vZGlmaWVyc05hbWUKbW9kaWZpZXJzTmFtZTogY249RGlyZWN0b3J5IE1hbmFnZ 

XIsY249Um9vdCBETnMsY249Y29uZmlnCi0KcmVwbGFjZTogbW9kaWZ5VGltZXN0YW1wCm1vZGlmeVRp 

bWVzdGFtcDogMjAxMzA0MjUwOTI5NDRaCi0K
changeType: modify
changeTime: 20130425092944Z
objectClass: top
objectClass: changeLogEntry

dn: changeNumber=12,cn=changelog
targetDN: uid=olive,ou=people,o=usharesoft
changeNumber: 12
changes:: 
cmVwbGFjZTogZGVzY3JpcHRpb24KZGVzY3JpcHRpb246IEEgbmV3IHVzZXIncyBlbnRyeQ
otCnJlcGxhY2U6IG1vZGlmaWVyc05hbWUKbW9kaWZpZXJzTmFtZTogY249RGlyZWN0b3J5IE1hbmFnZ 

XIsY249Um9vdCBETnMsY249Y29uZmlnCi0KcmVwbGFjZTogbW9kaWZ5VGltZXN0YW1wCm1vZGlmeVRp 

bWVzdGFtcDogMjAxMzA0MjUwOTI5NDZaCi0K
changeType: modify
changeTime: 20130425092946Z
objectClass: top
objectClass: changeLogEntry

dn: changeNumber=13,cn=changelog
targetDN: uid=olive,ou=people,o=usharesoft
changeNumber: 13
changes:: 
cmVwbGFjZTogZGVzY3JpcHRpb24KZGVzY3JpcHRpb246IEEgbmV3IHVzZXIncyBlbnRyeQ
otCnJlcGxhY2U6IG1vZGlmaWVyc05hbWUKbW9kaWZpZXJzTmFtZTogY249RGlyZWN0b3J5IE1hbmFnZ 

XIsY249Um9vdCBETnMsY249Y29uZmlnCi0KcmVwbGFjZTogbW9kaWZ5VGltZXN0YW1wCm1vZGlmeVRp 

bWVzdGFtcDogMjAxMzA0MjUwOTI5NDhaCi0K
changeType: modify
changeTime: 20130425092948Z
objectClass: top
objectClass: changeLogEntry

[nik@nik-laptop OpenDJ]$

We can see I have 13 outstanding changes in ldap for targetDN: 
uid=olive,ou=people,o=usharesoft.

At this point I would expect my synchronization task to execute and 
these changes including the entry
uid=olive,ou=people,o=usharesoft
to be linked into syncope by the definition of user in the task 
definition [see h.png, g.png] but nothing changes
in my syncope-console user view [see k.png].


[1] 
http://blog.tirasa.net/blogs/index.php/ilgrosso/unlock-full-ldap-features-in

--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/