GETTING STARTED · FIRST-RUN SECURITY

Begin with a safe, recoverable configuration

The first configuration determines whether the security controls protect your servers without interrupting legitimate administration. Complete the checklist in order, keep a recovery path available, and validate every change from a separate session.

Do not activate MFA or firewall policy without recovery access.

Keep a tested console, hypervisor, iLO/iDRAC, VPN, or break-glass administrator path outside the protected RDP flow. Do not place the only recovery account behind an untested MFA dependency.

Why this sequence matters

Lira controls sensitive operations: RDP access, MFA policy, Windows Firewall, Defender, certificates, local users, and updates. The management console must therefore be protected as an administrative system, not treated as an ordinary website.

A staged configuration reduces lockout risk. Every exception should be explicit, time-limited where possible, documented, and reviewed after the initial rollout.

Security guidance

CISA · Cybersecurity best practicesUse layered controls, MFA, least privilege, patching, monitoring, and tested recovery procedures.
NIST SP 800-63B-4 · AuthenticationProvides guidance for authenticators, protected authentication channels, and account recovery.
Microsoft · Allow Remote Desktop access from outside your networkExplains safer options for external Remote Desktop access, including VPN and gateway-based connectivity.

Can access be restored from the Lira console?

Yes, while at least one independent management channel remains available.

Administrator address blocked: open the portal from the same external network, use Get my public IP in the allowlist, add the detected public address, and wait for online agents to synchronize Windows Firewall.
Incorrect RDP MFA policy: enable a temporary bypass or select Disabled. The online agent removes enforcement on its next policy exchange.
Incorrect RDP TLS certificate: select Restore listener. The online agent removes the forced binding, switches to Negotiate, and restarts the RDP services.
Agent service stopped: a superadmin can use previously configured WinRM to restart it, then repeat recovery. If both the agent and WinRM are unavailable, use a hypervisor, local, iLO/iDRAC/KVM/VNC, or physical console.

1. Protect the management console first

Use a named administrator account with a unique password; do not share a portal credential between operators.
Enable MFA for the Lira management console itself. Do not create an exception for the console: it controls your servers and, if compromised, can change firewall rules, users, certificates, Defender, and RDP policy.
Review active sessions and sign out of browsers or devices that are no longer managed.
Grant operators only the organization and server scope required for their work; reserve platform-wide administration for a small, audited group.

2. Add a trusted address before testing blocks

Add the fixed public address used by your administrators, VPN egress, or secure jump host to the Lira allowlist before you test automatic blocking. This prevents a temporary password mistake from blocking the only legitimate administration path.

Allowlisting is not a replacement for MFA or strong passwords. Keep the list narrow, document each entry, remove addresses that are no longer controlled, and review it after network changes.

Confirm the address from the same network that will be used for administration.
Add the address in the portal and verify that it appears in the trusted list.
If the address is dynamic, prefer a controlled VPN or jump host with a stable egress address.

3. Prepare authenticator applications

Install a standards-based TOTP authenticator such as Microsoft Authenticator, Google Authenticator, 1Password, Bitwarden, or another organization-approved application.
Enroll MFA from the Lira account security page and store recovery codes in an approved password manager or offline emergency record.
Keep a second controlled authenticator device for recovery; do not photograph secrets or place them in a shared chat.
Verify one current code before enforcing MFA on any Windows server.

4. Install and validate the first agent

Install the Lira Windows agent using the organization-specific enrollment key generated after registration. The agent communicates outbound over HTTPS; no inbound management port is required on the RDP host.

Wait for the first heartbeat and confirm the hostname, address, operating-system version, and current agent version. Resolve duplicate names or incorrect identity data before sending commands.

Install on one pilot server first.
Confirm events, firewall state, Defender status, and time synchronization in the portal.
Keep the existing RDP session open while testing a new session.

5. Enable MFA in a controlled pilot

Choose one named pilot user and one non-critical server.
Enroll the user, verify a current code, and enable enforcement only for the pilot.
Open a new RDP connection from a separate client; test password and MFA as a complete sequence.
Sign out and repeat the test so a cached session cannot hide a problem.
Expand by small groups only after the pilot, event logs, recovery account, and agent connectivity are confirmed.

6. Configure certificates and maintenance

Use a certificate whose Subject Alternative Name matches the exact DNS name used by RDP clients. Keep ACME DNS delegation permanent when automated renewal is enabled. Review the detailed certificate guide before deployment.

Schedule Windows updates, Defender scans, firewall changes, and certificate renewals in maintenance windows. Record the expected restart and rollback behavior before applying a policy to multiple servers.

Test certificate trust from an independent client.
Keep the previous listener binding and console recovery path recorded.
Apply changes to a pilot server before fleet-wide deployment.

7. Operate and review

Review failed and successful sign-ins, active blocks, agent heartbeats, MFA decisions, and administrative audit entries.
Remove temporary allowlist entries and MFA exceptions after the rollout.
Rotate credentials and recovery records when an operator leaves or a device is lost.
Repeat the recovery test periodically and after major network, certificate, or agent changes.

Common questions

Why must MFA protect the console too?

The console can change the controls that protect every server. Excluding it leaves the highest-impact administrative path protected only by a password and can allow an attacker to disable or weaken server controls.

Should I allowlist my home address?

Only if it is a controlled administration path. A stable VPN or jump host is preferable. Never allowlist an address you cannot reliably identify or protect.

Which authenticator should we choose?

Use an organization-approved TOTP application with encrypted backups or controlled recovery. Choose one that operators can use reliably and that supports your account-recovery policy.

What if the MFA link or code is no longer valid?

Do not repeatedly retry. Use the documented recovery path, verify server and device time, issue a fresh enrollment or code where appropriate, and record the incident in the audit trail.

Start with one protected, recoverable server

Register your organization, secure the console, add your trusted administration path, enroll MFA, and validate the first agent before expanding the policy.

Open the Lira console