How secure are your passwords?

It seems I am starting every post recently with “it’s been a while since I last posted”!  I have probably reached the point that it goes without saying… lol

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 flipside 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.

Remember me! New GP2010 feature

In GP2010, a new feature was introduced to remember the user and company.  I’ve seen a few blog posts about this, however I have also seen some incorrect information being posted about this topic which I hope to clear up.

What is it?

There are two parts to this:

Remember User (& Password) – automatically logs you in and bypasses the login window.

Pic_RememberUser

Remember Company – automatically chooses the company you “remembered” and bypasses the company selection window.

Pic_RememberCompany

How to enable it

For administrators, the Remember User functionality is disabled by default.  Use the System Preferences window (under System setup on the Administration home page) to enable this functionality if desired.  If this feature is not enabled, the Remember Company feature still works (there is no enable/disable option for this).  The remembered items are stored on the local workstation in the registry.

NOTE: enabling this is a system-wide setting, all companies, all users.  See the Workarounds section for ideas on how to restrict certain users or workstations from using this feature.

Pic_SystemPreferences

For users, simply tick the “remember” box on the applicable window, assuming your administrator has enabled it on the Welcome to Microsoft Dynamics GP window.  If the Remember User & Password is disabled, your administrator has not enabled it.

  • If you chose to Remember User & Password, the next time you log in, you will be brought to the Company Login window (or directly into GP if that is “remembered” as well).
  • If you chose to Remember Company, when you log in, you bypass the Company Login window and are brought directly into the company of your choice.

To change these settings, log in to Dynamics GP as normal, then click on either the Company Name or your UserID field on the home page to bring back the login and/or company selection windows.  There you can de-select the option to remember or change the remember me setting for companies.

Is it safe?

Yes, it is safe, the login and password are encrypted in the windows registry on the workstation.  For more detailed information, here is a blog post by Mariano Gomez, a Microsoft Dynamics GP MVP.  Mariano is the well-known Dynamics GP Blogster.

Is it recommended?

In my opinion, the decision to use the Remember User & Password feature is highly dependent on the strength of your organization’s other risk-related policies.

  • Do your users regularly lock their screens when they step away from their computers momentarily?
  • Do you have mandatory screen savers with the password protection features turned on?

If you answered yes to the above questions, then enabling this feature shouldn’t be too much of a risk.  If you answered no, you are risking the possibility of unauthorized users looking at, or worse, altering, your accounting data by accessing an unattended workstation.

Generally the Remember Company feature is not quite as risky and unless there is critical information in one particular company vs others you may not need to limit its’ use.

Workarounds

If you really would like to enable this functionality, then consider either policies to restrict access to the feature for certain users or possibly using VBA or Modifier to restrict access.   I recommend that users who use ‘sa’ or DYNSA should not use the remember login/password feature.  Other users who may be in the POWERUSER role or have access to critical data or setup windows should possibly also be restricted from auto-logging-in.

If you are going to use policy to restrict certain users from auto-logging-in, keep in mind you should be auditing it periodically: spot check the users’ workstations who should not be using this feature to see if it’s in use or not.  A policy without follow up is worthless!

Recap

  • Remember User & Password – disabled by default; bypasses the Welcome to Microsoft Dynamics GP window
  • Remember Company – enabled even if Remember User is not; bypasses the Company Login window
By |November 29th, 2010|Security|0 Comments|

Report Writer demystified – part 2 – other considerations

My last post was the introduction to dictionaries and launch files for those new to Report Writer (or GP).  This post is all about things to keep in mind before you actually venture into Report Writer to start working.  It’s rather boring stuff but it’s important to protect your reports from becoming corrupt or damaged due to poor process or lack of understanding.

Thoughts on Report Writer access

My recommendation is to create a special userID that is for report writing only – and grant it access only to a test company or Fabrikam (TWO) just to be on the safe side.  Why?  Well, if you have to log out as yourself and log in as a special user, you are more likely to follow a process once you put your “report writing” hat on.  If you can go into Report Writer on a whim at any point in your day, that is when I often see people taking shortcuts (no backups, editing live dictionaries etc.) and bad things can happen!

Process? Can’t I just click the Modify button? What are you talking about?

There are right ways and wrong ways to do a lot of things in life and Report Writer is no different.  People can get away with doing things that are not recommended but that one time it backfires on you, you will kick yourself for not following a consistent process.  I recommend having a methodology or process for report writing.  Mine looks something like this:

  1. Create a backup of the reports dictionaries (all of them) and save in a subfolder by date with a note to what the planned changes are.  If I am doing extensive changes I will actually create a notepad text file outlining at a high level the changes I am making, who asked for them and why.  (You can also export the modified reports and forms via Customization Maintenance instead of copying dictionary files if you prefer).
  2. Take the same copied dictionaries and paste them into my development folder (a folder where I can edit reports without affecting the production/live reports).
  3. Close Dynamics GP (if it’s open) and re-launch with a local dynamics.set file pointing to this development folder (I create a special “report writing” dynamics.set file and a special GP shortcut on my desktop with that launch file as a shortcut just for report writing).
  4. Log in with my report-writing userID in a test company and begin my work.

I have another process for bringing the reports back into production when they are tested.  Your process may be different but the bottom line is, don’t wing it!  If you are new to report writer, write down these steps or get a process from your partner/consultant and follow it every time until it is second nature.  If you have used report writer enough, you have likely be burned once or twice already from taking shortcuts… and you know the pain in recreating a dictionary or report!

Tracking Report Changes

Keep a log or notebook on the history of report modifications.  You would be surprised how often during an upgrade, we see a ton of modified reports that no one knows about (what was modified or why and whether they are being used right now or not).  If you want to do yourself a favour, assign someone the task of managing the reports and tracking changes.  Because security is required to get to modified reports, it makes sense that the person who tracks this is the person who manages security since they will know based on who asks them to grant access to a new report, what has been modified. It doesn’t need to be exhaustively detailed but a simple log of report name, date changed, reason for change and who requested it would suffice.  It would go a long way in the future during upgrades and other times when you are reviewing why certain reports are modified.

TIP: use the Customization Maintenance window to get a quick list of what is modified on your workstation (under the Dynamics GP menu, Tools, Customize, Customization Maintenance).  This window shows all modified resources based on the launch file you used; regardless of what reports or forms you have security/access to.  Remember my previous post relating to launch file configurations, depending on your configuration, you may not see the same list as another user on another workstation depending on how your workstations are configured and installed.  Spot check other machines to compare their lists from time to time.

Make a special launch file for report writing

Review my last post to see how the launch file is designed.  To make another launch file, simply open the default one in notepad or another text editor and copy it with a new name.  I recommend using a name without spaces in it for the GP shortcut purposes.  Example: dynamics-reportwriting.set

The top two parts of the dynamics.set file stay the same; the third part is where you would edit the pathnames of the reports dictionaries to point to a separate folder.  The folder can be anywhere, and keep in mind the syntax differences for local vs. UNC pathnames with slashes etc.

Types of Reports

Now we are finally getting into some actual Report Writer information!  There are three types of reports within Report Writer – original reports, modified reports and custom reports.

  • Original Reports – these are the unmodified reports that come with Dynamics GP and they are stored in the “code” dictionary.  In Report Writer, when you view the reports list, the original reports are those on the left hand side of the window.
  • Modified Reports – this is a copy of an original report which you have made changes to, stored in that product or module’s reports dictionary.  You can only have one modified version of an original report.  See “Is It Really Modified?” below for some sidebar notes on this!
  • Custom Reports – this is either a report created from scratch in Report Writer or a copy of a modified report.  NOTE: you cannot make a duplicate of a report that uses temporary tables so not all reports can be “copied”.

Is It Really Modified?

In my description above, I defined a Modified Report as a report in a reports dictionary for a given module.  However, to clarify, sometimes a report is in the reports dictionary that has not been touched.  How did it get there if no one has touched it?  One common reason is lax security: users who don’t know better are given access to Report Writer. Then the same user at some point will click on the Modify button on a screen output (preview) screen of a report, and clicking on that sends that report and you into Report Writer mode.  Typically the user didn’t realize what the Modify button was for, and didn’t know what to do once they got into Report Writer, and simply closed Dynamics GP and returned back to their regular job.  The result?  Whatever report they clicked the Modify button on is now in the reports dictionary.

The issue: you cannot really tell easily if a report has been modified or not.  If you have followed my advice and someone is responsible for tracking report changes, you will know pretty easily if there are reports not on the logbook that are in the report list.  My tip?  Use Security to try to identify if a report is really modified or not.  Read the next section and I’ll explain what I mean!

Security and Report Writer

The last topic of this post is an overview of security as it relates to Report Writer.  First there is security to allow a user access to Report Writer itself – as in access to the tool that is “Report Writer”.  Secondly, there is security to the modified reports themselves.  Users who do not know this often “mess” around in Report Writer only to get frustrated that they cannot see their report changes when it’s simply a matter of granting security.

I’ll back up one step to a previous comment: there are original reports and there are modified reports (I’ll deal with custom reports in a separate note).  Any given user can be granted access to the original report OR the modified report but not both at the same time in the same company.

When you modify a report for the first time – i.e. it has not been previously modified – when you are ready to test the report, you need to grant security to see it.  Typically my process is I will be working under a separate userID for report writing so I will grant access to the report to that userID in the test company to review it and ensure the changes are what I am expecting.  Once you grant access, you can continue to modify the report over and over again without having to go back into security and re-grant access.  You would only need to revisit security when you are done with report editing and ready to move the reports to production – to grant access to the report(s) to other users.

Modified Reports (and Forms) fall into the security category of “Alternate, Modified and Custom”.  In GP10/GP2010 security, this is within the Alternate/Modified Forms and Reports window.  In previous versions of GP, it falls under Alternative, Modified and Custom in Advanced Security.  The screen shot below is the GP2010 window showing an example of a report that has been modified.  You would select which user(s) or in this case which Alternate/Modified ID’s should have access to the modified report, and choose either the original or the modified report.  TIP: if you only have one Alternate/Modified ID, I recommend creating a copy of it for your special report writing user only for the temporary time when the new report is not yet in production.  There is nothing worse than granted security to a report while using a local launch file only to have a production user get an error because the modified report does not exist in production yet!

Pic_AltModSecurity

Now, back to the question Is It Really Modified?  My tip is to look at security as one way to try to identify if a report is modified or not.  If a report has been accidentally placed in the reports dictionary (via clicking Modify on the screen output window), chances are good that no one has security to that report.  If no one has security to the modified report and no one knows why it is in the list, chances are it is safe to remove from the reports dictionary!

Next time: I’ll start to dig into Report Writer itself for some tips and tricks.