WinCC 5.1 Client Server Password Prompt Resolving MCP

Problem Overview

When launching a WinCC V5.1 runtime client from a Windows 2000 SP4 workstation against a configured WinCC server, operators encounter a Windows security dialog demanding credentials the moment the runtime attempts to load the server-resident *.mcp project file. The dialog interrupts project startup, blocks the operator from reaching process screens, and on machines configured with mismatched user databases prevents any subsequent connection attempts until credentials are entered. The symptom appears in single-seat pilot builds that are then scaled to multi-user deployments, and on sites where the server project is delivered to the client using file sharing rather than a dedicated WinCC duplicate project.

The dialog is not produced by WinCC's internal user administration. It is generated by the Windows 2000 logon subsystem when the WinCC runtime on the client opens a network resource that requires SMB (Server Message Block) authentication. Understanding this distinction is the key to a clean resolution: configuring WinCC user rights does not eliminate the prompt, and configuring Windows accounts incorrectly eliminates the prompt but breaks WinCC operator authorization downstream.

WinCC V5.1 Multi-User Architecture

WinCC V5.1 supports distributed SCADA topologies through a Client-Server model. The server runs the WinCC Server service, hosts the project database, archives process values and alarms, and exposes the configured screens. A client workstation runs the WinCC Client runtime and consumes screens, tags, and archives from the server. The WinCC Explorer on the server contains the Server project type while the client machine contains a project that points at the server via the project path configured under Computer Properties > Startup.

Project files in WinCC V5.1 use the *.mcp extension for the central master project, *.mcd for duplicate project archives, and *.ldb for local database files used during runtime caching. When the client runtime initializes, it must read the server's *.mcp file over the network. The file resides in a share (typically \\<ServerName>\<ProjectName>) and is accessed through standard Windows network APIs. This is the operation that triggers the password dialog when the client machine cannot establish a transparent authentication session.

Root Cause Analysis

The Windows credential prompt is the result of NTLM/Kerberos-style SMB authentication failing between the client and the server. On Windows 2000 SP4 with default LAN Manager authentication settings, several conditions will cause the client runtime to fail an automatic (pass-through) logon and force a manual dialog:

1. User account mismatch. The Windows user name or password on the client workstation differs from the account the server recognizes on its SAM database or domain controller. Windows cannot reuse the current logon context to access the share.
2. Workgroup membership with no remembered credential. In a workgroup (no Active Directory or NT 4.0 domain), Windows does not have a domain trust to pass credentials through. If no persistent credential has been stored for the server, the OS prompts.
3. Domain trust missing or expired. In a domain environment, a stale or broken trust relationship between the domain the client belongs to and the resource domain the server belongs to causes the same prompt.
4. Local Security Policy restrictions. Windows 2000 policies such as Network access: Do not allow storage of credentials or .NET Passports for network authentication or restrictions on LM authentication level can force interactive prompts.
5. Service account context mismatch. If WinCC Client runtime is launched from a different logon session than the one used to map the network share, the runtime opens the share under a different security token.

The Siemens support entry referenced in the operator's incident (Siemens Support FAQ 27061845) confirms that the prompt originates from Windows authentication on the network share, not from WinCC user administration.

Diagnostic Procedure

Before applying any fix, isolate the cause with the following field-proven sequence:

1. From the client workstation, open a command prompt and execute net use \\\<ServerName>\<ProjectName>. Note whether the prompt appears, the error code returned, and the message text.
2. Run whoami /all on the client and compare the user SID against the same command executed on the server (using an account that has administrative access to both).
3. Open Control Panel > Administrative Tools > Event Viewer on the server and inspect the Security log for logon events with status 0xC000006A (unknown user name) or 0xC0000234 (account locked out).
4. Verify domain/workgroup membership with net config workstation on both machines. The Workstation domain field should match the configuration you expect.
5. From WinCC Explorer on the client, inspect Computer > Properties > Startup and confirm the server project path exactly matches the share name (case-sensitive on NTFS).
6. Check the WinCC diagnostic file WinCC_Service.log in %ProgramFiles%\Siemens\WinCC\diagnose for project load errors preceding the dialog.

Solution 1: Synchronize Windows User Accounts

The most direct resolution is to ensure the operator's Windows account on the client workstation is identical (same user name, same password) to an account that has access rights on the server. In a workgroup this means creating a local account on each machine with the same user name and password. In a domain, the same domain user account should log on at the client.

1. On the server, open Control Panel > Administrative Tools > Computer Management > Local Users and Groups > Users.
2. Create (or verify) a user named identically to the operator account. Set a known password; do not require password change at next logon.
3. On the client, create the same user with the same password.
4. Grant both accounts at least Read rights on the WinCC project share.
5. Log off and log back on at the client as the synchronized account.
6. Open the project share once via Windows Explorer, check Remember my password, and confirm the share opens without a prompt.
7. Launch the WinCC Client runtime; the dialog should no longer appear.

Solution 2: Configure Persistent Network Credentials

Where identical accounts are not possible (for example, the client operator logs on with a personal account but the WinCC runtime runs under a service account), use the Windows Stored User Names and Passwords applet to inject a persistent credential for the server:

1. On the client, open Control Panel > User Accounts > Advanced > Manage Passwords.
2. Click Add and enter the server name (e.g., WINCCSERVER), the Windows account that has access to the share, and its password.
3. Set the logon domain to match the server's workgroup or domain (use . for local accounts on a workgroup server).
4. Confirm and close. Windows will now reuse this credential automatically for any SMB connection to that server.
5. Restart the WinCC Client runtime to ensure new credentials are picked up.

This approach keeps the operator's interactive logon separate from the runtime's network access context and is preferred in mixed-trust environments.

Solution 3: Verify WinCC Internal User Administration

Because operators often confuse the Windows dialog with a WinCC login prompt, validate that the WinCC user administration is properly configured. Open WinCC Explorer > User Administrator on the server and confirm:

• An operator account exists with appropriate authorization level (e.g., Level 4 for control, Level 6 for administration).
• The account's WinCC logon password (configured under the Password column) is known and current.
• Authorization is granted on the relevant areas (picture hierarchy, tag read/write, archive operations).
• The Computer Properties > Startup on the client has User Administrator configured to auto-logon the operator, or it requires manual WinCC logon after the Windows authentication resolves.

Solution 4: Network and Share Configuration

Several share-level settings will trigger the prompt even with matching accounts:

1. Open the project folder's sharing properties on the server (right-click > Sharing > Permissions) and confirm the synchronized user has at least Read permission.
2. If NTFS permissions are stricter than share permissions, both must allow access. Check the Security tab on the folder and verify the user (or a group containing the user) has Read & Execute, List Folder Contents, and Read.
3. Disable Access-based Enumeration if it is enabled and clients are intermittently receiving access-denied errors.
4. Confirm the Server service is running on the server machine and the TCP/IP NetBIOS Helper service is started on both client and server.
5. Open Local Security Policy > Local Policies > Security Options and set Network access: Sharing and security model for local accounts to Classic - local users authenticate as themselves on both machines. The default Guest-only setting forces fallback to a guest identity and triggers prompts.

Solution 5: Registry Adjustments for Legacy Authentication

Windows 2000 SP4 with restrictive LM/NTLM policy can prevent pass-through authentication to older or mixed servers. Use the registry only after exhausting the user-account and share-configuration fixes, and back up the registry first.

After editing, restart the client (and server if any LSA-related value was changed) and test again.

Edge Cases and Field Cautions

• Case-sensitivity: Windows 2000 user names are not case-sensitive, but WinCC V5.1 internal user names and group names may be. Match them carefully when migrating operators between machines.
• Password expiry: If the synchronized account has a password expiration policy, the prompt will reappear after the policy interval. Set the password to Never expires for service-style accounts, or use a managed rotation process with downtime.
• DNS suffix mismatches: Mixed environments where the client resolves the server by NetBIOS but the server expects FQDN access can cause intermittent prompts. Configure the same DNS suffix search order on both machines.
• Firewall and NetBIOS: If Windows Firewall is enabled on the server (less common on Windows 2000, but possible after applying later updates), UDP 137/138 and TCP 139 must be open for SMB and NetBIOS resolution. Without these the share appears as unreachable and a credential prompt with an error message may surface.
• Time skew: Kerberos authentication (if a domain controller is involved) requires less than 5 minutes time skew between client and server. Check with net time \\\<ServerName> and resync if needed.
• Multi-user project file locking: Only one writer may hold the *.mcp file. If the server is also in a development transition, the file may be held exclusively, and clients attempting to open it during this state will see authentication failures misreported as password prompts.

Verification Procedure

1. Log on to the client workstation as the synchronized account (Solution 1) or as an account that has a stored credential (Solution 2).
2. Open Windows Explorer and navigate to \\<ServerName>\<ProjectName>. The directory listing must open without any dialog. If a dialog appears, the underlying Windows authentication is not yet resolved; do not proceed.
3. Open the *.mcp file by double-clicking. WinCC Explorer should start and load the project without requesting credentials.
4. Launch WinCC Runtime. Verify that the operator either auto-logs on or that the WinCC logon dialog (separate from Windows) accepts the configured credentials.
5. Open Tools > Status of Server Connections in WinCC Runtime and confirm the server tag list, alarm list, and archive list report Connected.
6. Force a tag write from the client and verify the change appears in the server archive.
7. Restart the client and re-verify; a successful cold-boot test confirms the persistent credential path is functioning.

Troubleshooting Matrix

FAQ