We are associating using a manual provisioning Here the main information:
Connector version 1.3.2 -SSL enabled -Retrieve deleted users enabled -Retrieve deleted groups enabled -Trust all certs enabled Entry object classes: -Top -person -organizationalPerson -inetOrgPerson -user Custom user search filter cn=* Rootsuffixes + base contexts + defaul people container: ou=myad,dc=test,dc=local uidAttribute - cn Object clases to synchronize - user Resource: username -> cn (remote key) password -> __PASSWORD__ (Password) email -> mail fn -> givenName ln -> sn username -> sAMAccountName Object link 'CN='+username+',OU=myad,dc=test,dc=local' Push tasks: Active Matching rule : Update Unmatching rule: provision Allow Create, update, delete, sync status On 30/01/2017 15:01, Francesco Chicchiriccò wrote: > On 30/01/2017 14:53, Tech wrote: >> This is what happen when I open the Password Manager, while when I >> update the password no log is generated. > > This is what I suspected: you could definitely find a confirmation if > you are able to verify that the user on Active Directory has still the > password set during create (while on Syncope the password value was > changed). > > How are you associating the users to the AD resource? Directly or via > group? Could you please enlist your full connector configuration (with > *all* options) and resource mapping? Screenshots will also work via > http://pasteboard.co/, for example. > > Regards. > >> 13:43:57.477 DEBUG Enter: getObject(ObjectClass: __ACCOUNT__, >> Attribute: {Name=__UID__, Value=[user07]}, OperationOptions: >> {ATTRS_TO_GET:[__PASSWORD__,mail,sAMAccountName,givenName,__NAME__,cn,sn,__UID__,__ENABLE__]}) >> Method: getObject >> 13:43:57.477 DEBUG Enter: executeQuery(ObjectClass: __ACCOUNT__, >> LdapFilter[nativeFilter: (cn=user07); entryDN: null], >> org.identityconnectors.framework.impl.api.local.operations.SearchImpl$1@3c72ca1f, >> OperationOptions: >> {ATTRS_TO_GET:[__PASSWORD__,mail,sAMAccountName,givenName,__NAME__,cn,sn,__UID__,__ENABLE__]}) >> Method: executeQuery >> 13:43:57.478 WARN Reading passwords not supported Method: >> getAttributesToGet >> 13:43:57.478 WARN Attribute __ENABLE__ of object class __ACCOUNT__ >> is not mapped to an LDAP attribute Method: getLdapAttribute >> 13:43:57.478 DEBUG Options filter: {0} null Method: getInternalSearch >> 13:43:57.478 DEBUG Search filter: {0} cn=* Method: getInternalSearch >> 13:43:57.478 DEBUG Native filter: {0} (cn=user07) Method: >> getInternalSearch >> 13:43:57.478 DEBUG Membership filter: {0} Method: getInternalSearch >> 13:43:57.478 DEBUG Searching in [OU=myad,DC=test,DC=local] with >> filter >> (&(&(objectClass=top)(objectClass=person)(objectClass=organizationalPerson)(objectClass=user))(cn=user07)(cn=*)) >> and SearchControls: {returningAttributes=[cn, entryDN, givenName, >> mail, sAMAccountName, sn, unicodePwd, userAccountControl], >> scope=SUBTREE} Method: doSearch >> 13:43:57.479 DEBUG User Account Control: 512 Method: >> createConnectorObject >> 13:43:57.479 DEBUG Enter: {Uid=Attribute: {Name=__UID__, >> Value=[user07]}, ObjectClass=ObjectClass: __ACCOUNT__, >> Attributes=[Attribute: {Name=__PASSWORD__, >> Value=[org.identityconnectors.common.security.GuardedString@204e249b]}, >> Attribute: {Name=userAccountControl, Value=[512]}, Attribute: >> {Name=sAMAccountName, Value=[user07]}, Attribute: {Name=mail, >> Value=[user07@test.local]}, Attribute: {Name=__NAME__, >> Value=[CN=user07,OU=myad,DC=test,DC=local]}, Attribute: {Name=cn, >> Value=[user07]}, Attribute: {Name=sn, Value=[oln07updated]}, >> Attribute: {Name=__UID__, Value=[user07]}, Attribute: >> {Name=__ENABLE__, Value=[true]}, Attribute: {Name=givenName, >> Value=[ofn07updated]}], Name=Attribute: {Name=__NAME__, >> Value=[CN=user07,OU=myad,DC=test,DC=local]}} Method: handle >> 13:43:57.479 DEBUG Return: false Method: handle >> 13:43:57.479 DEBUG Return Method: executeQuery >> 13:43:57.480 DEBUG Return: {Uid=Attribute: {Name=__UID__, >> Value=[user07]}, ObjectClass=ObjectClass: __ACCOUNT__, >> Attributes=[Attribute: {Name=__PASSWORD__, >> Value=[org.identityconnectors.common.security.GuardedString@204e249b]}, >> Attribute: {Name=sAMAccountName, Value=[user07]}, Attribute: >> {Name=mail, Value=[user07@test.local]}, Attribute: {Name=__NAME__, >> Value=[CN=user07,OU=myad,DC=test,DC=local]}, Attribute: {Name=cn, >> Value=[user07]}, Attribute: {Name=sn, Value=[oln07updated]}, >> Attribute: {Name=__UID__, Value=[user07]}, Attribute: >> {Name=__ENABLE__, Value=[true]}, Attribute: {Name=givenName, >> Value=[ofn07updated]}], Name=Attribute: {Name=__NAME__, >> Value=[CN=user07,OU=myad,DC=test,DC=local]}} Method: getObject >> >> On 30/01/2017 14:36, Francesco Chicchiriccò wrote: >>> On 30/01/2017 12:34, Tech wrote: >>>> When we create the user we are able to initialize the correct >>>> password, connecting to the target system we can verify that >>>> Syncope did its job. >>>> >>>> If the Admin tries to reset the password from the console, or if >>>> the user tries to change is password from the enduser interface, >>>> the password is still correctly updated into Syncope, but it's not >>>> propagated to AD, therefore the user will be able to login only >>>> using the old password. >>> >>> Hi, >>> I am not completely familiar with AD password management internals, >>> but I would examine what Syncope is actually sending to AD by >>> watching the core-connid.log file both when creating new user and >>> updating existing user, to determine if Syncope is effectively >>> sending the updated password to AD during the latter phase. >>> >>> Regards. >>> >>>> On 30/01/2017 12:28, Tech wrote: >>>>> I'm not sure about this step. >>>>> >>>>> As mentioned we can already propagate changes as "email, "first >>>>> name" and "last name". >>>>> >>>>> The AD user that we are using is able to change the passwords of >>>>> other AD users, create, update and delete other users. >>>>> >>>>> I think that there is an additional step that was not performed in >>>>> Syncope. >>>>> >>>>> On 27/01/2017 16:32, Fabio Martelli wrote: >>>>>> Il 27/01/2017 15:53, Tech ha scritto: >>>>>>> Yes, we are connecting via SSL. >>>>>>> >>>>>>> We know that the connection is working because we are still able >>>>>>> to propagate the user modification like firstname and lastname. >>>>>>> >>>>>>> We can change the password and internally is working, but it's >>>>>>> not propagated to AD. >>>>>> When you performed the change password by using the >>>>>> administration console, did you select AD resource in the list >>>>>> provided after password fields? >>>>>> Are you sure that the user principal configured to perform >>>>>> updates into AD owns all the needed entitlements? >>>>>>> >>>>>>> the On 27/01/2017 15:42, Fabio Martelli wrote: >>>>>>>> Hi, find my comment in-line. >>>>>>>> Regards, >>>>>>>> F. >>>>>>>> >>>>>>>> Il 27/01/2017 12:12, Tech ha scritto: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> we are working on the password propagation using the AD connector. >>>>>>>>> >>>>>>>>> We are able to check the connectivity both using plain and >>>>>>>>> SSL, we are able to create new users and to update information >>>>>>>>> like email, first name and last name. >>>>>>>>> >>>>>>>>> We edit the connector: >>>>>>>>> >>>>>>>>> * We check SSL >>>>>>>>> * we change the Server port to 636 >>>>>>>>> * We enable Trust all certs >>>>>>>>> >>>>>>>>> We run again some modification and the first name and last >>>>>>>>> name are still updated. >>>>>>>>> >>>>>>>>> We try now to change the password, both from user and admin >>>>>>>>> interface. >>>>>>>>> >>>>>>>>> The user can correctly access to Syncope using the new >>>>>>>>> credentials, while we detect that the password is not >>>>>>>>> correctly propagated to the target system. >>>>>>>>> >>>>>>>> >>>>>>>> Do you mean that you can still access with the previous one? >>>>>>>> Please note that you can change password by working in SSL only >>>>>>>> [1]. >>>>>>>> >>>>>>>> Regards, >>>>>>>> F. >>>>>>>> >>>>>>>> [1] >>>>>>>> https://connid.atlassian.net/wiki/pages/viewpage.action?pageId=360482#ActiveDirectory(JNDI)-Configuration > -- > Francesco Chicchiriccò > > Tirasa - Open Source Excellence > http://www.tirasa.net/ > > Member at The Apache Software Foundation > Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail > http://home.apache.org/~ilgrosso/
