On 15/02/2017 13:56, Tech wrote:
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
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!
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
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
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
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'
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:
>>
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
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
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
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
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
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
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
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
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
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,
17 matches
Mail list logo
