Topic
  • 12 replies
  • Latest Post - ‏2013-10-08T20:26:45Z by yn2000
TY8
TY8
7 Posts

Pinned topic ITIM: Workflow Retrieving operational attribute, modifytimestamp

‏2013-10-07T04:17:15Z |

HI,

I am trying to retrieve the operational attribute, modifytimestamp in the workflow for the purpose of identify if an account was recently orphaned like 2 minutes ago against weeks or months ago. This information will be crucial in the aid of approval process for assigning account ownership.

I tried using DirectoryObject.getProperty("modifytimestamp") but it was undefined.

Listing the account's properties using getPropertyNames() shows that modifytimestamp was not retrievable.

Any ideas how I can retrieve it the least hassle way?

 

  • franzw
    franzw
    383 Posts

    Re: ITIM: Workflow Retrieving operational attribute, modifytimestamp

    ‏2013-10-07T06:01:16Z  

    You cannot get to the TDS operational attributes through the ITIM API - you willl need to use the native JNDI API.

    That said - there is something wrong if you need that attribute. That is an attribute that is updated whenever there is a change via the ldap interface - of course ITIM does that deep into its API somewhere.

    Instead you should look into the ermanageditem objectclass - this has an attribute erlastmodifiedtime - and that you should be able to get through the directoryobject.

    The subtle difference if that this will be set if the update process is via ITIM - but not if it is performed directly via ldap. And within ITIM you should not care if something technically has been performed that has nothing to do with ITIM has changed the entity. This is an important principle in all systems design - you must separate the domains you are working with.

    HTH

    Regards

    Franz Wolfhagen

  • goonitsupport
    goonitsupport
    116 Posts

    Re: ITIM: Workflow Retrieving operational attribute, modifytimestamp

    ‏2013-10-07T07:37:24Z  
    • franzw
    • ‏2013-10-07T06:01:16Z

    You cannot get to the TDS operational attributes through the ITIM API - you willl need to use the native JNDI API.

    That said - there is something wrong if you need that attribute. That is an attribute that is updated whenever there is a change via the ldap interface - of course ITIM does that deep into its API somewhere.

    Instead you should look into the ermanageditem objectclass - this has an attribute erlastmodifiedtime - and that you should be able to get through the directoryobject.

    The subtle difference if that this will be set if the update process is via ITIM - but not if it is performed directly via ldap. And within ITIM you should not care if something technically has been performed that has nothing to do with ITIM has changed the entity. This is an important principle in all systems design - you must separate the domains you are working with.

    HTH

    Regards

    Franz Wolfhagen

    Strangely erlastmodifiedtime is not being set on any of my account objects (isim 6.0) but is being set on Person objects. Not sure whether this is a feature or a bug on my test system?

    In any event the modifytimestamp attribute would not tell you when an account has been orphaned as the account may have been modified by a reconciliation (assuming they are being performed).

    Best regards,

    Vincent Cassidy

  • franzw
    franzw
    383 Posts

    Re: ITIM: Workflow Retrieving operational attribute, modifytimestamp

    ‏2013-10-07T08:10:44Z  

    Strangely erlastmodifiedtime is not being set on any of my account objects (isim 6.0) but is being set on Person objects. Not sure whether this is a feature or a bug on my test system?

    In any event the modifytimestamp attribute would not tell you when an account has been orphaned as the account may have been modified by a reconciliation (assuming they are being performed).

    Best regards,

    Vincent Cassidy

    Same here - and also on 5.1 - this is one of the places where the documentation could definitely be improved...

    I looked the erlastmodifiedtime up in the ldap reference - here it is defined as :

    "Entry removal date and time" - but this is not how it is used on persons - but this may be part of the recyclebin functionality.

    It does not make sense to me - but I can see that IBM Support L3 deemed this "working (broken) as designed"... The guidance is to use a custom field instead - a very bad advice IMHO.

    My thinking is - if you include an attribute like this into the ermanageditem class it should be maintained for all entities belonging to this class - I would even say that this should be implemented so that this was automatically done for new entity types...

    If I were a customer I would challenge this - so it may be worth a new PMR - if there is a very good usecase it may be something that can be changed - else an RFE will be necessary.

    Sorry for have let you down this non-working route - should have checked before answering...

    Regards

    Franz Wolfhagen

  • TY8
    TY8
    7 Posts

    Re: ITIM: Workflow Retrieving operational attribute, modifytimestamp

    ‏2013-10-07T08:52:06Z  
    • franzw
    • ‏2013-10-07T08:10:44Z

    Same here - and also on 5.1 - this is one of the places where the documentation could definitely be improved...

    I looked the erlastmodifiedtime up in the ldap reference - here it is defined as :

    "Entry removal date and time" - but this is not how it is used on persons - but this may be part of the recyclebin functionality.

    It does not make sense to me - but I can see that IBM Support L3 deemed this "working (broken) as designed"... The guidance is to use a custom field instead - a very bad advice IMHO.

    My thinking is - if you include an attribute like this into the ermanageditem class it should be maintained for all entities belonging to this class - I would even say that this should be implemented so that this was automatically done for new entity types...

    If I were a customer I would challenge this - so it may be worth a new PMR - if there is a very good usecase it may be something that can be changed - else an RFE will be necessary.

    Sorry for have let you down this non-working route - should have checked before answering...

    Regards

    Franz Wolfhagen

    Vincent,

    I noticed the same thing as well. erlastmodifiedtime is only updated in Person objects but not in account objects. You were right that ermodifiedtime may not be the most trustworthy reference when an account is orphaned. It could be updated by reconciliation.

     

    Franz,

    No worries. You have been most helpful and your detailed patience replies are deeply appreciated. Many of us have benefited from your sharing. I agreed with your views and I notice that IBM Support has the habit of using "working as designed".

     

    The thing is currently my client requires approval process for assigning general/generic accounts to user. I feel this is a common request that most clients will ask for. Strangely, ISIM does not support approval process for such workflow.

    Even though, ISIM has the functionality to assign account to user through its "Assign to user" button. The account is orphaned first before going through the assignment (via singleaccountadopt operation workflow). I modified singleaccountadopt to include approval process (working around ISIM limitations). However, this leads to a problem where we are not able to identify if this is an aged orphaned account or newly mint orphaned account (caused by the button) because if approver rejects the request, we will need to reassign the ownership back if it is a newly mint orphaned account. Thus, the reason why we are exploring modifytimestamp.

    Anyone here encounter similar requirement from client? and how do you handle it in ISIM? 

     

    Warm Regards
    Timothy Yeo

    Updated on 2013-10-07T08:52:49Z at 2013-10-07T08:52:49Z by TY8
  • franzw
    franzw
    383 Posts

    Re: ITIM: Workflow Retrieving operational attribute, modifytimestamp

    ‏2013-10-07T09:57:10Z  
    • TY8
    • ‏2013-10-07T08:52:06Z

    Vincent,

    I noticed the same thing as well. erlastmodifiedtime is only updated in Person objects but not in account objects. You were right that ermodifiedtime may not be the most trustworthy reference when an account is orphaned. It could be updated by reconciliation.

     

    Franz,

    No worries. You have been most helpful and your detailed patience replies are deeply appreciated. Many of us have benefited from your sharing. I agreed with your views and I notice that IBM Support has the habit of using "working as designed".

     

    The thing is currently my client requires approval process for assigning general/generic accounts to user. I feel this is a common request that most clients will ask for. Strangely, ISIM does not support approval process for such workflow.

    Even though, ISIM has the functionality to assign account to user through its "Assign to user" button. The account is orphaned first before going through the assignment (via singleaccountadopt operation workflow). I modified singleaccountadopt to include approval process (working around ISIM limitations). However, this leads to a problem where we are not able to identify if this is an aged orphaned account or newly mint orphaned account (caused by the button) because if approver rejects the request, we will need to reassign the ownership back if it is a newly mint orphaned account. Thus, the reason why we are exploring modifytimestamp.

    Anyone here encounter similar requirement from client? and how do you handle it in ISIM? 

     

    Warm Regards
    Timothy Yeo

    Thanks for your nice words - it is nice to know that my posting are regarded useful.

    But I forgot an important thing - in ITIM 4.6 a new attribute "erlastoperation" was introduced that is held on all account and person entities. This is intended to be used ofr purposes where you need to store information on the account/person that is not part of the normal built-in business flows. This also means it will not be  sent to the adapter.

    I use it for state machines controlling processes around the reconciliation process - basically applying an approval workflow for accounts created outside ITIM.

    Regards

    Franz Wolfhagen

  • goonitsupport
    goonitsupport
    116 Posts

    Re: ITIM: Workflow Retrieving operational attribute, modifytimestamp

    ‏2013-10-07T12:08:38Z  
    • TY8
    • ‏2013-10-07T08:52:06Z

    Vincent,

    I noticed the same thing as well. erlastmodifiedtime is only updated in Person objects but not in account objects. You were right that ermodifiedtime may not be the most trustworthy reference when an account is orphaned. It could be updated by reconciliation.

     

    Franz,

    No worries. You have been most helpful and your detailed patience replies are deeply appreciated. Many of us have benefited from your sharing. I agreed with your views and I notice that IBM Support has the habit of using "working as designed".

     

    The thing is currently my client requires approval process for assigning general/generic accounts to user. I feel this is a common request that most clients will ask for. Strangely, ISIM does not support approval process for such workflow.

    Even though, ISIM has the functionality to assign account to user through its "Assign to user" button. The account is orphaned first before going through the assignment (via singleaccountadopt operation workflow). I modified singleaccountadopt to include approval process (working around ISIM limitations). However, this leads to a problem where we are not able to identify if this is an aged orphaned account or newly mint orphaned account (caused by the button) because if approver rejects the request, we will need to reassign the ownership back if it is a newly mint orphaned account. Thus, the reason why we are exploring modifytimestamp.

    Anyone here encounter similar requirement from client? and how do you handle it in ISIM? 

     

    Warm Regards
    Timothy Yeo

    Hi Timothy,

    I think this is an unusual requirement but there is perhaps a way to crack it although you need to consider whether it is worth it for your requirement.

     

    You can create a new string attribute and add it to the eraccountitem objectclass.

    Then have a lifecycle rule/account modify operation that runs daily  and populate this attribute with the owner dn and date value. You can then use this attribute in your workflow to determine whether there was an owner before the "Assign user" button was pushed.

     

    Best regards,

    Vincent

  • franzw
    franzw
    383 Posts

    Re: ITIM: Workflow Retrieving operational attribute, modifytimestamp

    ‏2013-10-07T12:47:13Z  

    Hi Timothy,

    I think this is an unusual requirement but there is perhaps a way to crack it although you need to consider whether it is worth it for your requirement.

     

    You can create a new string attribute and add it to the eraccountitem objectclass.

    Then have a lifecycle rule/account modify operation that runs daily  and populate this attribute with the owner dn and date value. You can then use this attribute in your workflow to determine whether there was an owner before the "Assign user" button was pushed.

     

    Best regards,

    Vincent

    That's a no-no if you want to stay within support - at least if you do not ask first :-)

    It is probably going to work quite nice - but if IBM decides to change the eraccountitem class in a fixpak you may get into real trouble - this really requires that you know the inner working of ldap and the ldapUpgrade script.

    A procedure that would remove the problem would be something like :

    1.Dump all of you custom attributes to a file

    2.Delete the attributes and delete it from the schema

    3.Perform the fixpak upgrade

    4.Add your attribute to the schema and reload you attribute

    This may sound simple - but as ITIM is restarted during the upgrade process you also need to ensure no jobs are running that uses your attribute.

    I will strongly recommend against this - that is why erlastoperation was added.

    Regards

    Franz Wolfhagen

     

  • yn2000
    yn2000
    1102 Posts

    Re: ITIM: Workflow Retrieving operational attribute, modifytimestamp

    ‏2013-10-07T13:30:04Z  
    • TY8
    • ‏2013-10-07T08:52:06Z

    Vincent,

    I noticed the same thing as well. erlastmodifiedtime is only updated in Person objects but not in account objects. You were right that ermodifiedtime may not be the most trustworthy reference when an account is orphaned. It could be updated by reconciliation.

     

    Franz,

    No worries. You have been most helpful and your detailed patience replies are deeply appreciated. Many of us have benefited from your sharing. I agreed with your views and I notice that IBM Support has the habit of using "working as designed".

     

    The thing is currently my client requires approval process for assigning general/generic accounts to user. I feel this is a common request that most clients will ask for. Strangely, ISIM does not support approval process for such workflow.

    Even though, ISIM has the functionality to assign account to user through its "Assign to user" button. The account is orphaned first before going through the assignment (via singleaccountadopt operation workflow). I modified singleaccountadopt to include approval process (working around ISIM limitations). However, this leads to a problem where we are not able to identify if this is an aged orphaned account or newly mint orphaned account (caused by the button) because if approver rejects the request, we will need to reassign the ownership back if it is a newly mint orphaned account. Thus, the reason why we are exploring modifytimestamp.

    Anyone here encounter similar requirement from client? and how do you handle it in ISIM? 

     

    Warm Regards
    Timothy Yeo

    Hi Tim,

    Just thinking out loud... you are talking about moving around owner??? plus newly mint orphaned account??? This means that you are talking about service/system/shared/generic accounts, because it is a bad idea to allow the creation of normal/individual account from the target. So, if you are dealing with service/system/shared/generic accounts, then you are better with 'as manual as possible' processes first and then gradually automate with caution. For example: If you assign service/system/shared/generic accounts without telling the owner, then the owner change his/her individual password that changed the service/system/shared accounts attach to him/her, then you are screwed, unless you never sync password.

    Then... with approval??? It means that the management does not trust the ITIM Admin team, unless the approval is for notification only, but then you mentioned about 'rejection of user assignment process'. Well, you can easily create a 'dummy' person and assign all 'rejected accounts' to this 'dummy' person, so that you can distinguish between aged orphaned account or newly mint orphaned account, but what is 'reject' mean? You assign to the wrong person or you assign to the wrong account, where the account should not be owned by anyone?

    Anyway, I am 'agreer' (not a word of incorrect 'more agree') with Vincent's "..this is an unusual requirement..", than your "...I feel this is a common request that most clients will ask for..." (Joke: Two negatives do not always equal to positive. It could just be more negative (or 'negativer'))

    Rgds. YN.

  • goonitsupport
    goonitsupport
    116 Posts

    Re: ITIM: Workflow Retrieving operational attribute, modifytimestamp

    ‏2013-10-07T13:36:11Z  
    • franzw
    • ‏2013-10-07T12:47:13Z

    That's a no-no if you want to stay within support - at least if you do not ask first :-)

    It is probably going to work quite nice - but if IBM decides to change the eraccountitem class in a fixpak you may get into real trouble - this really requires that you know the inner working of ldap and the ldapUpgrade script.

    A procedure that would remove the problem would be something like :

    1.Dump all of you custom attributes to a file

    2.Delete the attributes and delete it from the schema

    3.Perform the fixpak upgrade

    4.Add your attribute to the schema and reload you attribute

    This may sound simple - but as ITIM is restarted during the upgrade process you also need to ensure no jobs are running that uses your attribute.

    I will strongly recommend against this - that is why erlastoperation was added.

    Regards

    Franz Wolfhagen

     

    I new you would like it Franz ;-)

    So now I understand your previous post and what you are suggesting is pretty similar to mine. So have a lifecycle rule or something which stores the owner and perhaps date in erlastoperation field. This can then be checked in the singleaccountadopt workflow!

    PS Fixpacks and upgrades in the past have only ever modified objectclasses not deleted and re-added. But I guess IBM may do something new one day;-)

    Franz's suggestion is best.

     

    Updated on 2013-10-07T13:36:22Z at 2013-10-07T13:36:22Z by goonitsupport
  • TY8
    TY8
    7 Posts

    Re: ITIM: Workflow Retrieving operational attribute, modifytimestamp

    ‏2013-10-08T03:21:30Z  

    Hi Timothy,

    I think this is an unusual requirement but there is perhaps a way to crack it although you need to consider whether it is worth it for your requirement.

     

    You can create a new string attribute and add it to the eraccountitem objectclass.

    Then have a lifecycle rule/account modify operation that runs daily  and populate this attribute with the owner dn and date value. You can then use this attribute in your workflow to determine whether there was an owner before the "Assign user" button was pushed.

     

    Best regards,

    Vincent

    Vincent,

    Thanks for your suggestion. It does open up doors.

     

    Franz,

    Thanks for the insights on "erlastoperation" attribute and highlighting consideration for maintenance and patching for custom attribute in eraccountitem class. After patching, the custom attribute's value will be repopulated by the lifecycle rule.

     

     

  • TY8
    TY8
    7 Posts

    Re: ITIM: Workflow Retrieving operational attribute, modifytimestamp

    ‏2013-10-08T03:36:07Z  
    • yn2000
    • ‏2013-10-07T13:30:04Z

    Hi Tim,

    Just thinking out loud... you are talking about moving around owner??? plus newly mint orphaned account??? This means that you are talking about service/system/shared/generic accounts, because it is a bad idea to allow the creation of normal/individual account from the target. So, if you are dealing with service/system/shared/generic accounts, then you are better with 'as manual as possible' processes first and then gradually automate with caution. For example: If you assign service/system/shared/generic accounts without telling the owner, then the owner change his/her individual password that changed the service/system/shared accounts attach to him/her, then you are screwed, unless you never sync password.

    Then... with approval??? It means that the management does not trust the ITIM Admin team, unless the approval is for notification only, but then you mentioned about 'rejection of user assignment process'. Well, you can easily create a 'dummy' person and assign all 'rejected accounts' to this 'dummy' person, so that you can distinguish between aged orphaned account or newly mint orphaned account, but what is 'reject' mean? You assign to the wrong person or you assign to the wrong account, where the account should not be owned by anyone?

    Anyway, I am 'agreer' (not a word of incorrect 'more agree') with Vincent's "..this is an unusual requirement..", than your "...I feel this is a common request that most clients will ask for..." (Joke: Two negatives do not always equal to positive. It could just be more negative (or 'negativer'))

    Rgds. YN.

    Hi YN,

    Thanks for your input.

    Yes. I am talking about service/system/shared/generic accounts where user ownerships will changed but the accounts will stay.

    "Newly mint orphaned account" is caused by clicking the "Assign to User" button, where the account with it's existing owner will be removed first (orphaned) before going through the singleaccountadopt workflow for the next assignment of new owner.

    A 'dummy person' could be an alternative approach but it may raise issues with audit.

  • yn2000
    yn2000
    1102 Posts

    Re: ITIM: Workflow Retrieving operational attribute, modifytimestamp

    ‏2013-10-08T20:26:45Z  
    • TY8
    • ‏2013-10-08T03:36:07Z

    Hi YN,

    Thanks for your input.

    Yes. I am talking about service/system/shared/generic accounts where user ownerships will changed but the accounts will stay.

    "Newly mint orphaned account" is caused by clicking the "Assign to User" button, where the account with it's existing owner will be removed first (orphaned) before going through the singleaccountadopt workflow for the next assignment of new owner.

    A 'dummy person' could be an alternative approach but it may raise issues with audit.

    Hi Tim,

    When you talk to French speaking people (Audit people), then you have to speak in French of course. So, when I talk to ITIM literate people, like you, I would say 'dummy people', because you know exactly what I meant. But when I talk to Audit, I would use the word 'Service Account' entity, aka SAE. This is a non-human entity, using a different objectclass, where service/system/shared/generic accounts were tracked, own, or administers by someone. Or, technically, you can say something (jargon) that the Audit people have no clue (or cannot relate with something he/she knows) and then close it with the words…It is 'auditable'. This SAE is the one attached (the owner, in ITIM world) to the real account in the target. I do not know what 'audit policy' that you have to follow, but usually all of these discussions are just a tip of iceberg. For example: Maybe your client just saying that 'all service accounts are to be owned and administer by an individual (human)'. It is very common requirement, but you mentioned that 'an approver can reject' ownership of someone. So, one procedure just breaks the other procedure. Another sign from you… someone clicking something… that means, in your case, the issue is more about the procedure. So, do not afraid to put 'human' to be part of the procedure. You would be amaze what 'human' can do. That is why I said "…you are better with 'as manual as possible' processes first and then gradually automate with caution…" It could be a tough sell, but if you lucky enough to have a great customer, they would agree.

    By the way… please use ISIM v6.0 or above.

    Rgds. YN.