WorkflowWindows Domain-Based Security
You can use Windows domain user accounts to manage access to and within Workflow. You can also configure domain user accounts for automatic login on either a global basis or for individual computers.
By using Windows domain user accounts, you gain the following advantages of Windows security in relation to Workflow login:
- Case sensitive passwords
- Passwords that expire
- Online password changes
- Ability to specify minimum password requirements
- Account lockout
Windows domain user accounts also provide options for controlling access to Workflow functionality after users have logged in to the system. Specifically, you can enforce security based on the permissions afforded by either:
- Workflow groups that you directly associate with users one at a time, and/or
- Workflow groups that you map to active directory universal or global groups and, thus, to all related users at once.
Important: Only Windows domain user accounts are supported, and you cannot remove user accounts from Windows domains from within Workflow.
Login Security Management
Workflow requires that any Windows domain user be authenticated by active directory. To designate a Windows domain user in Workflow, you must name the corresponding Personnel resource in the format of <Fully Qualified Windows Domain Name>\<Windows Account Name> (for example) MyDomain.MyCompany.com\RobertGray). In response, the system automatically creates a Workflow user account that provides for access to the system based on the user's Windows credentials.
Note: Beginning with Workflow 2.0, you can add non-Windows domain users to the Windows Users group in the Personnel model. However, Workflow does not consider those users to be Windows domain users for security purposes; rather, they are considered Workflow users who are members of a Workflow group named Windows Users. You must manually create accounts and specify system access credentials for such users, and cannot control their access to Workflow functionality by way of active directory mapping.
In attempting to log in a Windows domain user, Workflow sends the user's Windows user name and password to a Windows domain controller for authentication. If the controller verifies the user name and password, Workflow completes the login process; otherwise, an error message appears alerting you to the failure.
Note: To log in to Workflow, the system must be in a state of either Complete or Partial health. For more information, see System Health and Program Use. If autologin is configured for Windows domain users—either for the current computer or all computers in the system—Workflow will log in with the currently logged in Windows domain user.
Following initial log in, Windows domain users are automatically designated as such for the purpose of system access, as reflected on the Domain Users tab of the Security Editor.
Post-Login Security Management
In relation to Windows domain users, you can control access to Workflow functionality based on either the Workflow groups that you directly associate with the user, or the active directory groups that the user belongs to and that you, in turn, map to Workflow groups. Users inherit the key sets and corresponding permissions defined for the Workflow groups that they are associated with either directly or by way of active directory group mapping.
Note: These two approaches are mutually exclusive for any given Windows domain.
Direct group association and active directory mapping both offer the benefit of centralized, Windows domain-based credential management for access to the overall system. In deciding which approach to adopt for controlling access to Workflow functionality, consider the following aspects of each:
- Directly associating Windows domain users with Workflow groups provides for a comparatively greater degree of flexibility in granting access to the Workflow functionality, because any such user can be provided broader or narrower permissions than other users in the same Windows domain active directory group. However, maintenance efforts may be greater, because the security configurations must be managed on a per-user basis.
- Mapping active directory groups to Workflow groups provides for a comparatively lesser degree of flexibility in granting Windows domain user access to the Workflow functionality, because all users in an active directory group are subject to the same security constraints within the system. However, an active directory group can be mapped to many Workflow groups, and a Workflow group can have many active directory groups mapped to it. Furthermore, changing the mapping between active directory groups and Workflow groups changes the permissions that are granted to all Windows domain users who are members of the mapped active directory groups at once, which can speed maintenance efforts. Additional time savings can also be realized when adding new Windows domain users who are members of previously mapped active directory groups, as these users are automatically and immediately afforded the permissions provided by the related Workflow groups.
Note: Windows domain users that were created in versions of Workflow prior to 2.0 will continue to function as before assuming that the active directory groups they are members of are not mapped to any Workflow groups.
User Type Conversion
Beginning with Workflow version 2.2, you can convert Workflow users to domain users, and vice versa, by either adding the applicable domain designation to the user's name or removing the designation from the name, respectively.
If you convert a Windows domain user to a Workflow user, you must subsequently specify access credentials for the user, and, if the permissions that were previously afforded the user, which carry over with the conversion, are no longer appropriate, adjust group associations.