A recent scenario at a client got me to 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 really sounds too goofy to be true but I’m quite sure this happens more often than people realize.

First lesson to share: SOMEONE write down the key ingredients to a new product install - that includes admin accounts, service accounts, etc.  Ideally your VAR is installing new products for or with you and they really should be responsible for documenting some of this for you - and yes, you have to pay for this to be done!  If you don’t want to pay for this kind of documentation, then someone needs to pay attention, ask questions and write things down.

Let the hacking begin

“Hacking” may be a bit extreme but what I had to do was go into any and all 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 that no one seemed to know the password to, so a-hacking I went trying 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 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 it’s 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 a smart idea.

My reaction

It really 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 the 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 or if you do, at least 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.  Personally I am a believer that very few people should use the ‘sa’ account: nearly everything can be done with 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 admin that requires elevated SQL permissions?  I always recommend elevating DYNSA’s permissions and using that for the usual user setup, user access types of things and in some cases elevate specific GP user ID permissions in SQL as well where named users makes more sense.

The risk of going too far overboard is the opposite effect.  I had a client once where their audit recommendations were the use of 14-character passwords for everyone in the organization.  Yikes!  I’m ok with the recommendation I suppose, 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 is 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.