Page History

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

Windows AD Authentication

Automatic Availability

Windows AD support is

automatically

enabled when:

• Solution runs on Windows

In this case, you will use the configured users for the Active Directory login. If the Windows OS has the same name as the user created in Security → Permissions, the application will use the permissions configured for that user. Otherwise, it will use the permissions for the Guest user.

You just need to connect the clients (RichClient or SmartClients) using the Windows AD port, as defined in Runtime → Execution Profiles or Runtime → Startup. The default port is 3102, but this can be changed in the project configuration.

• 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

When using Redundancy, the port follows the command line defined to start the server projects. 

Accepting only AD connections

When running the solution, it is also possible to force to use the AD only, disabling the solution denied users from runtime access.

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

User Identification

The Windows user that is logged in on the computer accessing the server where the solution is running will be the username identified by the solution.

When you are using client instances, the server computer is the one that validates the user for the client. Therefore, the logged Windows user on the client computer needs to exist on the server computer and be in the same domain group.

After user validation, the user's Windows group will determine which project security permission will be used. It will search in the project's security permissions for the same Windows group name. If it finds an exact match, then the security permissions for that name will be used in the project for the logged user. If no names match, the Guest permission will be used.

LDAP Server Integration

To enable the LDAP Server in the platform, please go to Security → RuntimeUsers. Then, type the LDAP server's name in the AD/LDAP Server field.

To integrate the LDAP Server, the only customization you need to do is to use the AD/LDAP Server field.

The project Client.LogOn() method in the LOGON page will work properly after enabling the LDAP Server.

When this method is called, it will check the project for an Engineering User. If none are found, it will check for a Runtime User. If no Runtime Users are found, it will check for an LDAP user if the LDAP Server is configured. The first user that is found and validated will be the user that is logged into the project.

After user validation, the user’s Windows group will determine which project Security Permission will be used. It will search in the project Security Permissions for the same Windows Group name. If it finds an exact match, the Security Permission will be used in the project for the logged-in user. If no names match, the Guest permission will be used.

In this section: