Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Control runtime user accounts.

ReferenceModules SecurityUI → RuntimeUsers | Users | Permissions | Policies | Secrets | Monitor


Security RuntimeUsers (Reference)

 extend solution access dynamically

: Dynamic user management during runtime, allowing user

management

creation and authentication without modifying

the

solution configuration.

RuntimeUsers provide:

  • Dynamic user creation during runtime
  • External database integration
  • Active Directory/LDAP authentication
  • Temporary or permanent user accounts
  • Script-based user management

RuntimeUsers combined with SecurityUsers form the complete Solution Users.

In this page:

Table of Contents
maxLevel2
minLevel2
indent10px
excludeSteps
stylenone


Security → Tutorial | Concept | How-to Guide |  Standards Compliance | Reference

RuntimeUsers vs SecurityUsers

AspectSecurityUsersRuntimeUsers
CreationDesign-time onlyRuntime only
StorageSolution fileExternal database
Engineering AccessYesNo
Modify SolutionYesNo
Runtime AccessYesYes
SourceInternalExternal/Scripts

<ac:structured-macro ac:name="note"> ac:rich-text-body Note: RuntimeUsers cannot access Engineering mode or modify solution configuration. They are application users only. </ac:rich-text-body> </ac:structured-macro>


Configuration Sources

1. Script Creation

csharp

// Create user programmatically
@Security.CreateUser(
    "john.doe",
    "password123",
    "Operator,Maintenance",
    "Enhanced"
);

2. External SQL Database

Configure at Configuration: Datasets → DBs → RuntimeUsers

  • Default: SQLite database
  • Supports: SQL Server, MySQL, PostgreSQL
  • Auto-created table structure

3. AD/LDAP Integration

  • Users validated against directory
  • Created in memory only
  • No database storage
  • See [Windows AD/LDAP Server]

  • RuntimeUsers Table Properties

    Access: Security → RuntimeUsers (read-only view at Security → RuntimeUsers:)

    PropertyDescriptionModifiable
    NameUnique usernameVia script/DB
    PasswordEncrypted credentialVia script/DB
    PermissionsGroup assignmentsVia script/DB
    PolicySecurity policyVia script/DB
    BlockedAccess denied flagVia script/DB
    DeletedSoft delete markerVia script/DB
    InvalidAttemptsFailed login countAuto-updated
    ChangePasswordRequiredForce password changeVia script/DB
    LastChangePasswordUTC_TicksPassword change timestampAuto-updated
    LastBlockedUserUTC_TicksBlock timestampAuto-updated
    LevelHierarchical accessVia script/DB
    CategoryUser classificationVia script/DB
    ContactInfoEmail/phoneVia script/DB
    CompanyOrganizationVia script/DBUserGroupDepartmentVia script/DB

    Database Configuration

    Default SQLite Structure

    Location: <SolutionPath>.dbRuntimeUsers

    Table automatically created with:

    • User authentication fields
    • Permission assignments
    • Policy enforcement
    • Audit tracking

    Custom Database

    1. Configure Datasets → DBs → RuntimeUsers
    2. Set connection string
    3. System creates table if missing
    4. Maintain schema compatibility

    Script Management

    Creating Users

    csharp

    public void CreateOperator(string username, string password)
    {
        bool success = @Security.CreateUser(
            username,
            password,
            "Operator",  // Permissions
            "Default"    // Policy
        );
        
        if (success)
        {
            @Info.Trace($"User {username} created");
        }
    }

    Modifying Users

    csharp

    // Change password
    @Security.ChangePassword("john.doe", "newPassword");
    
    // Update permissions
    @Security.SetUserPermissions("john.doe", "Operator,Supervisor");
    
    // Block user
    @Security.BlockUser("john.doe");

    Deleting Users

    csharp

    // Soft delete (mark as deleted)
    @Security.DeleteUser("john.doe", softDelete: true);
    
    // Hard delete (remove from database)
    @Security.DeleteUser("john.doe", softDelete: false);

    Windows AD / LDAP

    Users

    Characteristics

    • No database storage
    • Memory-only during runtime
    • Permissions from AD groups
    • Automatic authentication
    • Session-based existence

    Configuration

    csharp

    // Enable AD authentication @Security.AuthenticationMode = "WindowsAD"; @Security.ADDomain = "company.local"; // Map AD groups to permissions @Security.ADGroupMapping["Domain Users"] = "Operator"; @Security.ADGroupMapping["Domain Admins"] = "Administrator";

    Integration

    Windows AD Authentication

    Automatic Availability when:

    • Solution runs on Windows
    • Domain connectivity exists
    • Port 3102 (default) accessible

    Configuration:

    1. Navigate to Runtime → Startup
    2. Enable Use WA checkbox
    3. Set PortWA: 3102 (or custom)
    4. Configure redundancy ports if needed

    Connection Methods:

    Rich Client:

    Server: ServerName
    Port: 3102 (AD port)
    Windows Authentication: Enabled

    Web Client URL:

    http://server/fs-2024/TSmartClient.application?port1=3102&wa=true

    LDAP Server Configuration

    Setup:

    1. Navigate to Security → RuntimeUsers
    2. Enter LDAP server in AD/LDAP Server field:
    ldap://company.local:389
    ldaps://secure.company.local:636

    Connection String Examples:

    Standard LDAP:

    ldap://dc1.company.local:389

    Secure LDAP:

    ldaps://dc1.company.local:636

    With Base DN:

    ldap://dc1.company.local:389/DC=company,DC=local

    Permission Mapping

    User Resolution Order:

    1. Check for exact username match in Security → Users
    2. Map Windows groups to permission groups
    3. Apply Guest permissions if no match

    Group Mapping Example:

    Windows Group: Domain\Engineers
    Permission Group: Engineering
    Result: User gets Engineering permissions

    LDAP Attributes Mapping:

    LDAP AttributeSolution Property
    sAMAccountNameUserName
    memberOfPermissions (via groups)
    displayNameDisplay name
    mailContactInfo
    departmentUserGroup

    Runtime Behavior

    User Validation Order

    1. Check SecurityUsers (internal)
    2. Query RuntimeUsers database
    3. Validate against AD/LDAP
    4. Apply Guest if no match

    Authentication Flow

    Client.LogOn(username, password)
    1. Check Engineering Users (SecurityUsers)
    2. Check Runtime Users (Database)
    3. Check LDAP Server (if configured)
    4. First valid match logs in

    Session Management

    csharp

    // Get all active users
    var users = @Security.GetActiveUsers();
    
    // Check if RuntimeUser
    bool isRuntimeUser = @Security.IsRuntimeUser(username);
    
    // Get user source
    string source = @Security.GetUserSource(username); 
    // Returns: "Internal", "Database", "AD"

    Security Configuration

    Forcing AD-Only Access

    1. Enable Use WA in Runtime → Startup
    2. Disable standard authentication port
    3. Configure AD-only port

    csharp

    // Check if using Windows Authentication
    if (@Client.IsWindowsAuthenticated)
    {
        string domain = @Client.WindowsDomain;
        string user = @Client.WindowsUserName;
        @Info.Trace($"AD User: {domain}\\{user}");
    }

    Service Account Configuration

    csharp

    // Configure service account for LDAP queries
    @Security.LDAPServiceAccount = "svc_scada";
    @Security.LDAPServicePassword = GetSecurePassword();
    @Security.LDAPSearchBase = "OU=Users,DC=company,DC=local";

    Best Practices Checklist

    •  Use appropriate source - AD for enterprise, DB for standalone
    •  Set permissions carefully - RuntimeUsers can't be admins
    •  Use secure LDAP - LDAPS on port 636 when possible
    •  Implement audit trail - Track user creation/modification
    •  Regular cleanup - Remove inactive RuntimeUsers
    •  Secure database - Protect RuntimeUsers table
    •  Document user sources - Clear origin tracking
    •  Test authentication paths - Verify all
    paths work
    • methods work

    Common Configurations

    Manufacturing Domain

    AD Server: mfg.company.local
    Port: 3102
    Groups:
      - MFG\Operators → Operator
      - MFG\Engineers → Engineering
      - MFG\Managers → Supervisor

    Enterprise LDAP

    LDAP: ldaps://enterprise.local:636
    Base DN: DC=enterprise,DC=local
    Groups:
      - CN=SCADA_Users → User
      - CN=SCADA_Admin → Administrator

    Troubleshooting

    User not found:

    • Check database connection
    • Verify table exists
    • Review AD connectivity
    • Confirm username format

    Cannot create user:

    • Verify CreateUsers permission
    • Check database write access
    • Review policy restrictions
    • Confirm unique username

    AD/LDAP users not working:

    • Test domain connectivity
    • Verify group mappings
    • Check authentication mode
    • Review domain credentials

    Database errors:

  • Verify connection string
  • Check table schema
  • Review permissions
  • Wrong permissions:

    • Check group name spelling (exact match required)
    • Review permission mapping
    • Test with known group

    Slow authentication:

    • Check domain controller load
    • Review network latency
    • Optimize LDAP queries
    • Consider caching

    See Also

    Test database access



    In this section...

    Page Tree
    93DRAF
    root@parentspaces