Emerson Exchange 365

Some pre-requisites here - knowledge of Windows local and domain architecture and group policy. I reference the following BOL articles - You will need a Guardian account to access the links or simply search for the article names on your DV system BOL application:
WorkGroups and Domains guardian.emerson.com/.../secur_mgmt_dss_wkgroups.htm

Creating and Managing Windows Groups
guardian.emerson.com/.../secur_mgmt_dss_groupcreat.htm

Hardened Workstation Security Template
guardian.emerson.com/.../c_security_settings_overview.html

User Manager Application
guardian.emerson.com/.../dv_apps_user_manager.htm

Now on to the answers:

a) Q: There is domain controller that is also managing the credentials. Is this AD managing the password policy and etc for the access to Delta V system?

A: Yes , the domain's default policy on passwords controls the Windows and DeltaV accounts. I don't suggest changing the default policy but rather to create a new policy to override or more specifically define your needs. The Hardened Workstation Security Templates articles describe how to conduct this in a product-approved fashion.

Q: What is the difference between the User Management as well as the Domain Controller?

A: User Management is a DeltaV application which controls creation and management of DeltaV application level security and to some extent Windows domain and local account level security. It is advised to use the User Management application to create and manage all DeltaV/Windows accounts on the domain. To the extent that it is capable, management of Windows accounts relevant to DeltaV should be managed here as well. The User Manager application sends commands to the Windows local and domain security layer to affect Windows accounts on behalf of the DeltaV application space, but you cannot completely manage all features of Windows accounts here. This is why using the Active Directory Users and Computers and Local Account Management Windows consoles is required in certain special cases depending on your security needs.


b)Q: Can the password complexity be set in Delta V system, best practice is 8 characters but there is no options? If yes, how can the password be set?

A: It should be set in the domain's group policy management console. I suggest never changing the default policy, but to create a new one to manage site specific details. The Hardened Workstation articles describe the product approved way to achieve this.

c) Q: There are ample default administrative accounts such as DeltaVAdmin, DVBatchAdmin, DVHisAnlysUser, DVPEHAdministrator, MessengerDVUser, Configure, Maintainer, SIS_Configure and SOFTPHASEUSER. May I know which are the default accounts (that can be disabled) and which are the ones that are non-interactive accounts (cant be logon). Is there any documentation or place I can refer to ascertain the functionalities of this accounts please?

A: I have performed this audit previously and the answer is higher DeltaV versions are better at both documenting and controlling this. The User Manager link I included earlier does describe some do's and don'ts around the default accounts but here is my summary from a previous post regarding v. 13.3.1 emersonexchange365.com/.../6998:

1. Disable Users
CONFIGURE
Guest
MAINTAINER
OPERATOR
SIS_CONFIGURE
SOFTPHASEUSER (only if you are not using SoftPhases)
SUPERVISOR
Administrator (however most sites have configured other services against this account so only do so if you are confident it is not being used and another administrative account exists)

2. Change the default password for DeltaVAdmin across the board using servpwd.exe. You cannot disable this account. The DVBatchAdmin, DVHisAnlysUser, DVPEHAdministrator, MessengerDVUser accounts can be disabled if you are not using Batch, History Analysis, PEH, or Plant Web Messenger. These are both domain and local accounts so managing this is not simple in 11.3.1. Unfortunately, re-running workstation config will re-enable these, I believe. Changing their default passwords is also not straight forward if you are using these services as there are services and dcom objects potentially that use these accounts for which you would need to change the pw for as well.

d) Is there any audit trails capabilities within the system to ascertain the activities of the users? If yes, how can I obtain them?
There are multiple audit trail systems. First, Event Chronicle will record all DeltaV Application activities such as login/logoff, changing run time parameters, downloading, etc. for Areas which are assigned to the chronicle. The DeltaV Configuration Version and Audit Trail Control (VCAT) enforces check in / check out and audits control database configuration changes, and Graphics (though Graphics control is not used as often). Batch History records batch related activities such as operator prompts for a batch, active step changes, and recipe parameter changes. Windows-level auditing is conducted by the Windows event log system to the extent that you enable it, which by default is not very thorough. If you want to audit file-level changes for example, you have to configure this explicitly. SQL database changes to the chronicle and batch historian I believe are automatically audited by SQL though I don't know if this is completely true or thorough enough to prevent an administrator for adultering records out of the box.