Changing the SA account name causes maintenance jobs to fail

  • SQL 2012 Standard on Windows Server 2012 Standard

    After observing brute force attacks on our VPS myhosting instance against the SA login, I change the SA login name. Now my two new backup jobs are failing. The agent service logs in as NT Service\SQLSERVERAGENT. Nothing changed there (so far as I know and I'm the only one who should be on the VPS). The job owner was SA and after changing the SA account that was reflected in the SSMS gui; job owner 'newsaname'. I'm sure I can just rebuild the maintenance plans but I'd like to know what happened.

    Also, I would like to learn more about the brute force attacks and how to determine what port they are comming in on. I see an IP address associated with them. Does that mean they are coming in on 1433 or 1434?

    John

    SQL 2012 Standard VPS Windows 2012 Server Standard

  • Johnny B (9/23/2014)


    SQL 2012 Standard on Windows Server 2012 Standard

    After observing brute force attacks on our VPS myhosting instance against the SA login, I change the SA login name. Now my two new backup jobs are failing. The agent service logs in as NT Service\SQLSERVERAGENT. Nothing changed there (so far as I know and I'm the only one who should be on the VPS). The job owner was SA and after changing the SA account that was reflected in the SSMS gui; job owner 'newsaname'. I'm sure I can just rebuild the maintenance plans but I'd like to know what happened.

    Also, I would like to learn more about the brute force attacks and how to determine what port they are comming in on. I see an IP address associated with them. Does that mean they are coming in on 1433 or 1434?

    John

    Don't! It is better to disable "sa" than rename it. Things like SQL service packs wont' work later because they usually look for "sa" and if is not found, installation will fail.

    I think you can disable "sa" and your jobs can continue running without any issue.

    If you need another account that needs to be part of "sysadmin" role (not sure why someone wants that, but there are some cases) you can create it with a different name and add it to "sysadmin" server role.

    Regarding securing your SQL box, that's a complex topic with much more stuff to check than just ports. Changing ports just make hacking more difficult. But if you want to make your box more secure, just change the default MSSQL port to a different one. Keep in mind that your applications may break, so you need to coordinate with your developers and test before any change.

  • Ok, Thanks for the tip on not renaming but disabling. As to changing the default port. This should have little impact as we only have two applications; blog engine and ASPNETDB web site connecting. The connection strings are in web.config files and don't mention ports. Not sure how the connection string object knows what port SQL is listening on.

    What about SQL Clients tools such SSMC and tools like Matlab? I'll experiement on the dev box but if anyone can refer a SQL developer to some beginner sysadmin security infor for SQL Server I'd be appreciative.

    John

    SQL 2012 Standard VPS Windows 2012 Server Standard

  • By default the default instance of SQL Server listens on 1433. SQL Browser listens on 1434.

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply