![](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(252.8, 36%, 34%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESD%3C/text%3E%3C/svg%3E)
![](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(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
We install SQL Server in mixed mode. SQL authentication is used in application level. For security perspective I want to provide only windows authentication to all developers with limited access. The concern is developer also have the application server access and it is easy to them to see the database userid and password from application config file. So, if "SQL Server Authentication" dropdown is deleted then they can only able to login through "windows authentication".
First, no, you cannot remove that from the dropdown. And furthermore, if it would be possible, it would be something that is done locally, nothing you can enforce from SQL Server. And even if you could, developers could write their own application (ab)using that username and password.
What you possibly could to is to create a logon trigger, that only accepts logons from the application account from the IP address of the application server. But if developers have access to the application server, guess what, they can still log in.
Let's look at this from another way: why would it be a problem if developers log in with the application login? In a proper environment, I would more or less expect developers to have higher permissions than the application login. For instance, they are likely to have access to create stored procedures. The application login, on the other hand...Ideally it should only have permission to run stored procedures, nothing more. But not all applications use stored procedures exclusively, and there may be no alternative than to grant SELECT permissions and maybe also INSERT, UPDATE and DELETE permissions to the application login. But that's where it stops. You should never grant more. If the application needs to do more advanced operations, this should be handled by packaging the permissions in signed stored procedures that carefully only applies the permission for the exact operation.
