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/