You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@syncope.apache.org by Tech <te...@psynd.net> on 2017/01/27 11:12:40 UTC
Active Directory password propagation
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.
Any clues?
Thanks!
Re: Active Directory password propagation
Posted by Fabio Martelli <fa...@gmail.com>.
Il 27/01/2017 16:32, Fabio Martelli ha scritto:
> 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?
Furthermore, please check into AD resource user mapping configuration:
be sure about the correctness of the mapping provided for the password.
You can attach a screenshot of your user mapping if you need my opinion
about.
Regards,
F.
>>
>>
>>
>>
>>
>>
>> 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
>>>
>>>
>>>> Any clues?
>>>>
>>>> Thanks!
>>>>
>>>
>>>
>>> --
>>> Fabio Martelli
>>> https://it.linkedin.com/pub/fabio-martelli/1/974/a44
>>> http://blog.tirasa.net/author/fabio/index.html
>>>
>>> Tirasa - Open Source Excellence
>>> http://www.tirasa.net/
>>>
>>> Apache Syncope PMC
>>> http://people.apache.org/~fmartelli/
>>
>>
>
>
> --
> Fabio Martelli
> https://it.linkedin.com/pub/fabio-martelli/1/974/a44
> http://blog.tirasa.net/author/fabio/index.html
>
> Tirasa - Open Source Excellence
> http://www.tirasa.net/
>
> Apache Syncope PMC
> http://people.apache.org/~fmartelli/
--
Fabio Martelli
https://it.linkedin.com/pub/fabio-martelli/1/974/a44
http://blog.tirasa.net/author/fabio/index.html
Tirasa - Open Source Excellence
http://www.tirasa.net/
Apache Syncope PMC
http://people.apache.org/~fmartelli/
RE: Active Directory password propagation
Posted by Anas Asharat <an...@omnix.ae>.
Dear Francesco,
Can you please send me your phone or any communication tools like Skype,
Am sorry but I get more confused.
Regard,
Anas Sharat
From: Francesco Chicchiriccò [mailto:ilgrosso@apache.org]
Sent: Tuesday, January 31, 2017 1:03 PM
To: user@syncope.apache.org
Subject: Re: Active Directory password propagation
On 30/01/2017 16:02, Tech wrote:
The value in 'password.cipher.algorithm' was SHA1.
We updated to AES, we changed again the password for the user and we tried to login again to the enduser portal.
It's working, we tried to connect to AD but without success.
We realized after that the password, with a difference with the other fields, is not immediately propagate when changed, but it's only propagated by the scheduler.
No, this is not correct. The password is always sent along with all other attributes, both during propagation (automated provisioning) or push (manual provisioning).
The only difference is that, since the password values are never stored as cleartext into the internal storage, the actual value is available during propagation but must be retrieved from the internal storage during push. When using AES, the encrypted value from the internal storage can be decrypted and sent to AD.
Now, there could always be some bug that prevents the push flow to correctly retrieve and send password values: as soon as I'll have some available slots, I could take a look at this.
Regards.
On 30/01/2017 15:24, Francesco Chicchiriccò wrote:
On 30/01/2017 15:18, Tech wrote:
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
What is your value for the 'password.cipher.algorithm' general configuration parameter? If not 'AES', pushing password values (as any other encrypted value) will not work anyway.
The point is that Active Directory requires cleartext password values (encrypted via ConnId's GuardedString), which are normally available only during user update, not later. This unless AES (e.g. reversible encryption) is set for internal password values.
Provisioning - via resource assignment - is part of user update, push occurs after user update.
Regards.
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<ma...@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<ma...@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<ma...@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<https://connid.atlassian.net/wiki/pages/viewpage.action?pageId=360482#ActiveDirectory%28JNDI%29-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/
This e-mail may contain information that is proprietary, confidential or otherwise protected from disclosure and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient(s) is strictly prohibited. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
Re: Active Directory password propagation
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 30/01/2017 16:02, Tech wrote:
> The value in 'password.cipher.algorithm' was SHA1.
>
> We updated to AES, we changed again the password for the user and we
> tried to login again to the enduser portal.
>
> It's working, we tried to connect to AD but without success.
>
> We realized after that the password, with a difference with the other
> fields, is not immediately propagate when changed, but it's only
> propagated by the scheduler.
No, this is not correct. The password is always sent along with all
other attributes, both during propagation (automated provisioning) or
push (manual provisioning).
The only difference is that, since the password values are never stored
as cleartext into the internal storage, the actual value is available
during propagation but must be retrieved from the internal storage
during push. When using AES, the encrypted value from the internal
storage can be decrypted and sent to AD.
Now, there could always be some bug that prevents the push flow to
correctly retrieve and send password values: as soon as I'll have some
available slots, I could take a look at this.
Regards.
> On 30/01/2017 15:24, Francesco Chicchiricc� wrote:
>> On 30/01/2017 15:18, Tech wrote:
>>> 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
>>
>> What is your value for the 'password.cipher.algorithm' general
>> configuration parameter? If not 'AES', pushing password values (as
>> any other encrypted value) will not work anyway.
>>
>> The point is that Active Directory requires cleartext password values
>> (encrypted via ConnId's GuardedString), which are normally available
>> only during user update, not later. This unless AES (e.g. reversible
>> encryption) is set for internal password values.
>> Provisioning - via resource assignment - is part of user update, push
>> occurs after user update.
>>
>> Regards.
>>
>>> 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/
Re: Active Directory password propagation
Posted by Tech <te...@psynd.net>.
Hello,
actually that field at that stage was not flagged.
Checking them it's now working, but was generated confusion is that
without checking them, the other information as FirstName, LastName etc
are propagated.
Is there a way to keep as default the check [v] active?
Thanks for the support!
On 15/02/2017 12:07, Andrea Patricelli wrote:
>
> Good morning,
>
> we made a double check and password propagation on Active Directory
> was successful.
>
> In the user edit form (first tab of the wizard), beneath password and
> confirm password text areas, there are two (or more) checkboxes
> (depends on the number of resources associated to the user), have you
> flagged the AD checkbox?
> Please see image at [1].
>
> HTH,
> Andrea
>
> [1] https://ibin.co/3CTCYNjuyWT7.png
>
> Il 13/02/2017 14:52, Tech ha scritto:
>> Dear experts,
>>
>> We guess that there is a bug in the AD connector.
>>
>> 1. We are able to set in SSL the connection
>> 2. we can create a user with a chosen password
>> 3. we login with success to the system using the chosen password
>> 4. we try to change any value from the user interface and these
>> changes are immediately reflected to the AD
>> 5. we change the password, but it is not propagated
>> 6. we change the first name and it's correctly propagated, but the
>> password is not
>> 7. we try to manually run the PushTask, and only in this case the
>> password is correctly propagated
>>
>> We are able to automatically propagate all fields except the password
>> (that requires a manual propagation), could you please double check?
>>
>> Thanks
>>
>>
>>
>>
>> On 30/01/2017 16:02, Tech wrote:
>>> The value in 'password.cipher.algorithm' was SHA1.
>>>
>>> We updated to AES, we changed again the password for the user and we
>>> tried to login again to the enduser portal.
>>>
>>> It's working, we tried to connect to AD but without success.
>>>
>>> We realized after that the password, with a difference with the
>>> other fields, is not immediately propagate when changed, but it's
>>> only propagated by the scheduler.
>>>
>>> Can this be changed?
>>>
>>> Thanks for your support
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 30/01/2017 15:24, Francesco Chicchiricc� wrote:
>>>> On 30/01/2017 15:18, Tech wrote:
>>>>> 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
>>>>
>>>> What is your value for the 'password.cipher.algorithm' general
>>>> configuration parameter? If not 'AES', pushing password values (as
>>>> any other encrypted value) will not work anyway.
>>>>
>>>> The point is that Active Directory requires cleartext password
>>>> values (encrypted via ConnId's GuardedString), which are normally
>>>> available only during user update, not later. This unless AES (e.g.
>>>> reversible encryption) is set for internal password values.
>>>> Provisioning - via resource assignment - is part of user update,
>>>> push occurs after user update.
>>>>
>>>> Regards.
>>>>
>>>>> 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/
>>>
>>>
>>
>
> --
> Andrea Patricelli
>
> Tirasa - Open Source Excellence
> http://www.tirasa.net/
>
> Member at The Apache Software Foundation
> Syncope
Re: Active Directory password propagation
Posted by Andrea Patricelli <an...@apache.org>.
Good morning,
we made a double check and password propagation on Active Directory was
successful.
In the user edit form (first tab of the wizard), beneath password and
confirm password text areas, there are two (or more) checkboxes (depends
on the number of resources associated to the user), have you flagged the
AD checkbox?
Please see image at [1].
HTH,
Andrea
[1] https://ibin.co/3CTCYNjuyWT7.png
Il 13/02/2017 14:52, Tech ha scritto:
> Dear experts,
>
> We guess that there is a bug in the AD connector.
>
> 1. We are able to set in SSL the connection
> 2. we can create a user with a chosen password
> 3. we login with success to the system using the chosen password
> 4. we try to change any value from the user interface and these
> changes are immediately reflected to the AD
> 5. we change the password, but it is not propagated
> 6. we change the first name and it's correctly propagated, but the
> password is not
> 7. we try to manually run the PushTask, and only in this case the
> password is correctly propagated
>
> We are able to automatically propagate all fields except the password
> (that requires a manual propagation), could you please double check?
>
> Thanks
>
>
>
>
> On 30/01/2017 16:02, Tech wrote:
>> The value in 'password.cipher.algorithm' was SHA1.
>>
>> We updated to AES, we changed again the password for the user and we
>> tried to login again to the enduser portal.
>>
>> It's working, we tried to connect to AD but without success.
>>
>> We realized after that the password, with a difference with the other
>> fields, is not immediately propagate when changed, but it's only
>> propagated by the scheduler.
>>
>> Can this be changed?
>>
>> Thanks for your support
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 30/01/2017 15:24, Francesco Chicchiriccò wrote:
>>> On 30/01/2017 15:18, Tech wrote:
>>>> 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
>>>
>>> What is your value for the 'password.cipher.algorithm' general
>>> configuration parameter? If not 'AES', pushing password values (as
>>> any other encrypted value) will not work anyway.
>>>
>>> The point is that Active Directory requires cleartext password
>>> values (encrypted via ConnId's GuardedString), which are normally
>>> available only during user update, not later. This unless AES (e.g.
>>> reversible encryption) is set for internal password values.
>>> Provisioning - via resource assignment - is part of user update,
>>> push occurs after user update.
>>>
>>> Regards.
>>>
>>>> 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/
>>
>>
>
--
Andrea Patricelli
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope
Re: Active Directory password propagation
Posted by Tech <te...@psynd.net>.
Dear experts,
We guess that there is a bug in the AD connector.
1. We are able to set in SSL the connection
2. we can create a user with a chosen password
3. we login with success to the system using the chosen password
4. we try to change any value from the user interface and these changes
are immediately reflected to the AD
5. we change the password, but it is not propagated
6. we change the first name and it's correctly propagated, but the
password is not
7. we try to manually run the PushTask, and only in this case the
password is correctly propagated
We are able to automatically propagate all fields except the password
(that requires a manual propagation), could you please double check?
Thanks
On 30/01/2017 16:02, Tech wrote:
> The value in 'password.cipher.algorithm' was SHA1.
>
> We updated to AES, we changed again the password for the user and we
> tried to login again to the enduser portal.
>
> It's working, we tried to connect to AD but without success.
>
> We realized after that the password, with a difference with the other
> fields, is not immediately propagate when changed, but it's only
> propagated by the scheduler.
>
> Can this be changed?
>
> Thanks for your support
>
>
>
>
>
>
>
>
>
> On 30/01/2017 15:24, Francesco Chicchiricc� wrote:
>> On 30/01/2017 15:18, Tech wrote:
>>> 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
>>
>> What is your value for the 'password.cipher.algorithm' general
>> configuration parameter? If not 'AES', pushing password values (as
>> any other encrypted value) will not work anyway.
>>
>> The point is that Active Directory requires cleartext password values
>> (encrypted via ConnId's GuardedString), which are normally available
>> only during user update, not later. This unless AES (e.g. reversible
>> encryption) is set for internal password values.
>> Provisioning - via resource assignment - is part of user update, push
>> occurs after user update.
>>
>> Regards.
>>
>>> 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/
>
>
Re: Active Directory password propagation
Posted by Tech <te...@psynd.net>.
The value in 'password.cipher.algorithm' was SHA1.
We updated to AES, we changed again the password for the user and we
tried to login again to the enduser portal.
It's working, we tried to connect to AD but without success.
We realized after that the password, with a difference with the other
fields, is not immediately propagate when changed, but it's only
propagated by the scheduler.
Can this be changed?
Thanks for your support
On 30/01/2017 15:24, Francesco Chicchiricc� wrote:
> On 30/01/2017 15:18, Tech wrote:
>> 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
>
> What is your value for the 'password.cipher.algorithm' general
> configuration parameter? If not 'AES', pushing password values (as any
> other encrypted value) will not work anyway.
>
> The point is that Active Directory requires cleartext password values
> (encrypted via ConnId's GuardedString), which are normally available
> only during user update, not later. This unless AES (e.g. reversible
> encryption) is set for internal password values.
> Provisioning - via resource assignment - is part of user update, push
> occurs after user update.
>
> Regards.
>
>> 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/
Re: Active Directory password propagation
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 30/01/2017 15:18, Tech wrote:
> 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
What is your value for the 'password.cipher.algorithm' general
configuration parameter? If not 'AES', pushing password values (as any
other encrypted value) will not work anyway.
The point is that Active Directory requires cleartext password values
(encrypted via ConnId's GuardedString), which are normally available
only during user update, not later. This unless AES (e.g. reversible
encryption) is set for internal password values.
Provisioning - via resource assignment - is part of user update, push
occurs after user update.
Regards.
> 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/
Re: Active Directory password propagation
Posted by Tech <te...@psynd.net>.
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/
Re: Active Directory password propagation
Posted by Francesco Chicchiriccò <il...@apache.org>.
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/
Re: Active Directory password propagation
Posted by Tech <te...@psynd.net>.
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/
Re: Active Directory password propagation
Posted by Francesco Chicchiriccò <il...@apache.org>.
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/
Re: Active Directory password propagation
Posted by Tech <te...@psynd.net>.
This is what happen when I open the Password Manager, while when I
update the password no log is generated.
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/
Re: Active Directory password propagation
Posted by Francesco Chicchiriccò <il...@apache.org>.
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/
Re: Active Directory password propagation
Posted by Tech <te...@psynd.net>.
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.
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
>>>>
>>>>
>>>>> Any clues?
>>>>>
>>>>> Thanks!
>>>>>
>>>>
>>>>
>>>> --
>>>> Fabio Martelli
>>>> https://it.linkedin.com/pub/fabio-martelli/1/974/a44
>>>> http://blog.tirasa.net/author/fabio/index.html
>>>>
>>>> Tirasa - Open Source Excellence
>>>> http://www.tirasa.net/
>>>>
>>>> Apache Syncope PMC
>>>> http://people.apache.org/~fmartelli/
>>>
>>>
>>
>>
>> --
>> Fabio Martelli
>> https://it.linkedin.com/pub/fabio-martelli/1/974/a44
>> http://blog.tirasa.net/author/fabio/index.html
>>
>> Tirasa - Open Source Excellence
>> http://www.tirasa.net/
>>
>> Apache Syncope PMC
>> http://people.apache.org/~fmartelli/
>
>
Re: Active Directory password propagation
Posted by Tech <te...@psynd.net>.
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
>>>
>>>
>>>> Any clues?
>>>>
>>>> Thanks!
>>>>
>>>
>>>
>>> --
>>> Fabio Martelli
>>> https://it.linkedin.com/pub/fabio-martelli/1/974/a44
>>> http://blog.tirasa.net/author/fabio/index.html
>>>
>>> Tirasa - Open Source Excellence
>>> http://www.tirasa.net/
>>>
>>> Apache Syncope PMC
>>> http://people.apache.org/~fmartelli/
>>
>>
>
>
> --
> Fabio Martelli
> https://it.linkedin.com/pub/fabio-martelli/1/974/a44
> http://blog.tirasa.net/author/fabio/index.html
>
> Tirasa - Open Source Excellence
> http://www.tirasa.net/
>
> Apache Syncope PMC
> http://people.apache.org/~fmartelli/
Re: Active Directory password propagation
Posted by Fabio Martelli <fa...@gmail.com>.
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
>>
>>
>>> Any clues?
>>>
>>> Thanks!
>>>
>>
>>
>> --
>> Fabio Martelli
>> https://it.linkedin.com/pub/fabio-martelli/1/974/a44
>> http://blog.tirasa.net/author/fabio/index.html
>>
>> Tirasa - Open Source Excellence
>> http://www.tirasa.net/
>>
>> Apache Syncope PMC
>> http://people.apache.org/~fmartelli/
>
>
--
Fabio Martelli
https://it.linkedin.com/pub/fabio-martelli/1/974/a44
http://blog.tirasa.net/author/fabio/index.html
Tirasa - Open Source Excellence
http://www.tirasa.net/
Apache Syncope PMC
http://people.apache.org/~fmartelli/
Re: Active Directory password propagation
Posted by Tech <te...@psynd.net>.
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.
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
>
>
>> Any clues?
>>
>> Thanks!
>>
>
>
> --
> Fabio Martelli
> https://it.linkedin.com/pub/fabio-martelli/1/974/a44
> http://blog.tirasa.net/author/fabio/index.html
>
> Tirasa - Open Source Excellence
> http://www.tirasa.net/
>
> Apache Syncope PMC
> http://people.apache.org/~fmartelli/
Re: Active Directory password propagation
Posted by Fabio Martelli <fa...@gmail.com>.
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
> Any clues?
>
> Thanks!
>
--
Fabio Martelli
https://it.linkedin.com/pub/fabio-martelli/1/974/a44
http://blog.tirasa.net/author/fabio/index.html
Tirasa - Open Source Excellence
http://www.tirasa.net/
Apache Syncope PMC
http://people.apache.org/~fmartelli/