IAS/IPS: All passwords lost after a full resync?

[stianbl]

Hi,
I'd like to understand how password (or the user account) is handled in IAS, in case of a full resync, or a filter which excludes all users are set and a full read is done.

So we've got the following:
-IAS/IPS Set up for all internals.
-IAS/IPS Set up for all External Learners*

*Previously, these where Integrated External Learners. Which means they where External Learners, but authenticate through BizX (Logon through external LMS Site). Anyways, these are migrated to IAS now

So, my question is:

If I happen to enter a invalid filter condition in IPS for internals or externals, and a read/resync job is run. All users are removed? Are also all passwords lost forever then? So a simple typo in the user.filter could render all our ~50.000 users loosing their passwords? Or are they simply "inactivated and hidden" and "restored" if I then correct the filter and do a new read job, and these same users are now back in IAS. As in, are all data lost immediately, or will it remember it?

(I guess for migrated external LMS users, where they still have not signed in first time, password is still in BizX, so it will be remembered. But for the rest. Migrated users, and users living only in LMS-IAS).

Hope to get some clarification on this, as it seems very vulnerable if all is lost with a small error like that?

Thanks in advance for any insight!

[khbayne]

Hi there. I believe you have multiple questions here, but just a quick clarification...

Do you have external LMS users set to "external" in LMS?

[istvanbokor · Accepted solution]

Hello,

When you filter for for example active users on the source system, IPS will provision and keep those users on the target. If one user becomes inactive on the source next time - to keep the data accurate - the user will be deleted from the target.

Therefore if you change the filter, and instead of filtering for only one user, that user will be kept and other users will be deleted, since this is what you specified.

I understand this can cause issues, but I can see several options meanwhile to avoid this:

1.

You can control the number of users, groups or roles to be deleted in a target system by defining a threshold. This will prevent you from accidentally deleting a huge number of entities, for example by adding a filter or condition. If the number of the entities to be deleted is greater than the defined threshold, Identity Provisioning will mark them as failed in the job statistics and will not delete them.

For more information, see List of Properties → ips.delete.threshold.users, ips.delete.threshold.groups and ips.delete.threshold.roles.

2.

You can simulate a provisioning job before you actually run it. Simulating a provisioning job allows you to test your Identity Provisioning configurations and see whether they produce the desired result in the target system.

For more information, see Simulate Provisioning Jobs

Best regards,
István

[stianbl]

Awesome, thanks a lot for a great answer! I will read up on the provided topics!