InletDownload

Connect · Azure SQL Database

Connect to Azure SQL Database from your Mac

Copy the server name (<server>.database.windows.net) and the ADO.NET connection string from the Azure portal, add your IP address to the server’s firewall rules, and sign in with SQL authentication on port 1433. Connections are always encrypted, with a certificate your Mac already trusts.

Updated 9 October 2026

What you need

  • The server name, <server>.database.windows.net, and the database name.
  • A SQL authentication login and its password: the server admin you chose when you created the server, or a login or contained database user made for you. Inlet signs in with a user name and password; it doesn’t support Microsoft Entra ID (formerly Azure AD) sign-in yet.
  • Network access from your Mac: public network access set to Selected networks and a firewall rule for your IP address. A server reachable only through a private endpoint has no public address; reach it from inside its virtual network, for example through an SSH tunnel via a VM there.
  • Your network must allow outgoing TCP port 1433, and ports 11000–11999 if the server uses the Redirect connection policy (below).

Find your connection details

  1. In the Azure portal, open the database. On its Overview page, Server name is the host: <server>.database.windows.net.

  2. Under Settings, open Connection strings and copy the ADO.NET string. The SQL authentication string has this form:

    Server=tcp:<server>.database.windows.net,1433;Initial Catalog=<database>;Persist Security Info=False;User ID=<user>;Password={your_password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
    

    The password isn’t in it: replace {your_password}, or leave it and enter the password separately.

  3. The admin login’s name is on the server’s Properties page as Server admin login. You can’t rename it. If you’ve lost the password, select the server under SQL servers and choose Reset password.

Firewall rules. A new server’s firewall blocks everything. On the server’s Networking page, Public access tab, set Public network access to Selected networks, add your client IPv4 address under Firewall rules, and select Save. (From the database’s Overview page, Set server firewall opens the same page.) Changes can take up to five minutes. With the Azure CLI:

az sql server firewall-rule create --resource-group <group> --server <server> \
  -n my-mac --start-ip-address <your-ip> --end-ip-address <your-ip>

--server takes the short name (<server>), not the full host name. Because of address translation, the address Azure sees can differ from the one your Mac reports; error 40615 (below) names the one to allow.

Allow Azure services and resources to access this server is a different switch. It adds a rule for 0.0.0.0 named AllowAllWindowsAzureIps that lets in every Azure service, including ones in other customers’ subscriptions. It does nothing for your Mac, and Microsoft suggests private or service endpoints instead.

Ports and connection policy. Clients first reach a gateway on port 1433. What happens next depends on the server’s connection policy (Networking › Connectivity tab):

PolicyFrom your MacPorts to allow outbound
DefaultProxy: everything goes through the gateway1433
ProxyEverything goes through the gateway1433
Redirect (Microsoft’s recommendation)The client is sent on to the node that hosts the database1433, and 11000–11999 to Azure SQL’s addresses in the region

Redirect gives lower latency, but only if your network lets the client out on the higher ports. Inlet follows Azure’s redirect routing, so with Redirect it connects directly to the node.

Azure SQL Managed Instance connects the same way, with different endpoints. From inside its virtual network, use the host name on its Overview page and port 1433. From your Mac, turn on its public endpoint (Security › Networking), add an inbound network security group rule for TCP port 3342, and connect to <instance>.public.<dns-zone>.database.windows.net,3342. Server-level firewall rules don’t apply to Managed Instance.

SQL authentication and Microsoft Entra ID

Azure SQL Database accepts SQL authentication (user name and password) and Microsoft Entra ID. Microsoft Entra-only authentication turns SQL authentication off for the whole server: the server admin, logins and contained users all stop working, though the accounts stay. It can be switched on when the server is created. Such a server still shows a Server admin login, named CloudSA and some random characters, but no one can sign in with it.

To use SQL authentication, someone with the right Azure role turns the setting off, in the portal on the server’s Microsoft Entra ID page or with the Azure CLI, then sets a new admin password with Reset password:

az sql server ad-only-auth disable --resource-group <group> --name <server>

From a query window, SELECT SERVERPROPERTY('IsExternalAuthenticationOnly') returns 1 while it’s on.

Rather than use the admin, which has every permission on every database, create a login for daily work. In the master database:

CREATE LOGIN app_reader WITH PASSWORD = '<password>';

Then in your database:

CREATE USER app_reader FOR LOGIN app_reader;
ALTER ROLE db_datareader ADD MEMBER app_reader;

Or make a contained user, which lives in your database only. Connected to that database:

CREATE USER app_reader WITH PASSWORD = '<password>';
ALTER ROLE db_datareader ADD MEMBER app_reader;

Azure SQL Database enforces password complexity: at least 8 characters, from three of the four kinds (uppercase, lowercase, digits, symbols), and not containing the name.

Connection string

The ADO.NET string from the portal is the easiest to use. The same connection as a URL and in JDBC form:

sqlserver://<user>:<password>@<server>.database.windows.net:1433?database=<database>&encrypt=true
jdbc:sqlserver://<server>.database.windows.net:1433;databaseName=<database>;encrypt=true;trustServerCertificate=false

A contained database user (one created inside the database, with its own password) can only sign in to that database, so always give the database name. More forms in SQL Server connection strings; percent-encode special characters in URL passwords (special characters in passwords).

TLS

Every connection is encrypted: Azure SQL Database forces encryption, and the minimum TLS version is 1.2 (TLS 1.0 and 1.1 are retired). A server can raise the minimum to TLS 1.3 on the Networking page, Connectivity tab; an older client then gets Error 47072 Login failed with invalid TLS version.

The server certificates chain to public roots: Microsoft names DigiCert Global Root G2, Microsoft RSA Root Certificate Authority 2017 and Microsoft ECC Root Certificate Authority 2017. All three are in the macOS trust store (checked on macOS 26.2), so check the certificate and the host name; there’s no CA file to download. That’s what the portal’s string does with Encrypt=True and TrustServerCertificate=False, and Microsoft warns against TrustServerCertificate=True.

The check compares the name you connected to with the names in the certificate, so connect with the server name, not an IP address. If you must use another name (a DNS alias), drivers that have the option can be told the expected name with HostNameInCertificate.

Microsoft recommends strict encryption (TDS 8.0, Encrypt=Strict) when the driver supports it; Azure SQL Database does.

Connect with Inlet

  1. Copy the ADO.NET string from the portal and paste it into Inlet. Inlet fills in the connection form. Or choose New Connection, pick SQL Server, and enter the server name, port 1433, the database, user and password.
  2. Under encryption, choose to verify the certificate and the host name. Azure’s certificates chain to roots macOS trusts. Turn on strict encryption (TDS 8.0) if your organisation asks for it.
  3. Save the password in the Keychain, or have Inlet ask every time.
  4. For a server you reach only through a private endpoint, or Managed Instance’s VNet endpoint, turn on the SSH tunnel through a VM in the virtual network. Inlet uses the system ssh, so ~/.ssh/config and the SSH agent work.
  5. Tag the environment. A production connection opens read-only: SQL Server has no read-only session, so Inlet refuses writes itself, before they’re sent. Temp tables and SQL Server’s reporting procedures (sp_help, sp_who…) still work. For a limit the server enforces, sign in as a login with only db_datareader, like app_reader above.

Inlet’s Activity view (sessions and who blocks whom, locks, table sizes, the plan cache’s costliest queries) needs VIEW DATABASE STATE on Azure SQL Database. The server admin has it; for another user, GRANT VIEW DATABASE STATE TO app_reader; in the database.

Connect from the command line

Microsoft’s Go-based sqlcmd installs with Homebrew (brew install sqlcmd). Give the database for a contained user, and leave out -P to be asked for the password:

sqlcmd -S <server>.database.windows.net -d <database> -U <user> -N true

According to Microsoft’s documentation, with -N and without -C go-sqlcmd checks the server certificate, which is what you want here; without either, it doesn’t check. It can also sign in with Microsoft Entra ID (-G), which Inlet can’t yet. We couldn’t run these commands against Azure for this page; they follow Microsoft’s documentation as of October 2026.

To see whether your network lets you out on port 1433:

nc -vz <server>.database.windows.net 1433

A connection there only shows the gateway is reachable: the firewall check happens when you sign in.

Troubleshooting

  • Error 40615, client IP not allowed: your address isn’t in the firewall rules. The message names it (as posted on Microsoft Q&A):

    Cannot open server '<server>' requested by the login. Client with IP address '<ip>' is not allowed to access the server. To enable access, use the Windows Azure Management Portal or run sp_set_firewall_rule on the master database to create a firewall rule for this IP address or address range. It may take up to five minutes for this change to take effect.
    

    Add that address, wait up to five minutes, and try again. If your IP changes often, ask your provider for its range.

  • Error 47073, The public network interface on this server is not accessible.: public network access is set to Disable. Set it to Selected networks, or connect through the private endpoint.

  • Login failed for user (18456): a wrong user name or password, Microsoft Entra-only authentication switched on, or a contained user signing in without the database name.

  • Cannot open database requested by the login (4060): the database name is wrong, or your login has no user in that database.

  • It connects, then times out: the server uses Redirect and your network blocks ports 11000–11999. Open them outbound, or set the connection policy to Proxy.

  • The certificate chain isn’t trusted: you connected by IP address or through another name. Use <server>.database.windows.net. Inlet says The server’s certificate couldn’t be verified: followed by OpenSSL’s reason.

  • Error 47072, invalid TLS version: the client offers a TLS version below the server’s minimum. Update the client.

  • Error 40613, database not currently available: Microsoft lists it among the transient errors. Retry after a short wait.

  • A network-related or instance-specific error: a firewall on your side blocks outgoing port 1433, or the server name is wrong. Inlet says Couldn’t connect to <host>:1433: with the reason, or Couldn’t find the host for a name that doesn’t resolve.

Related

Sources