how to allow others to connect to database

Hi helpm

It sounds like you’ve set up SQL auth users and added your teammates’ IPs to the firewall but they still can’t connect. Here’s a checklist and some detailed steps you can try:

Make sure you’re editing the server-level firewall settings, not the database blade

• In the Azure portal, search for SQL servers (not “SQL databases”), pick your server.
  • Under Settings, click Networking or Firewalls and virtual networks.
    • If you don’t see a Networking tab on the database page, you’re in the database view—switch to the server view.
    Configure Public network access and firewall rules

    - Under **Public network access**, set it to **Selected networks** (or **Yes** for “Allow Azure services…” if they’re connecting from within Azure).
    
       - Click **Add your client IP** or enter your teammates’ public IP addresses (double-check each IP via something like [https://whatismyipaddress.com/](https://whatismyipaddress.com/)).
    
          - Save your changes.
    
          Verify SQL authentication settings
    
             - Ensure your server admin login (the one you created when provisioning) still exists and is enabled for SQL auth.
    
                - When your teammates connect, they should use: • Server name: `<your-server-name>.database.windows.net` • Login: `<sql-username>@<your-server-name>` • Authentication type: SQL Login
    
                Create and grant database-level users correctly If you created extra SQL logins/ users, make sure you did this at the right scope:
    
                   - Connect as the server admin in SSMS or the Azure Query Editor.
    
                      - In the `master` database run: `CREATE LOGIN MyUser WITH PASSWORD = 'StrongPass!123';`
    
                         - Switch to your project database and run: `CREATE USER MyUser FOR LOGIN MyUser;` `ALTER ROLE db_datareader ADD MEMBER MyUser;` `ALTER ROLE db_datawriter ADD MEMBER MyUser;`
    
                         Test network connectivity From a local machine or VM, run: `Test-NetConnection -ComputerName <your-server-name>.database.windows.net -Port 1433` You should get `TcpTestSucceeded : True`.
    

If it’s still not working, could you share the exact error message your teammates see when they try to log in? That’ll help pinpoint whether it’s a firewall/network issue or a login/permission problem.

Hope this helps! Let me know what error you’re getting and we’ll go from there.

Reference links:

• IP firewall rules – Azure SQL Database and Azure Synapse Analytics: https://learn.microsoft.com/azure/azure-sql/database/firewall-configure
• Understanding and configuring “Allow Azure services and resources to access this server”: https://learn.microsoft.com/azure/azure-sql/database/network-access-controls-overview#allow-azure-services
• Configure Public network access: https://learn.microsoft.com/azure/azure-sql/database/network-access-controls-overview?view=azuresql#public-network-access
• Tutorial: Secure a database in Azure SQL Database (create logins/users): https://learn.microsoft.com/azure/azure-sql/database/secure-database-tutorial#manage-database-access

Use the following checks step by step to allow group members to connect to the Azure SQL Database.

1. Confirm server-level firewall rules for each member

• Databases are blocked by default; server-level firewall rules must allow each client IP.
• In the Azure portal:
  1. Go to SQL databases → select the database.
  2. On the database overview page, select the Server name link to open the logical SQL server.
  3. Under Settings, select Networking (or Firewalls and virtual networks depending on UI).
  4. Under Public network access, choose Selected networks to see Firewall rules.
  5. For each group member:
     • Use the Add client IP button when they are connected from their machine, or
     • Manually add a rule with their public IPv4 address (or a range if they use dynamic IPs).
• It can take up to 5 minutes for firewall changes to take effect.

2. Handle dynamic or incorrect client IPs

• The IP shown on a user’s PC might not be the one Azure sees because of NAT.
• On the server’s Networking / Firewalls page, Azure shows the Current client IP address when that user is connected through the portal; use that value in the firewall rule.
• If users have dynamic IPs:
  • Ask the ISP or IT for the public IP range and create a rule for that range, or
  • Have them use a static IP and add that IP as a rule.

3. Ensure local/network firewalls allow outbound port 1433

• Azure SQL Database requires outbound TCP 1433 from the client network.
• If group members are on a corporate or school network, that firewall might block 1433. In that case, they cannot connect until the network admin opens outbound 1433.

4. Verify authentication and user permissions

• Firewall rules only allow the connection attempt; the login still needs valid credentials and permissions.
• For SQL authentication:
  1. Connect to the database with an admin account (for example via SSMS).
  2. Create a contained database user for each group member if needed:

          CREATE USER User1 WITH PASSWORD = 'StrongPassword1!';
          ALTER ROLE db_datareader ADD MEMBER User1;
          ALTER ROLE db_datawriter ADD MEMBER User1;
     

  3. Share with each member the server name (for example, yourserver.database.windows.net), database name, username, and password.
• If using Microsoft Entra authentication, ensure each user has a contained database user and appropriate roles.

5. If connecting from other Azure services

• If group members are using Azure services (App Service, Functions, etc.) instead of local machines, either:
  • Add the service’s outbound IPs as firewall rules, or
  • Temporarily enable the rule 0.0.0.0–0.0.0.0 (Allow Azure services and resources to access this server). Be aware this allows all Azure subscriptions to reach the server, so rely on strong logins and permissions and consider more secure options like private endpoints later.

6. If there is no Networking tab

• Access to firewall settings is on the logical SQL server, not the database blade itself.
• Always click through from the database to the server resource, then open Networking / Firewalls and virtual networks there.

7. Re-test and check timing

• After adding or changing firewall rules, wait up to 5 minutes.
• Have each member test with a simple SQL client (for example, SSMS) using the correct server name, database, and credentials.

References:

• Azure SQL Database and Azure Synapse IP firewall rules
• Tutorial: Secure a database in Azure SQL Database
• Link to or import data from an Azure SQL Server Database