Reducing your attack surface for identity theft

While this does not have anything to do with Exchange, I have gotten seen some good advice over the years and have learned some interesting tips. Even my own mother got phished about two and a half years ago. So, we have to be diligent.

1. Don't sign the back of your credit cards. I put "REQUIRE PHOTO ID" on the back of mine.
2. Don't get your checks pre-printed with your social security number.
3. Never follow a link in an e-mail from your financial institutions, eBay, etc... Always type them in to the URL line of the browser yourself. I get at least two phishing schemes in my mailbox per day; many of them are VERY convincing. I even got one supposedly from MY OWN bank (First Hawaiian Bank). I clicked on the link out of morbid curiosity, and they had my full name and address pre-filled in.
4. Use only your initials (instead of your first and middle names) on your checks. This makes it difficult to identify your gender and if someone steals your checkbook, they don't know if you sign your check with your full name or not. Your bank, however, does have this on file.
5. When you pay credit card bills, write only the past few numbers of your credit card number in the "For" section of the check.
6. Keep a record (such as photo copies) of all of your credit card and financial information; make sure this information includes customer service numbers that are used if you have to lose your card. This helped me immensely a few years back when I got robbed (yes, robbed at gun point.) Keep these records, of course, in a very safe place.
7. Don't leave important outgoing mail in your mailbox with the little red flag up. Take it to a postal service drop box.
8. When throwing things away, shred everything relating to your finances.
9. If your bank calls you, ask them for a telephone number and a way to call them back. Then do it!
10. Run a credit report on yourself a couple of times per year.

If you suspect any of your credit card or banking information has been compromised, call all releveant companies immediately. The longer you wait, the more likely it will be that you will be responsible for some of the charges.

Call the three national reporting agencies and tell them to place your name and social security number on a fraud alert. This will help halt issuance of new credit cards in your name. Do this right away.

• Equifax: (888) 766-0008
• Experian (formerly TRW): (888) 397-3742
• Trans Union: (800) 680-7289
• Social Security Administration (fraud line): (800) 269-0271
• Federal Trade Commission (ID theft line): (800) 438-4338

Call the police and file a police report immediately. Keep copies of the report if you need to provide proof to the credit agencies.

Keep records of all conversations you had, with whom, and the date and time. Record the details of these conversations along with what you have been told will be done.

"The condition upon which God hath given liberty to man is eternal vigilance."
- John Philpot Curran (though often attributed to Thomas Jefferson or Patrick Henry)

Sender Id is coming! Get your TXT records in order!

You heard right, Sender Id is coming! What is Sender Id, you ask? Don't feel bad, most Exchange admins are asking the same question. Essentially (and very simplified) Sender Id is part of an initiative (I'm not sure that is the exact correct word), to reduce spam. Sender Id is part of the Sender Policy Framework (SPF).

So how does it work? First, you create a DNS TXT record for your domain (or domains) that identifies the mail servers from which e-mail will be sent for your domain. SMTP servers that support Sender Id will then check that TXT record when they receive a message from one of your users.

Here is the FUD (fear, uncertainty, and doubt) part. If the message is coming from a domain that does not have a Sender Id TXT record or the record does not match the sending IP address, the receiving system has a couple of options:

1. Do nothing.
   
2. Reject the message entirely. (!!!!)
3. Accept the message and then delete it prior to delivering it to the user.
   
4. Give the message to the anti-spam inspection system with the assumption that the antispam system (such as Microsoft's IMF starting in Exchange 2003 SP2) will give the message a higher spam probability if the sender's domain does not have valid Sender Id records

Exchange 2003 SP2 will support these options. Rumors went around for a while that MSN and HotMail was going to reject entirely all messages. (Not entirely true, MSN will use the lack of a Sender Id as part of their spam detection process.) Currently, I have heard (again, this is sort of like hearing something about a friend of a friend) that AOL and other domains are going to reject messages whose sending domains do not have Sender Id records in place. So, there is some fear, uncertainty, and doubt (not to mention rumors) afloat.

Needing Sender Id TXT records for each of your e-mail domains is not FUD or a rumor. What to do? First, get to know Sender Id and SPF a little better. Microsoft has a Sender Id home page with lots of good information.

To make figuring out what your Sender Id TXT record needs to be, Microsoft has published their Sender ID Framework SPF Record Wizard; this wizard makes creating your TXT record for your domain MUCH easier. This wizard will also test your existing domain to see if there are any records. You can then send a mail message to check-auth@verifier.port25.com and you will get an automated response verifying the Sender Id record.

The sooner you can make this happen, the better off you will be.

Will Sender Id eliminate spam? No. Many spammers will simply generate, regenerate, and regenerate SPF records for whatever IP addresses their are currently using. An RBL (realtime block list) like The Spamhaus Project's SBL and XBL lists can help with these types of spammers that like to think they are legimate marketing organizations. I use Spamhaus's SBL-XBL combined list and I know that it reduces the amount of spam I receive by about 60% (and the very occasional valid message, too.)

Will Sender Id create lots of confusion, newsgroup questions, calls to tech support, and angry users/admins? I'm betting it will. Just like the RBLs, this will cause some legimate e-mail to be rejected. And, unfortunately, there are people out there managing DNS servers that can't even get A and MX records created properly, so the TXT records (which are somewhat more complicated) are just going to make matters worse.

Clustering MVP Russ Kaufmann forwarded on to me this link from his blog about his experience with this first mail rejection due to sender id. Thanks Russ!

Paul Robichaux webcast on high availability

Paul Robichaux is speaking on a webcast that is being produced in conjunction with the release of his new eBook entitled The Definitive Guide to Exchange Disaster Recovery (Realtimepublishers.com) and registration for the event is free. It will take place on Wednesday, July 27th, 2005 at 2pm EST. Paul’s webcast discussion will touch upon the following series of topics:

• Replication and Failover
• Design Choices
• Failover and Failback Design
• DNS vs IP vs other; AD; client redirection; manual vs semiautomatic vs fully automatic; symmetry
• Planned Versus Unplanned

Chapter 2 of the eBook is now available. It is titled The Definitive Guide to Exchange Disaster Recovery and Availability. This chapter will explore the fundamental principles behind disaster recovery and look at technical solutions that purport to improve disaster recovery. It will then examine some of the design choices and tradeoffs you face in trying to design an effective disaster recovery plan.

A recipe for setting up permissions to run ExMerge

I have seen a number of questions relating to getting ExMerge running in Exchange 2000/2003. The quickest and dirtiest way to do this is to clear the Send As and Receive As "explicit denies" on the Exchange organization object for Domain Admins and Enterprise Admins. However, this is sloppy and it means that anyone with Domain Admins or Enterprise Admins can open anyone's mailbox.

I work in a lot of senstive environments (both corporate and government) and management is usually very uncomfortable with the thought that any senior admin can easily open anyone's mailbox. Well, unfortunately, that is just a fact of life with Exchange. Someone with Enterprise Admins or Domain Admins in the root domain can figure out how to do it anyway. However, you can take some steps to make this more difficult.

First, limit access to accounts that are delegated the Exchange Full Admins role to the organization or admin group objects.

Second, the membership in your Domain Admins / Enterprise Admins groups should be less than the number of fingers on your hand (service accounts are the exception, of course). Let me say that again clearly, almost no one should have access to Domain Admins or Enterprise Admins level permissions on a regular basis. And no one should be logging in regularly with these permissions, only as needed.

Anyway, back to why I started this blog entry. Ultimately, you are going to need the ExMerge tool. The latest version of it is found with the Exchange 2003 Tools.

You are also going to need to expose the Security property page for the Exchange oganization object and the admin group objects in Exchange System Manager. It is hidden by default. The registry key is HKCU\Software\Microsoft\Exchange\ExAdmin. In this key, create a REG_DWORD value and set the data value to 1. Then launch Exchange System Manager. Microsoft KB article 259221, XADM: Security Tab Not Available on All Objects in System Manager has more information on this. A little trivia on the Security property page, it was automatically visible in Exchange 2000's betas, but I think too many people got themselves in trouble by removing permissions the thought they did not need.

Now, on to the procedure. In this example, I'll assume that only one user for your entire organization will be used for this, but you can easily do this to individual administrative groups rather than at the organization. Create yourself a user that will ONLY be used for ExMerge operations. I call mine something like ExMergeOperator; this user does not need a mailbox and it should NOT be a member of Domain Admins or Enterprise Admins (they are denied by default, remember?) Protect the password of the ExMergeOperator user so that only an authorized person has it. In some places, they use "two person" integrity, where the security officer has one part of the password and the Exchange admin has the other part.

Next, create a global (or universal) security group called something like Exchange Demi-god Admins. Add the ExMergeOperator in to this group.

Next, using Exchange System Manager, right click on the Organization object and Delegate Control to the Exchange Demi-god Admins group. Delegate the Exchange Full Admins permissions to this group. Then, right click on the organization and display the Security property page, scroll down and locate the group you just created, highlight that group, then scroll down in the permissions until you see the explicit denies for Receive As and Send As.

Once you have cleared the Receive As and Send As checkboxes in the Deny column, this user will truly have "complete control" of your Exchange organization.

Some Exchange gurus are going to look at this and say that the Exchange Demi-god Admins group has too many permissions to the Exchange organization. And this is true. You can scale back the permissions by delegating only the Exchange View Only Admins role, then explicitly assigning only Receive As. The above procedure is just about the simplest, but somewhat secure solution I could quickly write about. More secure solutions are usually somewhat more complex. The important thing is that you protect the use that has these rights.

Finally, from where do you run ExMerge? IMHO, the most efficient place (if you have the local storage for the PST files) is the console of the Exchange server on which you are extracting mail. If this is the case, the Exchange Demi-god Admins group will also need to be delegated permissions to log on locally to the Exchange server console and (probably) access the server through Remote Desktop Connection (you can do this through a GPO).

Granting a user permissions to access mailboxes (even for the sake of performing archives, extracting viruses, or other official work) can be tricky. Make sure management knows that you have this capability and under what circumstances it may have to be used.

Get the official scoop on Exchange 2003, Windows 2003, and the BOOT.INI file

It's here! The Exchange team has written the final word on whether or not you should use the /NOPAE and /EXECUTE switches in the BOOT.INI file of an Exchange 2003/Windows 2003 SP1 server with more than 1GB of RAM (and 4GB of RAM or less, anything more than 4GB of RAM in an Exchange 2000/2003 server is usually a waste of money)

Basically, for mailbox and public folder servers with more than 1GB of RAM, add the /3GB /USERVA=3030 switches to the BOOT.INI file. This is different that some newsgroup postings and blog entries in the past (including my own blog back on May 9). Read more detailed guidance on this on the Exchange team's You Had Me At EHLO blog.

Front-end servers that handle just SMTP, POP3, OWA, NNTP, or IMAP4 should not use these switches. An front-end server that also handles envelope journaling or the MTA (anything that requires a mailbox store be mounted and used heavily) should use the /3GB /USERVA=3030 switches.

Have you seen Google Earth?

Everytime I think Google has out-done themselves with another neat new technology. I'm still impressed with Google Maps (and the Satellite view!) and Picasa. With Google's purchase of Keyhole's image library and technology, they have been able to add neat imaging services to their offerings. Now comes Google Earth! I'm stuck. I'm addicted. I have got to stop playing with this and get some work done! And the best part is the basic services are all free. Awesome quality images from satellite.

Exchange 2003 setup failures

This past week, I tackled a problem that really kicked my behind for a few days. I was installing a new Exchange 2003 server in to an existing Exchange 5.5 organization. Windows 2003 Service Pack 1. The forest had been prepped and so had all of the domains. Lots of time for replication to occur. The user I was logging in with had all the necessary administrative permissions. All the prereqs had been met.

However, about 2 - 3 minutes after the install started, I got the following message:

Setup failed while installing sub-component Microsoft Exchange Organization-Level Container Object with error code 0xC1037AE6 (please consult the installation logs for a detailed description). You may cancel the installation or try the failed step again.


Clicking retry was, of course, a worthless endeavour. When I clicked Cancel, the setup continued. However, the Exchange server had lots of problems. MTA would not start. The store was generating EXOLEDB errors.

The Exchange Setup Log had a couple of interesting, but worthless entries when this happened.

[12:43:56] Configuring Administrative Rights
[12:43:56] Entering ScInstallLDIFScript
[12:43:56] ScRunLDIFScript (f:\titanium\admin\src\libs\exsetup\exmisc.cxx:1309) Error code 0xC1037AE6 (31462): Extending the schema in the Active Directory failed. Please consult the error log LDIF.ERR in your TEMP directory.

These errors suggested that the problem might be related to forestprep, but forestprep was already run. The LDIF.ERR file was also not in the directory that the TEMP variable pointed to.

After completely removing and re-installing the organization and the server a couple of times and redoing /forestprep and /domainprep, I stumbled across a KB article (870829) that recommended checking to see if my TEMP environmental variable had a space in it. Sure enough, my TEMP variable had spaces in the folder names. I changed the user's TEMP and TMP variables to C:\WINDOWS\TEMP and the install ran like a charm.

From what I can figure, the very first time I was running this, the setup program was creating the CN=Addressing containers under the Exchange organization in the directories Configuration partition. The Exchange Setup program uses the template.ldf file to create everything necessary in this container. This looks like where it was bombing when the setup was trying to run LDIFDE.

I know I have run Exchange 2003 setups via RDP under very similar circumstances, but I have never experienced this before. This set me back nearly 2 days. Eeeks!

For more information, see:
Setup with the /forestprep switch does not succeed, and you receive a 0xC1037AE6 error message

Pictures, pictures, pictures

My roommate and I recently took a trip to Thailand and Cambodia. A couple of folks asked me about pictures, so I finally got around to going through the 1,500+ pictures, picking some good ones, and posting them. Anyone interested can see them at http://www.somorita.com/travel. And, if you are wondering, Cambodia was definitely the high point of the trip!