Overview 💥
When the Microsoft SQL Server Inspector is created via auto-discovery, it often defaults to using the same Windows account that the Liongard Agent runs as. The Inspector can run using Windows Authentication (the Agent account) or SQL Authentication (a SQL login you supply).
If the connection succeeds but the account lacks required permissions, inspections will either fail or return incomplete data.
This article explains why that happens, recommended (least-privileged) permissions, step-by-step remediations, example T-SQL, and security best practices.
Why this happens? 🤔
Auto-discovery frequently uses the Agent service account (a Windows principal). That account must be allowed to access the SQL instance and must have permissions to read system metadata.
SQL Server distinguishes authentication (can you connect?) from authorization (what you’re allowed to do). A successful connection does not imply the account can query the system views the Inspector needs.
Step(s) To Resolve 👨💻
✅ Switch the Inspector to SQL Authentication :
If Windows Authentication is not practical, create a dedicated SQL login.
How to configure the Inspector UI?
Edit the Inspector in Liongard.
Set Authentication Type → SQL.
Enter the SQL username and password you created.
Save and run the Inspector (use Clear Cache + Debug if you want verbose logs).
Quick troubleshooting checklist 📝
Connection is OK but inspection fails → Confirm which authentication mode the Inspector is using (Windows vs SQL).
If Windows auth:
Does the Agent account exist as a SQL Server LOGIN?
Does it have required permissions?
If SQL auth:
Does the SQL login exist and are credentials correct in the Inspector?
Does the login have the required grants?
Run the Inspector in Clear Cache + Debug to capture full logs.
What to provide when contacting Support 🦁
If you need help, include the following to speed up triage:
Inspector name and Environment in Liongard.
Which Authentication Type is configured (Windows or SQL).
Exact error message from the Inspector logs.
SQL Server version (e.g., 2019 CU#, 2017, etc.
Results of a Clear Cache + Debug run (logs).
Evidence of permissions attempted (optional: output of
SELECTqueries below).
Helpful SQL to run for diagnostics (share results with Support):
-- Server version
SELECT @@VERSION;
-- Check if login exists and server roles
SELECT name, type_desc FROM sys.server_principals WHERE name = 'DOMAIN\LiongardAgentUser' OR name = 'lg_inspector';
-- Check granted server permissions
SELECT * FROM sys.server_permissions WHERE grantee_principal_id = SUSER_ID('DOMAIN\LiongardAgentUser');