Configuring WinCC 7.4 SP1 User Administration and Authorizations

Overview of WinCC V7.4 SP1 User Administration

SIMATIC WinCC V7.4 SP1 implements role-based access control through a three-tier model: Authorizations (the permission definitions), Users (named operator accounts), and Groups (named bundles of users that share the same authorization set). All three are maintained in the User Administrator editor, which lives in the WinCC Explorer navigation tree and writes its data to the project runtime database. Authorizations in WinCC V7.4 SP1 are addressed by a numeric identifier between 0 and 999; system-defined authorizations occupy the 0–100 range and customer-defined authorizations occupy the 100–999 range. The numeric identifier — not the human-readable name — is what the C and VBS runtime APIs use to gate function calls, which is why a consistent numbering scheme should be agreed upon project-wide before any custom authorizations are created.

When a project is first created in WinCC V7.4 SP1, a single predefined user account named Administrator exists with no password and full system rights. Adding additional operators is a normal, documented procedure; however, projects that were originally commissioned with only the default account, or that have been migrated from a WinCC V7.0 or earlier database, frequently appear to lose the ability to assign granular authorizations. In nearly every case the cause is one of three things: the WinCC installation is missing a service pack update, the local SQL Server instance that hosts the project database has lost the user administration tables, or the user is editing the project on an engineering station whose WinCC version does not match the server. SIMATIC WinCC V7.4 SP1 Update 9 addresses a number of issues in this area and is the minimum recommended patch level for new projects. The Update 9 release can be obtained from Siemens Industry Online Support entry 109762790.

Authorization Number Space and Predefined Authorizations

The authorization number space in WinCC V7.4 SP1 is fixed at 0–999. Numbers 0–100 are reserved for Siemens-defined authorizations and must not be redefined; numbers 100–999 are available for customer-defined function authorizations. The 0–100 range includes the constants referenced by every standard WinCC picture template and the WebNavigator client, so changing them is treated as a project-destroying modification and is blocked at compile time.

For custom function authorizations, the recommended numbering convention is to reserve blocks of numbers for each functional area. For example, in a process line with four packaging machines, allocate 100–199 to machine 1, 200–299 to machine 2, and so on. The numeric ID becomes a hard-coded literal in C and VBS scripts, so well-organized numbering is critical for long-term maintainability.

Prerequisites

Before adding authorizations and users in WinCC V7.4 SP1, verify the following:

1. The engineering station runs SIMATIC WinCC V7.4 SP1 with Update 9 or later. The Update 9 release is available from Siemens entry 109762790.
2. The WinCC project opens without database migration warnings. If the project was originally built in WinCC V7.0 or V7.2, allow the migration to complete before configuring user administration.
3. The local Microsoft SQL Server instance used by WinCC (default instance name WINCC) is running and reachable. WinCC Explorer → Project Properties → Computer shows the active database server.
4. You are logged in to the engineering station with a Windows account that has local administrator rights; the WinCC User Administrator editor writes to the project database and to %ProgramData%\Siemens\Automation\WinCC\.
5. For runtime verification, either a redundant engineering station or a WinCC Runtime license on the engineering machine is available.

Step-by-Step: Creating Custom Function Authorizations

Custom authorizations are the only way to gate application-specific actions such as "Reset maintenance counter for extruder 3" or "Acknowledge line clear condition". Follow this procedure to define them in WinCC V7.4 SP1.

1. Open WinCC Explorer on the engineering station and load the target project.
2. In the navigation tree, right-click User Administration and select Open. The User Administrator opens with three tabs: Users, Groups, and Authorizations.
3. Click the Authorizations tab. The default view shows the Siemens-defined authorizations (0–10 and 100).
4. Click in the next free row of the Authorization Number column and enter a unique number in the 100–999 range.
5. In the Authorization Name column, enter a descriptive name. Use a consistent naming convention such as Area01_ResetCounter or Line3_StartSequence.
6. Press Enter to commit the entry. The authorization is now available for assignment to users and groups.
7. Repeat for every function authorization your runtime scripts and graphic objects need to check.
8. Close the User Administrator; the changes are written to the project database immediately.

Step-by-Step: Adding Users and Assigning Authorizations

Once the authorization set is defined, the next step is to create user accounts and to grant authorizations either directly on the user or via group membership. Group membership is preferred for long-term maintainability because a single group change updates every member.

1. In the User Administrator, click the Users tab.
2. Click in the first empty row of the User Name column and enter the operator's login name. Login names are case-insensitive in WinCC V7.4 SP1 and may contain letters, digits, the underscore, and the hyphen.
3. Click the Password column and enter an initial password. The password is stored as a salted hash in the project database; the plain text is not recoverable.
4. To grant an authorization directly to the user, double-click in the corresponding cell of the authorizations matrix. A check mark indicates the user holds that authorization.
5. To organize users, switch to the Groups tab and create a group (for example, LineOperator, ShiftSupervisor, Maintenance). For each group, check the authorizations the group should hold.
6. Back on the Users tab, assign each user to one or more groups. A user's effective authorization set is the union of direct grants and group grants.
7. Set the Time Zone and Logon Time Limit per user. The logon time limit defines the maximum number of hours a single logon remains valid before re-authentication is required.
8. Save and close the User Administrator.

Applying Authorizations to Graphics and Faceplates

Authorizations become effective when they are referenced by a runtime object or a script. The most common reference point is the Authorization property of a WinCC graphic object (button, I/O field, slider, faceplate instance).

1. Open the target picture in Graphics Designer.
2. Select the object whose operation you want to gate (for example, the Start button).
3. In the Properties dialog, navigate to Miscellaneous → Authorization.
4. Enter the numeric authorization ID (for example, 5 for process operation, or 103 for a custom authorization).
5. Close the Properties dialog. The change is saved with the picture.
6. At runtime, the button is disabled if the currently logged-on user does not hold authorization 5 (or 103).

For faceplates, the same property exists on the faceplate instance and is exposed as a configurable interface property when the faceplate is placed. The faceplate type can also enforce a minimum authorization at the type level; place a check on the type's Authorization property in the type's own Properties dialog to ensure every instance of the faceplate requires that authorization.

Authorization Checks in C Scripts and VBS

When a script performs an action that is not bound to a single graphic object — for example, a global action that runs once a minute and resets counters — the script must perform its own authorization check. WinCC V7.4 SP1 exposes this through the standard function PWRTCheckPermission() in C and through the VBS object model in VBScript.

C Action — checking a single authorization

// C action in a global or picture script
// Returns TRUE if the current user holds authorization 103.
#include "apdefap.h"

BOOL _main(char* lpszPictureName, char* lpszObjectName, char* lpszPropertyName)
{
    #define AUTH_RESET_COUNTER_LINE3  103

    if (PWRTCheckPermission(AUTH_RESET_COUNTER_LINE3))
    {
        // User is authorized — perform the action
        SetTagDWord("Line3.CounterReset", 1);
        return TRUE;
    }
    else
    {
        // Not authorized — log and abort
        printf("Authorization 103 missing for user; counter reset denied.\r\n");
        return FALSE;
    }
}

VBScript — checking authorization and prompting for logon

' VBS action on a button click event in Graphics Designer
Const AUTH_REQ = 5  ' Process operation level

If HMIRuntime.Authorization >= AUTH_REQ Then
    ' User holds at least process-operation authority — proceed
    HMIRuntime.Tags("Line3.StartCommand").Write 1
Else
    ' Insufficient privilege — log denial and prompt for escalation
    HMIRuntime.Trace "Authorization 5 missing; command denied." & vbCrLf
    HMIRuntime.UI.Logon
End If

Migrating Legacy Projects With the Default Administrator Only

A common situation is to inherit a project that was commissioned years ago with the default Administrator account and no additional user administration. The following procedure restores a proper user model without requiring a full project re-build.

1. Open the legacy project on a WinCC V7.4 SP1 engineering station. If a migration dialog appears, accept and let it complete.
2. Open the User Administrator. The default Administrator account is listed under Users with no password. Do not delete this account; WinCC runtime requires at least one user with Auth 1 (User Administration) to exist.
3. Create the target group structure (Operator, ShiftSupervisor, Maintenance, Administrator) as described earlier.
4. Create the target users and assign them to groups. Optionally set an initial password and instruct the operators to change it at first logon.
5. Set a strong password on the default Administrator account — even if you do not plan to use it for daily operation, an unpassworded administrator is a known audit finding for WinCC V7.4 SP1 projects.
6. On every picture that gates actions with the Authorization property, verify that the property is set to the correct numeric ID. Pictures created in older projects often have an empty Authorization property, in which case the action is permitted for every logged-on user.
7. Compile the project and start runtime in simulation mode to verify the new user model before deploying to production.

Runtime Configuration, Password Policies, and SIMATIC Logon

Beyond the per-user password, WinCC V7.4 SP1 supports a project-wide password policy. In WinCC Explorer, select Project Properties → User Administration to set the minimum password length, the required character classes (upper, lower, digit, special), and the maximum number of failed logon attempts before an account is locked. The default settings are 6 characters minimum and 5 attempts; harden these for any production system exposed to external networks.

For site-wide single sign-on, WinCC V7.4 SP1 can be configured to delegate authentication to SIMATIC Logon, which in turn uses a central Windows Active Directory. When SIMATIC Logon is enabled, the User Administrator maintains the authorization set but the password is verified against Active Directory. This combination is the recommended deployment for plants governed by IEC 62443 or similar industrial cybersecurity frameworks.

Verification and Diagnostics

After configuring the user model, perform the following verification steps before declaring the project ready for production deployment.

1. Start WinCC Runtime in simulation mode from the engineering station.
2. Log on as the Operator user. Confirm that operator-level buttons are enabled and that supervisory buttons (for example, the line clear acknowledgement) appear disabled.
3. Log off, log on as the ShiftSupervisor user. Confirm that the previously disabled buttons are now enabled.
4. Open the WinCC Diagnostic Window (Alt+Tab from the runtime window) and inspect the User tab. Verify that the active user, group memberships, and effective authorization set match the design document.
5. Trigger a script that performs an explicit PWRTCheckPermission() call and confirm the expected branch is taken.
6. Reboot the runtime and re-test. A common symptom of an incomplete configuration is that the first logon after a reboot inherits the previous session's authorization, which indicates the runtime is reading the database from a stale cache.

Troubleshooting Matrix

Field-Commissioning Notes

Three caveats drawn from production deployments apply whenever a WinCC V7.4 SP1 user administration is rolled out to an active line:

• Picture-by-picture audit. Inherited projects routinely have 10–20% of picture objects with an empty Authorization property. A targeted audit using the Cross Reference editor (Tools → Cross Reference, with the Authorization property filter) is the fastest way to identify these and to assign the correct IDs.
• Group-level vs. user-level grants. Always prefer group-level grants. Direct user-level grants survive user renames and group restructuring badly and are difficult to audit. A direct grant should be used only for a one-off exception that has a documented expiry date.
• Backup of the project database. WinCC V7.4 SP1 stores the user database in the project's runtime database; the file is not part of the source project archive. After every user administration change, take a backup of the runtime database files (typically under <ProjectName>\<ComputerName>\) in addition to the normal project source backup.

Frequently Asked Questions