Page History

Control runtime user accounts.

Reference → Modules →Security → UI → RuntimeUsers | Users | Permissions | Policies | Secrets | Monitor

RuntimeUsers vs SecurityUsers

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)

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:

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

• Security Module (Reference) - Complete security documentation
• Security & Compliance (Tutorial) - Setup guide
• Standards Compliance (How-to Guide) - Regulatory requirements

Image Removed

Understanding RuntimeUsers

The combination of the Runtime Users and the ones defined at the SecurityUsers table are called Solution Users.

The RuntimeUsers can be enabled from the following sources:

• Creating RuntimeUsers with Scripts, using the Security namespace 
• From External SQL databases (As defined in the Dataset.DB.RuntimeUsers connections)
• Integration with AD or LDAP server

RuntimeUsers from AD or LDAP

RuntimeUsers who access the Solution based on AD/LDAP validation will not appear in the RuntimeUsers Database. These users are created directly in memory while the Solution is running, as their usernames and permissions are managed by external security servers

For Information to use AD/LDAP go to Windows AD / LDAP Server.

In this section: