So there is a bug with the exchange website don't use the less than sign, otherwise, all text is removed from your post!
In reply to AdrianOffield:
Adrian, Can you email me the text you entered? I'll submit it to the Zimbra support team. Thanks...
In reply to Jim Cahill:
Adrian,
the DeltaV only accounts are to allow specification of a pass-through authentication of operating system accounts on an external trusted or parent domain.
For instance, if you wanted to integrate your enterprise network login accounts to your DeltaV system, you could use a DeltaV only account with a domain specification of your enterprise domain (provided the necessary trusts and domain name resolutions were also set up). The passwords for these accounts are managed by the other domain, but the application access is managed by you as the DCS administrator.
I guess this doesn't address your specific need, as you want to prohibit the user OS access. With DeltaV Autologon and Autoswitch Desktop enabled, the only way they would be able to do this is by using the 'logoff' command on the 'Alt+Space' menu of Flexlock.
You could enact a policy to disable interactive logon by the users, but this may impact their ability to use the application even when not logged in to windows.
You'd have to test that.
<testing html encoding!!!>
I don't know when the dv only user feature disappeared, and maybe someone else knows where it went.
For now, yes integration of dv domain as a child or trusting domain to authenticate those foreign users is the only conceivable use of dv only user. The password comes from the foreign domain.
Regarding policies, Deltav builds in hardened workstation domain policies you may take advantage of to improve security such that even if the operator logs in to Windows, they are severely limited (even beyond deltav desktop restriction).
You can build your own domain policies to augment these efficiently across all users and workstations.
Youssef El-Bahtimy | Systems Integration Technologist PROCONEX | 103 Enterprise Drive | Royersford, PA 19468 USA Proconex Office: 610 495 2970 | Cell: 267 275 7513 Youssef.El-Bahtimy@ProconexDirect.com
In reply to Youssef.El-Bahtimy:
I'm not sure exactly what the issue is, but there was a change made in v10 or v11 to associated the DeltaV account with a specific domain. DeltaV uses a windows account and associates the DeltaV security to that Account name. Before this change, any "Administrator" account that could log onto a workstation gained the DeltaV privileges of that account. So if you trusted domains, the workstation, child domain and parent domain administrator all have the same DeltaV privilege.
By specifying the domain of the account, the DeltaV logon does not allow a user to "hack" onto the system by having a back door windows account that gives them DeltaV write privileges. DeltaV Logon only lists the users under their domain or station.
DeltaV does not have passwords for its accounts. It relies on the windows account password authentication. The DV only account allows for the creation of a DeltaV account to be associated with a Windows account that DeltaV User Manager cannot create, such as a local account on an App Station or a domain account in a trusted domain. You have to manage that account/password externally to DeltaV. DeltaV Logon passes the logon information to Windows for authentication, and if it returns a valid logon, then the user logs on to DeltaV, without affecting the underlying windows interactive logon. This is still the same v11/v12.
When creating the DV Database only account, I believe you still have to define the Computer/domain. If computer is used, it assumes there will be a local account on the computer. If you specify a domain, the windows account must exist in that domain, and the password is managed there. If it is unspecified, the account can be any location, so long as the account name matches. I think the Pro Plus must be a domain Controller to allow specification of the computer name, otherwise it uses Unspecified. My workgroup Pro plus does not allow me to set this parameter, and default is Unspecified.
Andre Dicaire
The typicaly setup we use is to have a DEFAULT operating system account user who is also a DeltaV user with no priviliges other than to see alarms in all areas. This user is the automatic logon OS / DeltaV user. Individuals who access DeltaV then have their own DeltaV accounts (which are also domain user accounts).
The DeltaV users can't shutdown the workstations, and don't have Windows desktop access. If they log off Windows using the Flexlock Alt+Space menu option, they can log into Windows, but the experience once they do is realy no different or less secure than when the DEFAULT user logs in (as they have the same OS level rights as DEFAULT). When I see a individual logged into the OS of a workstation, I usually log them off and put in the DEFAULT user, nonetheless.
So if you have
1. Windows Automatic logon of DEFAULT,
2. Autoswitch desktop enabled
3. No Windows Desktop Access for non-administrators
you have a pretty good security strategy. Bottom line, I don't think you need to prevent logon to the OS.
To go further, you can add your users to the Basic Operator role, which applies a more strict domain policy to them. Lastly, you should also consider how USB ports on workstations are secured. This is a topic of a whole other discussion, however.
www3.emersonprocess.com/.../orgunitsandgpos.htm
Basic Operator Role
The Basic Operator role has Read and Execute permissions on DeltaV files. Only operators should be assigned to this role. This role has very restricted access to DeltaV files and the GPO settings deny access to most operating system features. If a user is somehow able to bypass the DeltaVFlexLock Application, the GPO settings will deny them easy access to programs and operating system capabilities. Users assigned to the Basic Operator role are restricted from any of the administrator account types (DeltaV Administrator, DeltaV Batch Historian Administrator, DeltaV Event Chronicle Administrator) and from Windows Desktop Access.
Users assigned to the Basic Operator role can only run the following DeltaV applications:
Batch History View
Batch Operator Interface (if operator has Batch Operate key)
Control Studio (read only)
DeltaV Explorer (read only)
DeltaV Logger
DeltaV Logon
DeltaV Operate Run mode
Diagnostics
Process History View (if operator has CHART_SAVE Functional Security assigned)
Books Online
InSight
Neural
FlexLock
Condition Summary
AMSMenu
MPC Operate
MPC Operate Pro
Users assigned to the Basic Operator role are restricted from using the following Windows applications:
Notepad
MSPaint
Calculator
Windows Media Player
Windows Movie Maker