Yep. The other issue is that these companies need to provide software that “just works” for 80+% of all shops out there. It’s not easy, and I think it’s why we see a lot of companies having success by scaling back on features offered. Fewer features means less support and greater chance it works on as many systems as possible.

Kenneth, Do you use TFS for your source control needs? What is the process you follow to ensure checked in code is in the environment? Do you have any good resources? Thank you.

Hi Cody, thanks for the comment.

My experience with larger enterprises is that a separation of duties is necessary. The DBA should not be managing security. I believe it is best to have a defined security team reviewing the members of the AD groups, and this should not be a concern for the DBA.

Service accounts should have passwords that expire. There are 3rd party apps out there that help to manage the password generation and rotation. I think we rotated passwords every year at a minimum, not every 90 days. But that was because of volume. With hundreds of servers, having to rotate every 90 days was extra work, and the audit team was comfortable with once a year.

Like you said, these should be staples for any modern infrastructure.

And yeah, I realize I am outlining what seems like Nirvana here, but having seen it done, I know it is possible.

(But I love SQL logins, too.)

It would be nice. Do you though?

It’s my perception that in most enterprises that have a separation of duties like that, the DBAs aren’t the ones given the power to create those logins, nor the power to force others to use them at the exclusion of other accounts they may have. Meanwhile the actual gatekeepers have little interest in maintaining AD all day and throw meaningless paperwork at you until you give up and go home – or farm it out to juniors who will screw it up anyway.

I’ve made it a policy to check each account afterwards to make sure service accounts don’t still have a 90 day password expiry set. That’s fun the 2nd, 5th, and 10th times it happens, despite filling out that said paperwork correctly.

And I’m not against paperwork. Or process. However they are often not designed with any kind of automation or long-term master data management in mind. Oh how nice it would be to have a web API and page, so that you can fill it out and get the record created (or automate it with a script), while they get all the data they want. But no, that never seems to happen. Instead it’s a poorly formatted Word document with incorrect titles, designed for a single account, and with fields that don’t make sense and are mostly left blank.

Frankly when I find myself in that kind of environment I just thank heavens SQL still maintains mixed mode. At least we as DBAs can a) create logins, b) secure and cycle the passwords, c) document the owners to our satisfaction (in a database and not a folder of forgotten/discarded Word documents and paper files), and d) disable them when we can see they’re no longer in use.

I just wanted to point out that this item feels like a wish list. While the best of us DBAs thrive on security, efficiency, process, documentation, AND automation, I feel like we are on the cutting edge in IT. The rest of the departments are stuck in a 1980s IBM era mentality of trying to maintain as much grip on Windows infrastructure to the exclusion of all other teams that might possibly somehow take some of their work away.