Voice of the DBA

Tag: Database Weekly

  • Microsoft Security Changes and SQL Server

    For almost as long as I’ve been working as a data professional, NTLM has been the security protocol used in Windows. Microsoft added Kerberos over 20 years ago, but NTLM is still a fallback. Like so many things Microsoft has worked on, they loathe breaking backwards compatibility, so NTLM has been available. However, it has issues, like the double hop problem, and there are numerous security issues with the protocol. I tested a security product over 20 years ago that could break NTLM passwords in under an hour. On old Pentium-based computers.

    This week Rebecca Lewis posted an article about the upcoming changes in Windows where NTLM is being phased out. She audits various clients and finds many are still using NTLM for SQL Server connections. Her observation is many people aren’t aware of this, and I’d concur. There is an informational message that is written to the SQL Server error log, but how many of you are checking the log and acting on this or even understand what it means? How many of you might have developers (or yourself) using named pipes and be unaware? That’s an NTLM only connection.

    Heck, I’ve got a friend fighting through SSL connections with SQL Server, which is something I rarely seen. This person will eventually no longer need to “trust server certificate” in every connection string, but I bet many of you are years away from implementing that. That’s another change Microsoft wanted implemented, and why modern drivers no only set this to true by default.

    Later this year, NTLM v1 will phase out, but that’s not likely what most of you use with SQL Server. However, the next major Windows server release will disable NTLM v2, and you won’t remember this editorial or the announcement then. What will happen is Windows admins will upgrade systems and you won’t be able to connect.

    Rebecca gives you some things to check, but since many of you might work in large estates, you’ll need time to ensure clients and servers get updated and NTLM isn’t the protocol you depend on. Trust me, if Windows or even a client driver upgrade remove this, you are in for a bad day (or week, or weeks) trying to get things working.

    I’d also suggest you learn how SQL Server SSL connections work. I don’t know that many orgs will require this, but some might as security becomes more automate-able and more CSOs start to ask that we ensure no man-in-the-middle attacks reach our servers.

    Steve Jones

  • No Defaults Passwords Ever

    I appreciate default passwords on systems. Often, for routers or other devices, I might need a way to connect initially. Or, if I perform a hardware reset, I want some password that I can use to reconfigure things. However, I am pretty good (not perfect, but really good) at changing those passwords to something else. It drives my wife slightly crazy at times, but I save the passwords and stick them in a manager I share with her periodically.

    SQL Server doesn’t store a default password when you install it. If you enable the sa account, you need to create your own password. I primarily deal with containers, and I always set one, usually my own default. However, lots of software either allows a blank password or has a default password set on installation. Oracle even lists theirs in docs. That’s not the worst idea if sysadmins change them, but if they don’t, it’s a threat vector for attackers. I was working with a customer last year who had an Oracle database. I asked them to try a default user/pwd as a test and it worked. I think my head was slowly shaking for the rest of the call.

    Recently, Silicon Valley saw the result of a default password not being changed when someone hacked the crosswalk signals and uploaded fake audio files that played when the signals changed. The vendor (not surprisingly) advised the city to change the passwords to something strong. A somewhat harmless prank, but it’s possible that someone might have made a more nefarious change.

    It’s 2026. We know there are people out there with malicious intentions, as well as those whose prank goes sidesways and have unexpected side effects. There isn’t a good reason to keep default passwords anywhere, including in your own personal devices. These days, connectivity among many systems is a reality with network, Bluetooth, NFC, and who knows what other connections are possible. Your personal devices ought to have defaults changed for your own protection.

    Inside organizations, it can be worse as the weakest link can be exploited to gain access to other systems. Quite a few hacks started in test systems and progressed to accessing production data. Even places we might not expect to be problematic, such as version control systems, have been used by hackers to gain access.

    To me, finding a default password is worthy of a reprimand and a note in whoever’s file forgot to change it. A second offense ought to lead to a suspension at a minimum and possibly termination. This is such a low bar of required security that I can’t think of a good excuse to allow it anywhere.

    Steve Jones

  • Widespread New Technology Adoption

    This week I saw an article at Ars Technica that noted in 2025 that electrical vehicle sales had increased 28% in the US. That’s quite a level of growth in adoption of this technology, especially given how set in their ways the US can be and how often these transition away from ICE vehicles has been politicized.

    I’ve had a Tesla for a little over 3 years and I think it’s the best and most fun car I’ve over owned. The technology and convenience are amazing, and I still enjoy driving the car around. For the most part I don’t have range anxiety, though I recently skipped using it on a weekend trip. The car has proven to be very inexpensive to operate and I wouldn’t hesitate to purchase another EV.

    Apparently lots of other people feel the same, though not everyone. About 75% of new vehicles sold are still ICE vehicles, which I completely understand. Not everyone has access to regular charging at home and the cost of these vehicles, while only slightly more than ICE ones, is still much higher to start. That hasn’t stopped many people from evaluating and choosing to purchase a car that runs on battery technology. However, plenty of people just don’t want to adopt new technology.

    I see the same thing in the tech industry. GenAI has been quite the disrupter the last few years, but many people don’t trust models and don’t want to try to use them. I’ve also seen many people who blindly trust this new technology, which can be even worse.

    I’ve seen the same type of attitude in the past with DevOps, PowerShell, NoSQL and other technologies. Many people are slow to adopt new technology, for a variety of reasons. It might be they aren’t sure the technology really offers any improvement, which is understandable. After all, if something new doesn’t actually provide significant benefits, is it worth an investment? After all the investment is a cost and there are likely some downsides.

    There are other people who are resistant to any change or unmotivated to bother, preferring to stick with what they know and are comfortable with using. I don’t quite understand this view, as it’s entirely possible we originally learned a poor way of doing things. It’s also likely that as technology changes, there are improvements made from our learnings in the industry. Certainly doctors, mechanical engineers, architects, lawyers, and more adopt new practices because their professions evolve and move in new ways, so why should technology professionals be different?

    I’d like to think that the reason many people don’t bother to learn new (or improve existing)  skills or adopt new tools is that they don’t have time. We’re all under pressure to get work done, and often without any planning for our various administrative work and meetings, let alone time to invest in ourselves. However, I will say that finding a way to carve out time to read, experiment, and practice skills has helped me improve my own career prospects, as well as helped me convince employers to match my investment with their own time, resources, and funding.

    Steve Jones

  • No End to Programmers

    There’s an interesting piece at O’Reilly this week titled The End of Programming as We Know It. That’s actually a good title, but it doesn’t mean the end to programmers, developers, software engineers, of whatever people call themselves.

    The piece looks back at history, starting with physically connecting circuits to program and moving to switch flippers, cards, compiled languages, and on to the web and mobile systems. Each of this brought more and more programmers into the industry because there’s no end to the software needs of the world and it’s hard to write good code.

    I like that the web was seen as the end of programming as anyone could easily build a minimal application to share things. Even frameworks like WordPress let novices create applications that do all sorts of useful things. However, we still need programmers. Look around at how many WordPress consultants are willing to help you.

    That’s because there’s a difference between configuring something off a shelf (or from a digital store) and actually having a working application for your situation. There’s no end to what people want to build, and really, they need someone to build it for them. Or at least modify, improve, or re-implement the proof of concept they created.

    The world of AI LLMs, and chat-oriented programming, is no different. Anyone can ask for an app and get a reasonable prototype. However, I don’t think this means less programmers. While more people will build more PoCs or prototypes, that also means more people will need a professional to clean up their system and make it work, scale, and perform well. And probably help secure it better.

    Programmers (developers, software engineers, etc.) will scale themselves with AI tech, as they’ll get the AI to do some scaffolding and initial work that they clean up. I’m sure the very best will build RAG AI systems that generate the type of code they want with a little training and input. I could see millions of AI assistants that help write basis code outlines, write tests, check for standards and code smells, and help the human shift left, catching small, simple, silly mistakes.

    I think we’ll have more people producing software in the future, but I also think that those who know their industry well will be in more demand. They’ll recognize issues in AI-generated code, they’ll guide AIs better, and they’ll communicate more clearly with AIs. They’ll get their pick of the best jobs, and they might be better compensated.

    Things they likely do today with their fellow humans.

    Steve Jones