Skip to main content

Hi,
Can anyone describe to me the “normal” (Best Practice) way to handle common accounts such as IFSAPP?
It is quite common that more than one consultant (or employee for that sake) uses common accounts. Either a pre defined account (IFSAPP) or if it is one custom made user account for lets say IFS-consultants.

We need to have unique accounts for every user. Consultants included. What I ask here is what the Best Practice is for the System Owner account IFSAPP. According to our regulations we need to log every single use of IFSAPP for the traceability of who was using the login and for what.

How do you handle this? Please advise even if it isn’t Best Practice

Hi @KUNGTOM ,

IFSAPP account is the schema owner account and hence should not be shared among users or used as a typical end user account. See below extract from  F1 doc: 

 

User Name Purpose Special privileges
Application owner
Appowner
Any name, but often called <IFSAPP> Provides views, tables, packages methods for IFS Applications. Database schema owner.
Grants on SYS views and system privileges grants.

 

The best practice would be to use the IFSAPP account to create user accounts and segregate them according to your requirement. 

Using an end user account a shared account can be tricky and difficult to track. The following threads discuss the details on tracking end user account login times: 

See User Login Record | IFS Community

Last Login for user | IFS Community

 

Also, to track end user activity, it is possible to use history logging. You should be able to find some threads in the community. Here’s a couple from a quick search I did: 

 

History Logging on Custom LUs | IFS Community

Viewing History Log records of all users without granting FND_ADMIN permission | IFS Community

 

Thanks,

Kasun

 


I agree with @Kasun Balasooriya , IFSAPP should not be a shared account and should not be provided to consultants unless you have no other internal IT support to do this work.  It should be restricted and well controlled as to who has access.  We provide cloned versions of IFSAPP with separate password controls to make sure we know when there is any outside access to the system.  

The history logs provide a useful track of that access.

We make as many extra accounts as required to adequately keep track of the access required.  Usually down to the individual.  If there dormant periods of use for some accounts we will inactivate them to ensure they aren’t used.


Hi @KUNGTOM ,

IFSAPP account is the schema owner account and hence should not be shared among users or used as a typical end user account. See below extract from  F1 doc: 

 

User Name Purpose Special privileges
Application owner
Appowner
Any name, but often called <IFSAPP> Provides views, tables, packages methods for IFS Applications. Database schema owner.
Grants on SYS views and system privileges grants.

 

The best practice would be to use the IFSAPP account to create user accounts and segregate them according to your requirement. 

Using an end user account a shared account can be tricky and difficult to track. The following threads discuss the details on tracking end user account login times: 

See User Login Record | IFS Community

Last Login for user | IFS Community

 

Also, to track end user activity, it is possible to use history logging. You should be able to find some threads in the community. Here’s a couple from a quick search I did: 

 

History Logging on Custom LUs | IFS Community

Viewing History Log records of all users without granting FND_ADMIN permission | IFS Community

 

Thanks,

Kasun

 

Hi Kasun,
Thank you for your answer. I am aware that IFSAPP should not be used by End Users. That is not the case here. We use two IFS-consultants (employees of IFS Sweden) for those changes we need to do and can’t manage ourselves. I am pretty sure that we are not alone here in letting more than one person use IFSAPP. According to my experience, there is a lot of companies letting their consultants use the IFSAPP for full access when necessary. 

I have earlier worked with a company where we only let the consultants use IFSAPP after getting permission from us. That way we could see if it was used any time without permission. This was a rule that worked fine for them. In my case there isn’t enough. We need to make sure no one can use the account without some kind of traceability...


I agree with @Kasun Balasooriya , IFSAPP should not be a shared account and should not be provided to consultants unless you have no other internal IT support to do this work.  It should be restricted and well controlled as to who has access.  We provide cloned versions of IFSAPP with separate password controls to make sure we know when there is any outside access to the system.  

The history logs provide a useful track of that access.

We make as many extra accounts as required to adequately keep track of the access required.  Usually down to the individual.  If there dormant periods of use for some accounts we will inactivate them to ensure they aren’t used.

Thank you @ShawnBerk for your answer. I thought you couldn’t clone the System Owner Account IFSAPP…
I have in the past cloned the IFSALL permissions to a User Account, but that isn’t quite the same as cloning IFSAPP permissions.
/tom


Hi @KUNGTOM ,

I agree with you that, may IFS customers are sharing app owner account with their outside IFS consultants, which is very easy and efficient with their work handling. But, almost all IFS customers have restricted access to their IFS apps from external network. So, external parties are provided with a VPN account/accounts to connect to the IFS application through the internal network. So, I think it is possible to track from which VPN account / IP address, the system has been accessed and what date/time. I don’t know exactly, because I’m not familiar with that process, but I think it should be possible.

And, another thing some customers practice is that, they don’t share the app owner account of the production system, but that of the test systems. And I know some customers daily copy the production system to their test systems. So, when an investigation needed for a specific problem, consultants can investigate it in the test system,so the same solution can be applied in the prod by the internal IFS admin. For any developments, consultants/developers can develop the solution in the test system, and then the customer can export it and import/apply it in prod.

And, also, even though we have not an option to directly clone the app owner account to create a similar account, a super user account/accounts with same privileges can be created, so that those accounts can be used separately by the consultants. I think, the standard permission set FND_ADMIN has almost all access/privileges app owner has. (Some other type of access other than permissions, also need to be configured like HR access, document access, finance user groups etc..)

As @ShawnBerk and @Kasun Balasooriya mentioned, you can user history logging and user logging tracing options to track the changes/logging done by different users using app owner, if it is shared.

 

Thanks,

 

 


Hi

In IFS9 documentation there was implicit recommendation to lock ifsapp account to make IFS Application more secure and use it only for installing, upgrading, etc:

 https://wit.ifsworld.com/f1docs/apps9upd16/Foundation1/040_administration/210_security/010_users/110_lock_appowner/default.htm

 

I looks like after my long discussion 2 years ago with GSO/RnD it was removed from official IFS10 documentation - there were plenty places where only IFSAPP user can do some specific actions.


Reply