Control runtime user accounts.

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


Security RuntimeUsers (Reference): Dynamic user management during runtime, allowing user creation and authentication without modifying 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.


RuntimeUsers vs SecurityUsers

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

Note: RuntimeUsers cannot access Engineering mode or modify solution configuration. They are application users only.


Configuration Sources

1. Script Creation

csharp

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

2. External SQL Database

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

RuntimeUsers Table Properties

Access: Security → RuntimeUsers (read-only view)

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

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 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 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

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



In this section...