Task started by unknown/unknown

[Michael A. Lowry]

This morning I saw a schedule (JSCH) task in the Activity table that was started by <unknown>/<unknown>.

Probably as a consequence, a child workflow (JOBP) failed with the error U00000009 Access denied.

I didn't see anything informative in the logs. Has anyone see this problem? What can cause it?

[Timothy Yanosko]

Is it possible the user who originally submitted the JSCH has been deleted from the system?

[Pete Wirfs]

I agree with @Timothy Yanosko's assessment.  I've seen <unknown> before as the result of a USER object being deleted.  The USER object provides the user name and authorities to UC4, and is connected to operational objects via the oh_idnr value.  

This is why we do not delete USER objects of departing staff.  Instead, we just inactivate them and delete them several years later so that any objects they modified will still reflect the appropriate user name information.

------------------------------
Pete
------------------------------

[Juergen Lechner]

This is correct! Specially the deactivation is the only easy way to prevent the "Access denied" error. Otherwise you would need a method to hand over objects from leaving users to someone else.
Yesterday I rejoined a project to work on their rights management for Automic. My internal contact ran a script to show me because of which objects my user had not been deleted - as I had expected. So no matter how good people prepare their leave. There are always some breadcrumbs on their way out. ;-)

Regards
Juergen

------------------------------
Senior Consultant
setis GmbH
------------------------------

[Carsten Schmitz]

Unfortunately, not deleting accounts is incompatible with many a corporation's IT policies :(​

[Juergen Lechner]

​Oh yesss... You are right about this. But until now the deactivation satisfied auditors. I have not seen any case of audit findings in banks for that.

A "cleaner" way would be to identify leavers and replace them in the system before deletion. This would alarm auditors for sure. Because then you will have tons of objects either from "unknown" or assigned to users who have never touched them. This would create false information. Also not good. If you explain this to audit, they have to accept this.

------------------------------
Senior Consultant
setis GmbH
------------------------------

[Carsten Schmitz]

It's a problem without a neat solution, the way it stands in Automic today.

What we usually do is tell the colleagues ​of the soon-to-be-ex-employee to make a filter for all running objects of that user. Then, they "take over" (by right clicking in Activity Monitoring) all running activities of that user. Once we verify this has happened, we delete the user account.

Apart from this, we have gotten most departments to launch their schedulers and other top level objects with a blanket user account, one that is not bound to a specific user. An example would be an account called "SAP" or "FINANCE". Somewhat to my surprise, the auditors allow this in our case.

Either way, this only solves the issue for running objects. For change history, one still often finds "unknown/unknown" as the author of an object - this is unfortunate and something Automic ought to improve. But then, when you "transport" objects, Autmomic doesn't "transport" the change history anyway, so as more and more objects get transported between environments, that elegantly removes "unknown/unknown" by ... erm ... wiping the entire history clean. Wonder what the auditors would think about that ;)

Br,
Carsten