## Connect directly with IP allowlisting

URL: https://docs.atlan.com/apps/connectors/database/microsoft-sql-server/how-tos/connect-directly-with-ip-allowlisting

> 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 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.

:::note New to this?

Read [How SQL Server connectivity works](https://docs.atlan.com/llms/connectors/microsoft-sql-server/how-sql-server-connectivity-works/llms.txt) 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](https://docs.atlan.com/llms/connectors/microsoft-sql-server/private-network-links-to-microsoft-sql-server/llms.txt) or the [self-deployed runtime](https://docs.atlan.com/llms/connectors/microsoft-sql-server/special-cases/llms.txt) 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](https://docs.atlan.com/support/submit-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](https://docs.atlan.com/llms/governance/administration/atlan-network-details/llms.txt).

## 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](https://docs.atlan.com/llms/connectors/microsoft-sql-server/firewalls-and-allowlists/llms.txt)):

- **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](https://docs.atlan.com/llms/connectors/microsoft-sql-server/troubleshooting-microsoft-sql-server-connectivity/llms.txt)).
- **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.

```shell

# 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](https://docs.atlan.com/llms/connectors/microsoft-sql-server/set-up-microsoft-sql-server/llms.txt), with additions that recurring support cases showed are missing.

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

```sql
-- 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>;
```

:::caution 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:

```sql
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:

```sql
-- 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](https://docs.atlan.com/llms/connectors/microsoft-sql-server/troubleshooting-microsoft-sql-server-connectivity/llms.txt).

## 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](https://docs.atlan.com/llms/connectors/microsoft-sql-server/troubleshooting-microsoft-sql-server-connectivity/llms.txt)).
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](https://docs.atlan.com/llms/connectors/microsoft-sql-server/mine-microsoft-sql-server/llms.txt)

## Next steps

[Crawl Microsoft SQL Server](https://docs.atlan.com/llms/connectors/microsoft-sql-server/crawl-microsoft-sql-server/llms.txt): Configure and run the crawler to extract metadata from SQL Server

---