Disable Sql Server Windows Login Account?

Question

For security purposes i am droping all the server roles from each login in the database and leaving only the "sa":

        //Get all server info for this instance
        Server oServer = new Server(@"YAHYA-PC\SQLEXPRESS");

        //Get all logins
        var users = oServer.Logins;
        //Get all server roles in the current instance
        ServerRoleCollection oServerCollection = oServer.Roles;
        //foreach login name drop all roles 
        foreach (Login oLogin in users)
        {
            if (oLogin.Name != "sa")
            {
                foreach (ServerRole oRole in oServerCollection)
                {
                    if (oRole.Name != "public")
                    {
                        oRole.DropMember(oLogin.Name);
                    }
                }
            }
        }

It was a success at first, but after running the code for the second time it turns out that the Server object connects via Sql Windows Authentication so it keeps giving me an exception since i omitted all the server roles from the Sql Windows Account. is there any possible way to make the Server object connects via Sql Server Account Login ?

Edit with the answer:

ServerConnection oConnection = new ServerConnection(@"ServerInstance","UserName","Password");
Server oServer = new Server(oConnection);

Answer 1

Try changing the connection string to: Provider=SQLNCLI10;Server=myServerAddress;Uid=myUsername;Pwd=myPassword

Update: While this may have given you the answer you were originally seeking, I agree with everything in Dave Markle's post and should have mentioned that earlier.

Answer 2

For security purposes i am droping all the server roles from each login in the database and leaving only the "sa"

I guess the "security purpose" is to take the wisely designed security features away from SQL Server and replace them with an ill-advised set of security holes that you've designed?

This is a bad, bad idea, and while there may be a way of doing this a convoluted system, you should avoid doing this. There's a reason why SQL Server gives you no option of using only SQL Server authentication, but instead allows only Windows Authentication. Actually, there are multiple reasons:

1) Everything in Windows runs under a Windows security context. That includes SQL Server itself, which has to run under a service process identity which exists in Windows in order to access, among other things, all of its data files. There's no way you can remove Windows authentication from the picture entirely, as it literally governs everything on every Windows machine.

2) Using Windows-only authentication (which is usually the better option than using mixed-mode auth) allows for delegation scenarios using Kerberos. Other schemes involve an unwise and sometimes impossible distribution of credentials. The trick is that you have to configure Kerberos correctly to do this.

3) Your password policies can be centrally administered using Active Directory with Windows authentication. This is not possible with SQL Server authentication, as password policy checks can be turned off without knowledge of your network admin.

Also, you're opening up the SA account as the only means of logging on to the server. This is extremely ill-advised unless you're just playing around inside a sandbox, and even then, I wouldn't do it. By using only the SA account, everyone who uses the server has carte blanche access to do pretty much anything to your server. And if you've granted a high level of access to the SQL Server service process, pretty much any user could gain control of the entire machine with relative ease.

It's a bad idea. My recommendation is to abandon this idea, and post a question on SO about your higher-level goals and how you might go about achieving them.

Answer 3

You may choose to use Windows Authentication and/or SQL Server Authentication at SQL Server install time. This would be the best way to truly exclude an authentication type. As for the motivation you mention above, I would caution you against it. I liken this to saying "I'm improving security by making everyone an Admin." It just doesn't make sense.

You have a multitude of knobs to turn to improve security... Roles are a key part of any strategy...