Skip to content

SecurITaas Windows Integration Guide

Introduction

This document provides step-by-step instructions for configuring Windows domain controllers and target Windows servers to work with SecurITaas FIDO authentication using smart cards. This includes setting up trust relationships, installing credential providers, and procedures for uninstalling these configurations.

Smart Card Flow Diagram

Note: All steps in this guide require Domain Administrator privileges on domain controllers and local Administrator privileges on target Windows servers.

Prerequisites

Before beginning, ensure you have:

  • Access to SecurITaas server (ports 443 and 9001)
  • Administrator credentials for SecurITaas web application
  • Domain Administrator access to all domain controllers
  • Local Administrator access to target Windows servers
  • SecurITaas certificate utility executable (securitaas_cert_utility.exe)
  • SecurITaas Credential Provider installer (securitaascpinstaller.exe)
  • Network connectivity between administrative workstation and all target systems

1. Configure Each Domain Controller to Trust SecurITaas CA

This section covers configuring domain controllers to trust the SecurITaas Certificate Authority (CA) for KDC (Key Distribution Center) certificate authentication.

1.1 Gather Domain Controller Details and Generate KDC Certificate

For each domain controller in your environment, you need to generate a KDC certificate using the SecurITaas certificate utility.

Step 1: Collect Domain Controller Information

Before running the certificate utility, gather the following information for each domain controller:

  • DC FQDN: Fully Qualified Domain Name (e.g., DC01.securitaas.com)
  • Domain Name: Active Directory domain name (e.g., securitaas.com)
  • NetBIOS Name: NetBIOS domain name (e.g., SECURITAAS)
  • SecurITaas Server IP/FQDN: IP address or FQDN of your SecurITaas server
  • Administrator Credentials: Email and password for SecurITaas web application

Step 2: Run SecurITaas Certificate Utility

  1. Launch the Certificate Utility:
  2. Open a command prompt or PowerShell session on your workstation or laptop. This can only be run from a laptop or endpoint with soagent installed. Please use soadmin user's credentials for this.
  3. Navigate to the directory containing the SecurITaas certificate utility executable

  4. Run the utility: 

    securitaas_cert_utility.exe

  5. Authenticate with SecurITaas Server:

  6. When prompted, enter the following:
    • SecurITaas Server IP or FQDN: Enter your SecurITaas server address
    • Email: Enter your SecurITaas administrator email
    • Password: Enter your SecurITaas administrator password

  7. The utility will authenticate and register an agent automatically

  8. Select KDC Certificate Generation:

  9. From the main menu, select option 1 (Generate KDC Certificate)

  10. Enter Domain Controller Information:

  11. DC FQDN: Enter the fully qualified domain name of the domain controller
    • Example: DC01.securitaas.com
  12. Domain: Enter the Active Directory domain name
    • Example: securitaas.com
  13. NetBIOS Name: Enter the NetBIOS domain name (uppercase)
    • Example: SECURITAAS
  14. Key Size (optional): Press Enter for default (2048) or enter a custom value

  15. Valid Years (optional): Press Enter for default (2.5) or enter a custom value

  16. Certificate Generation:

  17. The utility will generate the KDC certificate and save it as a PFX file
  18. The file will be saved in the same directory as the utility with the naming format: 
    <NETBIOS_NAME>_kdc_<TIMESTAMP>.pfx
    Example: SECURITAAS_kdc_20241215_143022.pfx

  19. Note: The PFX file is unencrypted (no password required)

  20. Repeat for Each Domain Controller:

  21. Repeat steps 1-5 for each domain controller in your environment
  22. Keep track of which PFX file corresponds to which domain controller

Step 3: Import KDC Certificate on Domain Controller

For each domain controller:

  1. Transfer the PFX File:
  2. Copy the generated PFX file to the domain controller

  3. Ensure you have administrative access to the domain controller

  4. Import the Certificate:

  5. Open a command prompt as Administrator on the domain controller
  6. Navigate to the directory containing the PFX file
  7. Import the certificate using certutil: 
    certutil -importPFX <PFX_FILENAME>.pfx
    Example: 
    certutil -importPFX SECURITAAS_kdc_20241215_143022.pfx

  8. The certificate will be imported into the local machine's Personal certificate store

  9. Verify Certificate Import:

  10. Open Certificate Manager (certlm.msc) or MMC with Certificates snap-in
  11. Navigate to Personal > Certificates

  12. Verify the KDC certificate is present and shows:

    • Intended Purpose: Server Authentication, KDC Authentication
    • Issued By: SecurITaas CA
    • Issued To: The DC FQDN you specified

  13. Configure Certificate for KDC:

  14. The certificate should automatically be used by the KDC service

  15. Restart the KDC service if needed: 

    net stop kdc
net start kdc

  16. Verify KDC Certificate Acceptance (Optional):

  17. Restart KDC Service:

    • Open Services console (services.msc) or use Command Prompt as Administrator
    • Restart the KDC service: 
      net stop kdc
net start kdc

  18. Check Event Logs for Certificate Acceptance:

    • Open Event Viewer (eventvwr.msc)
    • Navigate to Windows Logs > System
    • Filter the log for events from the KDC source:
    • Click Filter Current Log... (or right-click System and select Filter Current Log...)
    • Under Event sources, check KDC
    • Click OK
    • Look for event ID 4 (KDC certificate loaded successfully) or similar success messages
    • Verify the event log shows the SecurITaas-issued KDC certificate is being used
    • You should see messages indicating the certificate was found and loaded

  19. Enable Detailed KDC Logging (if needed):

    • If you need more detailed logging, you can enable it through Group Policy:
    • Open Group Policy Management (gpmc.msc)
    • Navigate to your domain's Group Policy Object (e.g., Default Domain Policy)
    • Edit the policy and navigate to: 
      Computer Configuration > Policies > Administrative Templates > System > KDC
    • Enable KDC support for claims, compound authentication and Kerberos armoring
    • This will provide more detailed logging in Event Viewer

  20. If Certificate Not Found in Logs:

    • Verify the certificate is still in the Personal store (repeat step 3)
    • Ensure the certificate subject name matches the DC FQDN exactly
    • Check that the certificate has not expired
    • Restart the KDC service again: 
      net stop kdc
net start kdc
    • Wait a few moments and check the event logs again

1.2 Import SecurITaas CA Certificate into NTAuth Store

The SecurITaas CA certificate must be imported into the Enterprise NTAuth store so that all domain controllers trust certificates issued by SecurITaas.

Step 1: Obtain SecurITaas CA Certificate

  1. Using the Certificate Utility:
  2. Run the SecurITaas certificate utility
  3. Authenticate with your SecurITaas server credentials
  4. From the main menu, select option 2 (Get CA Certificate)

  5. The CA certificate will be saved as: 

    securitaas-ca_<TIMESTAMP>.cer
    Example: securitaas-ca_20241215_143500.cer

  6. Alternative Method - From SecurITaas Web Interface:

  7. Log in to the SecurITaas web application
  8. Navigate to the certificate management section
  9. Download the root CA certificate in .cer format

Step 2: Import CA Certificate into NTAuth Store (Method 2 - Using Certutil)

This method uses certutil.exe to publish the CA certificate to the Enterprise NTAuth store, which automatically replicates to all domain controllers.

  1. Open Command Prompt as Administrator:
  2. On any domain controller or a workstation with Domain Admin privileges

  3. Right-click Command Prompt and select Run as administrator

  4. Publish CA Certificate to Enterprise NTAuth Store:

  5. Navigate to the directory containing the SecurITaas CA certificate
  6. Run the following command: 
    certutil -dspublish -f securitaas-ca_<TIMESTAMP>.cer NTAuthCA
    Example: 
    certutil -dspublish -f securitaas-ca_20241215_143500.cer NTAuthCA

  7. This command publishes the certificate to Active Directory, which will replicate to all domain controllers

  8. Verify Publication:

  9. The command should output confirmation that the certificate was published

  10. You should see a message indicating successful publication to the NTAuthCertificates container

  11. Update Local NTAuth Store (if needed):

  12. On each domain controller, you may need to update the local registry: 
    certutil -enterprise -addstore NTAuth securitaas-ca_<TIMESTAMP>.cer

  13. This ensures the certificate is immediately available on the local machine

  14. Verify Certificate in NTAuth Store:

  15. To view certificates in the NTAuth store: 
    certutil -viewstore NTAuth

  16. You should see the SecurITaas CA certificate listed

  17. Replication Verification:

  18. Wait for Active Directory replication to complete (typically a few minutes)
  19. On other domain controllers, verify the certificate is present: 
    certutil -viewstore NTAuth
  20. All domain controllers should show the SecurITaas CA certificate
  1. Import CA Certificate to Trusted Root Certification Authorities:

  2. On each domain controller, import the CA certificate to the Trusted Root Certification Authorities store: 

    certutil -addstore Root securitaas-ca_<TIMESTAMP>.cer

  3. Verify Group Policy Distribution:

  4. The NTAuth store certificate should automatically be distributed via Group Policy
  5. You can verify this in Group Policy Management:
    • Navigate to Default Domain Policy > Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities
    • The SecurITaas CA certificate should appear here

2. Configure Target Windows (Domain-Joined Servers) for SecurITaas FIDO Authentication

This section covers installing the SecurITaas Credential Provider on target Windows servers to enable FIDO authentication with smart cards.

2.1 Install the Credential Provider Using SecurITaasCPInstaller

The SecurITaas Credential Provider enables smart card authentication on Windows servers using SecurITaas FIDO tokens.

Step 1: Prepare for Installation

  1. Verify Prerequisites:
  2. Ensure the target Windows server is domain-joined
  3. Verify you have local Administrator privileges on the target server
  4. Confirm network connectivity to the SecurITaas authentication server

  5. Note the SecurITaas server IP address and port number (default port: 9001)

  6. Obtain Installation Files:

  7. Ensure you have the securitaascpinstaller.exe executable
  8. Ensure the RDPQRProvider.dll file is in the same directory as the installer
  9. Transfer both files to the target server

Step 2: Run the Installer

  1. Open Command Prompt as Administrator:
  2. Log in to the target Windows server
  3. Right-click Command Prompt and select Run as administrator

  4. Important: The installer must be run with Administrator privileges

  5. Navigate to Installer Directory:

  6. Change to the directory containing securitaascpinstaller.exe: 

    cd C:\Path\To\Installer

  7. Execute Installation:

  8. Run the installer with the following syntax: 
    securitaascpinstaller.exe install <ServerIP> <Port>
    Example: 
    securitaascpinstaller.exe install 172.31.46.149 9001
  9. Replace <ServerIP> with the IP address or FQDN of your SecurITaas authentication server

  10. Replace <Port> with the port number (typically 9001)

  11. Monitor Installation Process:

  12. The installer will perform the following operations:
    • Store authentication server configuration in registry
    • Encrypt and store registration credentials in registry
    • Copy RDPQRProvider.dll to C:\Windows\System32\
    • Register the DLL as a COM component
    • Register the Credential Provider in Windows registry

  13. You should see progress messages for each step

  14. Verify Installation:

  15. The installer will display "Installation Complete!" when finished
  16. Note the message indicating a restart is required

Step 3: Configure Server for QR Code Logon UI

Before restarting, configure the server to disable Network Level Authentication (NLA) and ensure the logon UI is displayed for QR code authentication:

  1. Disable Network Level Authentication (NLA) via System Properties:
  2. Open System Properties:
    • Press Win + R, type sysdm.cpl, and press Enter
    • Or right-click This PC (or My Computer) > Properties > Advanced system settings
  3. Navigate to the Remote tab
  4. Under Remote Desktop, select Allow remote connections to this computer
  5. Uncheck the option "Allow connections only from computers running Remote Desktop with Network Level Authentication"
  6. Click OK to save the changes
  7. If prompted, click OK on any warning dialogs

  8. Note: This allows the logon UI to be displayed instead of prompting for credentials before connection

  9. Disable Network Level Authentication (NLA) via Group Policy (Recommended if System Properties method doesn't work):

If users still see credential prompts after disabling NLA via System Properties, configure it through Group Policy:

Option A - Using Local Group Policy Editor (for standalone servers): - Open Local Group Policy Editor: - Press Win + R, type gpedit.msc, and press Enter - Note: Local Group Policy Editor is only available on Windows Pro, Enterprise, or Server editions - Navigate to the following path: 

Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security
- In the right pane, locate and double-click "Require user authentication for remote connections by using Network Level Authentication" - Select Disabled - Click OK to save - Close the Local Group Policy Editor

Option B - Using Domain Group Policy (for domain-joined servers): - On a domain controller or a machine with Group Policy Management Tools installed, open Group Policy Management (gpmc.msc) - Navigate to your domain or create/edit a Group Policy Object (GPO) that applies to the target servers - Right-click the GPO and select Edit - Navigate to: 

Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security
- In the right pane, locate and double-click "Require user authentication for remote connections by using Network Level Authentication" - Select Disabled - Click OK to save - Close the Group Policy Management Editor - Apply the policy: - On the target server, open Command Prompt as Administrator - Run the following command to force Group Policy update: 
gpupdate /force
- Wait for the policy to apply (you should see "Computer Policy update has completed successfully")

Option C - Using Registry (if Group Policy Editor is not available): - Open Registry Editor (regedit.exe) as Administrator - Navigate to: 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
- Locate or create the following REG_DWORD value: - Name: SecurityLayer - Value: 1 (This disables NLA) - If the value doesn't exist, right-click in the right pane > New > DWORD (32-bit) Value > Name it SecurityLayer > Set value to 1 - Close Registry Editor - Note: Registry changes require a restart or service restart to take effect

Verify NLA is Disabled: - After applying Group Policy or registry changes, verify the setting: - Open Command Prompt as Administrator - Run: 

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer
- The value should be 0x0 (0) if NLA is disabled - If it shows 0x1 (1) or 0x2 (2), NLA is still enabled and you may need to restart the server

  1. Enable Remote Desktop (if not already enabled):

  2. In the same Remote tab of System Properties:

    • Ensure Allow remote connections to this computer is selected
    • If you need to allow connections from any version of Remote Desktop, you can also configure firewall rules if needed

  3. Verify Remote Desktop Service is Running:

  4. Open Services console (services.msc)
  5. Locate Remote Desktop Services service
  6. Ensure it is set to Automatic and is Running
  7. If not running, right-click and select Start
  8. If startup type is not Automatic, right-click > Properties > Set Startup type to Automatic > OK

Step 4: Post-Installation Steps

  1. Restart the Server:
  2. Important: You must restart the server for the Credential Provider to be active
  3. The installer will display: "IMPORTANT: You must restart your computer for changes to take effect!"

  4. Restart the server: 

    shutdown /r /t 0

  5. Verify Credential Provider Registration:

  6. After restart, verify the Credential Provider is registered:

    • You can verify by checking the logon screen (see step 3)

  7. Test QR Code Authentication:

  8. Connect to the server via Remote Desktop from a client machine
  9. Important: With NLA disabled, you should see the Windows logon screen immediately without being prompted for credentials first
  10. At the logon screen, you should see the option "Logon using Securitaas"
  11. The QR code should be displayed for authentication
  12. Scan the QR code with your SecurITaas FIDO token or mobile app
  13. Verify successful logon

Step 5: Repeat for Additional Servers

  • Repeat steps 1-4 for each target Windows server that needs SecurITaas FIDO authentication

3. Just in Time Provisioning for Windows Servers

This section covers configuring OpenSSH Server on Windows target servers to enable just-in-time (JIT) provisioning and deprovisioning of user access. This allows SecurITaas to automatically provision users to local or domain groups when they request access and remove them when sessions close.

Overview

Just-in-time provisioning enables: - Automatic user provisioning: When a user clicks "Connect" on the Request Connection page, SecurITaas automatically adds the user to the required local or domain group - Automatic deprovisioning: When the session closes, the user is automatically removed from the group - Passwordless authentication: Uses SSH certificate-based authentication with ephemeral certificates - Zero standing privileges: Users only have access during active sessions

Prerequisites

Before configuring JIT provisioning, ensure:

  • Target Windows server is domain-joined (for domain group provisioning) or standalone (for local group provisioning)
  • Administrator access to the target Windows server
  • Access to SecurITaas Appliance Manager
  • Port 22 is open from SecurITaas appliance to the target Windows server (see Port Requirements)
  • A local or domain user account configured in the Device page for passwordless provisioning operations

3.1 Install OpenSSH Server

OpenSSH Server can be installed on Windows Server 2019 and later, or Windows 10/11. Choose one of the following methods:

Method 1: Install OpenSSH Server via PowerShell (Command Line)

  1. Open PowerShell as Administrator:
  2. Press Win + X and select Windows PowerShell (Admin) or Terminal (Admin)

  3. Or right-click Start button and select Windows PowerShell (Admin)

  4. Check if OpenSSH Server is already installed: 

    Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH.Server*'

  5. If you see State : Installed, OpenSSH Server is already installed

  6. If you see State : NotPresent, proceed with installation

  7. Install OpenSSH Server: 

    Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

  8. Wait for the installation to complete

  9. You should see output indicating successful installation

  10. Start and configure OpenSSH Server: 

    Start-Service sshd
Set-Service -Name sshd -StartupType 'Automatic'

  11. Verify the service is running: 

    Get-Service sshd

  12. The status should show Running

Method 2: Install OpenSSH Server via Settings UI

  1. Open Settings:
  2. Press Win + I to open Settings

  3. Or click Start > Settings

  4. Navigate to Apps:

  5. Click Apps (or Apps & features on older Windows versions)

  6. Click Optional features (or Manage optional features)

  7. Add OpenSSH Server:

  8. Click Add a feature (or + Add a feature)
  9. In the search box, type OpenSSH
  10. Select OpenSSH Server
  11. Click Install

  12. Wait for installation to complete

  13. Start the OpenSSH Server service:

  14. Open Services console (services.msc)
  15. Locate OpenSSH SSH Server
  16. Right-click and select Start
  17. Right-click again and select Properties
  18. Set Startup type to Automatic

  19. Click OK

  20. Verify the service is running:

  21. In Services console, verify OpenSSH SSH Server shows status as Running

3.2 Configure Firewall Rule for SSH

Firewall rules for SSH (port 22) can be configured either through Windows Firewall on the target server or through an external firewall (network firewall, cloud security groups, etc.). Choose the method that best fits your environment.

Option A: Configure via Windows Firewall

  1. Open Windows Defender Firewall with Advanced Security:
  2. Press Win + R, type wf.msc, and press Enter

  3. Or search for "Windows Defender Firewall with Advanced Security" in Start menu

  4. Create Inbound Rule:

  5. Click Inbound Rules in the left pane
  6. Click New Rule... in the right pane
  7. Select Port and click Next
  8. Select TCP and enter port 22
  9. Click Next
  10. Select Allow the connection and click Next
  11. Check all profiles (Domain, Private, Public) and click Next
  12. Enter a name: OpenSSH Server (SSH)

  13. Click Finish

  14. Restrict SSH Access to SecurITaas Appliance (Recommended):

  15. Important: For security best practices, it is recommended to restrict SSH access to only the SecurITaas appliance IP address
  16. Right-click the newly created rule OpenSSH Server (SSH)
  17. Select Properties
  18. Navigate to the Scope tab
  19. Under Remote IP address, select These IP addresses:
  20. Click Add...
  21. Enter the IP address or IP address range of your SecurITaas appliance
  22. Click OK
  23. Click OK to save the changes

  24. Note: This ensures only the SecurITaas appliance can connect via SSH, preventing unauthorized access attempts

  25. Configure Provisioning User Permissions:

  26. The provisioning user account configured in the Device page should have limited permissions:
    • Required: Permissions to add/remove users from local or domain groups
    • Not Required: Remote Desktop access or interactive logon rights
    • Recommended: Create a dedicated service account with minimal privileges (only group management permissions)
  27. This ensures the provisioning user can only perform group membership changes and cannot be used for interactive access to the server

  28. Security Benefit: Even if the provisioning user credentials were compromised, an attacker would only be able to modify group memberships, not gain direct access to the server

  29. Verify the rule is active:

  30. In the Inbound Rules list, verify the new rule is enabled (green checkmark)
  31. Verify the scope shows only the SecurITaas appliance IP address(es)

Option B: Configure via External Firewall

If you prefer to manage firewall rules through an external firewall (network firewall, cloud security groups, etc.):

  1. Configure Inbound Rule:
  2. Access your external firewall management interface
  3. Create a new inbound rule allowing TCP port 22
  4. Important: Restrict the source IP address to only your SecurITaas appliance IP address(es)

  5. Apply the rule to the target Windows server(s)

  6. Verify Connectivity:

  7. From the SecurITaas appliance, test SSH connectivity to the target server: 
    Test-NetConnection -ComputerName <target_server_ip> -Port 22

  8. Ensure the connection is successful

  9. Security Best Practice:

  10. Always restrict SSH access (port 22) to only the SecurITaas appliance IP address
  11. Avoid allowing SSH from any source (0.0.0.0/0) for security reasons

3.3 Download and Configure SecurITaas Public Key

  1. Access SecurITaas Appliance Manager:
  2. Log in to the SecurITaas web application
  3. Navigate to Support > Appliance Manager
  4. Click Generate Token and copy the token
  5. Launch the Appliance Manager executable
  6. Enter:
    • IP of your SecurITaas appliance
    • Port 9090
    • Paste the token in the 'Bearer Token' box
    • Select 'Appliance Manager' from the dropdown
    • Click Connect

  7. For detailed instructions, see Logging into Appliance Manager

  8. Download securitaas.pub:

  9. In Appliance Manager, click Navigator on the left
  10. Navigate to /home/user0/Certificates/CA
  11. Locate the file named securitaas.pub
  12. Download or copy the contents of this file

  13. Note: This is the public key of the SecurITaas Certificate Authority used to sign ephemeral SSH certificates

  14. Create SSH Configuration Directory:

  15. Open PowerShell or Command Prompt as Administrator
  16. The default SSH directory on Windows is C:\ProgramData\ssh
  17. Verify the directory exists: 
    Test-Path C:\ProgramData\ssh

  18. If it doesn't exist, create it: 

    New-Item -ItemType Directory -Path C:\ProgramData\ssh -Force

  19. Place securitaas.pub in SSH Directory:

  20. Copy the securitaas.pub file to C:\ProgramData\ssh\securitaas.pub
  21. You can use PowerShell: 
    # If you have the file content, create it:
Set-Content -Path C:\ProgramData\ssh\securitaas.pub -Value "<paste_pub_key_content_here>"

  22. Or copy the file using File Explorer:

    • Navigate to C:\ProgramData\ssh (you may need to show hidden items)
    • Paste the securitaas.pub file here

  23. Set File Permissions:

  24. Right-click securitaas.pub in File Explorer
  25. Select Properties > Security tab
  26. Click Edit
  27. Ensure SYSTEM and Administrators have Read permissions
  28. Remove any unnecessary user permissions
  29. Click OK to save

3.4 Configure SSH Server to Trust SecurITaas CA

  1. Locate SSH Configuration File:
  2. The SSH server configuration file is located at: 
    C:\ProgramData\ssh\sshd_config

  3. Note: This is the default location for Windows OpenSSH Server

  4. Edit sshd_config:

  5. Open C:\ProgramData\ssh\sshd_config in a text editor (Notepad, VS Code, etc.)
  6. Important: You must run the text editor as Administrator to save changes
  7. Add the following line to the configuration file: 
    TrustedUserCAKeys C:\ProgramData\ssh\securitaas.pub
  8. Note: Use the full path to the public key file

  9. Save the file

  10. Verify Configuration:

  11. Check that the line was added correctly: 
    Select-String -Path C:\ProgramData\ssh\sshd_config -Pattern "TrustedUserCAKeys"

  12. You should see the line you just added

  13. Restart OpenSSH Server:

  14. Restart the SSH service to apply changes: 
    Restart-Service sshd

  15. Or use Services console:

    • Open Services (services.msc)
    • Locate OpenSSH SSH Server
    • Right-click and select Restart

  16. Verify Service Status: 

    Get-Service sshd

  17. Status should show Running

3.5 Configure Provisioning User in Device Page

Before JIT provisioning can work, you must configure a provisioning user account in the SecurITaas Device page:

  1. Log in to SecurITaas Web Application:
  2. Access the SecurITaas web portal

  3. Navigate to Devices page

  4. Select or Add Target Windows Server:

  5. Locate the target Windows server in the device list

  6. Or add a new device if not already registered

  7. Configure Provisioning User:

  8. In the device configuration, specify a provisioning user account
  9. This can be:
    • Local user account: A local Windows user account on the target server (e.g., provisioning-user)
    • Domain user account: A domain user account with appropriate permissions (e.g., DOMAIN\provisioning-user)

  10. Requirements for the provisioning user:

    • Must have permissions to add/remove users from local groups (for local group provisioning)
    • Must have permissions to add/remove users from domain groups (for domain group provisioning)
    • Should be a dedicated service account, not a regular user account
    • Must be configured to allow passwordless SSH access (using certificate authentication)

  11. Configure Group Membership:

  12. Specify which local or domain groups users should be provisioned to
  13. This is typically configured in the Access Rights or Device configuration

  14. Users requesting access will be automatically added to these groups when they click "Connect"

  15. Save Configuration:

  16. Save the device configuration
  17. The provisioning user will be used by SecurITaas to perform automated group membership changes

3.6 Verify JIT Provisioning Configuration

  1. Test SSH Certificate Authentication:
  2. From the SecurITaas appliance or a test machine, attempt to connect using an ephemeral certificate: 
    ssh -i <ephemeral_certificate> provisioning-user@<target_server_ip>

  3. You should be able to connect without a password if the certificate is valid

  4. Verify Port 22 is Accessible:

  5. From the SecurITaas appliance, test connectivity: 
    Test-NetConnection -ComputerName <target_server_ip> -Port 22
  6. Or use telnet: 
    telnet <target_server_ip> 22

  7. You should see the SSH banner if the port is open

  8. Check SSH Server Logs:

  9. SSH server logs are located at: 
    C:\ProgramData\ssh\logs\sshd.log
  10. Check for any authentication errors or connection issues
  11. Look for successful certificate-based authentication entries

3.7 How JIT Provisioning Works

Provisioning Flow (When User Clicks "Connect"):

  1. User Request:
  2. User logs into SecurITaas web application
  3. Navigates to Request Connection page

  4. Selects target Windows server and clicks Connect

  5. Session Establishment:

  6. Once provisioning is complete, user session is established
  7. User can now access the target server with appropriate permissions

Deprovisioning Flow (When Session Closes):

  1. Session Closure Detection:

  2. SecurITaas detects when user session ends (RDP disconnect, logout, timeout, etc.)

  3. Access Revocation:

  4. User is immediately removed from the group
  5. No standing access remains after session closure
  6. User must request access again for future sessions

Summary

With JIT provisioning configured:

  • Automatic Access Management: Users are automatically provisioned and deprovisioned based on session requests
  • Zero Standing Privileges: No permanent group memberships; access is only granted during active sessions
  • Passwordless Operations: All provisioning operations use SSH certificate authentication
  • Auditable: All provisioning and deprovisioning actions are logged and auditable
  • Secure: Uses ephemeral certificates that are invalidated after use

5. Uninstall Trust from Domain Controllers

This section covers removing the SecurITaas trust configuration from domain controllers, including KDC certificates and CA certificates.

3.1 Remove KDC Certificate

To remove the KDC certificate from a domain controller:

Step 1: Identify the KDC Certificate

  1. Open Certificate Manager:

  2. On the domain controller, open Certificate Manager:

    • Press Win + R, type certlm.msc, and press Enter
    • Or open MMC and add the Certificates snap-in for Computer account

  3. Locate the Certificate:

  4. Navigate to Personal > Certificates
  5. Identify the SecurITaas-issued KDC certificate
  6. Note the certificate's subject name (should match the DC FQDN) and thumbprint

Step 2: Remove the Certificate

  1. Delete from Certificate Store:
  2. Right-click the SecurITaas KDC certificate
  3. Select Delete

  4. Confirm the deletion when prompted

  5. Alternative Method - Using Certutil:

  6. Open Command Prompt as Administrator
  7. List certificates in the Personal store: 
    certutil -store My
  8. Find the thumbprint of the SecurITaas KDC certificate
  9. Delete the certificate using the thumbprint: 
    certutil -delstore My <Thumbprint>
    Example: 
    certutil -delstore My a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0

Step 3: Verify Removal

  1. Confirm Certificate Deletion:
  2. Refresh the Certificate Manager console

  3. Verify the KDC certificate is no longer present in the Personal store

  4. Restart KDC Service:

  5. Restart the KDC service to ensure changes take effect: 

    net stop kdc
net start kdc

  6. Repeat for All Domain Controllers:

  7. Perform these steps on each domain controller that had a KDC certificate installed

3.2 Remove SecurITaas CA Certificate from NTAuth Store

To remove the SecurITaas CA certificate from the Enterprise NTAuth store:

Step 1: Identify the CA Certificate

  1. View NTAuth Store:
  2. Open Command Prompt as Administrator
  3. List certificates in the NTAuth store: 
    certutil -viewstore NTAuth
  4. Identify the SecurITaas CA certificate
  5. Note the certificate's serial number or thumbprint

Step 2: Remove from Enterprise NTAuth Store

Choose one of the following methods to remove the CA certificate from the Enterprise NTAuth store:

Method 1: Using Certutil (Command Line)

  1. Remove from Active Directory:
  2. On a domain controller or workstation with Domain Admin privileges
  3. Open Command Prompt as Administrator
  4. Remove the certificate from the Enterprise NTAuth store: 
    certutil -dspublish -f -del <CertificateSerialNumber> NTAuthCA
    Replace <CertificateSerialNumber> with the serial number of the SecurITaas CA certificate

  5. Note: The -del flag removes the certificate from Active Directory

  6. Alternative - Using Certificate File:

  7. If you have the certificate file, you can use: 
    certutil -dspublish -f -del securitaas-ca_<TIMESTAMP>.cer NTAuthCA

Method 2: Using Enterprise PKI (PKIView) - UI-Based

  1. Open Enterprise PKI Management:
  2. On a domain controller or workstation with Domain Admin privileges
  3. Start Microsoft Management Console (MMC):
    • Press Win + R, type mmc.exe, and press Enter

  4. Add the Enterprise PKI snap-in:

    • Go to File > Add/Remove Snap-in (or press Ctrl + M)
    • Select Enterprise PKI from the list
    • Click Add
    • Click OK

  5. Remove Certificate from NTAuth Store:

  6. In the Enterprise PKI console, right-click Enterprise PKI
  7. Select Manage AD Containers...
  8. Navigate to the NTAuthCertificates tab
  9. Locate the SecurITaas CA certificate in the list
  10. Select the certificate
  11. Click Remove (or right-click and select Remove)
  12. Confirm the removal when prompted

  13. Click OK to close the dialog

  14. Verify Removal:

  15. The certificate should no longer appear in the NTAuthCertificates list
  16. Close the Enterprise PKI console

Step 3: Remove from Local NTAuth Store

  1. Remove from Local Registry:
  2. On each domain controller, remove the certificate from the local NTAuth store: 
    certutil -delstore NTAuth <CertificateSerialNumber>

  3. Or if you have the certificate file: 

    certutil -delstore NTAuth securitaas-ca_<TIMESTAMP>.cer

  4. Verify Removal:

  5. Verify the certificate is removed: 
    certutil -viewstore NTAuth
  6. The SecurITaas CA certificate should no longer appear

Step 4: Remove from Trusted Root Certification Authorities (if applicable)

  1. Remove from Root Store:
  2. If the CA certificate was also imported to the Trusted Root Certification Authorities store: 
    certutil -delstore Root <CertificateSerialNumber>

  3. Or: 

    certutil -delstore Root securitaas-ca_<TIMESTAMP>.cer

  4. Verify Removal:

  5. Verify the certificate is removed: 
    certutil -viewstore Root

Step 5: Wait for Replication

  1. Active Directory Replication:
  2. Wait for Active Directory replication to complete (typically a few minutes)

  3. The removal will replicate to all domain controllers automatically

  4. Verify on All Domain Controllers:

  5. On each domain controller, verify the certificate is removed: 
    certutil -viewstore NTAuth

6. Uninstall Credential Provider from Target Windows Servers

This section covers uninstalling the SecurITaas Credential Provider from target Windows servers.

4.1 Uninstall Using securitaascpinstaller and Perform Cleanup

To completely remove the SecurITaas Credential Provider from a target Windows server:

Step 1: Run the Uninstaller

  1. Open Command Prompt as Administrator:
  2. Log in to the target Windows server
  3. Right-click Command Prompt and select Run as administrator

  4. Important: The uninstaller must be run with Administrator privileges

  5. Navigate to Installer Directory:

  6. Change to the directory containing securitaascpinstaller.exe: 

    cd C:\Path\To\Installer

  7. Execute Uninstallation:

  8. Run the uninstaller with the following command: 
    securitaascpinstaller.exe uninstall

  9. Alternative syntax (also supported): 

    securitaascpinstaller.exe /u
    Or: 
    securitaascpinstaller.exe -u

  10. Monitor Uninstallation Process:

  11. The uninstaller will perform the following operations:
    • Unregister the DLL (COM unregistration)
    • Remove Credential Provider from Windows registry
    • Delete RDPQRProvider.dll from C:\Windows\System32\
    • Remove configuration registry entries

  12. You should see progress messages for each step

  13. Verify Uninstallation:

  14. The uninstaller will display "Uninstallation Complete!" when finished
  15. Note any warnings that may appear (some are non-fatal)

Step 2: Restart the Server

  1. Restart Required:
  2. Important: You must restart the server for all changes to take effect
  3. The uninstaller will display: "IMPORTANT: You must restart your computer for changes to take effect!"
  4. Restart the server: 
    shutdown /r /t 0

Step 3: Manual Cleanup (if needed)

After restart, perform additional cleanup to ensure complete removal:

  1. Verify DLL Removal:
  2. Check that RDPQRProvider.dll is removed from System32: 
    dir C:\Windows\System32\RDPQRProvider.dll

  3. The file should not exist (you'll get a "File Not Found" error)

  4. Verify Registry Cleanup:

  5. Open Registry Editor (regedit.exe)
  6. Check that the following registry paths are removed:
    • HKEY_LOCAL_MACHINE\SOFTWARE\SecurITaas\CredentialProvider
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{8B5C9F21-3A4D-4E2F-9C1B-7A8E6D5F4C3B}
    • HKEY_CLASSES_ROOT\CLSID\{8B5C9F21-3A4D-4E2F-9C1B-7A8E6D5F4C3B}

  7. If any of these keys still exist, delete them manually:

    • Right-click the key and select Delete
    • Confirm deletion

  8. Verify Credential Provider Removal:

  9. After restart, log out or lock the server
  10. At the login screen, verify that "Logon using Securitaas" option is no longer present

  11. Only standard Windows authentication options should be available

  12. Check for Residual Files:

  13. Search for any SecurITaas-related files: 
    dir /s C:\Windows\System32\*SecurITaas*
dir /s C:\Program Files\SecurITaas
dir /s C:\ProgramData\SecurITaas

  14. Delete any found files or directories

  15. Check Event Logs (Optional):

  16. Open Event Viewer (eventvwr.msc)
  17. Check Application and System logs for any SecurITaas-related errors

  18. These should be minimal after successful uninstallation

  19. Re-enable Network Level Authentication (Optional but Recommended):

  20. If you disabled NLA during installation, you may want to re-enable it for security:
    • Open System Properties (sysdm.cpl)
    • Navigate to the Remote tab
    • Under Remote Desktop, check the option "Allow connections only from computers running Remote Desktop with Network Level Authentication"
    • Click OK to save
    • Note: This will require users to authenticate before seeing the logon screen, which is more secure but prevents QR code authentication

Step 4: Repeat for Additional Servers

  • Repeat steps 1-3 for each target Windows server that has the SecurITaas Credential Provider installed

Troubleshooting

Common Issues

  1. KDC Certificate Not Working:
  2. Verify the certificate is in the Personal store with correct intended purposes
  3. Check that the certificate hasn't expired
  4. Ensure the KDC service is running

  5. Verify the certificate subject name matches the DC FQDN

  6. CA Certificate Not Replicating:

  7. Wait for Active Directory replication (can take up to 15 minutes)
  8. Manually trigger replication if needed

  9. Verify Domain Admin privileges are being used

  10. Credential Provider Not Appearing:

  11. Ensure the server has been restarted after installation
  12. Verify the DLL is registered correctly

  13. Check Event Viewer for errors related to credential providers

  14. Uninstallation Incomplete:

  15. Ensure you're running as Administrator
  16. Manually delete registry entries if needed
  17. Restart the server after manual cleanup

Verification Commands

  • Check KDC Certificate: 

    certutil -store My

  • Check NTAuth Store: 

    certutil -viewstore NTAuth

  • Verify Credential Provider Registration: 

    reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{8B5C9F21-3A4D-4E2F-9C1B-7A8E6D5F4C3B}"

Additional Resources

Summary

This guide covers:

  1. Configuration: Setting up domain controllers and target Windows servers for SecurITaas FIDO authentication
  2. Installation: Installing KDC certificates and Credential Provider
  3. Uninstallation: Removing all SecurITaas components and trust relationships

Always ensure you have proper backups and test in a non-production environment before applying changes to production systems.