Users are denied permissions unexpectedly

Possible causes and solutions:

The security policy Require computer accounts for all client machines
is set to Enabled
and the user is attempting to use Remote Desktop Services for remote access to the

FactoryTalk

network directory.

If users requires access to the

FactoryTalk

network directory using Remote Desktop Services, change the security policy Require computer accounts for all client machines
setting to Disabled
.

Additionally, check the policy setting for Identify terminal server clients using the name of:

If set to Terminal client
, all computers connecting to the network directory must have computer accounts in the network directory in order to log on.

If set to Server computer
, the Remote Desktop Session Host must have an account in the network directory in order for clients to log on.

There are conflicting permission sets. If conflicting explicit permissions are set at the same level, Deny
takes precedence over Allow
. For example, if you explicitly deny the Operators group access to an application, but you explicitly allow an individual user account (Jane) access to the application, Deny takes precedence over Allow, and Jane cannot access the application if her user account is a member of the Operators group. This happens because conflicting explicit permissions are set on the same resource. To Allow Jane access to the application, you must Deny the Operators group access to a resource at a higher level in the hierarchy (for example, the

FactoryTalk

network directory or

FactoryTalk

local directory in which the application is located), and then explicitly allow exceptions for the application.

Check the permissions for the user and the groups the user belongs to and modify the permissions as needed to permit access.

A user with a

Windows

-linked account is using a blank password. Users should not use blank passwords for

Windows

-linked accounts, otherwise they might experience intermittent security failures or an inability to log on. As a matter of good security practice, do not use blank passwords with accounts.

Have the user change their

Windows

account to use a password if possible. If there is an operational requirement that users do not use a password for

Windows

-linked accounts, on each user's local computer disable the Windows
local security policy Accounts: Limit local account use of blank passwords to console logon only
.

Group membership changes are pending for a user account.

If a user account's group memberships have changed or if a user account was added to a user group account, the user must log off

FactoryTalk

and then log on again before the changes take effect.

An action group was deleted during the user session.

If an action group was deleted, a user might now be denied permissions that the action group explicitly allowed. To correct this problem, either:

Recreate the action group and then reassign permissions to the user and resource (permissions are not restored by recreating an action group with the same name as the deleted action group)

Assign the required permissions explicitly to the user or group's account.

If the action group is used in many resources, it might be quicker and easier to restore the

FactoryTalk Directory

from a backup than to recreate the action group and recreate its permissions.

The action group explicitly denies permissions

If using action groups, and have explicitly denied permissions to a group that includes actions users need to complete a task, remove the affected actions from the action group, and then reset the permissions for those actions.

Permissions are not defined after restoring

FactoryTalk Directory

, the System folder, or an application

If using local workstation accounts as part of a

Windows

workgroup,

Windows

-linked user accounts will be missing their security settings. This happens because the unique identifier associated with the account cannot be reattached to the restored account for security reasons. After restoring the

Windows

-linked account, permissions must be recreated. To prevent this problem from occurring, use

Windows

domains instead of workgroups.

If restoring an application without its associated System folder to a different directory or to a directory on a different computer, the security permissions associated with the original application no longer work in a restored application that is associated with a different System folder. Security settings that no longer work are identified by a dimmed user icon, followed by the account's unique ID. Recreate these permissions after restore.

Security settings are not configured for the directory

Security settings are completely separate in the network directory and local directory. Changes made to the security settings in the network directory do not affect the local directory and vice versa. If using both a network directory and a local directory, set up security in each directory separately. Additionally, ensure that users are logging on to the correct directory.

Installing or upgrading the version of

FactoryTalk Services Platform

on to a client computer that is connected to a FactoryTalk Network Directory Server running an earlier version might cause unexpected results with

Rockwell Automation

applications. This is because the later release of

FactoryTalk Services Platform

might include new product policies or new securable actions.

To avoid this problem, upgrade the

FactoryTalk

platform software on the computer hosting the

FactoryTalk

Network Directory Server to the same version as the latest version of the