A recent scenario at a client got me thinking about security - or lack thereof - that exists at some clients for various reasons as well as the flip side of ridiculous security that was going too far the other way.

The Background

I've been documenting the configuration of a third-party reporting & budgeting tool one of my clients uses, since no one, including myself, knows any of the inner workings.

  • Does it require a service account to run?
  • How does it connect to the server?
  • How are user permissions managed?
  • What are the admin passwords?

It's an odd situation really, no one knows much about this application and the person who was all gung ho about it to buy it and get it installed is no longer with the company. Having spoken to this person before they left, they didn't know either. Swell!

I started down this road because they are in the middle of an upgrade and they are interested in scaling back on the use of 'sa' internally after the upgrade is complete. The question came up: does XYZ product use 'sa' anywhere that we need to know about? Great question! It was bought and installed long before I was involved so I have no idea, and the VAR didn't do the install so they have no idea either. To compound it, the IT person who was working with the software vendor is no longer here, didn't document anything and no one knows who did the original install. It sounds too goofy to be true but I'm quite sure this happens more often than people realize.

The first lesson to share: someone needs to document the key elements to a new product install - that includes admin accounts, service accounts, etc. Ideally, the person who is installing new products is responsible for documenting some of this - and yes, expect to have to pay for this to be done! If the organization doesn't want to pay for this kind of documentation, then someone needs to pay attention, ask questions and document things themselves for the organization.

Let the hacking begin

"Hacking" may be a bit extreme but what I had to do was go into all of the undocumented applications and configuration areas this suite of products had to determine what some of these settings were. The documentation I had from the software vendor was sadly lacking; but of course, they are not typically documenting the configuration settings of an install, at least not for an end user.  Those kinds of instructions the VARs may get or they may learn them via training on installation of the product.

In this case, there were two separate products, one was a data warehouse kind of tool with a front-end administration console and the second was a reporting tool.  Both have client pieces as well. Fortunately one of the users knew one of the admin passwords - which was the software company's name (that's original!). The documentation from the software vendor did mention the default password for one of the admin tools was "admin" and turns out, that still worked. Yikes… no mention of how to change this either.

There was a third admin user no one seemed to know the password to, so I proceeded to guess. It didn't take long, I tried all of the common passwords people use, like password, access, no password etc..  No rocket scientist is needed here.

Now that I was able to access some of the admin sides of these apps, I did find that "sa" was being used as a service account of sorts for the connection to the server and the other app used its own service account, and they used the 'sa' password for that service account. Of course that wasn't documented anywhere but through trial and error I tried the same password as the 'sa' account and sure enough that was it. At least that was easy to guess, if not recommended.

My reaction

It bugs me when people - VARs, Consultants, Software Providers, Clients - use such weak passwords for admin functions. Sometimes it's the clients' request - they don't want it too complicated. Sometimes it's the installers though - they just merrily install with weak passwords without consulting the client on what to use.  In my opinion, it's our job as a consultant/VAR to recommend - if the client chooses not to follow our recommendations, that's their option.

  • Don't use obvious passwords on admin accounts and document how and where to change them.
  • Use strong passwords in particular on critical user accounts - 'sa' for instance.
  • Use specific user accounts as service accounts or default logins; don't use 'sa' as a service account login!

I could go on and perhaps will in a future post. I am a believer that very few people should use the 'sa' account: nearly everything can be done by granting the necessary SQL permissions to DYNSA or a GP user account. Installation routines are probably the one thing where 'sa' is still sometimes hard-coded into installation routines, even if DYNSA is granted the sysadmin SQL role, for instance. Day-to-day administration that requires elevated SQL permissions? I always recommend elevating DYNSA's permissions and using that for the usual user setup, and user access types of things and in some cases elevating specific GP user ID permissions in SQL as well where named users make more sense.

The risk of going too far overboard is the opposite effect. I had a client once whose audit recommendations were the use of 14-character passwords for everyone in the organization. Yikes! I'm okay with the recommendation, but the client does have a choice between ridiculous requirements and reasonable requirements. In this case, the client chose to follow the recommendations. Guess what, EVERY user has their password written on a Post-it note on their desk because 14 characters are too long to remember. How secure is that?

Well, the good news is now that we found the configuration areas we were able to secure things better and have a nice starting point for the IT department on the inner workings of this third-party tool.