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

In this section...