Common Support Issues

Local Admin Passwords Not Rotating

Symptoms

• Local admin password shows stale/unchanged

• Rotation status not updating as expected

Common Causes

• Microsoft LAPS is managing the local admin password instead of Evo

• Password length/complexity policy mismatch

• Minimum password age policy prevents frequent rotation

• Endpoint can’t reach Evo services (network/allowlist)

What to Check

1. LAPS configuration
• Confirm whether Microsoft LAPS is enabled/configured in the environment.
• If LAPS is managing the same local admin account, it may override or conflict with rotation expectations.

2. Password length & complexity
• In the Evo Portal, verify any tenant-wide password policy (example: Local Password Account Length) meets the environment requirements.

3. Minimum password age
• If Windows/AD policy enforces a minimum password age (ex: 1 day), ensure Evo rotation is set to 1 day or greater.

4. Connectivity / allowlisting
• Review firewall/proxy requirements and allowed destinations.
• Reference: Evo prerequisites / allowlist guidance (maintain your preferred canonical KB link here).

When to Collect Logs

• Rotation appears to trigger but never completes

• Rotation is intermittent across multiple devices

• You suspect firewall/proxy/EDR interference

Windows Login Error: c000006

Symptoms

• Elevated login fails with c000006

• “Invalid credentials” behavior even when the user can sign into other services

Common Causes

• Username/password mismatch (most common)

• Account not properly licensed or missing elevation assignment/tenant access

• Connectivity/allowlisting prevents authentication flow from completing

What to Check

1. Credential accuracy
• c000006 typically indicates an invalid username/password.
• If using Entra ID / Azure AD: ensure the credentials being used for Evo elevation are correct and match what Evo expects.
• Important note: Evo does not “pull down” passwords from Entra ID. Validate what credentials Evo is using in your workflow.

2. Portal configuration
• Confirm the user is:
• Properly licensed
• Has the correct Elevation Assignment
• Has correct Tenant Access / Role to perform the action

3. Connectivity / allowlisting
• Confirm the endpoint can reach required Evo services (especially in restricted networks).

When to Collect Logs

• Credentials are confirmed correct but failures persist

• Only failing from certain networks/sites

• Works via OTP but not push, or works sometimes but not always

Tech Unable to Access the Evo Portal

Symptoms

• Technician cannot sign into the portal

• Portal access denied / missing tenant visibility

Common Causes

• User is not an Evo Admin

• Device registration is missing (can also correlate with MFA/push issues)

What to Check

1. Admin conversion
• Verify the user is converted to Admin (portal access requires admin capability).

2. Device registration
• Check the user record for a registered device.
• If no device is registered, MFA/push will likely fail as well.

User Not Receiving MFA / Push Notifications

Symptoms

• Push never arrives

• Push arrives inside the Evo app but not as a phone notification

• User can’t scan QR code during enrollment

Common Causes

• No device registered, or device registration is stale

• Phone OS notification permissions disabled

• App install is corrupted / needs reinstall

• QR code is clipped/incomplete

• Biometrics/FaceID not enabled (impacts QR enrollment in some cases)

What to Check

1. Portal basics
• Confirm the user is:
• Synced into Evo
• Properly licensed
• Has a device registered

2. If no device is registered
• Have the user uninstall and reinstall the Evo app
• On Android, a reboot after uninstall can help clear remnants.

3. Welcome email / enrollment steps
• Re-send the welcome/enrollment and confirm they follow the intended flow.
• If they are MFA-only, they generally should not attempt to log into the Evo portal (portal requires admin).

4. Phone notification permissions
• Confirm notifications are enabled at:
• OS level (Settings → Notifications)
• App level (Evo app permissions)
• Ask the user to open the Evo app and check whether the push exists but isn’t surfacing as a notification.

5. QR enrollment troubleshooting
• Ensure biometrics/FaceID is enabled (if required for QR scanning on the device).
• Confirm the QR code is fully visible (not clipped by email client, zoom, or RMM screen scaling).

6. Refresh device registration
• In the Portal: delete the device under the user.
• On the phone: force close the Evo app and reopen it to re-register the device.

API/Authentication Error: 401 Unauthorized

Symptoms

• API calls fail with 401

• Token-based operations fail as “unauthorized”

Common Causes

• Token invalid/expired

• Credentials incorrect

• User not licensed / missing required role for action

What to Check

• Confirm token validity and correct usage

• Confirm the user is licensed

• Confirm the user has the correct role for elevated login / action being performed

API/Authentication Error: 403 Forbidden

Symptoms

• API calls fail with 403

• Access token accepted but action is blocked

Common Causes

• Access/Secret token issue

• Token expired or not authorized for the intended scope

What to Check

1. Go to Endpoints → Access Token

2. Confirm token is not expired

3. If not expired and still failing, recreate the token and retest

Domain Admin Password Not Rotating

Symptoms

• Domain admin rotation stuck (ex: “PASSWORD ROTATION PENDING”)

• Rotation timing inconsistent

Common Causes

• Rotation frequency too aggressive

• Domain/Entra password policies or AD GPO constraints

What to Check

• Avoid setting rotation to extremely frequent intervals (example: 1 hour can leave rotation in a perpetual “pending” state in some environments).

• Review relevant password policies:
• Entra/Azure password policy settings (if applicable)
• AD domain password policy / GPO (minimum password age, complexity, etc.)

Office 365 SAML Metadata Reference

• https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml

LDAP Agent: New Groups Not Syncing

Symptoms

• Newly added AD groups don’t appear in Evo

Fast Fix Workflow

1. Open the LDAP Agent

2. Stop the LDAP Agent service

3. Select the groups you want to sync

4. Apply changes

5. Start the service

6. Run a manual sync (ex: CTRL + Sync)

1 Installer Error:

Symptoms

• Install fails immediately with “active Internet connection” message

Common Causes

• Firewall/proxy blocking required endpoints

• EDR/AV blocking installer or traffic (commonly seen with certain configurations)

What to Check

1. EDR/AV
• Ask whether they use EDR/AV that could block installers or outbound communication.
• If using SentinelOne (S1), confirm the agent/version and exclusions (older agents/configs can be more restrictive).

2. Firewall / allowlisting
• Validate allowlisting requirements using your prerequisites article.
• Reference: Evo prerequisites / supported OS + network allowlist guidance (use your canonical KB link).

Recommendation: Password Rotation Frequency

• Recommended: 1 day

• Not recommended: hourly rotation (can cause operational issues in some environments)

Clear Offline End User Elevation Rule Cache (Offline DB)

When to Use

• A rule was changed/removed, but endpoints still behave as if old rules are present

• Users are prompted for a reason even though a rule should auto-approve

Procedure (Windows, elevated PowerShell)

Stop-Serviceevosecureloginagent
Remove-Item"C:\ProgramData\EvoSecurity\SecureLogin\evoagent.db"-Force
Start-Serviceevosecureloginagent

Expected Result

• Within ~10 minutes, the endpoint should refresh rule cache for the user and apply the latest rules.

Duo + Evo Install Order Behavior

Notes

• Evo installer detects Duo and can automatically enable expected settings when Duo is installed before Evo.

• If Duo is installed after Evo, the auto-detection behavior may not apply the same way.

Recommended Practice

• If Duo is part of the standard build, install Duo first, then Evo.

macOS Agent Notes (MFA Enforcement / Failsafe)

What to Check

• Ensure the user intended to be enforced for MFA is not set as the failsafe account.

• Confirm there is a dedicated local admin failsafe account that remains available for recovery scenarios.