Fixing SIMATIC Logon Change Logon Button Not Responding in ALM

Problem: SIMATIC Logon "Change Logon" Button Has No Effect in Automation License Manager

Symptom: A user opens Automation License Manager (ALM), attempts to invoke Change Logon from a SIMATIC Logon entry to create or modify an account, and nothing happens. The dialog does not appear, no error is raised, and the system returns to its previous state. The same condition can occur when an engineer selects Options > Access Protection > Enable inside the legacy SIMATIC Manager and the dialog silently closes without applying protection.

Affected environment observed in the field:

• Automation License Manager V5.0 + SP1, 32-bit edition
• SIMATIC Logon runtime component shipped with WinCC V7.x / TIA Portal V13-V20
• Windows 7 SP1 / Windows 10 LTSC workstations joined to a local workgroup (no domain)

This article explains the architectural reason the dialog does nothing and provides the correct procedure for creating SIMATIC Logon users. The recommended fix is independent of ALM build because ALM is never the correct tool for user administration.

Root Cause: ALM Is a License Tool, Not a User Store

Automation License Manager exists to manage, transfer, and validate Siemens software licenses (Floating, Single, Rental, Trial). It is not designed to hold user accounts, role assignments, or password hashes. The Change Logon entry visible inside ALM corresponds to the Windows service account that owns the ALM process; it does not create SIMATIC Logon identities.

SIMATIC Logon uses two stores:

1. Windows User Management - the authoritative source of users and groups. Located under Computer Management > System Tools > Local Users and Groups (workgroup) or Active Directory Users and Computers (domain).
2. WinCC User Administration - the runtime map that grants WinCC/TIA Portal permissions to the Windows groups.

If you only clicked Change Logon in ALM, no user is created because ALM has no schema for users. Access Protection in SIMATIC Manager requires a valid Windows group with the Logon_ prefix already present on the workstation; otherwise the toggle closes silently because the validation step finds no eligible principal.

SIMATIC Logon Architecture and Identity Flow

SIMATIC Logon is the central user-administration component for WinCC Runtime, WinCC Professional (RT Professional), Panels, Comfort Panels, and PC-based HMI systems. Central user administration using SIMATIC Logon keeps user credentials outside the HMI project so the same user account can authenticate to multiple runtime instances, panels, and engineering stations.

Identity flow at runtime:

1. Operator enters username/password on the panel or RT client.
2. The runtime calls the SIMATIC Logon service (SLSS) on the engineering station or domain controller.
3. SLSS validates the principal against Windows (local SAM or Active Directory).
4. The service returns the user's group memberships to the runtime.
5. WinCC compares the groups against its permission table and grants the configured authorization.

Because step 3 depends entirely on Windows, ALM is excluded from this path. Configuring SIMATIC Logon is documented in the official SIMATIC Logon help PDF and the TIA Portal V20 user-administration manual:

• SIMATIC Logon Help (English, slhelp_b_en-US.pdf)
• Central user administration using SIMATIC Logon (TIA Portal V20)
• Logging on using SIMATIC Logon (TIA Portal V20)

Prerequisites Before Creating Users

Step-by-Step: Correctly Creating a SIMATIC Logon User

Step 1 - Create the role groups in Windows

1. Open Computer Management (right-click This PC > Manage).
2. Navigate to System Tools > Local Users and Groups > Groups.
3. Create one group per role. Use the prefix exactly as shown:

Logon_Administrator
Logon_Manager
Logon_Operator
Logon_Viewer

4. Add the appropriate Windows users to each group as required.

Step 2 - Mirror the groups inside WinCC User Administration

1. In the WinCC project, open User Administration (WinCC Explorer) or Runtime Settings > User administration (TIA Portal).
2. Create a group entry with the identical name you used in Windows, including the Logon_ prefix.
3. Assign the operator-level authorizations to the group:

Step 3 - Create the Windows user

1. Under Local Users and Groups > Users, create the operator account (example: seaf).
2. Set a strong password and clear User must change password at next logon.
3. Add the user as a member of one or more Logon_ groups (for example, seaf → Logon_Manager).

Step 4 - Enable SIMATIC Logon in the runtime

In TIA Portal V20 (or compatible WinCC):

1. Open the project tree > Runtime settings > User administration.
2. Check Enable SIMATIC Logon.
3. Select Windows domain if the station is joined to Active Directory, otherwise select Windows workgroup.
4. Compile and download the project to the panel or RT station.

Step 5 - Configure the SIMATIC Logon service

1. Launch Start > SIMATIC > SIMATIC Logon > Configure SIMATIC Logon.
2. Enter the logon credentials of a Windows administrator.
3. Confirm that the SLSS service is registered and started.

Why "Enable Access Protection" in SIMATIC Manager Does Nothing

Legacy SIMATIC Manager projects (STEP 7 V5.x) include an Access Protection toggle under Options. When enabled, the project requires the active Windows user to be a member of a defined group. If no project-level group is configured, or if no user with that membership opens the project, the toggle reverts silently. The dialog does not display an error because STEP 7 internally considers the request fulfilled once the validation passes against an empty principal set.

To make Access Protection active:

1. Open the S7 project in SIMATIC Manager.
2. Right-click the project > Properties > Protection.
3. Set the password and define the authorized user/group.
4. Save and reopen the project - the login prompt now appears.

Compatibility Matrix for SIMATIC Logon Components

Automation License Manager V5.0 + SP1 - What "Change Logon" Actually Does

On ALM V5.0 + SP1 (32-bit), the Change Logon menu modifies the account under which the almservice runs. This is unrelated to SIMATIC Logon users and is required only when:

• Floating licenses must be returned to a license server across a service restart boundary.
• The ALM service must impersonate a domain user that owns the license file.
• Service account passwords are rotated and ALM must re-bind.

If none of those apply, leave ALM running under the default LocalSystem account and perform all user administration in Windows + WinCC as described above.

Verification Checklist

1. Open Computer Management > Local Users and Groups and confirm the Logon_ groups exist.
2. Open WinCC User Administration and confirm each Windows group has a mirror entry with the correct authorizations.
3. Log on to the runtime as the test user. The login dialog should accept the Windows credentials.
4. In WinCC, check Tools > User Administration > Status - the user's groups and their assigned authorizations must be listed.
5. Verify SLSS event log is free of warnings: Event Viewer > Applications and Services Log > SIMATIC Logon.
6. Stop and restart the runtime - the logon must succeed without re-entering credentials when the user is already cached.

Troubleshooting Matrix

Field-Proven Caveats

• Domain controllers must be reachable on UDP 389 (LDAP) and TCP 88 (Kerberos) during the first login of a session. Subsequent logons use cached Kerberos tickets.
• If the panel is in a workgroup and the user account is local, the username must be entered in the form HOSTNAME\username or .\username.
• Do not delete the Logon_ group from Windows while a WinCC project is running - the runtime holds open handles and may crash when re-validating.
• Long-running WinCC projects that upgrade from WinCC V7 to WinCC V8 must recreate the WinCC-side group entries even when Windows groups are unchanged. The internal authorization IDs change between major versions.
• If you enable Secure communication on a Comfort Panel with firmware V14 or earlier, SIMATIC Logon V1.5 fails - upgrade panel firmware to V15.0 or later.

Quick Reference: Command-Line and Service Names

FAQ