Overview 💥
When a SonicWall Inspector run fails with the message:
access denied. please check that the credentials are correct.
It means the Liongard Inspector was able to reach the device but the credentials or account context used to connect were rejected by the SonicWall device.
This can be due to wrong credentials, insufficient privileges, account lockout, protocol mismatch (SSH vs HTTPS/API), or management interface restrictions. This article explains how to diagnose the root cause and remediate the issue.
Why this happens? 🤔
Common root causes:
Incorrect credentials entered in the Inspector configuration (typo, outdated password).
Wrong management protocol used for your SonicOS version (v6 uses SSH for many inspector operations; v7 uses HTTPS/API).
Insufficient user privileges — the account lacks administrative/API privilege required to run the inspector.
Account locked or disabled due to failed logins or security policy.
MFA / 2FA applied to the management account (API/SSH accounts should not require interactive MFA).
Management interface restrictions (Trusted Hosts, management only from specific interfaces/subnets).
Recent firmware changes altered authentication or role mappings.
Quick triage checklist 📝
Confirm SonicOS version (v6 or v7).
Verify your Inspector is configured to use the correct management protocol for that version.
From the Liongard agent host, attempt to authenticate to the device using the same method/credentials.
Check SonicWall admin UI for account lockout, role, and Trusted Hosts.
Re-run Inspector in Clear Cache + Debug Mode after fixes and collect logs if problem persists.
Steps To Resolve 👨💻
Perform these checks from a system where agent is installed.
1️⃣ — Confirm SonicOS version and correct protocol
SonicOS v6 : inspectors often use SSH for data collection.
SonicOS v7 : inspectors primarily use HTTPS / REST API.
If you are using SSH credentials against a v7 device expecting HTTPS (or vice versa) the Inspector will fail with access denied or connection type errors. Update the Inspector template to the correct protocol.
2️⃣ — Verify credentials by logging in from the agent host
SSH (v6) — run from the agent host:
ssh -p <port> <user>@<sonicwall-ip>
# for verbose debug
ssh -vvv -p <port> <user>@<sonicwall-ip>
Successful SSH login → credentials OK.
Permission denied→ incorrect username/password or account lacks SSH access.Connection refusedorno route to host→ different issue (network/port).
HTTPS / API (v7) — curl test from agent host:
curl -v -u '<user>:<password>' 'https://<sonicwall-ip>:<port>/api/sonicos/some-endpoint' --insecure
200/expected JSON → credentials and API reachable.
401/403 → credentials rejected or insufficient permissions.
TLS errors → certificate/trust issue (see SSL checks below).
Use --insecure only for debugging; do not use it in production config unless acceptable.
3️⃣ — Check user account status & privileges
In SonicWall UI: Users / Administrators → confirm the account exists, is enabled, not expired, and not locked out.
Role: the account should have the required role.
If role is limited, temporarily assign Administrator role to confirm and then tighten back for least privilege.
4️⃣ — Check for account lockout & failed login attempts
In SonicWall: View Logs and filter for failed logins from the agent IP.
If account is locked: unlock it or reset the password and test.
If many failed attempts are recorded, review automation/deployment scripts that may be retrying with bad creds.
5️⃣ — Trusted Hosts / Management interface restrictions
SonicOS allows restricting management to specific interfaces and host IPs. Verify:
Admin → Device → Management or System → Administration (UI varies)
Ensure the agent’s source IP is allowed in Trusted Hosts or management rules.
If the agent is behind NAT, use the agent’s external NATed IP or add NAT gateway IP to Trusted Hosts.
6️⃣ — MFA / 2FA considerations
If the admin account is protected with interactive MFA / 2FA, API and SSH calls will fail. Use a dedicated non-MFA API/SSH account for the Inspector.
7️⃣ — Password complexity & recent changes
If the password recently changed, ensure the Inspector template is updated.
Confirm new password meets SonicWall complexity rules. Some SonicWall versions enforce complexity that might break scripted logins.
8️⃣ — Certificate / TLS issues (v7 API)
If HTTP auth fails with TLS errors, validate cert chain from agent host:
openssl s_client -connect <sonicwall-ip>:<port> -servername <hostname>
If the cert is self-signed, either:
Add the cert to the agent host trust store, or
Use a publicly-signed cert for management, or
Use an internal CA that the agent trusts.
9️⃣ — Rerun Inspector & collect debug logs
In Liongard: Admin → Inspectors → SonicWall inspector → Run → Clear Cache + Debug Mode.
Download the debug logs and compare timestamps against SonicWall logs to see the exact failure.
Troubleshooting Summary 🤩
Symptom | Probable cause | What to check | Remediation |
| Bad creds or wrong protocol | Verify SonicOS version; try login from agent host via SSH or curl for API | Correct credentials in Inspector; adjust protocol (SSH vs HTTPS) |
| Account lacks SSH access or wrong password | SSH -vvv from agent host; check SonicWall Admin user role | Grant SSH/API access or update password/role |
401 / 403 via API | Account lacks API privilege | Curl API with credentials; check admin role and API access flags | Assign appropriate admin role or enable API access |
Account locked repeatedly | Failed login attempts from automation | Check SonicWall logs for source IP and attempts | Unlock account, correct credentials, implement rate limiting/backoff |
Best practices & security considerations 🌟
Use a dedicated, least-privilege service account for inspectors (grant only required API/SSH permissions).
Avoid using interactive admin accounts protected by MFA for automated agents.
Document and rotate Inspector credentials according to your security policy.
Use certificate-based trust or public CA-signed certs for appliance management where possible.
Log and monitor failed login attempts — repeated failures indicate an automation or credential drift issue.
When to contact Liongard Support 🦁
Contact Support if, after completing the above steps, any of the following remain true:
You confirmed correct credentials from the agent host, but the Inspector still shows
access denied.SonicWall logs show requests from the agent, but responses indicate rejection for unclear reasons.
You cannot determine whether the Inspector is using SSH or API (we can help verify Inspector configuration).
You want us to review Inspector debug logs and correlate with SonicWall logs.
What to collect before contacting Support
Please gather the following and attach to your ticket to speed triage:
Liongard Inspector debug log (run Clear Cache + Debug Mode).
Output of connectivity & auth tests from the agent host (ssh -vvv, curl -v, Test-NetConnection).
SonicWall system logs screenshots showing failed login attempts (timestamps).
SonicOS version and build number.
Inspector configuration screenshot.
Exact error string & timestamp shown in the Inspector.
Note any recent changes (password rotation, firmware upgrade, network ACL change).
References & external links 📚
Third-Party Link Disclaimer ‼️
We may reference external third-party resources solely as additional guidance.
Liongard does not own, control, or guarantee the accuracy, security, or reliability of third-party sites.
Please use them at your own discretion and risk.