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

RuntimeUsers vs SecurityUsers

<ac:structured-macro ac:name="note"> ac:rich-text-body 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 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 read-only view at Security → RuntimeUsers:

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

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

Runtime Behavior

User Validation Order

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

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"

Best Practices

1. Use appropriate source - AD for enterprise, DB for standalone
2. Set permissions carefully - RuntimeUsers can't be admins
3. Implement audit trail - Track user creation/modification
4. Regular cleanup - Remove inactive RuntimeUsers
5. Secure database - Protect RuntimeUsers table
6. Document user sources - Clear origin tracking
7. Test authentication - Verify all paths work

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 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
• Test database access

CONSOLIDATE:

Windows AD / LDAP Server (Reference)

Windows AD Authentication

Automatic Availability

Windows AD support is automatically enabled when:

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

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

Configuration

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

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

Configuration Steps

1. Create permission group matching AD group name
2. Set desired permissions for group
3. AD users automatically inherit permissions

LDAP Server Integration

Configuration

1. Navigate to Security → RuntimeUsers
2. Enter LDAP server in AD/LDAP Server field:

   ldap://company.local:389
   ldaps://secure.company.local:636

Authentication Flow

csharp

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

User Identification

Domain Requirements

• Client user must exist on server domain
• Same domain group membership required
• Server validates client credentials
• Domain trust relationships honored

Username Formats

DOMAIN\username     // NetBIOS format
username@domain.com // UPN format
username           // Local/simple format

Forcing AD-Only Access

Configuration

Disable solution users, accept only AD:

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

Implementation

csharp

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

LDAP Configuration Details

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

LDAP Attributes Mapping

Redundancy Configuration

Primary/Backup Servers

Primary AD Port: 3102
Backup AD Port: 3103

Command Line:

TServer.exe /port1:3102 /wa:true
TServer.exe /port1:3103 /wa:true /backup

Security Considerations

Best Practices

1. Use secure LDAP - LDAPS on port 636
2. Limit service account - Minimal permissions
3. Configure firewalls - Restrict AD ports
4. Regular group audits - Review mappings
5. Test failover - Verify redundancy
6. Document mappings - Clear group relations
7. Monitor authentication - Track failures

Service Account

csharp

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

Troubleshooting

Cannot authenticate:

• Verify domain connectivity
• Check port accessibility
• Confirm user exists in AD
• Review group memberships

Wrong permissions:

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

LDAP connection failed:

• Test LDAP server access
• Verify credentials
• Check SSL certificates
• Review firewall rules

Slow authentication:

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

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

In this section...