Voice of the DBA

Tag: sql server

  • Removing SA from Azure SQL Database

    One of the recommendations from Microsoft SQL Server is to use Windows authentication. This has been in the docs for years, and I’ve heard many MS consultants and employees note this. Many customers and clients have tried to use Windows Authentication only, but often in a cross platform environment with Java or Linux clients, one usually has needed SQL authentication with a user and password. Client libraries have been enhanced so this isn’t necessary, but still some people prefer SQL authentication, especially with clients outside their organization. It’s simple, easy, and developers can make it work in seconds.

    With Azure SQL Databases, some companies defaulted to a username and password, as their Active Directory (AD) wasn’t extended to Azure. That has become easier to do, and many people are taking advantage of it. In fact, some customers are so integrated, they want to do away with usernames and passwords in Azure.

    Microsoft has listened, and is giving them the option. The feature is in preview, but if you enable this, SQL auth is turned off, which means whatever administrative account you set up for the server with a name and password will not work. That’s essentially the “sa” account, though with your own custom name.

    While this feature won’t be useful for everyone, it’s a good option to have. As more companies look to tighten security and limit the attack surface area, being able to make this choice is important. It’s also something that architects and administrators should be aware of and consider in their decisions on how to implement applications in Azure.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Security Updates for SQL Server Jan 2021–CVE-2021-1636

    There was a security bulletin (CVE-2021-1636) for SQL Server, an elevation of Privilege vulnerability that could be exploited when an Extended Event session is running.

    SQL Server has released a number of patches. You can see them on the Release blog, but there are KB links below. If you have any servers that potentially can be accessed by unauthorized traffic, consider patching them.

    SQL Server 2019

    SQL Server 2017

    SQL Server 2016

    SQL Server 2014

    SQL Server 2012

    For SQL Server 2016 and earlier, make sure you are at the Service Pack levels listed. If you aren’t, you cannot patch these instances.

  • The Pace of Data Platform Change

    I was watching Vicky Harp in the 2020 October GroupBy conference recently talking about her challenges of working with the SQL Server platform as it’s grown. It’s a good keynote, with Vicky noting that she started with SQL Server 2000 and the journey to today is incredible. There’s a great view of her world at the 10:00 mark (after the start).

    She had this quote, which I found really thoughtful. This is something I think is true and something that many of us don’t like.

    “Usually growth comes at the expense of the previous comfort of safety.” – Josh Waitzkin, The Art of Learning.

    What’s your response? Run, fight? Embrace change? Resist doing anything different? I think many of us want to think that we easily embrace change, but think about the last time someone wanted to change something at work? Reorg, new protocol, etc. Did you resist and think it was silly or go along and give it a chance? For many people, it’s the former.

    To be fair, it is for me as well, and I think many people that have some success in their career often want to stick with the things they are experienced in. That’s not necessarily a problem, but it is worth investigating and embracing some new things, just to see if they might be better.

    The data platform is certainly one of those technologies in my life that has changed dramatically, and the pace is sometimes overwhelming. At this point, it’s hard to keep up, and hard to understand sometimes if new tech is better or worse. I’ve started to try and assume there is some good reason why Microsoft makes some changes, and then experiment, test, and evaluate the tech.

    Not just once when something is released or I encounter it, but by also watching what others do and then learning where they’ve had success or failure. ADF is one of those areas where I initially dismissed it as a poor port of SSIS, but I’ve come to appreciate some of the ways in which this is an improvement to many flows, especially with hybrid workflows.

    The data platform is an exciting place to work these days, and I hope you embrace some of the changes and see where a new technology might improve your environment. Of course, lots of traditional features out there work very well, and it’s not worth changing just to change. Make sure there is value and an improvement in some way, beyond you just enjoying working with something shiny and new.

    Steve Jones

    Note: Podcasts are suspended for a week as I deal with the PASS Summit.

  • SQL Server Phone Home

    A few versions ago Microsoft added the Customer Experience Improvement Service to the SQL Server platform. This is the CEIP service, and it comes with SQL Server. It is designed to get telemetry from your operation of a SQL Server instance on your premises. If you have Standard or Enterprise, you can turn this off, but if you use Developer or Eval, you cannot. Brent wrote a short description of this service recently, which is a good summary.

    When this first came out, there was a lot of concern with regards to data privacy, but I suspect most of this is overblown. Microsoft is bound by the GDPR, and my conversations with employees over the years have convinced me they take this seriously. Not just the legal staff, but many of the developers were surprised by the detail and documentation that they had to provide in order to gather data.

    Microsoft documents about what they collect, as well as the access restrictions at Microsoft and the data retention. I don’t see anything here that I am too concerned about, but I do think this is a great template that many organizations could use to document what data they capture from customers, how it is used, and how long they keep it. Whether you are required to do this or not now, I suspect more of us will be required to do this over time. You could start doing this now and be prepared early.

    This isn’t a fun task, and it’s very tedious, but if you capture this data and adjust it as you evolve and alter your schema, it’s not too bad. If you also include a place to document this, you can then work on this over time, not as one big, long, really annoying project. As data documentation has become more important to many of the customers I deal with at Redgate, having the ability to work on this over time is helpful in any size organization.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.