Best practice != only practice

I saw some recent posts in this newsgroup that led me to make this
important point. The term "best practice" has become rather popular in the
last few years. But "best practice" seems to be touted all too often around
here as "only practice." If I made the assertion that the "best practice" is
to drive a Sherman tank because it is the safest way to travel, I'd be
laughed off the newsgroup. It isn't entirely untrue; if I owned a Sherman
tank, and I could get a license to drive one, it would in fact be the safest
way for me to travel. It would have lots of advantages. But it would not be
practical. It would be silly.

If I said that the "best practice" is to wear a bulletproof vest
because I could get shot, well, maybe that is true. But does that mean that
all the people not wearing bulletproof vests are stupid?

If I said that the "best practice" is to consume dairy products
within two days of purchase, is someone who waits four days a complete idiot
for not pouring what's left down the sink?

If I said that the "best practice" is to have six months' salary in
the bank in case of an emergency, does someone who can only afford to have
three have to hold his head in shame? Do we call such a person
irresponsible?

There are innumerable examples in everyday, real life of "best
practices" that not everyone can follow for one legitimate reason or
another. Does that mean that there are no "best practices?" Of course not.
Does that mean that those who do not follow the "best practices" are
dummies? No.

Certainly there are "bad practices" that actually constitute
malpractice. Some people actually do things that should cost them their
jobs. I also hold, however, that there can be degrees of "good." "Best" can
be tolerant of "good" and "better," and maybe even "okay." And context is
always important. As I often say, what is okay in a five-workstation
business may be absolutely unacceptable in a 75-workstation business, and
things that pass for okay in the 75-workstation scale may be found to be
hideous in a 10,000-workstation context. Yesterday at a five-user client
with no resident IT person, I had to give the domain administrator password
to a user because Internet was down and I couldn't otherwise know if the
server (SBS 2003 Premium with ISA 2004) was okay. At other clients, that
would be grounds for dismissal. The alternative was for me to make a
one-hour trip to look at it myself-- while it was down.

I think we need to save the religion for religious newsgroups.

 

Andrew,

though you have pointed out a few ridiculous examples you do not suggest
in what way 'best practice' is being enforced as 'only practice' in respect
to SBS.

This makes your post a 'semidecent rant' but gives no opportunity for
argument. Care to expand a little?

 

Hi Andrew,

I create a second domain administrator account on my client's SBS servers
just for those instances when I have to have someone in the office log on if
I cannot remotely access their server and "need a pair of hands (or eyes)".
I then change the password for that account after they're finished. This
also gives me a way to access the server if THE domain administrator account
profile becomes corrupt or is otherwise unusable for logins. (actually I
create/use an additional domain admin account for daily administrative
activities rather than THE administrator account).

One of our SBS-MVPs made a statement a while back about CALs and SBS
administration:

"Administering an SBS server does not consume a CAL, no matter what
credentials are used."

I believe this statement is correct.

 

I have to agree.

Of course, there are times where best practices cannot be used... but
choosing a security point as the one to apply makes little sense to me.
There are many ways to ensure security and you just violated one, in
my opinion, by giving the domain admin's password out. Especially if
that account is (inappropriately) used for services.

My own rules of thumb on security best practices in this area:

1. Rename the administrator account (otherwise, hackers are 50% of the
way to successfully hacking your system).
2. Use a STRONG password for any domain admin rights enabled account. I
try to set mine to 14+ characters.
3. NEVER use the same password for a client and NEVER use an obvious
password that could be easily "translated" to another client. For
example, "[email protected]" is awful because if one person at one
company knows it, it's pretty obvious to them what the admin password to
another one of your clients is if they know who your clients are.
4. Always give each user their own domain admin account (that is, each
user who absolutely needs one). Otherwise, delegate OU authority.
5. In an environment where you cannot always have a domain admin on
grounds, setup a domain admin account for emergencies (like you had) and
put the password in an envelope that is SEALED. You will know if
someone used it and you should put the envelope where no one is going to
stumble across it.

-Lee

 

Andrew is right in the too much use of the phrase "Best practice"... for
whom?

I personally don't like the phrase as you need to devise the RIGHT
practices for your firm/client/whatever.