Hi everyone,

years ago, due to multiple problems in a migration, ISIM was set to point to an ldap that was "cryptographically unsynched".

Given that, I know that there are many users whose "erSynchPassword" is no more readable. In addition, user's password management has been externalized (to respect with ISIM) so password unreadability is not a problem.

Anyway, even when no lifecycle rule is running and ISIM seems to be 'idle', I can read lots and lots of decryption errors like this:

Every time an entity that contains an encrypted attribute the system will probably try to decrypt that attribute. 

So in this case there is an activity going on for the person mentioned. That can be regular handling of persons such as an DSML feed running - or you may have scheduled tasks in the RDBMS schedule that should have been cleaned up.

Anyway - you need to get these problems fixed - either by redoing the migration (probably too late) or fixing all the records - this is no easy task - my best advice is to open a support case and get some external help from e.g. IBM Expert Labs to help on what can be done... 

Hi everyone,

years ago, due to multiple problems in a migration, ISIM was set to point to an ldap that was "cryptographically unsynched".

Given that, I know that there are many users whose "erSynchPassword" is no more readable. In addition, user's password management has been externalized (to respect with ISIM) so password unreadability is not a problem.

Anyway, even when no lifecycle rule is running and ISIM seems to be 'idle', I can read lots and lots of decryption errors like this:

Ciao Franz, 

thank you for really fast answer.

In the meantime I've discovered who is triggering the decryption function: the 'search users' function in the administrative gui (/itim/console).

I don't know why, but it seems that ISIM tries to decypher the pwd attributes for every person returned.

Anyway, no problem (or at least, a solvable problem), knowing the root cause was in this case more important than the issue itself.

And, definitely, the old passwords must be fixed (or erased). I think a well designed assembly line could help.

Thank you!

Ciao 

Every time an entity that contains an encrypted attribute the system will probably try to decrypt that attribute. 

So in this case there is an activity going on for the person mentioned. That can be regular handling of persons such as an DSML feed running - or you may have scheduled tasks in the RDBMS schedule that should have been cleaned up.

Anyway - you need to get these problems fixed - either by redoing the migration (probably too late) or fixing all the records - this is no easy task - my best advice is to open a support case and get some external help from e.g. IBM Expert Labs to help on what can be done... 

Hi everyone,

years ago, due to multiple problems in a migration, ISIM was set to point to an ldap that was "cryptographically unsynched".

Given that, I know that there are many users whose "erSynchPassword" is no more readable. In addition, user's password management has been externalized (to respect with ISIM) so password unreadability is not a problem.

Anyway, even when no lifecycle rule is running and ISIM seems to be 'idle', I can read lots and lots of decryption errors like this:

Ciao Franz, 

thank you for really fast answer.

In the meantime I've discovered who is triggering the decryption function: the 'search users' function in the administrative gui (/itim/console).

I don't know why, but it seems that ISIM tries to decypher the pwd attributes for every person returned.

Anyway, no problem (or at least, a solvable problem), knowing the root cause was in this case more important than the issue itself.

And, definitely, the old passwords must be fixed (or erased). I think a well designed assembly line could help.

Thank you!

Ciao 

Every time an entity that contains an encrypted attribute the system will probably try to decrypt that attribute. 

So in this case there is an activity going on for the person mentioned. That can be regular handling of persons such as an DSML feed running - or you may have scheduled tasks in the RDBMS schedule that should have been cleaned up.

Anyway - you need to get these problems fixed - either by redoing the migration (probably too late) or fixing all the records - this is no easy task - my best advice is to open a support case and get some external help from e.g. IBM Expert Labs to help on what can be done... 

Hi everyone,

years ago, due to multiple problems in a migration, ISIM was set to point to an ldap that was "cryptographically unsynched".

Given that, I know that there are many users whose "erSynchPassword" is no more readable. In addition, user's password management has been externalized (to respect with ISIM) so password unreadability is not a problem.

Anyway, even when no lifecycle rule is running and ISIM seems to be 'idle', I can read lots and lots of decryption errors like this:

I forgot - do not use an SDI AL unless you use APIs to update the stuff.

You can write a custom operational person workflow that does the job and then roll it out using an LCR starting with a single (test) user....

Ciao Franz, 

thank you for really fast answer.

In the meantime I've discovered who is triggering the decryption function: the 'search users' function in the administrative gui (/itim/console).

I don't know why, but it seems that ISIM tries to decypher the pwd attributes for every person returned.

Anyway, no problem (or at least, a solvable problem), knowing the root cause was in this case more important than the issue itself.

And, definitely, the old passwords must be fixed (or erased). I think a well designed assembly line could help.

Thank you!

Ciao 

Every time an entity that contains an encrypted attribute the system will probably try to decrypt that attribute. 

So in this case there is an activity going on for the person mentioned. That can be regular handling of persons such as an DSML feed running - or you may have scheduled tasks in the RDBMS schedule that should have been cleaned up.

Anyway - you need to get these problems fixed - either by redoing the migration (probably too late) or fixing all the records - this is no easy task - my best advice is to open a support case and get some external help from e.g. IBM Expert Labs to help on what can be done... 

Hi everyone,

years ago, due to multiple problems in a migration, ISIM was set to point to an ldap that was "cryptographically unsynched".

Given that, I know that there are many users whose "erSynchPassword" is no more readable. In addition, user's password management has been externalized (to respect with ISIM) so password unreadability is not a problem.

Anyway, even when no lifecycle rule is running and ISIM seems to be 'idle', I can read lots and lots of decryption errors like this:

Good point: I don't want SDI to write a bunch of new "isim-unreadable" passwords. (I will not use api in this case)

Let ISIM do the crypto job.

Thank you again, you saved me a round of failed tests.

Ciao

I forgot - do not use an SDI AL unless you use APIs to update the stuff.

You can write a custom operational person workflow that does the job and then roll it out using an LCR starting with a single (test) user....

Ciao Franz, 

thank you for really fast answer.

In the meantime I've discovered who is triggering the decryption function: the 'search users' function in the administrative gui (/itim/console).

I don't know why, but it seems that ISIM tries to decypher the pwd attributes for every person returned.

Anyway, no problem (or at least, a solvable problem), knowing the root cause was in this case more important than the issue itself.

And, definitely, the old passwords must be fixed (or erased). I think a well designed assembly line could help.

Thank you!

Ciao 

Every time an entity that contains an encrypted attribute the system will probably try to decrypt that attribute. 

So in this case there is an activity going on for the person mentioned. That can be regular handling of persons such as an DSML feed running - or you may have scheduled tasks in the RDBMS schedule that should have been cleaned up.

Anyway - you need to get these problems fixed - either by redoing the migration (probably too late) or fixing all the records - this is no easy task - my best advice is to open a support case and get some external help from e.g. IBM Expert Labs to help on what can be done... 

Hi everyone,

years ago, due to multiple problems in a migration, ISIM was set to point to an ldap that was "cryptographically unsynched".

Given that, I know that there are many users whose "erSynchPassword" is no more readable. In addition, user's password management has been externalized (to respect with ISIM) so password unreadability is not a problem.

Anyway, even when no lifecycle rule is running and ISIM seems to be 'idle', I can read lots and lots of decryption errors like this:

Hello, 

You can remove these attributes from ldap with any ldap tool or SDIor a lifecycle like Franz pointed out already. Just remove from one person and/or account to see if any issue occurs. 

There is also erhistoricalpassword attribute on accounts. That stores the "previous passwords" user used.It's binary in format , maybe you would want to check these too.I am not sure this is affected by ldap encryption or encryption key of ISIM. <disregard if there is no log/error about this>

Either way, if you don't need these attributes or just want to clean them, you can remove any or all of these with lifecycles and using <entity>.removeProperty(). Just a script and modify account box would be enough. While doing with SDI you have to return null and use null behaviours. LC is easier but slower mostly. 

If you have passwords -somehow :) -, you can also re-fill "ersyncpassword" if you need them via .setAndEncryptPassword() and another lifecycle. We have used this method and its decryptor (getAndDecrypt) to transfer passwords between two systems for example. 

erPersonPassword is the same it's used when pass sync is disabled. But it can stay there even if you change the setting. A person can have both because of this. 

Hope these helps. 

Good point: I don't want SDI to write a bunch of new "isim-unreadable" passwords. (I will not use api in this case)

Let ISIM do the crypto job.

Thank you again, you saved me a round of failed tests.

Ciao

I forgot - do not use an SDI AL unless you use APIs to update the stuff.

You can write a custom operational person workflow that does the job and then roll it out using an LCR starting with a single (test) user....

Ciao Franz, 

thank you for really fast answer.

In the meantime I've discovered who is triggering the decryption function: the 'search users' function in the administrative gui (/itim/console).

I don't know why, but it seems that ISIM tries to decypher the pwd attributes for every person returned.

Anyway, no problem (or at least, a solvable problem), knowing the root cause was in this case more important than the issue itself.

And, definitely, the old passwords must be fixed (or erased). I think a well designed assembly line could help.

Thank you!

Ciao 

Every time an entity that contains an encrypted attribute the system will probably try to decrypt that attribute. 

So in this case there is an activity going on for the person mentioned. That can be regular handling of persons such as an DSML feed running - or you may have scheduled tasks in the RDBMS schedule that should have been cleaned up.

Anyway - you need to get these problems fixed - either by redoing the migration (probably too late) or fixing all the records - this is no easy task - my best advice is to open a support case and get some external help from e.g. IBM Expert Labs to help on what can be done... 

Hi everyone,

years ago, due to multiple problems in a migration, ISIM was set to point to an ldap that was "cryptographically unsynched".

Given that, I know that there are many users whose "erSynchPassword" is no more readable. In addition, user's password management has been externalized (to respect with ISIM) so password unreadability is not a problem.

Anyway, even when no lifecycle rule is running and ISIM seems to be 'idle', I can read lots and lots of decryption errors like this:

If you are using defaults the historical passwords are hashed - not encrypted. They are normally only used in password policies to ensure that you are not reusing an old password.

I have never tried just to delete the ersynchpassword - that may be a simple solution - but I would definitely do thoroughly test of password/suspend/restore/account creation to verify that the system is able to handle the missing attribute.

Also be aware you may also have issues with all your services if you haven't already changed passwords there...

Hello, 

You can remove these attributes from ldap with any ldap tool or SDIor a lifecycle like Franz pointed out already. Just remove from one person and/or account to see if any issue occurs. 

There is also erhistoricalpassword attribute on accounts. That stores the "previous passwords" user used.It's binary in format , maybe you would want to check these too.I am not sure this is affected by ldap encryption or encryption key of ISIM. <disregard if there is no log/error about this>

Either way, if you don't need these attributes or just want to clean them, you can remove any or all of these with lifecycles and using <entity>.removeProperty(). Just a script and modify account box would be enough. While doing with SDI you have to return null and use null behaviours. LC is easier but slower mostly. 

If you have passwords -somehow :) -, you can also re-fill "ersyncpassword" if you need them via .setAndEncryptPassword() and another lifecycle. We have used this method and its decryptor (getAndDecrypt) to transfer passwords between two systems for example. 

erPersonPassword is the same it's used when pass sync is disabled. But it can stay there even if you change the setting. A person can have both because of this. 

Hope these helps. 

Good point: I don't want SDI to write a bunch of new "isim-unreadable" passwords. (I will not use api in this case)

Let ISIM do the crypto job.

Thank you again, you saved me a round of failed tests.

Ciao

I forgot - do not use an SDI AL unless you use APIs to update the stuff.

You can write a custom operational person workflow that does the job and then roll it out using an LCR starting with a single (test) user....

Ciao Franz, 

thank you for really fast answer.

In the meantime I've discovered who is triggering the decryption function: the 'search users' function in the administrative gui (/itim/console).

I don't know why, but it seems that ISIM tries to decypher the pwd attributes for every person returned.

Anyway, no problem (or at least, a solvable problem), knowing the root cause was in this case more important than the issue itself.

And, definitely, the old passwords must be fixed (or erased). I think a well designed assembly line could help.

Thank you!

Ciao 

Every time an entity that contains an encrypted attribute the system will probably try to decrypt that attribute. 

So in this case there is an activity going on for the person mentioned. That can be regular handling of persons such as an DSML feed running - or you may have scheduled tasks in the RDBMS schedule that should have been cleaned up.

Anyway - you need to get these problems fixed - either by redoing the migration (probably too late) or fixing all the records - this is no easy task - my best advice is to open a support case and get some external help from e.g. IBM Expert Labs to help on what can be done... 

Hi everyone,

years ago, due to multiple problems in a migration, ISIM was set to point to an ldap that was "cryptographically unsynched".

Given that, I know that there are many users whose "erSynchPassword" is no more readable. In addition, user's password management has been externalized (to respect with ISIM) so password unreadability is not a problem.

Anyway, even when no lifecycle rule is running and ISIM seems to be 'idle', I can read lots and lots of decryption errors like this: