You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@syncope.apache.org by jeverling <je...@surfnet.nl> on 2013/11/07 23:52:52 UTC
user resource removing and reassigning
Hello Ilgrosso,
I thought you might be interested in this thing I discovered tonight.
If I create a user and assign a resource (APDS with the LDAP connector)
every goes well. I can change attributes of the user, activate and
deactivate the user and every change shows up perfectly at APDS.
When I remove the resource, it says that the entry is removed from the ldap.
But it's still there.
After reassigning the resource it gives the error below. In orde to fix the
entry I have to completely remove the account and create it again. Just
removing the LDAP entry doesn't suffice.
The strange thing is... all goes well when i just delete the entire user.
Then it is being removed properly.
I did not found any related issue on this forum, so I thought you might be
interested.
Or is this a configuration issue? It did not seem that way, but correct me
if I am wrong.
Kind regards,
Jeffrey Everling
java.lang.IllegalArgumentException: Must be a single value.
at
org.identityconnectors.framework.common.objects.Attribute.<init>(Attribute.java:118)
~[connid-framework-1.3.3.jar:na]
at
org.identityconnectors.framework.common.objects.AttributeBuilder.build(AttributeBuilder.java:188)
~[connid-framework-1.3.3.jar:na]
at
org.identityconnectors.framework.common.objects.AttributeBuilder.build(AttributeBuilder.java:109)
~[connid-framework-1.3.3.jar:na]
at
org.connid.bundles.ldap.schema.LdapSchemaMapping.createAttribute(LdapSchemaMapping.java:286)
~[na:na]
at
org.connid.bundles.ldap.search.LdapSearch.createConnectorObject(LdapSearch.java:288)
~[na:na]
at
org.connid.bundles.ldap.search.LdapSearch.access$000(LdapSearch.java:67)
~[na:na]
at
org.connid.bundles.ldap.search.LdapSearch$1.handle(LdapSearch.java:143)
~[na:na]
at
org.connid.bundles.ldap.search.DefaultSearchStrategy.doSearch(DefaultSearchStrategy.java:76)
~[na:na]
at
org.connid.bundles.ldap.search.LdapInternalSearch.execute(LdapInternalSearch.java:70)
~[na:na]
at
org.connid.bundles.ldap.search.LdapSearch.execute(LdapSearch.java:138)
~[na:na]
at
org.connid.bundles.ldap.LdapConnector.executeQuery(LdapConnector.java:135)
~[na:na]
at
org.connid.bundles.ldap.LdapConnector.executeQuery(LdapConnector.java:56)
~[na:na]
at
org.identityconnectors.framework.impl.api.local.operations.SearchImpl.rawSearch(SearchImpl.java:118)
~[connid-framework-internal-1.3.3.jar:na]
at
org.identityconnectors.framework.impl.api.local.operations.SearchImpl.search(SearchImpl.java:82)
~[connid-framework-internal-1.3.3.jar:na]
at sun.reflect.GeneratedMethodAccessor395.invoke(Unknown Source)
~[na:na]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[na:1.6.0_24]
at java.lang.reflect.Method.invoke(Method.java:616) ~[na:1.6.0_24]
at
org.identityconnectors.framework.impl.api.local.operations.ConnectorAPIOperationRunnerProxy.invoke(ConnectorAPIOperationRunnerProxy.java:93)
~[connid-framework-internal-1.3.3.jar:na]
at sun.proxy.$Proxy146.search(Unknown Source) ~[na:na]
at
org.identityconnectors.framework.impl.api.local.operations.GetImpl.getObject(GetImpl.java:65)
~[connid-framework-internal-1.3.3.jar:na]
at sun.reflect.GeneratedMethodAccessor645.invoke(Unknown Source)
~[na:na]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[na:1.6.0_24]
at java.lang.reflect.Method.invoke(Method.java:616) ~[na:1.6.0_24]
at
org.identityconnectors.framework.impl.api.local.operations.ThreadClassLoaderManagerProxy.invoke(ThreadClassLoaderManagerProxy.java:100)
~[connid-framework-internal-1.3.3.jar:na]
at sun.proxy.$Proxy147.getObject(Unknown Source) [na:na]
at sun.reflect.GeneratedMethodAccessor645.invoke(Unknown Source)
~[na:na]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[na:1.6.0_24]
at java.lang.reflect.Method.invoke(Method.java:616) ~[na:1.6.0_24]
at
org.identityconnectors.framework.impl.api.DelegatingTimeoutProxy.invoke(DelegatingTimeoutProxy.java:107)
~[connid-framework-internal-1.3.3.jar:na]
at sun.proxy.$Proxy147.getObject(Unknown Source) [na:na]
at sun.reflect.GeneratedMethodAccessor645.invoke(Unknown Source)
~[na:na]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[na:1.6.0_24]
at java.lang.reflect.Method.invoke(Method.java:616) ~[na:1.6.0_24]
at
org.identityconnectors.framework.impl.api.LoggingProxy.invoke(LoggingProxy.java:76)
~[connid-framework-internal-1.3.3.jar:na]
at sun.proxy.$Proxy147.getObject(Unknown Source) [na:na]
at
org.identityconnectors.framework.impl.api.AbstractConnectorFacade.getObject(AbstractConnectorFacade.java:227)
[connid-framework-internal-1.3.3.jar:na]
at
org.apache.syncope.core.propagation.impl.AsyncConnectorFacade.getObject(AsyncConnectorFacade.java:97)
[AsyncConnectorFacade.class:na]
at
org.apache.syncope.core.propagation.impl.AsyncConnectorFacade$$FastClassByCGLIB$$5578eaa3.invoke(<generated>)
[spring-core-3.2.4.RELEASE.jar:na]
at
org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
[spring-core-3.2.4.RELEASE.jar:3.2.4.RELEASE]
at
org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:698)
[spring-aop-3.2.4.RELEASE.jar:3.2.4.RELEASE]
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
[spring-aop-3.2.4.RELEASE.jar:3.2.4.RELEASE]
at
org.springframework.aop.interceptor.AsyncExecutionInterceptor$1.call(AsyncExecutionInterceptor.java:95)
[spring-aop-3.2.4.RELEASE.jar:3.2.4.RELEASE]
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
[na:1.6.0_24]
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
[na:1.6.0_24]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
[na:1.6.0_24]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[na:1.6.0_24]
at java.lang.Thread.run(Thread.java:679) [na:1.6.0_24]
--
View this message in context: http://syncope-user.1051894.n5.nabble.com/user-resource-removing-and-reassigning-tp5707401.html
Sent from the syncope-user mailing list archive at Nabble.com.
Re: user resource removing and reassigning
Posted by jeverling <je...@surfnet.nl>.
ilgrosso [via syncope-user] schreef op 08-11-13 16:19:
> On 08/11/2013 14:22, jeverling wrote:
>> Ilgrosse,
>>
>> Thank you very much for your explanation and helping with the issue
> (learned
>> a bit more about troubleshooting aswell :)
>
> You're welcome :-)
>
>> I have confirmed that when I provide a password while reassigning the
>> resource it works like a charm.
>
> Good: I've opened SYNCOPE-435 [1] for this issue: please watch it if you
> want to be informed about progresses.
I am following it. Thanks
>
> Regards.
>
> [1] https://issues.apache.org/jira/browse/SYNCOPE-435
>
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~ilgrosso/
>
>
>
> ------------------------------------------------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
> http://syncope-user.1051894.n5.nabble.com/user-resource-removing-and-reassigning-tp5707401p5707421.html
>
> To start a new topic under syncope-user, email
> ml-node+s1051894n4425151h70@n5.nabble.com
> To unsubscribe from syncope-user, click here
> <http://syncope-user.1051894.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4425151&code=amVmZnJleS5ldmVybGluZ0BzdXJmbmV0Lm5sfDQ0MjUxNTF8Mzk4NTQzMDg2>.
> NAML
> <http://syncope-user.1051894.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
met vriendelijke groet,
Jeffrey Everling
Interne Automatisering
SURFnet BV
--
View this message in context: http://syncope-user.1051894.n5.nabble.com/user-resource-removing-and-reassigning-tp5707401p5707422.html
Sent from the syncope-user mailing list archive at Nabble.com.
Re: user resource removing and reassigning
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 08/11/2013 14:22, jeverling wrote:
> Ilgrosse,
>
> Thank you very much for your explanation and helping with the issue (learned
> a bit more about troubleshooting aswell :)
You're welcome :-)
> I have confirmed that when I provide a password while reassigning the
> resource it works like a charm.
Good: I've opened SYNCOPE-435 [1] for this issue: please watch it if you
want to be informed about progresses.
Regards.
[1] https://issues.apache.org/jira/browse/SYNCOPE-435
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: user resource removing and reassigning
Posted by jeverling <je...@surfnet.nl>.
Ilgrosse,
Thank you very much for your explanation and helping with the issue (learned
a bit more about troubleshooting aswell :)
I have confirmed that when I provide a password while reassigning the
resource it works like a charm.
Kind regards,
Jeffrey Everling
--
View this message in context: http://syncope-user.1051894.n5.nabble.com/user-resource-removing-and-reassigning-tp5707401p5707420.html
Sent from the syncope-user mailing list archive at Nabble.com.
Re: user resource removing and reassigning
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 08/11/2013 13:44, jeverling wrote:
> Hello Ilgrosso,
>
> > I don't see any evident problem with your configuration.
> > Could you restart everything, clean up your log files and just perform
> > the following operations:
> >
> > 1. create user with LDAP resource
> > 2. remove LDAP resource
> >
> > then paste core-connid.log content to http://apaste.info/ ?'
>
> This is the paste of your specific 2 steps.
> I noticed that these steps perform as expected. The LDAP entry is
> succesfully removed.
> http://apaste.info/dkC1
>
> I noticed the actual problem occurs when reassigning the resource. You
> can see the complete log here:
> http://apaste.info/mBFO
>
> The user is propagated to the LDAP, but in the details pane Syncope says
> that the user is not found in the LDAP resource. Also it gives an
> unclear (at least for me) error in the core-connid.log
By examining the second log, I've found that user is created in ApacheDS
(see line 43: Return: Attribute: {Name=__UID__, Value=[donald]} which is
expected) but that the subsequent read from ApacheDS, performed by
Syncope to retrieve the full actual status to be shown on the admin
console, raises (lines 49 and 50):
java.lang.IllegalArgumentException: Must be a single value.
at
org.identityconnectors.framework.common.objects.Attribute.<init>(Attribute.java:118)
~[connid-framework-1.3.3.jar:na]
If you take a look at Attribute.java:118 [1], you will see that an
exception is raised because that user has no password value.
At the end of the day: the actual problem is that, when re-assigning the
LDAP resource, you are not providing a password again: this is needed
because by default Syncope uses SHA internally hence cannot provide a
cleartext value to be encrypted by the underlying connector.
However, providing password value when subscribing a new resource
*should* be mandatory: I'll investigate and open an issue, in case. In
the meanwhile just remember to provide again a valid password.
Thanks for reporting.
Regards.
[1]
https://github.com/Tirasa/ConnId/blob/master/framework/src/main/java/org/identityconnectors/framework/common/objects/Attribute.java#L118
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: user resource removing and reassigning
Posted by jeverling <je...@surfnet.nl>.
Hello Ilgrosso,
> I don't see any evident problem with your configuration.
> Could you restart everything, clean up your log files and just perform
> the following operations:
>
> 1. create user with LDAP resource
> 2. remove LDAP resource
>
> then paste core-connid.log content to http://apaste.info/ ?'
This is the paste of your specific 2 steps.
I noticed that these steps perform as expected. The LDAP entry is
succesfully removed.
http://apaste.info/dkC1
I noticed the actual problem occurs when reassigning the resource. You
can see the complete log here:
http://apaste.info/mBFO
The user is propagated to the LDAP, but in the details pane Syncope says
that the user is not found in the LDAP resource. Also it gives an
unclear (at least for me) error in the core-connid.log
I hope this is a better explanation than then previous one.
--
Kind regards,
Jeffrey Everling
Interne Automatisering
SURFnet BV
--
View this message in context: http://syncope-user.1051894.n5.nabble.com/user-resource-removing-and-reassigning-tp5707401p5707418.html
Sent from the syncope-user mailing list archive at Nabble.com.
Re: user resource removing and reassigning
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 08/11/2013 10:18, jeverling wrote:
> Hello Ilgrosso,
>
> I compared the settings. I see i forgot to remove the objectclasses person
> and top, but that should not be the problem.
Agree.
> Besides that misconfiguration all seems to be rather the same, since all the
> group info is in another connector.
> I also made sure "be sure to flag "Full reconciliation" from the
> synchronization task" was actually done.
>
> I have answers to your questions below. I have posted everything of my user
> connector/resource.
>
> 1. which LDAP server are you dealing with?
>
> Apache Directory Server (APDS) 2.0.0-M12
Interesting: we use ApacheDS 1.5.7 for integration tests and in the
various demo.
> 2. LDAP connector configuration
>
> <http://syncope-user.1051894.n5.nabble.com/file/n5707406/connector1.png>
>
> <http://syncope-user.1051894.n5.nabble.com/file/n5707406/connector2.png>
>
> <http://syncope-user.1051894.n5.nabble.com/file/n5707406/connector3.png>
>
> 3. LDAP resource configuration (especially user mapping)
>
> <http://syncope-user.1051894.n5.nabble.com/file/n5707406/usermapping.png>
>
> 4. input data of the user to which the LDAP resource is assigned
>
> username
> password
> gidNumber (in syncope attributes)
> givenname (same)
> surname (same)
> commonname (derived user attribute)
> homedir (also derived)
I don't see any evident problem with your configuration.
Could you restart everything, clean up your log files and just perform
the following operations:
1. create user with LDAP resource
2. remove LDAP resource
then paste core-connid.log content to http://apaste.info/ ?
> PS the link to your vm demo
> (http://syncope.tirasa.net/syncope/live/hctsite_en/common/virtual-machine.html)
> does not seem to work anymore.
Link fixed, thanks for reporting ;-)
Regards,
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: user resource removing and reassigning
Posted by jeverling <je...@surfnet.nl>.
Hello Ilgrosso,
I compared the settings. I see i forgot to remove the objectclasses person
and top, but that should not be the problem.
Besides that misconfiguration all seems to be rather the same, since all the
group info is in another connector.
I also made sure "be sure to flag "Full reconciliation" from the
synchronization task" was actually done.
I have answers to your questions below. I have posted everything of my user
connector/resource.
1. which LDAP server are you dealing with?
Apache Directory Server (APDS) 2.0.0-M12
2. LDAP connector configuration
<http://syncope-user.1051894.n5.nabble.com/file/n5707406/connector1.png>
<http://syncope-user.1051894.n5.nabble.com/file/n5707406/connector2.png>
<http://syncope-user.1051894.n5.nabble.com/file/n5707406/connector3.png>
3. LDAP resource configuration (especially user mapping)
<http://syncope-user.1051894.n5.nabble.com/file/n5707406/usermapping.png>
4. input data of the user to which the LDAP resource is assigned
username
password
gidNumber (in syncope attributes)
givenname (same)
surname (same)
commonname (derived user attribute)
homedir (also derived)
PS the link to your vm demo
(http://syncope.tirasa.net/syncope/live/hctsite_en/common/virtual-machine.html)
does not seem to work anymore.
Kind regards,
Jeffrey Everling
--
View this message in context: http://syncope-user.1051894.n5.nabble.com/user-resource-removing-and-reassigning-tp5707401p5707406.html
Sent from the syncope-user mailing list archive at Nabble.com.
Re: user resource removing and reassigning
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 07/11/2013 23:52, jeverling wrote:
> Hello Ilgrosso,
>
> I thought you might be interested in this thing I discovered tonight.
>
> If I create a user and assign a resource (APDS with the LDAP connector)
> every goes well. I can change attributes of the user, activate and
> deactivate the user and every change shows up perfectly at APDS.
> When I remove the resource, it says that the entry is removed from the ldap.
> But it's still there.
> After reassigning the resource it gives the error below. In orde to fix the
> entry I have to completely remove the account and create it again. Just
> removing the LDAP entry doesn't suffice.
>
> The strange thing is... all goes well when i just delete the entire user.
> Then it is being removed properly.
> I did not found any related issue on this forum, so I thought you might be
> interested.
>
> Or is this a configuration issue? It did not seem that way, but correct me
> if I am wrong.
Hi,
de-assigning a resource from a user triggers removal from the actual
external resource (LDAP in your case): specifically for this type of
resource there are some integration tests proving that this should be
normally working, so it might be something in you specific use case
(configuration, input data, ...).
I invite you to compare your configuration with the one of the blog post
I've linked yesterday; anyway, please provide some more details to give
some more insight of your problem:
1. which LDAP server are you dealing with?
2. LDAP connector configuration
3. LDAP resource configuration (especially user mapping)
4. input data of the user to which the LDAP resource is assigned
Regards.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/