Mark Minasi's Windows Networking Tech Page
Issue #46 April 2005

To subscribe, visit http://www.minasi.com/nwsreg.htm. To unsubscribe, link to http://www.minasi.com/unsubs.htm. To change e-mail address, switch between HTML or text format, etc., link to http://www.minasi.com/edit-newsletter-record.htm.  Visit the Archives at http://www.minasi.com/archive.htm.  Please do NOT reply to this mail; for comments, please link to www.minasi.com/gethelp.  Document copyright 2005 Mark Minasi.

What's Inside

  • News: 
    • LAST 2005 Active Directory and Security Seminars Coming To Dallas In May, Chicago and Philly in June
  • Tech Section
    • Renaming Someone's 2003 Exchange Mailbox
    • Correction: CN=Common Name
    • Honest, HOSTS beats the local DNS cache!
    • How SMB Signing Works: An Alcoholics Anonymous Protocol
  • Conferences
  • Bring a Seminar to Your Site

News

This month, more on AD names, this time with a focus on Exchange names.  I also explain how SMB signing works and in particular how to use its four cryptic settings.  Then I fix a goof from the last newsletter and answer a reader question about DNS cache versus HOSTS files.  But first, a word from our sponsor...

The LAST 2005 Seminars are Coming to Philly, Chicago, and Dallas Soon!

I have to buckle down and get some work done on writing so the May and June seminars in Dallas (week of May 9), Chicago (latter part of the week of June 13) and Philadelphia (week of June 20) are the only ones for the rest of the year.  Please consider joining me at one...

Seminar: Securing Your Windows Desktops and Servers

Everyone wants to secure their network, but many don’t feel that they have the time. I find that a lot of people have a general idea about what they should be doing to secure their networks -- they've heard terms like SMB signing, null session, secure channel, LM hash, and so on -- but haven't the time to sift through the often-contradictory knowledge base articles and the welter of group policy settings, Registry hacks, patches and the like. In just one day, I go through what the big security issues mean and help attendees understand the exact step by step methods that you need to know to make your system more secure.

If you'd like to find out more, please visit www.minasi.com/secoutln.htm.

Running a 2003/2000-Based Active Directory

AD's great, but it can be a fragile flower if not built and maintained properly. Find out how to build, implement, maintain, and repair Active Directory at "Running a 2003/2000-Based Active Directory;" information at www.minasi.com/2003outln.htm .

Tech Section

Renaming An Exchange 2003 Mailbox

Last month, I looked into AD names and renaming.  Many of you wrote me back to ask how the heck to rename an Exchange mailbox.  Now, I've said a grillion times that I'm not an Exchange expert (truthfully!), but enough of you asked so nicely that I hacked around with it and I believe I can reveal How To Rename An Exchange Mailbox ... sort of.  But there are caveats to this:

  • First, again, I am NOT an Exchange guru so I'm just wandering around here -- I'm reporting what I found worked.  There are probably better ways.
  • Second, I tested this on the world's simplest and lamest Exchange Server 2003 system.  I'm absolutely certain that things may work differently for Exchange 5.5 and 2000 and -- let me stress this -- I do not have either of those running.  Therefore, I can only say that this works for Exchange 2003 and under no circumstances can I research things further for 5.5 and 2000.
  • Third, despite the second point, I'd be delighted to hear from anyone who knows for certain what's going on and how to reliably rename an Exchange mailbox of any stripe, with my thanks in advance.

With the caveats out of the way, here's what I found when I created a user, got her e-mail working, and then changed her last name and e-mail address.

I created a new Active Directory user named "Mary Smith" with e-mail alias "msmith@minasi.com."  Recall from last month that one of the many places where AD records Mary's name is as an AD attribute called the "Displayname."  That gets populated immediately and automatically with "Mary Smith."  As I've got the extra Exchange doodads on my copy of Active Directory Users and Computers, Mary immediately gets an e-mail account named "msmith@minasi.com."  So far, so good.   (If I I recall correctly, Exchange creates a user mailbox when that user gets his or her first message or first logs on and tries to retrieve mail.)

The first wrinkle appears when I fire up Outlook 2003 and try to create an e-mail to "Mary Smith."  I press ctrl-K to get Outlook to look her up and it can't find her.  Some kind of Exchange magic must occur for the global catalog and then the global address list to get updated and for Outlook to be able to find Mary.  (Note that this test network had just two servers -- one DC and the Exchange server, so you'd think that global catalog replication issues in a one-domain, one-DC forest would be minimal.)  For whatever reason, Mary appeared on ctrl-K lookups in Outlook about 12 hours later.  So I hypothesize that Exchange must do some kind of periodic reading from the global catalog server, and that happens about twice a day.  If you're impatient, you can, if you like, respond to Outlook's "I can't find anyone by that name" response by clicking the "show more names" button, and in the resultant dialog box under the "Show names from the:" text, choose "All users" in the drop-down selection box.  Mary seems to appear immediately there.

The next day, let's say that Mary gets married and is now Mary Jones.  She'd like that to be reflected in the global address list, and she'd like her e-mail address to become mjones@minasi.com.  Changing her last name, full name, display name and e-mail address is fairly simple in Active Directory Users and Computers.  Exchange immediately accepts e-mail from mjones@minasi.com.  (And yes, of course we'd probably want Exchange to respond to the old e-mail address for a while, but that's not relevant to what I'm trying to do here.)

As before, Outlook's the last guy to know when something happens, and typing "Mary Jones" into Outlook and pressing ctrl-K gets a Check Names dialog box with "(No Suggestions)" in the "Select the address to use:" field.  Again, clicking Show More Names and then All Users will bring up Mary Jones immediately, but that's not what we want.  As with Mary's first appearance, Outlook seems to figure out what's going on about 12 hours after we make the change in Active Directory.

I should parenthetically note that there are a few little things that I thought might speed up the process -- the Mailbox Cleanup Agent, or rebuild or update Recipient Update Services -- but none seemed to speed up the process.  The recipe for changing an Exchange name, then, is to modify the user's name and particular the "Displayname" attribute and, if you like, the e-mail address, and then wait 12 hours!

Later note:

A few readers tell me that the culprit here is that I’ve got Outlook in Cached mode… very logical, thanks to all! 

Correction: CN=Common Name

Sorry, I goofed last month.  In LDAP names, CN= refers to "common name," not "container name."  Dunno how I did that one, major apologies.  (I think it's the constant rain we're having on the east coast and The Winter That Will Not End.)

Honest, HOSTS really DOES beat the DNS cache

Two readers recently took me to task about the DNS cache versus the HOSTS file.  As I explain in my Server books, the DNS client software on 2000, XP and 2003 caches the results of previous DNS queries.  So if you've recently, for example, pinged somehost.somesite.com then the IP address that corresponds to somehost.somesite.com is still in your local system's DNS cache.  Pinging it again doesn't force your computer to re-ask the question "what IP address corresponds to somehost.somesite.com?"  Instead, your system just pulls the answer out of that local DNS cache.  But, as I explain in the book, information in the HOSTS file always "beats" cached values.   The two readers said that was silly and why would I include such a falsity in my books?

The answer is that while I have no idea why Microsoft built it that way, they did.  Prove it for yourself.

  1. Ping a Web site, like www.acme.com.  The IP address of that Web site is now in your local DNS cache.
  2. Using Notepad, edit the file \windows\system32\drivers\etc\hosts.  (If you're running 2000 or upgraded from 2000 or an earlier OS then the location will be \winnt\system32\drivers\etc\hosts.)  Add a new line to the HOSTS file that says "68.15.149.117  www.acme.com."  This is a HOSTS entry that says "If you're ever wondering what IP address corrsponds to the name www.acme.com, it's 68.15.149.117."
  3. Save the HOSTS file.  If you're running an anti-spyware app then it may ask if you're sure.
  4. Again, ping www.acme.com.  You will see that you're pinging 68.15.149.117 rather than www.acme.com's actual IP address of 216.27.178.28.  Proof positive that HOSTS beats DNS cache.
  5. Re-edit HOSTS to remove the line that you just created, and re-save it.

Why does it work this way?  Well, remember that the DNS client always first looks in HOSTS before asking DNS to resolve a name.  Whenever HOSTS gets changed, the DNS client flushes its local cache.  Thus, the next time we try to resolve www.acme.com, it’s already in cache with the new HOSTS value.

(My thanks to all who wrote to discuss the under-the-hood reason for this behavior.)

How SMB Signing Works: An "Alcoholics Anonymous" Protocol

Ever since Windows NT 4.0 Service Pack 3, we've had something called "SMB signing," an optional security feature available to NT 4.0, 2000, XP, 2003 and even Windows 9x.  You probably already knew that, and you probably already had some vague notion that it's a Good Thing and that one of these days you'd look into it in detail.  You might have even looked at the four group policy settings that control it...

  • Microsoft network server: Digitally sign communications (if client agrees)
  • Microsoft network server: Digitally sign communications (always)
  • Microsoft network client: Digitally sign communications (if server agrees)
  • Microsoft network client: Digitally sign communications (always)

And then you'd kinda scratch your head and say, "huh?  There's something missing here..." which is pretty much what I did until about 18 months ago.  So here's a guide to what SMB signing is, why you care, how it works and what it'll cost.

The Man In The Middle, Signing and Hashing

Virtually any network conversation is prone to a class of attacks called "man in the middle" attacks.  In these sort of attacks, system A and system B are talking to each other, when all of sudden a third system, C, inserts itself stealthily in the middle of their conversation.  All of A's communications to B are intercepted and modified by C, which then re-transmits those communications to B.  Communications from B to A, similarly, are intercepted and changed by C, then re-sent to A, who, like B, is none the wiser that the A-B conversation is being corrupted.

Therein lies the need for signing.

Systems sign communications by taking their message body and hashing it in some manner.  For those who don't recall, hashing just means taking a big bunch of data and boiling it down into a much smaller piece of data.  For example, the simplest hash I could imagine (it's not a very good one) would be to simply take all of the bytes in a message and add them together.  So, for example, if your message were "Hi, Mark" then you'd compute the hash by looking up the ASCII value for "H" (72), then "i" (105), then a comma and a space (44 and 32) and so on, adding each character's ASCII value to get a sum -- a "hash" -- of 648.  You could then send me a "signed" message that looked like

"Hi, Mark" 648

I could then check the message's integrity by removing the hash, setting it aside, and computing a hash based on the "Hi, Mark" message.  I'd get 648, which would then compare to the hash that you sent me, which is also 648.  As they match, I would then know that your message to me wasn't modified along the way. 

But clearly we need more than that; if this were all that there were to it, then a bad guy could just modify the message and compute a new hash based on the modified message, and then send that along.  Sending a hash in cleartext, then, isn't a very good message integrity checking method.  So before you send me that hash, you encrypt it in some fashion, using some key that only you and I know.  I could then decrypt the hash using that secret that only you and I know, and check it as before.  A bad guy could modify the message and compute the new correct hash, but because he doesn't have our secret, he can't encrypt it, so we'll discover his dastardly deeds. 

This, then, is how we sign digital traffic to verify its integrity:  hash the message using some hashing algorithm.  (In case you're wondering what a real hashing algorithm is,  you'll hear references to MD4, MD5, SHA, SHA-1 as examples of hashing algorithms.  SHA stands for Secure Hashing Algorithm and MD stands for Message Digest.  A "message digest" and a hash are basically the same thing.)

One way to sign digital traffic is with IPsec and its "AH" protocol.  IPsec appeared first in Windows 2000, so if you had an all-2000, XP and 2003 network, with no NT or Windows 9x or DOS clients, then one way to validate your network traffic would be to create an IPsec policy that requires packet signing.  The nice thing about IPsec message signing is that IPsec works way down at the IP layer and so could in theory be used to sign any kind of IP-based traffic.  But a lot of folks still have NT 4 and 9x which, again, doesn't support IPsec, so that won't work to sign SMB traffic reliably.  But SMB can be signed even in a network that includes NT 4 and Win 9x, even if those OSes can't do IPsec.

File Sharing-Specific Signing:  SMB Signing

Back in NT 4.0 SP3, Microsoft added a signing capability to SMB.  SMB, recall, is Server Message Block, a not-very-helpful name for the protocol for Microsoft's file sharing service, the tool that lets us connect to file shares on file servers.  Every time you do a NET USE or open up a share in Network Neighborhood, you're using SMB. 

When a Windows system signs an SMB packet, it hashes the SMB message using some hashing algorithm, producing and eight-byte hash.  That is hashed using a shared key.  As with other signing methods, both sides need to somehow agree on that key;  SMB signing uses a key encrypted by yet another key, something called the "session key" which is generated whenever a Microsoft client logs onto a server.  So the initial process of logging onto a file server generates a session key, which is then used to encrypt the SMB signing key for communication between the file sharing client and file sharing server.

You can make 2000, XP and 2003 do SMB signing with group policy settings, NT 4 with Registry settings, and Windows 9x with Registry settings in combination with the DS Client, the Active Directory add-on for 9x that appeared on the 2000 Server CD in the Clients directory.  You control SMB signing with four basic commands.  As SMB signing's four commands first appeared in NT 4 SP3, let me introduce them in their NT form.  SMB has, like most protocols, two pieces -- a client piece and a server piece.  The SMB server module in NT has always been simply called "Server."  Its parameters are in HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ LanManServer \ Parameters.  The client piece is known by its more cryptic name of the "workstation" service -- it has nothing to do with being a workstation, it's only the client piece of SMB file sharing communications -- and its control parameters in NT 4 were in HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Rdr \ Parameters, where "Rdr" was short for "redirector," another old name for a file sharing client.  Both the Rdr\Parameters and the LanManServer\Parameters keys could accept two new value entries:

  • EnableSecuritySignature: this says whether or not to create and send SMB signatures.
  • RequireSecuritySignature: this says whether or not to require SMB signatures.  If you require SMB signatures, then any SMB traffic without a signature is rejected, as is any traffic with an invalid signature.

There is an EnableSecuritySignature and RequireSecuritySignature for both the file sharing server parameters and the file sharing client parameters -- that's why I said there were four Registry values.  The "EnableSecuritySignature" settings correpond to the group policy settings that end "... (if client/server agrees)."  The "RequireSecuritySignature" settings correspond to the group policy settings that end "...(always)."

 Summarized, then,

  • A 1 or 0 value on ...LanManServer\Parameters\EnableSecuritySignature is the same as an enable or disable value on the group policy setting "Microsoft network server: Digitally sign communications (if client agrees)"
  • A 1 or 0 value on ...Rdr\Parameters\EnableSecuritySignature is the same as an enable or disable value on the group policy setting "Microsoft network client: Digitally sign communications (if client agrees)"
  • A 1 or 0 value on ...\LanManServer\Parameters\RequireSecuritySignature is the same as an enable or disable value on the group policy setting "Microsoft network client: Digitally sign communications (always)"
  • A 1 or 0 value on ...\Rdr\Parameters\RequireSecuritySignature is the same as an enable or disable value on the group policy setting "Microsoft network client: Digitally sign communications (always)"

And in case you want to go looking for the settings in 2000, XP or 2003's Registries, then you won't find the Rdr key; it was renamed the "Lanmanworkstation" key in 2000. 

Because you can configure the file sharing server module with different Registry entries than the file sharing client module, it'd be theoretically possible for you to set EnableSecuritySignature to 1 (in other words, always create and include SMB signatures) in the Rdr\Parameters key but then set EnableSecuritySignature to 0 (don't generate signatures) on the LanManServer\Parameters key.  The effect would be that when this computer is acting as a file sharing client then it signs its communications but when acting as a file sharing server it doesn't sign its communications.  Again, I can't think of why you'd want to do that, but I suppose the flexibility's not a bad thing.

What the Settings Really Mean

As I've said, these settings confused me a bit, for several reasons.  The corresponding group policy settings to "EnableSecuritySignature" are "Microsoft network server: Digitally sign communications (if client agrees)" and "Microsoft network client: Digitally sign communications (if server agrees)," which sounded to me as if there was some kind of negotiation going on.  (I mean, doesn't "agrees" imply negotiation?)  So I ran a network monitor on dozens of SMB session setups and couldn't find the negotiation anywhere.  But I did find these behaviors:

  • If EnableSecuritySignature was 1 or "Digitally sign communications (if [other side] agrees)" was enabled, then the file sharing client or server on the computer in question would always generate signatures -- even if talking to a system that didn't understand signatures, like a DOS client or a Windows for Workgroups system.  (Such a system would just ignore the signatures and everything would be fine.)
  • If RequireSecuritySignature was 1 or "Digitally sign communications (always)" was enabled, then the client or server who required the signature simply refused to even set up the session unless its opposite number emitted signatures.

And then it hit me:  this protocol is from Microsoft.  Naturally, that means that there is no negotiation -- you know, "resistance is futile" and all that!  Seriously, a little thought made me see the approach as less Borg-ian and more Alcoholics Anonymous-y.  All of the movie characters that I've ever seen who are supposed to be in AA say something like "dude, you must realize that you can't control anyone but yourself."  Aha!  So that's what's going on here.  Recast, here's what these settings mean.

  • If EnableSecuritySignature is 1 or the group policy setting that ends "... (if client/server agrees)" is enabled, then the client or server module in question generates SMB signatures with every communication.  It neither knows nor cares whether anyone wants those signatures; it just creates 'em.
  • If, on the other hand, it's set to 0 or disabled, then the client or server in question never generates signatures.  Again, it couldn't care less whether or not the other side wants 'em.
  • If RequireSecuritySignature is 1 or the group policy setting that ends "...(always)" is enabled, then the client or server module in question requires valid SMB signatures in order to communicate with its opposite number.  Again, there's no negotiation, no warning -- there will just be a refusal to communicate unless there are valid signatures.
  • If it's set to 0 or disabled, then the client or server module in question does not require signatures.  It will, on the other hand, check any signatures that it receives and, if they're invalid, it will reject those SMB blocks, requesting a retry.

So EnableSecuritySignatures tells a system whether or not to give signatures, and RequireSecuritySignatures tells a system whether or not to insist on receiving signatures.  But where the setting that says whether or not a system should read, interpret and check any signatures that it receives?  Apparently there is no such setting -- every modern SMB system that receives an SMB block with a signature attached apparently always checks that signature and, if it's invalid, rejects the SMB block.

In 2000 SP3, XP SP1, and 2003 RTM, Microsoft changed the default settings so that the EnableSecuritySignature setting out of the box is 1.  The RequireSecuritySetting is set to 0 except on 2003 and 2000 domain controllers, where it's set to 1.  To repeat, by default all 2000, XP and 2003 systems always generate signatures, and only 2000 and 2003 DCs require them by default.  As far as I can see, NT 4.0 never enables or requires signing by default.

Thus, the chances are very good that all of your 2000, XP, and 2003 systems are emitting signatures, and it's a certainty that they compulsively check any that they receive as well.  Microsoft notes that generating and checking signatures can impose up to a 15 percent overhead on a network, so if your network seems a teeny bit slower since SP3, SP1 and the introduction of 2003, that might be the reason.  But let me suggest something:  turn on "RequireSecuritySignature" on your systems.

Here's my reasoning.  While many of you have some 9x and NT still in your systems, from what I can see they are not the majority of most networks.  As I said in the last paragraph, that means that most of your SMB communications are being signed and checked already -- you've already "paid the price," so to speak, in terms of network performance -- most of your SMB comms are already slowed down.  But by not requiring SMB signing, you've allowed the possibility that someone might enter your system and launch a man-in-the-middle attack.  Thus, suppose A and B are communicating with SMB signing:  they create signatures and check each other's signatures but do not require them.  C then inserts itself between A and B and is smart enough to scrub out the old signatures when modifying A->B or B->A communications.  ("Unsigned" just means "fill the eight bytes with zeros.")  In other words, you're making everyone do SMB signing but the (potentially present but hopefully nonexistent) bad guys!

So consider creating a domain-wide group policy with all four SMB signature settings set to "enable."  If you do do this, then ensure that your NT 4 and 9x systems are creating digital signatures.  You've seen the Registry hack to do it for NT 4 already.  For Windows 98/ME, install the DS Client and modify the Registry on the 98/ME box as follows:

First, install the DS client, as noted.

Second, go in the 98/ME Registry to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VxD\VNetsup.  In that key, use EnableSecuritySignature and RequireSecuritySignature as needed.  As far as I can see you can't get 95 to do SMB signing but some have told me that the DUN 1.4 update might fix that.  I fear that I do not have any 95 machines any more and so can't test it myself, apologies.  I am told that Microsoft does this on their internal network but then I'd guess that there isn't much in the way of pre-2000 systems on that network.

Is This A Real Threat?

Does this matter?  Well, consider that if you use folder redirection, roaming profiles, or group policies, then you rely upon SMB file sharing for important, basic, daily functions.  It's kind of scary to consider that a bad machine planted in your network could be handing out malicious group policies to your clients.  Additionally, I'm told that something called an "SMB reflection attack" is a real possibility in modern networks, and signing defeats that.

Potential Problems and Going Further

As with any tightening-up process, it's important to ask what it'll break.

Reader Aaron Lorton tells me that he’s got a Canon 5000 copy machine and a Oce large format scanner that cannot communicate with Microsoft products over a network despite vendor promises.  This unfortunately happens and so testing’s a good idea at all times.  But remember, when you’re talking to a vendor who’s whining about how Microsoft’s “new” settings are breaking their product, just laugh derisively at the vendor and say, “SMB signing is SEVEN YEARS OLD.  When were you planning on joining us in the 21st Century?” and demand a fix.

Another reader, Peter Kaufman, tells me that he's run into trouble with CIFS acceleration devices -- he mentions vendors Peribit and Riverbed -- and says that required-signing traffic can't be accelerated.  That's an interesting problem because it sounds like it wouldn't crash the accelerators, just disable them.  So the network would still work, but more slowly.

In my experience, I've been doing SMB signing and requiring it in my network for over a year and I've not run into problems except for the rare occasion that I try to boot a system in DOS using the old MS-DOS client for Microsoft Networks -- which doesn't support SMB signing and never will.  Otherwise it's been trouble-free.  But you've always got to test, test, test before deploying!

There was a time when XP SP1 first came out that XP boxes pulling data from 2000 file servers would sometimes lose connectivity with the 2000 file servers when doing big file transfers, but it appears that XP SP2 has fixed that.

If you'd like to look further into signing communications, look at the Group Policy editor and you'll see that there's also options for signing domain communications (that is, conversations between your system and its local DC) and all LDAP communications.  They're structured in the same way, although you have the option of not only signing but encrypting domain communications. 

Conferences

Join me at ...

Windows Connections Spring 2005:  my magazine's twice-per-year tech-o-rama start next week, on 17 April in San Francisco!  Our new program chair, Amy Eisenberg, has put on a pretty neat schedule ... but heck, don't believe me, check it out yourself.  Info at www.winconnections.com.

Bring Mark to your site to teach

I'm keeping busy doing Active Directory and Security seminars and writing, but I've still got time to visit your firm.  In just two days, I'll make your current NT techies into 2000, XP, Active Directory and 2003 experts.  (And better yet they won't have to sit through any Redmondian propaganda.)  To join the large educational, pharmaceutical, agricultural, aerospace, utility, banking, government, telecommunication, law enforcement, publishing, transportation, and other organizations that I've assisted, either take a peek at the course outlines at www.minasi.com/presentations.htm, mail our assistant Jean Snead at Assistant@Minasi.com, or call her at (757) 426-1431 (only between noon-5 Eastern time, weekdays, please).

Until Next Month...

Have a quiet and safe month. 

Please share this newsletter; I'd like very much to expand this periodical into a useful source of NT/2000/2003/XP information.  Please forward it to any associates who might find it helpful, and accept my thanks.  We are now at over 36,000 subscribers and I hope to use this to get information to every single Mastering 2003, XP, NT and 2000 Server reader. Thanks for letting me visit with you, and take care.  Many, many thanks to the readers who have mailed me to offer suggestions, errata, and those kind reviews.  As always, I'm at http://www.minasi.com/gethelp and please join us at the Forum with technical questions at www.minasi.com/forum. 

To subscribe, visit http://www.minasi.com/nwsreg.htm. To change e-mail, format, etc., link to http://www.minasi.com/edit-newsletter-record.htm.  To unsubscribe, link to http://www.minasi.com/unsubs.htm. Visit the Archives at http://www.minasi.com/archive.htm. Please do NOT reply to this mail; for comments, please link to http://www.minasi.com/gethelp.

All contents copyright 2005 Mark Minasi. You are encouraged to quote this material, SO LONG as you include this entire document; thanks.