Certified Mail: June 2002
User rights, disappearing MCTs and a look into the future of the MCP program.
What Rights to Grant Users?
We have more than 2,000 users running Windows 2000 and NT 4.0 workstations.
All users have admin rights to their local box. Our goal is to prevent
users from installing software and changing network configurations. We’ve
been testing (and irritating our customers) for several months, trying
to find a way to pull admin rights off the local machine so the user can’t
load any software, but can still use their applications. We’ve tried MMC
and policy editor and profiles; they’re either too restrictive, not restrictive
enough or create additional network traffic. We don’t have Win2K servers
with AD yet.
We’ve found that giving the Program Files folder Full
Control for the default users on that machine works for most applications,
but not all. We currently service more than 250 different applications.
We also have some users that need to go to secure sites on the Internet
that download and install a small security applet each time they visit,
so we have to give them admin rights on the local box in order to do their
Is there a specific hive in the registry to which we
can give Full Control that simulates the user having admin rights but
still prevents them from installing software?
—Steve Bourque , MCSE, A+
I’m afraid there’s no easy answer for this problem. It really is
an application issue; in many cases, though, the problem can be solved
by finding out which registry keys and files the offending application
needs to access and modify the ACLs, instead of giving Administrator
privileges on the machine. Often the problem occurs because the application,
though it only needs to open a file or key for Reading, requests opening
it for Reading and Writing. That’s why so many require Administrator
rights to run the software. To determine the keys and files to adjust
ACLs on, use a test machine and try the following steps:
- On this machine, turn on file and object auditing, then set
auditing for all types of access by everyone to failure.
- Log on as an ordinary user and run the application.
- The security audit log should contain events that show access
failures for keys and files that the application is attempting to
use, but that ordinary users don’t have access to. Inspect the log
and record the files and keys.
- Create a new group and call it what you want; it will include
those users who need to run the application. Give this group the required
access to the files, folders and registry keys that were giving errors.
- Place the ordinary user account you’re using in the new group.
- Run the application again.
- Check the security log for failures.
- Modify ACLs.
- Run the application.
- If the app runs fine, you’re done; if not, go back to step seven.
- Remove the audit settings.
You may need to repeat this for other applications.
The Silent Disappearance of 10,278
Amid the uproar of the on-again, off-again Win2K/NT 4.0 MCSE conversion,
did anyone notice the silent disappearance of 10,278 certifications?
Everyone cheered and sighed a note of relief as Microsoft
backed off its stand to force MCSEs to update or lose their certifications.
But was this just the sleight-of-hand trick used so that no one would
notice what the other hand was doing? According to numbers in this magazine,
the current MCT count is 13,056. 13,056! Did you know that as of the November
issue (the only older one I have on my shelf), the number was an astounding
That means that while the MCSE didn’t lose anyone and
their numbers grew, many certified trainers disappeared. It wasn’t that
big a deal compared to the large number of people who would lose their
MCSE, but look at the numbers! Fifty percent of the trainers said, “No,
I will not pay $400 for the privilege.” I recertified late and got hit
with a late fee of $80. That $480 went to Microsoft to be an MCT, and
will continue to go to them every year I want to remain an MCT, or they
will remove my MCT standing—which they did for several months!
Microsoft has lost 10,278 people—good people—because
they made a drastic change to the certification requirements. But because
of what was going on with the MCSE, no one seemed to notice. I hope that
someone does notice, because in November when it’s time to give Microsoft
another $400 to renew my trainer certification, that number just might
grow to 10,279.
—Marty Mulsow, MCSE, MCP+I, MCT?
Comments on “54 High-Voltage Tips”
number seven talks about the different looks in Win2K and XP. You
can still have the Windows 3.1 look in those programs by typing “progman”
in Start | Run. That’s the Program Manager we all know and love from the
good old days.
—Peter Van Gils, MCSE
I would like to comment on Bill
English’s Exchange Transaction Log Management tips in the April issue.
He states that you don’t want anti-virus software scanning the log files.
This past weekend we had this very issue, where a quarantined log file
caused a message store corruption on Exchange 2000. Where did you hear
about this? I saw nothing on Symantec’s documentation or in Microsoft
Press’ Exchange 2000 Server Administrator’s Companion. Can you
tell me where this critical information is documented?
I wanted to add that as per Microsoft, the EXCHSRV directory
should be excluded as well as the “M” virtual drive created by Exchange.
—Javier Sanchez, MCSE, CCNA
I initially received this tip from Jim McBee’s excellent book, Exchange
5.5 Server 24seven (Sybex). I think he learned about this from
working with a client who encountered exactly the same problem that
you did. I’ve since had this tip confirmed from my own experience in
working with clients. I included this tip in the book I co-authored
with Nick Cavalencia, Exchange
2000 Server Administration: A Beginner’s Guide (McGraw-Hill Osborne
Media). You referenced the Microsoft
Press book, which I co-authored with Walter Glenn. I wrote the second
chapter on the ESE architecture and meant to include this tip in that
chapter, but failed to “get it to paper.” Anyway, to my knowledge, this
tip is not in any Microsoft white papers. I agree that this is critical
information and I’m glad we can get this information out.
Missed the Nail on the Head
I couldn’t disagree more with May’s column, “The
Next 10 Years.” If things proceed the way Dian Schaffhauser envisions,
we go backwards! Computer management today is way too complicated. Complicated
because of software, not hardware. I think we will head in a direction
more in line with Gene Roddenberry’s vision as seen in Star Trek:
Computers will essentially manage themselves, freeing people to do more
useful things. Therefore, we won’t need certifications. The Microsoft
operating system “overhead” will be relegated to the dustbin. Computers
will most likely be based on something simple and reliable (Unix comes
to mind), but will be much more user-friendly and commonly directed by
voice. Even Microsoft made some rudimentary progress toward simplifying
things, like plug-and-play and easier, almost automatic loading. Over
the past couple of years we’ve watched the flip-flops (emphasis on “flops”)
that Microsoft has produced. “XP” (Xtra Problems) is one of the latest
in a line of OSs trying to find a direction—and this after we were assured
that Win2K was the golden spike of OSs. Ha! I find myself spending a fair
amount of time removing XP for people who were once again fooled by Mr.
—Tom Geis, MCSE
Amherst, New Hampshire
How Should An Upgrade Proceed?
I’ve heard different stories about NT in a Win2K and Active Directory
environment. So, the question is, do you have to upgrade all NT servers
to Win2K to run AD? Or, can you have stand-alone NT servers in an AD environment?
Thank you very much for your wonderful magazine.
From the point of view of legacy clients, nothing changes when an
NT 4.0 domain is upgraded to Win2K and Active Directory. Win9x clients
still use LM (LanMan) authentication. NT 4.0 clients still use NTLMv2
(NT LanMan version 2). All legacy clients continue to use WINS to register
their NetBIOS names and to resolve other NetBIOS names. NT member servers
still use local group accounts to protect resources, and they can nest
global groups from the Active Directory domain into those local machine
groups. The only clients who know the difference are Win2K and XP desktops,
who automatically shift to Kerberos authentication and use Win2K domain
controllers exclusively when a domain is upgraded to Active Directory
(unless you take steps to prevent them).
As for domain controllers, the original NT
4.0 PDC must be upgraded to Win2K before any BDCs can be upgraded. This
domain controller takes the role of PDC Emulator and continues to replicate
SAM (Security Account Manager) database changes to the remaining BDCs
as long as the domain remains in Mixed mode. Once you shift the domain
to Win2K Native mode, legacy NT 4.0 replication stops. Legacy clients
and member servers are unaffected by the shift to Native mode. If you
happen to leave any BDCs on the wire, they simply get more and more
out of date as time goes by, sort of like Madonna.
As for stand-alone NT servers, they interact
with member servers and clients in a Win2K domain exactly as they interact
with member servers in an NT 4.0 domain. The local SAM on the standalone
server is used to authenticate users, so you must maintain separate
accounts and manually keep the passwords in sync if you want to maintain
Stirtz, who complained about low salaries for MCPs in California in
the April online issue, needs to get out more. I don’t care if he had
no certifications—he should be making much more than $10 per hour with
12 years of experience, especially in California!
Having said that, I agree that the [results in the]
salary surveys are too high. I have 15-plus years of experience in the
IT industry, previously held an MCP on several NT 3.51 products and am
currently an MCSE and MCSA. Most of the surveys I’ve seen say I should
be earning in the low- to mid $70s in Huntsville, Alabama. That’s definitely
not the average in this town. There are a few who make that or more but
the majority are in the $58,000-$65,000 range.
I started working with NT before it was ever released as
version 3.1. After about four years using NT, and eight total years in
IT, I was earning almost $40,000, and that was low. I’m currently looking
for employment, but I bet you I’ll find a good job with a salary of at
least $63,000 in Huntsville. This fellow needs to seek a raise or another
job. He’s getting the shaft—and that hurts us all!
—Tony Bowman, MCSE, MCSA
Can I Hide My Server’s OS?
I’m a systems engineer in a software company in India. We’re running
a Win2K domain with Exchange 2000 and ISA Server. There’s another Linux
box that directly communicates with the Internet, and our mail server
forwards all mail to this server. Is there any way to hide the external
Internet users from knowing the OS type and the firewall type?
—Rajiv Kanna, MCSE
Tamil Nadu, India
The simple answer is no. Because each OS is unique, a determined
attacker will be able to eventually determine the OS of any machine.
There are some things that can be done, such as removing banners (replies
to port connections that announce the OS or give other bits of information
away), closing ports that aren’t used (typical OSs use particular ports)
and so on. But more aggressive techniques will still return information
that inform the attacker.
There’s another consideration here, as well.
It’s easy for an attacker to launch attacks against all systems on the
Internet, say, with a Code Red or Nimda-type worm, than seek out particular
OSs. These attacks only work on Windows systems running IIS; but rather
than attempting first to find servers running Windows to attack, the
attacker can launch a worm on all servers to save time and the nuisance
of doing such research. Nevertheless, you still should do what you can.
Realize, however, that there’s no 100 percent-secure way to hide your
server’s OS types. For more details, see: www.giac.org/practical/albert_boyle_GSEC.doc.
It details how OS fingerprinting is normally done, giving examples.