Hi guys,
thank both for your valuable opinions.
On the one hand, the reconciliation not just has to collect the attributes which you are going to enforce their values by provisioning policies, it could be used for deploying additional business logic, by means of life cycle rule, for instance. The best example of this kind of attributes is the erlastaccessdate which it is used to identify the dormant accounts. Thus, the exclusion in the reconciliation is not a solution.
Following this example, the erlastaccessdate is a read-only attribute, ie, its value will be "always" modified during a reconciliation process, so, it makes no sense to set the "Unknown" status for changing in this attribute. Some statement could be said with erlastchangepassworddate, ....
On the other hand, I totally agree that when provisioning policies are not enforced during a reconciliation, we are just only delaying when the policies are evaluated, but, I am sure you have the same opinion, a reconciliation process with policy evaluation is could be very dangerous process since a huge number of accounts could be modified by batch process.
As a summary, it could be said that we like to work with services in a "Correct" policies enforcement configuration when we are working with online process (it is mandatory in a RBAC model), but "Mark" or "Alert" policies enforcement configuration when the evaluation is done by batch process (reconciliation mainly). Thus, it is not a issue of spread of workload, just only a conservative attitude. It makes sense, doesn't it?
Taking into consideration we are just reconciling the account attributes which we are interested to manage, for enforcing values or deploying business logics, and, besides those attributes are not administrated in the target system (ISIM is the only responsible for managing them), the "Unknown" status is a way to identify "exceptional" situations. The only problem in this approach is that the "read-only" and the "Default" attributes modification generate "Unknown" status.
BTW: in our deployment a service reconciliation can only be executed by ISIM administrators.
------------------------------
Felipe Risalde Serrano
Security Expert
Banco de España
------------------------------
Original Message:
Sent: Fri January 24, 2020 02:19 AM
From: Franz Wolfhagen
Subject: Avoid the accounts will be marked as status 'Unknown' when the modified attributes are some of which we are not interested to enforce
Let me add my thoughts on top of Grey's excellent points...
I think you are going in the wrong direction here - the core functionality of ISIM is basically 2 things - closed loop provisioning with policy evaluation and rich operational workflows.
Doing reconciliations without policy checking is in general not a good idea - simply because you loose view of what you are doing - and you will - as indicated have to do the policy checking anyway - so the only thing you gains is to delay the policy checking.
If you problem is a spread of workload there are other means of doing it - e.g. running filtered reconciliations or use event based reconciliations. I do not know what kind of services you dealing with - but the AD Adapter can deliver this out of the box - you can build event based reconciliation using "unsolicited event notification" feature which is basically just sending in the account changes in ISIM DAML format to the correct configured listener in ISIM (this is partly covered in AD Adapter setup).
Another problem that makes me wonder here is that seem to have processes changing things outside of your IdM platform - this is in general a very bad idea (it is necessary for the IdM system to cater for it) - account changes outside IdM should be exceptional process only.
A last thing - Grey mentions filtered reconciliations as a mean to reduce attributes in the reconciliation - this works technically perfect - but you need to be aware that is somebody is running a reconciliation without filter that will basically void the filter - it is designed to be way of reducing load in exceptional cases - not a way of splitting/subset a service. There is no way you can limit a user to only run specific filtered reconciliations - a user that can manually run a reconciliation has full power filters/policy evaluation etc...
The problems you bring up here deserves a deeper discussion that what this place is capable of as the point you bring up should be covered by your general design of the ISIM solution - and that is something that much more than a question of ISIM capabilities - it is more into how your processes should work in general...
HTH
------------------------------
Franz Wolfhagen
IAM Technical Architect for Europe - Certified Consulting IT Specialist
IBM Security Expert Labs
Original Message:
Sent: Thu January 23, 2020 09:36 AM
From: Grey Thrasher
Subject: Avoid the accounts will be marked as status 'Unknown' when the modified attributes are some of which we are not interested to enforce
Hello Felipe...
I'm not sure if I fully understand what you're looking for above...but I'll see if I can provide some suggestions here.
First, you state that when Accounts have "unknown" State, you cannot change password, etc for these Accounts. I wonder if you might have something configured in your environment to prevent that (possibly some compliance status check in your Operations?)...because I don't recall this being default behavior, and I just tested in one of my environments and was able to successfully change password for an Account that was in "unknown" State (I could also restore, etc).
That said, it doesn't sound like changing password for "unknown" state Accounts is your main concern here.
In order to avoid ISIM reconciling in attributes you're not concerned with in ISIM, you should be able to exclude these in your Scheduled Reconciliations for your Service(s). On the Query tab of your reconciliations, you can move Attributes from the "Selected attributes" list, to the "Available attributes"...this will both prevent ISIM from reconciling those attribute values, as well as attempting to do any policy evaluation on those attributes during Reconciliation.
Of course, if you DO want these values in ISIM, but just do not want to have your policies evaluate these attributes, you can simply leave that attribute out of your Entitlement definition(s) in your Policy(ies), which would implicitly allow for any value.
------------------------------
Grey Thrasher
IBM
Original Message:
Sent: Thu January 23, 2020 04:13 AM
From: Felipe Risalde Serrano
Subject: Avoid the accounts will be marked as status 'Unknown' when the modified attributes are some of which we are not interested to enforce
First at all,
hi everybody in this new sharing knowledge space.
During an account reconciliation process, we don't want to check the policies, mainly for avoiding a massive policy checking will be done. When it is done (reconciliation without checking policies), the accounts which has been modified in the target system are identified as status 'Unknown'. When an account is defined with status 'Unknown', it is not allowed to change his password, neither restore, …
We will like to avoid the accounts will be marked as 'Unknown' when the modified attributes are some of which we are not interested to enforce.
As you probably know, it can be defined in the 'enrolepolicies.properties' file which attributes will be ignored by a policy compliance validation. From our point of view, it will be wished to be able to define a similar configuration file where you can list the attributes which are being going to be reconciled, but they shouldn't be taking into consideration in the checking modified values process done in the reconciliation.
Have any of you the same issue? What was the solution?
Going in depth, let me explain which attributes we would like to excluded.
This behaviour is very interested when the modified account attributes are those which you want that ISIM defines the allowed values, it those which are managed by provisioning policies using Mandatory, Excluded or Optional enforcement.
But, there are attributes which are defined during the account creation, and you are not interesting in make a compliance validation, ie, the attributes defined in the provisioning policies as 'Default' values, or even more important, there are account attributes which they are read only, such as, "last accesses date", "last change password date", …
There is no doubt, the later set of account attributes, should not be reviewed their values, just only reconciled.
Thanks in advance.
------------------------------------------
Felipe Risalde Serrano
Security Expert
Banco de España
------------------------------