This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(96, 70%, 19%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ECG%3C/text%3E%3C/svg%3E)
Hello, I am looking for some documentation or a way to view the account lockout policy for SQL authenticated Logins for Azure SQL Databases. (not VM) (ex. how many failed attempts before login gets locked).
Thanks!
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(220.8, 4%, 31%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESM%3C/text%3E%3C/svg%3E)
Hi
Chua, Gerson,
Following up to see if the below suggestion was helpful. If this answers your query, do click Accept Answer and Mark Helpful for the same. And, if you have any further query do let us know.
SQL authentication on Azure SQL Database does not have a built-in way to implement account lockout policy. In addition, Azure SQL Database only enforces password complexity for password policy.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(35.2, 51%, 13%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMS%3C/text%3E%3C/svg%3E)
Hi @Alberto Morillo Do you know if Azure SQL Database has a built-in "smart lock" default option? (any documentation for that)
I'm running vulnerability tests on Azure SQL Database, trying to brute force SQL login, and I've observed that after 10 attempts, the account appears to be locked. When I sends 30 FL, then only for 10th the Azure SQL Database audit will catch information about the login name that generated the FL attempts, and for 20th there will be no such information.
The Advanced Threat Protection (ATP) feature is designed to protect and detect against brute force attacks. If you disable that feature on Azure SQL you may find a different behavior. ATP can also identify penetrations tests workloads.
Thanks @Alberto Morillo
The Advanced Threat Protection (ATP) is a part of Microsoft Defender for SQL and it is disabled for my test database.
Even though Defender for Cloud is disabled. I can check the Defender plan in the environment settings and I found that by default Foundational CSPM is enabled.
but I don't find any feature in this plan that could prevent brute force attacks.
Anyway
Do you have any information about exclusion most popular botnets for Azure networks by default?
I created few Azure SQL database honeypots, opened them to public and expecting many brute force attack like it looks for on-premise SQL servers but I don't see a single one and that's weird.
any thoughts..?
To my knowledge only with Entra IDs is possible to configure smart lock to protect against brute force attacks On this thread I explain how to protect against brute force using Azure SQL Auditing. Have you examined Azure SQL Auditing? Maybe you can see the failed attempts there. You said you configured the database to public access, so are you allowing traffic on Azure SQL Firewall from the IPs you are expecting the attacks?
I'm using Azure SQL auditing to collect information about successful and failed logins attempts so I see all of them.
I opened database on firewall to public to allow all connections so I can see IP's from I expecting the attack and I see the ones that I generating.(but only mine)
I expected to see other attacks from known botnets in a short time like I was able see on on-premise SQL servers - but there is nothing so I started wondering what is the root of that. At the moment I have two theories that I am trying to verify :
If by any change, the IP address of those botnets is not listed on the whitelist of Azure SQL firewall, the connection attempts will be stopped on the Azure SQL Gateway and you won't be able to reach the attempts on the audit logs.
From this point of view we can assume that my statement: "open to public" mean that I added to whitelist all IP's.
Now I see what you mean... I fully agree, it is open to the public. I don't know what else could be the reason those connection attempts not reaching the database. Can you try to connect from your home using tools like sqlmap and hydra? Hydra can help you simulate a brute force attack.