Connect directly with IP allowlisting

✦TL;DR

Connect Atlan to a SQL Server that is reachable from the internet - including Azure SQL Database with "Selected networks" enabled. Four phases, each labeled with who performs it.

||

|Connect

Connect Atlan to a SQL Server that is reachable from the internet - including Azure SQL Database with "Selected networks" enabled. Four phases, each labeled with who performs it.

New to this?

Read How SQL Server connectivity works first (5 minutes). It explains NAT IPs, allowlists, listeners, and why "it works in SSMS" doesn't mean it will work from Atlan.

Prerequisites

• A SQL Server hostname that resolves on the public internet. Private names (.local, internal DNS) will not work - use a private link or the self-deployed runtime instead.
• SQL Server listening on a fixed port (1433 by default). Ask your DBA to confirm; note the real port if it differs.
• Someone who can edit your database firewall (cloud portal and/or network team).
• Someone with admin access to SQL Server for the credential phase.

Four phases at glance

Phase	What happens	Owner	Typical time
1. Gather	Get your tenant's outbound IPs from Atlan	Atlan User + Atlan support	1 ticket, ~1 business day
2. Allowlist	Open your firewall(s) to those IPs on the SQL port	Your cloud/network team	30 minutes
3. Credential	Create the login and grant metadata permissions	SQL Server admin	15 minutes
4. Connect and verify	Configure the crawler and test	Atlan User	30 minutes

Phase 1 - Get your tenant's outbound IPs

Owner: Atlan User + Atlan support

Raise a support request from within Atlan with your tenant URL: "Please share the outbound (NAT/egress) IP addresses for my tenant, for allowlisting on our SQL Server firewall - and note on our account that we need notification if they change." These are provisioned per tenant; there is no shared table, and values from another tenant (even your own sandbox) will not work. See Atlan Network Details.

Phase 2 - Allowlist IPs on every firewall layer

Owner: Your cloud/network team

Traffic from Atlan usually crosses several firewalls, and all of them must allow it. Work through the layers that apply to you (details on Firewalls and allowlists):

• Azure SQL Database: in the Azure portal, your server → Networking → Public access → Selected networks → add a firewall rule for each Atlan IP.
• Cloud VM / EC2: the NSG or security group on the machine's subnet, and the Windows Firewall on the server itself.
• On-prem or behind a corporate edge: the perimeter firewall, plus any load balancer or traffic manager in front of the database - a middlebox that silently drops unknown IPs looks exactly like a TLS problem from the outside (see troubleshooting).
• Listener redirects: if the server is part of an Always On availability group or a named instance, allowlist the redirect target host and port too.

# Azure CLI example - one rule per Atlan egress IP
# (values from YOUR support ticket - these are placeholders)
az sql server firewall-rule create \
  --resource-group my-rg --server my-sqlserver \
  --name atlan-egress-1 \
  --start-ip-address 203.0.113.10 --end-ip-address 203.0.113.10

Phase 3 - Create credential and grant permissions

Owner: SQL Server admin

Pick one of the three supported authentication methods. The minimum grants below come from Set up Microsoft SQL Server, with additions that recurring support cases showed are missing.

Option A - Basic (SQL username/password) or Windows (NTLM)

-- Minimum, per database to crawl:
GRANT VIEW DEFINITION ON DATABASE::<database_name> TO <username>;
-- Optional, only if you also want asset preview/querying:
GRANT SELECT ON DATABASE::<database_name> TO <username>;

The VIEW ANY DATABASE trap

Server-level VIEW ANY DATABASE only lets the login see that databases exist - it does not grant access inside them. If the crawler lists databases but finds no tables, or the include/exclude picker is empty, grant per-database CONNECT + VIEW DEFINITION, or at server level:

GRANT CONNECT ANY DATABASE TO <login_name>;
GRANT VIEW ANY DEFINITION TO <login_name>;

Option B - Service principal (Microsoft Entra ID)

Register an application in Entra ID and collect its client ID, client secret, and tenant ID. Then - the step most support cases missed - the app registration must also be created as a user inside each database:

-- Run per database, as an Entra admin:
CREATE USER [<app-registration-name>] FROM EXTERNAL PROVIDER;
GRANT VIEW DEFINITION ON DATABASE::<database_name> TO [<app-registration-name>];

Without this, the network path can be perfect and you'll still see a vague "Authentication failed" - see troubleshooting.

Phase 4 - Connect and verify

Owner: Atlan User

1. In Atlan, open New workflow → SQL Server Assets and choose the Direct extraction method.
2. Fill in Host (the public hostname - for availability groups, the listener address), Port (the real one), the database, and your Phase 3 credentials. For NTLM, also fill Windows Domain (e.g. CORP).
3. Leave Encrypt Connection on unless your DBA says otherwise. Self-signed certificates are generally fine - the connector relaxes certificate validation - so don't disable encryption to "fix" handshake errors; they're firewall problems (see troubleshooting).
4. Click Test Authentication, then run the preflight checks.

Success checklist

• Test Authentication passes
• Preflight checks pass
• The include/exclude picker shows your databases (if it's empty, revisit Phase 3 - the VIEW ANY DATABASE trap)
• A crawl scoped to one small database completes
• If you plan to mine lineage: Query Store is enabled (QUERY_CAPTURE_MODE = ALL) and the login has VIEW DATABASE STATE - see Mine Microsoft SQL Server

Next steps

Crawl Microsoft SQL Server: Configure and run the crawler to extract metadata from SQL Server