Yes, I can confirm, right in this moment we are only performing manual provisioning.
This is of course not the goal, but before moving to an automatic provision of accounts we want the manual one working On 30/01/2017 15:14, Francesco Chicchiriccò wrote: > On 30/01/2017 15:11, Tech wrote: >> We are associating using a manual provisioning > > Do you mean that you are only relying on a push task for provisioning > to AD? > > Could you confirm that you are *not* assigning the AD resource > directly to the users, neither via group membership or template? > >> 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/
