Description
The SQL Server connector connects to a Microsoft SQL Server instance via JDBC and discovers server-level logins, role memberships, and database-level principals. It identifies privileged logins such as members of sysadmin and other fixed server roles.
Both SQL Server Authentication (username + password) and Windows/Integrated Authentication are supported. Integrated Authentication uses the JDBC driver's pure-Java Kerberos implementation (authenticationScheme=JavaKerberos) rather than the native mssql-jdbc_auth-<version>.dll — it works cross-platform, including on Linux On-Premise Agent hosts, and authenticates directly with the supplied principal and password (no pre-existing Kerberos ticket cache or keytab needed). It does require a valid krb5.conf on the host running the scan, pointing at the correct realm/KDC.
System Type Classification
| Field | Value |
|---|
| System Type | Infrastructure |
| Default Scan Priority | 500 |
Version Support
| OrbisID Edition | Supported |
|---|
| Community | No |
| Pro | Yes |
| Enterprise | Yes |
SQL Server scanning requires a Pro or Enterprise licence.
Supported Protocols
| Protocol | Port | Notes |
|---|
| JDBC (TDS) | 1433 TCP | Standard SQL Server port; configurable per instance |
What OrbisID Discovers
| Data | Source |
|---|
| Server logins (SQL logins and individual Windows logins) | sys.server_principals |
| Windows/AD group logins | sys.server_principals (discovered as Entitlements, not Accounts — see below) |
| Server role memberships | sys.server_role_members |
| Fixed server roles | sysadmin, securityadmin, serveradmin, setupadmin, processadmin, diskadmin, dbcreator, bulkadmin |
| Login status (enabled/disabled) | is_disabled column |
| Login type (SQL login vs Windows login) | type_desc column |
Windows/AD Group Logins ("Shadow Groups")
A SQL Server login can be granted directly to a Windows local group (e.g. BUILTIN\Administrators) or an AD domain group (e.g. EXAMPLE\SQL_Admins), rather than to an individual account. SQL Server has no visibility into who is actually a member of that group — it only knows the group can log in and which server roles it holds. These group logins are discovered as their own Entitlement (type SQL_SERVER_WINDOWS_GROUP, tagged with a scope attribute of LOCAL or DOMAIN) rather than as an Account, so a group's server-role membership shows up as a proper child-group relationship (e.g. BUILTIN\Administrators → sysadmin) instead of being misrepresented as an individual privileged user.
Cross-system resolution: if the real group is also discoverable elsewhere in OrbisID, the shadow group login is automatically linked to it after each scan, so the real account holders show up with this SQL Server login as one of their entitlements:
DOMAIN-scoped groups (e.g. EXAMPLE\SQL_Admins) resolve against an Active Directory Target System matching that domain (by NetBIOS name or FQDN) — including accounts that hold the privilege through nested AD groups.LOCAL-scoped groups (e.g. BUILTIN\Administrators, NT AUTHORITY\..., NT SERVICE\...) resolve against a Windows Target System that shares the same hostname or IP address as this SQL Server system — i.e. add the machine SQL Server is running on as its own Windows Target System to get this link. If no matching AD or Windows system exists (or it hasn't been scanned yet), the reference simply stays unresolved rather than guessing.
Connection Requirements
Credential Requirements
The credential must be a SQL Server login or a Windows/AD account with at least the following server-level permissions:
| Permission | Purpose |
|---|
VIEW SERVER STATE | Read sys.server_principals and role memberships |
VIEW ANY DATABASE | (Optional) Extend discovery to database-level principals |
Recommended (SQL Server Authentication): Create a dedicated SQL login for OrbisID with minimal permissions:
CREATE LOGIN orbisid_scanner WITH PASSWORD = '<strong-password>';
GRANT VIEW SERVER STATE TO orbisid_scanner;
GRANT VIEW ANY DATABASE TO orbisid_scanner;
Windows/Integrated Authentication: Create (or reuse) an AD account, then grant it a SQL Server login mapped to that account and the same permissions:
CREATE LOGIN [EXAMPLE\orbisid_scanner] FROM WINDOWS;
GRANT VIEW SERVER STATE TO [EXAMPLE\orbisid_scanner];
GRANT VIEW ANY DATABASE TO [EXAMPLE\orbisid_scanner];
Credential Mapping (Windows/Integrated Authentication)
| OrbisID Field | Value |
|---|
credential.username | The plain Kerberos principal — no DOMAIN\ prefix (e.g. orbisid_scanner, not EXAMPLE\orbisid_scanner) |
credential.password | The account's password |
credential.domain | The Kerberos realm, typically the AD domain in upper case (e.g. EXAMPLE.COM) |
System Attributes
| Attribute | Required | Default | Description |
|---|
sqlServerAuthType | No | SQL | SQL for SQL Server Authentication, or WINDOWS for Windows/Integrated Authentication |
Network Requirements
| Requirement | Detail |
|---|
| SQL Server Browser service | Required if using named instances |
| TCP/IP protocol enabled | Must be enabled in SQL Server Configuration Manager — disabled by default on SQL Server Express/Developer editions |
| Port 1433 accessible | Or the custom port for the instance |
| SQL Server Authentication | For SQL logins, the instance must be in Mixed Mode (SQL Server and Windows Authentication mode) — Windows-Authentication-only instances reject every SQL login regardless of credentials |
| Kerberos configuration (Windows/Integrated Authentication only) | The On-Premise Agent (or OrbisID server) host needs a krb5.conf pointing at the correct realm/KDC, and the SQL Server service account needs a registered SPN (setspn -L <service account>) |
Configuration Steps
- Navigate to Systems in the sidebar
- Click Add System
- Fill in the fields:
| Field | Value |
|---|
| System Name (General tab) | Descriptive name (e.g., sql-prod-01) |
| IP Address / Hostname (Connection tab) | SQL Server hostname or IP |
| Port | 1433 (or custom port) |
| OS Type | SQL Server |
| System Type | Infrastructure (auto-selected) |
| Database Name | Name of the database to connect to (e.g., master) |
| Credential | SQL login or Windows/AD account with required permissions |
- If using Windows/Integrated Authentication, set Authentication Type to
Windows/Integrated Authentication in the Connection Attributes section (defaults to SQL Server Authentication)
- Click Test Connection to verify connectivity and authentication
- Click Save
The Database Name field specifies the initial connection database. The scanner reads server-level data from system views (sys.*), so master is typically appropriate.
Troubleshooting
| Symptom | Likely Cause | Resolution |
|---|
| Both SQL and Windows authentication fail identically against the same instance | Something is failing before authentication is even attempted — most likely TCP/IP disabled or a TLS/encryption handshake issue, not the credential | Verify TCP/IP is enabled in SQL Server Configuration Manager (disabled by default on Express/Developer editions) and port 1433 is reachable; the connector always requests encrypt=true |
SQL Server Authentication fails with Login failed for user 'X'. Reason: An attempt to login using SQL authentication failed. Server is configured to allow only Windows authentication. | The instance is in Windows-Authentication-only mode | Switch the instance to Mixed Mode (SQL Server and Windows Authentication mode) in SQL Server settings, or use Windows/Integrated Authentication instead |
Connection test fails with Login failed (SQL Server Authentication) | Invalid credentials or SQL auth disabled | Verify login exists and SQL Server is in mixed auth mode |
Windows/Integrated Authentication fails with a GSSException / Kerberos error | Missing or misconfigured krb5.conf, wrong principal/password, or the SQL Server service has no registered SPN | Verify krb5.conf on the agent host points at the correct realm/KDC; confirm the principal and password; run setspn -L <SQL service account> to confirm an MSSQLSvc/... SPN is registered |
Windows/Integrated Authentication fails with Login failed | The AD account authenticated successfully via Kerberos but has no SQL Server login mapped to it | Run CREATE LOGIN [DOMAIN\user] FROM WINDOWS; and grant it the required permissions |
Connection test fails with Connection refused | Port blocked or TCP/IP disabled | Check SQL Server Configuration Manager — enable TCP/IP and verify port 1433 |
| Named instance not found | SQL Server Browser not running | Start the SQL Server Browser service or specify the port explicitly |
| Scan succeeds but no roles found | Insufficient permissions | Grant VIEW SERVER STATE to the scanning login |
| Windows logins not discovered | N/A — Windows logins are always included | Windows logins and groups are discovered from sys.server_principals regardless of which authentication type OrbisID connects with; ensure WINDOWS_LOGIN/WINDOWS_GROUP accounts appear there |