Gmail discovers benefits of SSL, defaults to HTTPS

Google seems to have discovered the benefits of using SSL to encrypt HTTP traffic. In a blog post on the Gmail blog, Engineering Director Sam Schillace explains that Google has finally started valuing security over latency, and enabled HTTPS by default.

Gmail has always been using SSL to encrypt the authentication credentials sent from the login page. However, past the login page and accessing messages, all communication has been in the clear. Users have been accessing their messages over an unencrypted session. Users could choose to use SSL for the entire session, but since encryption would make Gmail slower, Gmail did not use it by default.

The latest change means the entire session will be encrypted by default.

If you haven't enabled SSL for the entire session before, you may see more latency when accessing Gmail. Encrypting data requires more resources. As Schillace comments in the post:

Over the last few months, we've been researching the security/latency tradeoff and decided that turning https on for everyone was the right thing to do.

To Gmail's credit, it's the only free web email provider that appears to be offering the use of SSL for the entire session. Microsoft's Live Mail and Yahoo Mail offer SSL-encrypted login pages, but there's no option to use SSL for the entire session. It's about time they follow suit.

cc:Betty: A cool web app you may want to block

If you haven't looked at Palo Alto-based cc:Betty yet, perhaps you should. cc:Betty promises to keep everyone on the same page. Still in beta, it's a useful web app that helps users organize their email communication, collects email content, catalogs attachments and files, and also maintains your contacts.

It's also amazingly simple to use. Besides adding content on the cc:Betty web site, users can simply add betty@ccbetty.com as an additional recipient (To/Cc/Bcc) to email they send, and it shows up in their cc:Betty account - email content, attachments, et al. With the click of a button, users can publish the discussion to their Facebook feed.


Figure 1:With the click of a button, cc:Betty posts your discussion to your Facebook profile

And therein lies the threat to your data!

Although it's an impressive tool for personal use (the usual caveats about personal information and privacy apply), organizations and IT departments must consider the consequences carefully. Many small businesses and organizations operating in unregulated industries or locales may not consider themselves to be at risk and actually welcome such services.

If your organization isn't one of them, consider that simply adding another recipient to all email messages results in data leakage. How's this any different from adding any other recipient to an email? Unlike other recipients, the sole purpose of cc:Betty is to facilitate further sharing of email content outside an organization. Email can contain sensitive information— including high business impact (HBI) data or personally identifiable information (PII). Transmitting and storing such information outside the organization, with no control over the content or its security, could expose your organization to multiple risks.

Content scanning and privacy
It's important to consider what services such as cc:Betty do with your information. cc:Betty's privacy policy is not very different from Gmail's privacy policy— email content is scanned to display relevant ads. Some would argue that similar content scanning is also performed by antispam and antivirus software and services, and that this isn't something to be concerned about.

Regardless of whether you find content scanning by an automated process acceptable or not, the bigger threat is data leakage.

If usage of cc:Betty and other such services is in violation of your organization's policies, your users must be informed. If your organization's policies don't address such services and usage, perhaps it's time to consider a policy review. You may also want to consider blocking outbound mail to domains offering such services.You can easily block outbound mail to a domain using transport rules or a Send Connector. Exchange 2010's Information Rights Management (IRM) features can also help you prevent data leakage.

What can cc:Betty do to help organizations?
How can cc:Betty help organizations protect themselves from unauthorized use of its service? As a web-based service its success lies in widespread adoption of its app. More users, more user content accumulated, more sticky the service proves to be, and more pageviews it racks up. As such, there's no incentive to actually stop users from joining or posting information. In fact, it may directly impact its success.

However, cc:Betty and other such services may gain a lot of goodwill and more acceptance if they work with organizations to help prevent data leakage. One way of doing this may be to block email from organizations that register with it. When a user signs up for an account using your organization's email address, he/she gets a polite message about your company not allowing use of the service. Email sent from your domain can also be bounced back with a polite NDR.

Some organizations may choose to allow their users to use the service, but with appropriate policy guidelines and controls in place. [Update: According to cc:Betty, an enterprise version of the service is in the works.]

Does your organization allow the use of cc:Betty.com or similar services?

iPhone OS 3.1 Security Changes and Exchange ActiveSync Policy

Apple implemented device encryption in the iPhone 3GS, improving its odds of being considered for enterprise deployment.

However, users using Exchange ActiveSync (EAS) to connect to their Exchange 2007 mailboxes couldn't take advantage of it, even when encryption was required by an Exchange ActiveSync Mailbox Policy, because the device didn't tell Exchange it can support encryption.

With the latest iPhone OS 3.1 update, iPhones start identifying themselves correctly, and if the ActiveSync policy configured by the administrator requires device encryption (see Figure 1 below), data on the device is encrypted. That's great news— unless you happen to have an older iPhone. If you're using the (Original/Classic/2G/1G?) iPhone , or the iPhone 3G, and device encryption is required, you will be unable to log on to your mailbox.

This is great for iPhone 3GS users, who can now be more secure than they previously were. Users of legacy iPhones can either buy an iPhone 3GS to have their data stored securely on the device, or downgrade, somehow, to the previous version of iPhone OS. I'm not sure if a downgrade is possible, or if you'll need to take your iPhone to an Apple store to have it downgraded. (Incidentally, the iPhone user in the family was in no rush to upgrade to iPhone OS 3.1, and can't really stand Apple's iTunes software.)


Figure 1: Enforcing device encryption using an ActiveSync Mailbox Policy in Exchange 2007

News.com's Jim Dalrymple suggests in Apple explains iPhone OS 3.1 Exchange changes:

If you already upgraded to iPhone OS 3.1 on an iPhone or iPhone 3G and connect to an Exchange 2007 server, you can ask that the IT admin turn off the hardware encryption requirement for those devices.

Good luck with that!

Update: Interestingly, the above suggestion is actually what Apple recommends in its knowledgebase article TS2941: iPhone OS 3.1: 'Policy Requirement' error when adding Microsoft Exchange account. Specifically:

To reestablish syncing, have your Exchange Server administrator change the mailbox policy to no longer require device encryption.

In a nutshell— lower security to allow older iPhones to sync. If you use the same ActiveSync policy for all users, this also lowers security for all mobile devices in your organization!

If you want to read InfoWorld (the dabbling-in-sensationalism publication I call MAD magazine of tech journalism and others equate with tabloid journalism) executive editor Galen Gruman's - should I say, more strongly worded take on it, here it is.

It turns out that Apple's iPhone 3.1 OS fix of a serious security issue -- falsely reporting to Exchange servers that pre-3G S iPhones and iPod Touches had on-device encryption -- wasn't the first such policy falsehood that Apple has quietly fixed in an OS upgrade. It fixed a similar lie in its June iPhone OS 3.0 update. Before that update, the iPhone falsely reported its adherence to VPN policies, specifically those that confirm the device is not saving the VPN password (so users are forced to enter it manually). Until the iPhone 3.0 OS update, users could save VPN passwords on their Apple devices, yet the iPhone OS would report to the VPN server that the passwords were not being saved.

I resisted highlighting that entire quote. Needless to say, if this is indeed true and not merely InfoWorld's interesting interpretation and reporting of facts— it makes Apple's tall claims of being "highly secure by design" and "secure from day 1" across its product line (OS X, Safari browser, the iPhone and Apples online services) worth every bit of suspicion, skepticism, and scrutiny they deserve.

The InfoWorld article ends with:

IT organizations can also consider using third-party mobile management tools that enforce security and compliance policies; several now support the iPhone to varying degrees, including those from Good Technology, MobileIron, and Zenprise.

Although mobile device management products such as those mentioned above can make it cost-effective to manage large number of mobile devices, improve service levels, lower time to resolution, and to some extent help with securing them, I doubt any of them can actually determine if what the device reports about its capabilities or status is really true. To read rest of the article, head over to The other iPhone lie: VPN policy support on InfoWorld.com.

Does the iPhone meet the bar for enterprise deployment? Do you allow iPhone users to connect to your Exchange server?

The 'Catastrophic' Windows 7 bug and security vulnerability that never was

Perhaps I should've used a different headline for this post. Something like "InfoWorld's conspiracy to derail the Windows 7 product launch". But that would be giving in to exactly the temptation I want to highlight— the one many bloggers, writers, and editors fall victim to, or otherwise find hard to resist in the quest for more pageviews.

Somewhere in the blogosphere, someone reports a "critical Windows 7 bug". One tech writer sees it as a "catastrophic bug" in Windows 7 which could "derail the Windows 7 launch".

Although the writer didn't discover the bug, and I'm not quite sure if the headlines are the writer's own or the handiwork of an over-zealous editor, but the outcome is an article with a sensational headline that screams for attention— Critical Windows 7 bug risks derailing product launch.

The sub-headline is equally interesting: An apparent fatal flaw in the NTFS driver stack may bring Microsoft's Windows 7 impending victory parade to a grinding halt.

What's wrong with Windows 7? In the writer's words:

The bug in question -- a massive memory leak involving the chkdsk.exe utility -- appears when you attempt to run the program against a secondary (that is, not the boot partition) hard disk using the "/r" (read and verify all file data) parameter. The problem affects both 32- and 64-bit versions of Windows 7 and is classified as a "showstopper" in that it can cause the OS to crash (Blue Screen of Death) as it runs out of physical memory.

Sounds like a serious security vulnerability, and the writer suggests it is exactly that.

Also worth considering: This command can be executed in a nonelevated context under the looser Windows 7 UAC implementation (Vista requires elevation of this command via the normal user consent dialog before continuing). Not only is this a potentially catastrophic bug from a functional standpoint, it also opens up a new attack vector for malicious code. Hackers may be able to use this unprotected command to destabilize a system (by consuming almost all available RAM), and in extreme cases, cause it to fail altogether.

As reported, Microsoft has not been able to reproduce the bug.

I waited till I actually had the RTM code, and had the time to install and try this out on a couple of computers. Not only have I not been able to reproduce the blue screen, but as you can see in the following screenshot, UAC actually does prevent you from running chkdsk! And this is plain vanilla Windows 7 RTM with no updates, hotfixes, or changes to UAC settings.


Figure 1: UAC prevents running chkdsk /r on a computer with Windows 7 RTM.

The writer's implication of this being a catastrophic bug that opens up a new attack vector is not true. The command is not "unprotected"— Windows requires an elevated prompt to run chkdsk.

I also ran the command with an elevated prompt, and failed again! Chkdsk did consume a fair amount of available memory, but nowhere close to the "massive amounts of memory" reported by the writer. Needless to say, the much feared blue screen of death (BSOD) was never encountered. (As a sidenote, I've not seen a blue screen in a long time. The last time I saw it was when I knowingly installed an unsigned driver, bypassing Windows' warnings urging me not to do so! When was the last time you saw one?)


Figure 2: Chkdsk consumes a fair amount of memory, but nowhere close to 90%. It graciously releases memory when required for other tasks.

On further testing, I also noticed that chkdsk graciously released memory when the system required it for other tasks, such as running other programs [see screenshot]. This is not very different from how Exchange Server has historically behaved as far as memory consumption goes. Some tasks require more memory, and if more memory is available, perhaps it's intended to be used at some point?

As a more-than-reasonably-technically-savvy user, I do not recollect running chkdsk more than once or twice in almost a decade. Yet, a so-called bug that can't really be reproduced easily— or reproduced at all, somehow becomes a catastrophic bug that "risks derailing product launch". Noted author and ZDNet columnist Ed Bott responds with A killer Windows 7 bug? Sorry, no. Ed explains further why this is not at all what it's made out to be.

In an unusual response, Windows division president Steven Sinofsky left a comment on the blog that reported this issue. Says Sinofsky:

While we appreciate the drama of ‘critical bug' and then the pickup of ‘showstopper' that I've seen, we might take a step back and realize that this might not have that defcon level.

And as you may have guessed, that got faithfully reported by InfoWorld in Windows president tries to calm fears of critical Windows 7 bug. Yet another headline for InfoWorld, and no questions asked about who stoked the fear to begin with.

[Update: Steven Sinofsky explains how Microsoft deals with bug reports, partially in response to this issue. Read What we do with a bug report? on the Engineering Windows 7 blog.]

Having had my own brush with InfoWorld editors and writers in the past (Details in "Save XP" Campaign: InfoWorld responds, and the facts about downgrade rights), all I can say is— it saddens me to see what used to be a well-regarded technical journal for geeks (and still has some excellent experts and writers I admire) accelerate its pace towards becoming the MAD magazine of tech journalism.

Trust Thy Certificate? New SSL Vulnerabilities Revealed At BlackHat 2009

It's BlackHat time in Vegas, and I was expecting some interesting security revelations to make headlines, but not as serious as the SSL vulnerability revealed by independent security researcher Moxie Marlinspike. Moxie showed a way to intercept SSL traffic using what he calls a null-termination certificate. Reportedly, some programs terminate processing of a certificate's subject name when they come across a null character.

The implications? A certificate issued to www.paypal.com\0.thoughtcrime.org might be read as belonging to www.paypal.com. The risk isn't that users could be tricked into visiting a phishing web site— that seems pretty trivial these days. This vulnerability opens the door for more dangerous man-in-the-middle attacks that can go undetected and intercept data from supposedly secure sessions, such as those used for online banking or stock trading, amongst others.

Moxie demonstrated such a man-in-the-middle attack using code that allowed him to intercept SSL traffic undetected. What increases the risk— according to him it can be used to intercept FireFox update requests, which depend on SSL. It's not hard to guess the consequences of such a compromise. With a modified copy of FireFox and his tool, "...anytime you submit something to a site it sends me a copy", he revealed.

Are other browsers vulnerable? Yes, but not to a similar extent. It would be harder on Internet Explorer, since it uses code signing to ensure the authenticity and integrity of code.

UAE BlackBerry Update A Surveillance App

Unsuspecting BlackBerry customers in the UAE have been pushed out a surveillance app disguised as a BlackBerry update by telco Etisalat. Rather than improve BlackBerry handheld performance, the update emails received messages back to a central server! After downloading the app developed by Milpitas, CA-based SS8, a provider of communications intercept and surveillance solutions, users reported significantly reduced battery life, poor reception and in some cases, handsets stopped working altogether.

The telco in question calls it a "slight technical fault", saying that the "upgrades were required for service enhancements".

BlackBerry-maker Research in Motion said that it did not authorize the software installation and "was not involved in any way in the testing, promotion or distribution of this software application."

"Independent sources have concluded that it is possible that the installed software could ... enable unauthorized access to private or confidential information stored on the user's smart phone,' it said in a statement.

More in RIM Warns Update Has Spyware on WSJ.com.

Windows 7 and Direct Access: The Anywhere Experience

Over the past few weeks, Windows 7 Release Candidate has been widely downloaded, used, praised (including by some very vocal critics), and loved. It's easy to fall in love with the Windows 7 user experience, and I don't just mean the lovely wallpapers and themes that are in stark contrast to the kind of visual content that's been generally packaged with Microsoft products in the past. You can see the images in A Little Bit of Personality on the Engineering Windows 7 blog. The Wall Street Journal's Nick Wingfield calls them "some of the most visually arresting background images ever to ship with a piece of software". More in This is Your Windows on Drugs on wsj.com.

Last night, Brandon LeBlanc revealed box shots and details of Windows 7 packaging on the Windows blog. Head over to Check out the New Windows 7 Packaging.

One of the Windows 7 features I love is called Direct Access. It's like the Outlook Anywhere version of VPNs.

Outlook Anywhere, AutoDiscover, and Microsoft Communicator: A Seamless Unified Communications Experience
Outlook Anywhere allows Outlook 2007 + Exchange 2007 users to seamlessly access their mailbox from outside (and inside) the corporate network. Yes, part of it is of course RPC over HTTP(S)— available in Exchange 2003, but another important piece that makes this experience so transparent to the user is AutoDiscover.

You get out of work (or work remotely), turn on your laptop, and if you have Internet access Outlook 2007 just works as if you were in your office. No VPN connections to establish, no wondering if the required ports are open on the firewall, no additional authentication prompts, and full Outlook access! Although Outlook Web Access has increasingly become more like a full-fledged email client, for many folks there's simply no replacement for the full blown functionality of Microsoft Outlook. With Office Communications Server 2007 implemented right, you can have a similar experience with Microsoft Communicator - seamless access to Instant Messaging, presence information, and the all-important ability to connect to the "voice world".

Yes, the voice world, still an inseparable part of our work lives. The ability to click and talk to a Contact is handy, and found in many free IM and telephony services such as Skype. However, what's more impressive and important for many— you can dial phone numbers and receive inbound phone calls on your work phone number, regardless of your location. You can check voicemail, and also redirect calls to another phone number. The voice quality is good enough that it's hard to tell if one's using an ordinary phone or a VoIP phone.

Direct Access: Extending the Anywhere Experience
Windows 7's Direct Access feature extends this Anywhere Experience. It allows you to access network resources on your corporate network, without having to establish a VPN connection. Now you can turn on your laptop, and if you have Internet access, you can access file shares on your corporate network, use client/server apps, and use RDP to connect to servers/computers "on the other side".

DirectAccess uses IPv6-over-IPSec to encrypt communication, and supports multifactor authentication mechanisms such as smart cards.

Besides the initial "Wow!" moment, which inevitably follows the first experience with Direct Access, the combined Anywhere Experience boosts productivity, and improves satisfaction levels of remote/mobile workers.

Steve Riley explains why it's one of his favorite Windows 7 features:



More about Direct Access in DirectAccess enhances mobility and manageability, or download Technical Overview of DirectAccess in Windows 7 and Windows Server 2008 R2 for a more in-depth technical look.

ASN1 Bad Tag Error Installing an SSL Certificate in IIS 7

You've installed SSL certificates on previous versions of IIS more times than you care to remember. It's no rocket science - you create a certificate request, request the certificate from a Certification Authority, get the certificate and complete your certificate request.

Then there's IIS 7. Modularized. Optimized. Secure. You follow the same procedure as you did with previous versions of IIS. Create a certificate request, check. Get the certificate from a CA, check. Install the certificate, and that's where the familiarity ends. Instead of installing the certificate, IIS 7 throws up a cryptic error: There was an error while performing this operation. Details: CertEnroll::CX509Encrollment::p_InstallResponse: ASN1 bad tag value met. 0x8009310b (ASN: 267).


Figure 1: IIS 7's cryptic error when trying to install an SSL certificate

If you fire up the Certificates console (start a new MMC console | add Certificates snap-in | select the computer account), you'll see the certificate is indeed installed.

By default, IIS does not create a binding for HTTPS.


Figure 2: IIS 7's default site bindings

Add a binding for HTTPS

1. In the Site Bindings window, click Add
   
2. In the Add Site Binding window, select https from the Type: drop-down.
   
3. Select an IP address (or optionally, leave All Unassigned selected if you want the site to bind to the specified SSL port on all IP addresses
   
4. From the SSL certificate: drop-down, select the certificate you want to use for the binding/web site.
   
   [Optional] You can click the View button to view the certificate and ensure you're selecting the right one.
   
   Figure 3: Creating a binding for https in IIS 7
   
5. Click OK to close the Add Site Binding window.

Close the Site Bindings, start a browser, and test the web site using https.

Internet Explorer 8 and OWA: Where Are The Images?

Internet Explorer 8 was released last week at MIX09. It's likely many users may already be running either the RTM version or one of the earlier betas.

IE 8 is more secure than previous versions (see Stay Safer Online for a list of IE8's security features), including some of the default settings. Here's one of those changes and how it may impact your OWA users (and potentially result in a helpdesk call).

A user gets an HTML message with images. When viewing the message in OWA, the user sees missing images, as shown below:


Figure 1: An HTML message rendered in OWA with missing images

Instead of this:


Figure 2: HTML message with images rendered in OWA

Is that the web beacon and form filtering feature of OWA 2007 at work?

OWA 2007: Web beacon and form filtering

Web beacons (aka "web bugs") are very small, transparent image files in web pages and HTML email. These 'invisible' images are commonly used by web sites to track visitors, along with cookies. When you inadvertently download such an image in an HTML email message, it calls home and tells Mr. Spammer: "I made it! The email address is valid, and someone even viewed the message!"

In Exchange 2007, OWA blocks web beacons, and displays the following prompt inline in the information bar (where header information such as subject, sender, recipient, and timestamp are displayed).


Figure 3: The web beacon and form filtering feature displays a prompt in the information bar to allow user to unblock content

If users determine the message is from a trusted sender and safe to open, they can unblock the blocked content by clicking on the "Click here" link in the information bar (highlighted in Figure 3 above).

Web beacon and HTML form filtering behavior can be controlled for an OWA virtual directory. Use the Set-OwaVirtualDirectory cmdlet to toggle the FilterWebBeaconsAndHtmlForms property, as shown in How to Control Web Beacon and HTML Form Filtering for Outlook Web Access.

But you don't see the familiar click here link in the message!

The Tale of The Two Prompts
You're accessing OWA (or any other web page for that matter) over a secure HTTPS session. The page has images or other unsecure content (not unsecure as in malicious content, but the content is accessed using HTTP) it wants the browser to display. The first time the browser faces this scenario, it sends alarm bells ringing. It warns you, the user almighty, and asks you what you wish to do.

You may even remember the IE prompt— even if vaguely so. Yes, the one you dismissed by clicking the "Yes" button, without giving it any thought? Afterall, what harm could a lowly web page do to your highly secure computer?

In IE8, the prompt has been reworded, and the choices reordered. Here's what the shiny new prompt looks like.


Figure 4: Security warning in Internet Explorer 8, clearly informing users about blocked content, and the potential security impact of displaying such content

As you can see, users instinctively clicking the "Yes" button continue to be protected by Internet Explorer 8. They do not end up in an insecure state! Moreover, the dialog is clearer and more informative, compared to the one found in previous versions of IE. Here's the dialog from IE 7:


Figure 5: The 'Security Information' prompt in Internet Explorer 7, prompting users about nonsecure items

Google Docs' Privacy Blunder: Shares Your Docs Without Permission

Just as I was beginning to warm up to certain kinds of cloud computing comes news of Google Docs' "privacy blunder". Google has sent a notice to a number of users notifying them that it may have inadvertently shared some of their documents with contacts who were never granted access to them. Jason Kincaid writes in TechCrunch:

According to the notice, this sharing was limited to people “with whom you, or a collaborator with sharing rights, had previously shared a document” - a vague statement that sounds like it could add up to quite a few people. The notice states that only text documents and presentations are affected, not spreadsheets, and provides links to each of the user’s documents that may have been shared in error.

Needless to say, information security and privacy is probably one of the biggest concerns for most organizations when considering a move to cloud services. I point this out not only because it's Google's security lapse today, but as we continue to move to more cloud-based services with different vendors, the possibility of such security incidents occurring with other service providers cannot be ignored.

More in 'Google Privacy Blunder Shares Your Docs Without Permission' on TechCrunch.com.

Released: Update Rollup 6 for Exchange 2007 Service Pack 1

Update Rollup 6 for Exchange Server 2007 SP1 has been released. Download it here.

As noted in previous posts, Exchange 2007 updates are cumulative and release-specific. Additionally, as Ananth notes in the post on the Exchange team blog (read 'Update Rollup 6 for Exchange Server 2007 Service Pack 1 Released'), this update has a fix for a security issue rated as critical, and the update to allow Internet Explorer 8 to be used to access Outlook Web Access does not include the S/MIME control. An updated version of the control will be released in a future rollup.

Fixes for the following issues are included (details in KB 959421):

• 959239 MS09-003: Vulnerabilities in Microsoft Exchange could allow remote code execution
  
• 950675 Downloaded .xls file attachments are empty when you open the files by using Outlook Web Access on Exchange Server 2007 Service Pack 1
  
• 955443 Some free/busy messages are not replicated from Exchange 2007 to Exchange 2003 servers after some mailboxes are migrated from Exchange Server 2003 to Exchange Server 2007
  
• 956356 The Microsoft Exchange File Distribution service uses lots of memory and processor time when Exchange Server 2007 processes many OABs
  
• 956624 The Microsoft Exchange Transport service crashes continuously after you enable journal rule or deploy an antivirus application on an Exchange Server 2007 server
  
• 957748 The custom message class of contact object is overwritten by the normal IPM.Contact class when an Exchange 2007 server replicates the contact object to any other public store

McCain Campaign Sells Loaded BlackBerry Smartphones

As part of winding down operations, the McCain-Palin campaign ended up making yet another security foible - the campaign sold 10 BlackBerry smartphones without wiping them clean. According to Fox News, the devices with confidential campaign data on them were sold for $20 each. More in McCain Campaign Sells Info-Loaded Blackberry to FOX 5 Reporter.

SCRIPT: List Delegates With Send On Behalf Access

Send On Behalf access allows a user to send mail on behalf of the mailbox owner.


Figure 1: Send On Behalf access can be assigned from ADUC | recipient properties | Exchange General | Delivery Options, or by the mailbox owner using Microsoft Outlook

Here's a script that lists all users with delegates.

File: listDelegates.zip

Related posts and links:

• Understanding Exchange Server 2003 Mailbox Access Delegation
  
• List users with email forwarding enabled
  
• HOW TO: Export all email addresses from a domain
  
• SCRIPT: Show mailbox limits
  
• SCRIPT: Reset Mailbox Limits
  

Microsoft: "High Priest of Secure Software Development"

From a company most frequently bashed for the security woes of the world, Microsoft has morphed into what CNET calls the "high priest of secure software development", which is now helping others develop secure software.

The Trustworthy Computing Initiative started six years ago is paying off.

More in 'Microsoft becomes high priest of secure software development' on News.com.

Where are mailbox last logon, client IP address, and other details in Exchange 2007?

In Exchange Server 2003/2000, expanding a Mailbox Database provides information about mailboxes in a database, last logon/logoff times and account(s) that logged on to mailboxes (see 'Displaying Client IP Address in Exchange System Manager' for details).


Figure 1: In Exchange 2003, the Logons node displays Store logon-related information. Click here to see a bigger screenshot.

In Exchange Server 2007, these details are not displayed in the EMC. The reasons are not hard to guess. These details are retrieved by querying the mailbox database. In Exchange 2003, these were displayed when you selected the mailbox database, resulting in a single mailbox database being queried. In Exchange 2007, mailboxes are displayed when you select Recipient Configuration -> Mailboxes, and depending on the selected scope/filter, the console displays mailboxes from the entire organization. Querying all mailbox databases on different servers in a distributed organization can become very slow, generate a lot of extra network traffic— terribly inefficient.

Instead, why not allow the administrator to query for these details when they're actually required? The shell provides you the flexibility to only get the fields you want, only for the mailboxes you want, making it much more efficient. If you manage smaller Exchange deployments and love your GUI management tools, you may not fall in love with the idea. (But that debate's already settled, and you're going to have to learn some bit of Exchange shell to be able to manage Exchange 2007 and later. The good news is, it's cooler, easy-to-use, well-documented by now, and comes with plenty of help!).

Logon Statistics
The Get-LogonStatistics cmdlet provides the following logon-related information.

AdapterSpeed :
ClientIPAddress :
ClientMode :
ClientName :
ClientVersion :
CodePage :
CurrentOpenAttachments :
CurrentOpenFolders :
CurrentOpenMessages :
FolderOperationCount :
FullMailboxDirectoryName :
FullUserDirectoryName :
HostAddress :
LastAccessTime :
Latency :
LocaleID :
LogonTime :
MACAddress :
MessagingOperationCount :
OtherOperationCount :
ProgressOperationCount :
RPCCallsSucceeded :
StreamOperationCount :
TableOperationCount :
TotalOperationCount :
TransferOperationCount :
UserName :
Windows2000Account :
ServerName :
StorageGroupName :
DatabaseName :
Identity :

The command can be constrained to a mailbox database (get-logonstatistics -Database "MyDatabase" | fl), a mailbox server (get-logonstatistics -Server "MyServer"), or a particular mailbox.

Mailbox information
In ESM, the Mailboxes node of a Mailbox Store displays mailbox-related information such as mailbox size, number of items, and last logon/logoff.


Figure 2: In Exchange 2003, the Mailboxes node displays mailbox-related information. Click here to see a bigger screenshot.

This information can be retrieved using the Get-MailboxStatistics cmdlet. It provides the following information related to a mailbox:

AssociatedItemCount :
DeletedItemCount :
DisconnectDate :
DisplayName :
ItemCount :
LastLoggedOnUserAccount :
LastLogoffTime :
LastLogonTime :
LegacyDN :
MailboxGuid :
ObjectClass :
StorageLimitStatus :
TotalDeletedItemSize :
TotalItemSize :
Database :
ServerName :
StorageGroupName :
DatabaseName :
Identity :

It can also be constrained to a -Database, -Server, or mailbox.

Now that we're dealing with the shell, besides these cmdlets' built-in filtering capabilities (Database, Server, or mailbox), you can use Powershell's where-object cmdlet to further filter the results based on the properties returned by each cmdlet. For example, to find out logon sessions from a particular IP address:

Get-LogonStatistics -Server "MyServer" | where {$_.ClientIPAddress -like "192.168.2.101"}

IIS 7 Authentication: What happened to the IUSR_MachineName account?

In previous versions of IIS, the IUSR_MachineName account is created for anonymous authentication. This is an actual user account created on the server (a domain account can be used in domain environments), and like all user accounts— it has a SID, and an account password with the accompanying management costs and risks.

One of the resulting annoyances (for me): when you install IIS first and then change the computer name, the computer name and the MachineName in IUSR_MachineName account don't match.

IIS 7 gets rid of the IUSR_MachineName account in favor of a built-in IUSR account that's guaranteed to have the same SID on all computers. This ensures ACLs copied from one web server to another work, domain accounts are no longer required, and applications can be easily deployed across multiple web servers. The IIS_WPG group (for IIS Application Pool identities) is replaced by the built-in group IIS_IUSRS.

Note: The IUSR_MACHINENAME account isn't completely gone— it is used for anonymous authentication to FTP, and gets created if/when you install FTP.

More on the IIS team blog in 'Understanding the Built-In User and Group Accounts in IIS 7.0'

- Security identifiers
- Well-known security identifiers in Windows operating systems

Released: ISA 2006 Service Pack 1

ISA Server 2006 SP1 has been released. SP1 brings some new features, and improvements such as support for SAN certificates. Download SP1.

New features:

• Configuration Change Tracking: Registers all configuration changes applied to ISA Server to help you assess issues that may occur as a result of these changes.
  
• Test Button: Tests the consistency of a Web publishing rule between the published server and ISA Server.
  
Traffic Simulator:Simulates network traffic in accordance with specified request parameters, such as an internal user and the Web server, providing information about firewall policy rules evaluated for the request.

• Diagnostic Logging Viewer: Now integrated as a tab into the ISA Server Management console, this feature displays detailed events on packet progress and provides information about handling and rule matching.

Improvements for existing features:

• Support for integrated NLB mode in all three modes, including unicast, multicast, and multicast with Internet Group Management Protocol (IGMP). Previously, ISA Server integrated NLB-supported unicast mode only.
  
• Support for use of server certificates containing multiple Subject Alternative Name (SAN) entries. Previously, ISA Server was able to use either only either the subject name (common name) of a server certificate, or the first entry in the SAN list.
  
• Support for KCD cross-domain authentication. Credentials from users located in a different domain than the ISA Server, but in the same Forest, can now be delegated to an internal published Web site by using KCD .
  
• Support for client certificate authentication in a workgroup deployment. This removes the requirement to map each client certificate to an Active Directory® directory user account when forms-based authentication is used as the primary authentication method and client certificates are used as the secondary method.

SP1 fixes the following issues:

• 894679 Users who do not have the appropriate permissions can receive restricted content from ISA Server 2004
  
• 920913 Error message in response to some HTTP requests on client computers that are running ISA Server 2004 as a proxy server: "400 Bad Request"
  
• 921944 A client computer takes longer than expected to connect to a Web site through an ISA Server 2004 Web proxy server
  
• 922851 You receive a blank page when your Web browser submits a POST request to an ASP Web site over an ISA Server 2004 access rule that requires client authentication
  
• 922899 An ISA Server 2004 Web chaining rule may not redirect requests to the specified port
  
• 923318 Error message in SecureNAT clients after you configure a Web chaining rule to forward HTTP as HTTPS in ISA Server 2004: "The target principal name is incorrect"
  
• 923322 A large file download fails when an ISA Server 2004 SOCKS client computer uses passive mode FTP
  
• 923765 The Microsoft Firewall service stops responding to client computer requests and Event IDs 7034, 14057, and 1000 are logged after you publish an OWA server in ISA Server 2004
  
• 923766 A client computer may not be authenticated by ISA Server 2004 when you use integrated Windows authentication
  
• 924405 Client computers cannot download attachments when you use ISA Server 2004 or ISA Server 2006 forms-based authentication and run a third-party OWA add-in program to manage attachments
  
• 925288 One or more published sites may stop being available if you create more than 300 Web site publishing rules in ISA Server 2006 Enterprise Edition
  
• 928273 Users may receive slow responses when you enable the Cache Array Routing Protocol in ISA Server 2004, Enterprise Edition
  
• 929818 You receive an error message when you try to install or to run Windows Vista: "The Software Licensing Service reported that the license is invalid"
  
• 930415 You cannot apply an OWA Web publishing rule that redirects users who connect to the root of the OWA Web site to an internal folder by using ISA Server 2006
  
• 933523 When an Internet Security and Acceleration Server 2004 client performs an action that uses the HTTP POST method, the action may be performed multiple times
  
• 934022 An ISA Server 2004 downstream server does not reuse the TCP connections to a third-party upstream server
  
• 935767 The authentication delegation in the existing Web publishing rules does not work after you upgrade ISA Server 2004 Enterprise Edition to ISA Server 2006 Enterprise Edition
  
• 938465 Error message when you try to access Web sites through a downstream server after you enable hotfix 927265 on an upstream server that is running ISA Server 2004: "502 Proxy Error"
  
• 938550 An update enables multicast operations for ISA Server integrated NLB
  
• 940659 Error message when you try to visit a Web site that is published in ISA Server 2004: "HTTP error 500: network name no longer exists"
  
• 940708 The "401 Authentication Required" response that is sent by a Web site is dropped when you use ISA Server 2004 as a Web proxy
  
• 941162 In ISA Server 2006, you cannot set a session time-out for private computers in a Web listener that has the RSA SecurID authentication method configured
  
• 941296 An ISA Server 2006 computer may stop responding under a heavy load
  
• 941634 After an ISA Server 2006 application filter establishes an HTTP connection, the connection closes before it can be used, and a "0x80004001 (E_NOTIMPL)" status code is logged
  
• 941870 Only 1,000 PPTP ports and 1,000 L2TP ports are open in Routing and Remote Access if the maximum number of VPN clients is set to more than 1,000 in ISA Server 2006
  
• 942313 Web pages do not appear as expected when you publish a Web site by using a publishing rule in Internet Security and Acceleration (ISA) Server 2006
  
• 942637 A user cannot access a Web site that is published in ISA Server 2006 by using Kerberos constrained delegation if the user is not in the same domain as the ISA Server computer
  
• 942638 POST requests that do not have a POST body may be sent to a Web server that is published in ISA Server 2006
  
• 943200 The Microsoft Firewall service stops unexpectedly on a computer that is running ISA Server 2004
  
• 943212 You cannot filter the RPC traffic based on universally unique identifiers (UUID) by using an access rule in ISA Server 2006
  
• 943214 When you publish a back-end ISA Server 2006 computer on a front-end ISA Server 2006 computer that faces the Internet, you cannot enable forms-based authentication on both computers
  
• 944699 The Microsoft Firewall service stops unexpectedly if a Web filter is used on a computer that is running ISA Server 2006
  
• 944764 Requests that have large request bodies may fail when you publish a Web site in ISA Server 2006
  
• 944824 Stop error message on a computer that has ISA Server 2006 installed: You receive a "Stop 0x0000007f"
  
• 945224 ISA Server 2006 may forward requests to an incorrect Web server when a client computer accesses Web sites that have different public names in the same session
  
• 945524 Some Web servers that are published in ISA Server 2006 by using the Web Publishing Load Balancing feature may be incorrectly detected as unavailable at random times
  
• 945814 Error message when you try to change the password of a user account even if you configure ISA Server 2006 to allow users to change their passwords
  
• 945882 HTTP SEARCH requests that do not have a SEARCH body may be sent to a Web server that is published in ISA Server 2006
  
• 947254 A computer that is running ISA Server 2006 may randomly stop routing packets from certain VPN clients or from certain VPN site-to-site networks
  
• 947255 Packets from the branch office may not reach the destination servers in the central office over a site-to-site VPN connection that you create through ISA Server 2006
  
• 947521 When HTTP compression is enabled in Web publishing rules in ISA Server 2006, the compression filter may be unable to handle HTTP responses
  
• 948711 A report may not display HTTPS traffic in ISA Server 2006
  
• 949628 The Microsoft Firewall service crashes randomly when you use ISA Server 2006 to publish a Web server by enabling forms-based authentication
  
• 950139 The Microsoft Firewall service in ISA Server 2006 stops responding to client requests after you publish a Web server by using NTLM authentication delegation
  
• 951508 When you use ISA Server 2006 to publish a Web server, and authentication delegation is enabled, some Web content may not be displayed correctly when a user accesses the published Web server
  
• 951509 Users cannot access a Web site that is published in ISA Server 2006 if the Web site accepts only the SPNEGO authentication package
  
• 950150 Error message when you open a .gz file that you downloaded through an ISA Server 2004 Web proxy server: "Invalid archive directory"
  
• 952675 You cannot log on to a local intranet site that you publish by using ISA Server 2006 when there are multiple user accounts that have the same account name in different domains

ISA 2006 SP1: Support for SAN certs, and new features

When ISA Server 2006 SP1 rolls out this summer, there will be some cool new features to look forward to, including support for SAN certificates.

Having started using Proxy Server 1.0 (I know... hold on to your comments for now.. :) back in the days, I turned away from ISA's predecessor(s) for a few years to engage with what I thought were better options at that time— "dedicated" hardware firewalls. Not too long ago, I started using ISA again, and became a convert with ISA 2006. It made "publishing" (am I the only one who finds the phrase "publishing to the internet" amusing?) Exchange services such as OWA, EAS, Outlook Anywhere, and SMTP secure and relatively effortless.

If you have ISA 2006 deployed with Exchange Server 2007, you're probably looking forward to SP1 as well for its SAN certificate support. Check out the other cool features in this post on the ForeFront TMG (ISA) team blog: ISA Server 2006 Service Pack 1 Features.

Removing internal host names and IP addresses from message headers

Another frequently asked question about SMTP mail - how can I remove internal host names and IP addresses from outbound internet mail? More often than not, this results from the belief that somehow if the outside world finds out an organization's internal IP addresses and host names, it makes the organization vulnerable. Auditors love to point this out for some reason. Perhaps it's a part of a checklist written by a security expert at some law firm somewhere, and given the viral nature of checklists it's all over the place!

Let's take a look at what we're talking about here. As a message makes its way from one server to another, it may be handled by more than one SMTP hosts. Each host adds a RECEIVED header at the beginning of message headers, leaving a trace of where the message has been and when (a timestamp).

Here are headers from a message received from Dell. (Unnecessary headers removed).

Received: from smtp.easydns.com (205.210.42.52) by exchange.somedomain.com
(192.168.2.171) with Microsoft SMTP Server id 8.1.240.5; Mon, 19 May 2008
03:12:46 -0700
Received: from mh.dell.m0.net (mh.dell.m0.net [209.11.164.66]) by
smtp.easydns.com (Postfix) with ESMTP id 647C222914 for ;
Mon, 19 May 2008 06:14:46 -0400 (EDT)
Received: from [192.168.138.130] ([192.168.138.130:57330]
helo=fc13a1.dc1.prod) by oms1.dc1.prod (ecelerity 2.1.1.24 r(19486)) with
ESMTP id 3B/AF-18306-11351384 for ; Mon, 19 May 2008
03:14:41 -0700
Message-ID: <14154167762.1211192081379@delivery.net>
Date: Mon, 19 May 2008 03:14:41 -0700
From: Dell Small Business
Reply-To:
To:
Subject: $429 desktop, plus new laptops. Hurry and shop now.
Errors-To: dell@smallbusiness.dell.com
Return-Path: dell@smallbusiness.dell.com

These headers can be used to determine the path taken by a message— useful information for troubleshooting and preventing message loops.

What the standards say
Let's take a look at what the standards say. RFC 2821 says (capitalization of words as it appears in the RFC, emphasis added):

4.4 Trace Information

When an SMTP server receives a message for delivery or further processing, it MUST insert trace ("time stamp" or "Received") information at the beginning of the message content, as discussed in section 4.1.1.4.

This line MUST be structured as follows:

- The FROM field, which MUST be supplied in an SMTP environment, SHOULD contain both (1) the name of the source host as presented in the EHLO command and (2) an address literal containing the IP address of the source, determined from the TCP connection.

and prohibits removing received headers (repeatedly). One example:

An Internet mail program MUST NOT change a Received: line that was previously added to the message header. SMTP servers MUST prepend Received lines to messages; they MUST NOT change the order of existing lines or insert Received lines in any other location.

More secure?
Should you remove these headers, and "hide" internal hosts and IP addresses? Is it really a security risk?

There are many opinions about security through obscurity, but if your security relies on hiding internal hostnames and IP addresses, you probably have other things to worry about.

Steve Riley, Senior Security Strategist at Microsoft, says:

In general, you can’t achieve any additional security by trying to hide things that weren’t designed to be hidden. IP addresses, wireless SSIDs, hostnames—these are all identifiers, and by definition, an identifier is intended to be known. Efforts to hide them generally fail, because the thing that the identifier points to still exists! Determined attackers will find the thing regardless of what you name it.

Microsoft does not remove internal message routing headers. Nor do Dell (as the message headers in the example above reveal), HP, and many other large organizations.

In many ways, the issues faced are similar to changing fqdn on SMTP Virtual Server/Receive Connector. Even if you make these changes, at least one internal hostname is likely to be revealed by the Message-ID (read "Masquerading SMTP Virtual Servers: Changing the fqdn and masquerade domain").

Nevertheless, many organizations may have a legitimate need to cleanse outbound mail of internal host names and IP addresses, and you probably don't want to invite adverse remarks in an IT or compliance audit (should you find such a requirement on the auditor's checklist).

How to remove Received headers in Exchange Server 2007
Exchange Server 2007 offers an easy way to accomplish this. If your transport server sends outbound email directly using DNS lookup, or delivers to a smarthost without authentication, simply remove the Ms-Exch-Send-Headers-Routing permission assigned to Anonymous Logon— a well-known security principal that refers to anonymous users, as shown below:

Get-SendConnector "Connector Name" | Remove-ADPermission -AccessRight ExtendedRight -ExtendedRights "ms-Exch-Send-Headers-Routing" -user "NT AUTHORITY\Anonymous Logon"

What's your take?
Does your organization remove internal Received headers? What are the reasons cited? Does removing internal received headers make your organization more secure? Feel free to leave a comment and share your opinion about this.

PWN to OWN Contest: Vista gets compromised

Update on the PWN to OWN contest at the CanSecWest conference. After the MacBook Air got compromised in 2 minutes, Shane Macaulay claimed victory over the Fujitsu laptop running Windows Vista. Yes, Windows Vista was compromised at the tail end of Day 2, at 7:30 p.m., thanks to a vulnerability in Adobe Flash.

More in PWN to OWN: Final Day (and another winner!) on TippingPoint.

The list of conference sponsors includes both Adobe and Microsoft.

Mac, meet PC: PC, the Mac's already hacked!

The Event: CanSecWest's PWN 2 OWN contest, Vancouver, Canada
The Contenders: Mac OS X Leopard, Microsoft's Windows Vista, and Linux.
The Challenge: Compromise the OS
The Prize: $10,000 + laptop
The Winner: Charlie Miller

Apparently, the OS that's safer by design is the first to get compromised, after the rules were relaxed a little bit. 2 minutes is all it took, according to a report in InfoWorld (yes, still one of my favorite tech news sources). Excerpt:

Contest rules state that Miller could only take advantage of software that was pre-installed on the Mac, so the flaw he exploited must have been accessible, or possibly inside, Apple's Safari browser.

And:

Shane Macaulay, who was Dai Zovi's co-winner last year, spent much of Thursday trying to hack into the Fujitsu Vista laptop, at one point rushing back to his Vancouver area home to retrieve a file that he thought might help him hack into the system.

But it was all in vain.

More in Gone in 2 minutes: Mac gets hacked first in contest on InfoWorld.com.

This comes little over a week after Apple released what is labeled a massive patch, a monster patch, a mega-update, or a mega-monster security update by the media (Yes, that makes me feel like Jon Stewart now). The patch contains 90 fixes according to these reports.

Last year's contest winner, Dino Dai Zovi, exploited a vulnerability in Apple's QuickTime to take home the prize.

Gloat not, Windows Vista and Linux. You are expected to be hacked by today— and when that happens, it will be further proof that vulnerabilities exist in all systems. That's the nature of software. When it comes to millions of lines of code, "bug-free" and "vulnerability-free" software is a myth. What really matters is how easily these can be exploited, how quickly the vendor responds and releases patches to fix vulnerabilities.

As far as Windows Vista is concerned, it has an enviable track record so far.

India wants access to BlackBerry encryption algorithms to fight terrorism

India's half a million BlackBerry users may have to live with the prospect of the Indian government having easy access to their wireless communication.

India says it needs access to RIM's encryption algorithms, used to encrypt email sent and received by BlackBerry smartphones, to fight terrorism. The Indian government is delaying a license to offer BlackBerry services to wireless carrier Tata Teleservices, and may cancel the licenses already issued to other Indian wireless carriers— Vodafone Essar, Bharti Telecom and Reliance Communications, if RIM doesn't comply by March 31st. The Information Technology Act of 2000 provides the government of India the right to intercept electronic communications for security reasons.

It's no secret that terrorists are increasingly using the internet and email to communicate. Bringing BlackBerry handhelds under the scope of lawful interception shouldn't come as a big surprise, but it does pose interesting questions for RIM.

The Department of Telecom's intent and its notice to carriers is anything but abrupt. The DoT had requested access some time last year. The March 31st deadline is an extension to the earlier deadline of December 31st. DoT officials are meeting with carrier execs and RIM officials to resolve the issue.

More in "BlackBerry under security scrutiny in India" on washingtonpost.com.

What makes the whole episode more interesting are reports that the Indian government wants significantly weaker encryption keys to be used across the board. If true, this could make security of online banking and e-commerce transactions questionable, and may even pose threats to India's growing outsourcing sector. ISP Association of India President Rajesh Chharia says "Routine check-ups are fine with us since the issue is one of national security. All ISPs must, and will, cooperate. What is of concern, though, is the fact that we have been asked to reduce the encryption from 128-bit to 40-bit, which is ridiculous.” (More in "BlackBerry security issue makes e-com insecure").

As similar incidents involving India's bureaucracy have proven in the past, better sense does eventually prevail in India (Read previous post: "Update: India blocks access to blogs"), but not before giving massive doses of anxiety attacks to those concerned.

HOW TO: Delegate recipient administration for an OU

Exchange Server 2007 allows easier delegation of administration responsibilities, based on the following predefined administration roles:
1) Exchange Organization Administrator
2) Exchange Server Administrator
3) Exchange Recipient Administrator
4) Exchange Public Folder Administrator and
5) Exchange View Only Administrator.


Figure 1: Exchange Server 2007 allows delegation of administrative responsibilities

The delegation wizard in the EMC allows you to delegate the Recipient Administrator role for the entire Organization, but doesn't allow more granular delegation at the Domain or OU level.

More about the Exchange Recipient Administrator role

Security principals that have the Exchange Recipient Administrator role delegated get membership of the Exchange View Only Administrators role. Additionally, they are assigned:
- Read access to all the Domain Users containers in AD (in domains where Setup /DomainPrep has been run)
- Write access to all the Exchange-specific attributes in those domains

When delegating the Exchange Recipient Administrator role using the Exchange console or the Add-ExchangeAdministrator command in the Exchange shell, all you're doing is adding the security principal (user/group) to Exchange Recipient Administrators, a (Universal) Security Group in the Microsoft Exchange Security container in AD.

For more details about Exchange Server 2007 permissions, refer to "Configuring Permissions in Exchange Server 2007".

Here's how you can delegate recipient administration for an OU.
Exchange Organization: E12Labs
Domain: E12Labs.com (DC=E12Labs,DC=com)
OU: San Francisco (OU=San Francisco,DC=E12Labs,DC=com)
User: foo (Best Practice: Assign permissions to Security Groups)

Allow generic read permission for objects in the OU:

Add-ADPermission -Identity "ou=San Francisco,dc=E12Labs,dc=com" -User "E12Labs\foo" -AccessRights GenericRead

Allow ReadProperty and WriteProperty permissions on Exchange-related attributes for objects in the OU

Add-ADPermission –Identity "ou=San Francisco,dc=E12Labs,dc=com" –User "E12Labs\foo" -AccessRights ReadProperty, WriteProperty -Properties Exchange-Information, Exchange-Personal-Information, legacyExchangeDN, displayName, adminDisplayName, displayNamePrintable, publicDelegates, garbageCollPeriod, textEncodedORAddress, showInAddressBook, proxyAddresses, mail

Property Sets in Active Directory

Exchange-Information and Exchange-Personal-Information are property sets - a number of related properties grouped together. Assigning permissions on a property set results in a single ACE in DACLS, making them much smaller and faster to process.

Exchange Server 2003 adds Exchange attributes to the Public Information and Private Information property sets that exist in Active Directory.

Exchange Server 2007 does not rely on these existing AD property sets, but creates 2 of its own. If deploying in an existing Exchange 2003 Forest, Exchange Server 2007 removes the Exchange properties added to the AD property sets and adds them to the new Exchange 2007 property sets. The Exchange-Information property set has 105 properties. Exchange-Personal-Information has 7. More information about the Exchange Server 2007 property sets and which properties are included in them can be found in "Property Sets in Exchange 2007".

Allow creation and management of Dynamic Distribution Groups in the OU
Exchange Server 2007 RTM:

Add-ADPermission -Identity "ou=San Francisco,dc=E12Labs,dc=com" -User "E12Labs\foo" -AccessRights GenericAll –InheritanceType Descendents -InheritedObjectType msExchDynamicDistributionList

Add-ADPermission -Identity "ou=San Francisco,dc=E12Labs,dc=com" -User "E12Labs\foo" -AccessRights CreateChild, DeleteChild -ChildObjectTypes msExchDynamicDistributionList

Exchange Server 2007 SP1:

Add-ADPermission -Identity "ou=San Francisco,dc=E12Labs,dc=com" -User "E12Labs\foo" -AccessRights CreateChild, DeleteChild -ChildObjectTypes msExchDynamicDistributionList

Allow permission to access RUS:

Add-ADPermission -Identity "CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=E12Labs,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=E12Labs,DC=com" -User "E12labs\foo" -InheritedObjectType ms-Exch-Exchange-Server -ExtendedRights ms-Exch-Recipient-Update-Access -InheritanceType Descendents

Allow permission to update Address Lists and Email Address Policies:

Add-ADPermission –Identity "CN=Address Lists Container,CN=E12Labs,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=E12Labs,DC=com" –User "E12Labs\foo" -AccessRights WriteProperty -Properties msExchLastAppliedRecipientFilter, msExchRecipientFilterFlags

Add-ADPermission –Identity "CN=Recipient Policies,CN=E12Labs,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=E12Labs,DC=com" –User "E12Labs\foo" -AccessRights WriteProperty -Properties msExchLastAppliedRecipientFilter, msExchRecipientFilterFlags

In addition to these Active Directory permissions, recipient administrators also need Exchange View Only Administrator permission on the Exchange Organization. Use the following command to assign it:

Add-ExchangeAdministrator "E12Labs\foo" -Role ViewOnlyAdmin

A script for SP1: If you're on Exchange Server 2007 SP1, a script written by Ross Smith IV makes delegating recipient administration permissions on an OU a simple task accomplished quickly (No, it's not for Exchange Server 2007 RTM). The script - ConfigureSplitPerms.ps1, resides in the \Scripts folder in the Exchange Server install path. Usage:

.\ConfigureSplitPerms.ps1 -user "MyDomain\foo" -identity "OU=San Francisco,DC=ExchangeLabs,DC=net"

InfoWorld's campaign to "Save Windows XP"

I've been an avid reader of InfoWorld for as long as I can remember. It is one of the finest trade publications out there. In case you've missed it, they've been running an online campaign to "save Windows XP". A few weeks ago, they announced that 75,000 XP users had signed up for it (Read "75,000 demand Microsoft keep Windows XP going"). If you look at the numbers, it's a tiny fraction of the overall number of Windows XP users.
Update: The last update from InfoWorld is dated Feb. 28th- the number reported is 97,280.

InfoWorld says its readers want Microsoft to keep selling and supporting Windows XP indefinitely. Given that Windows XP was released back in 2001 - almost 7 years ago, is Microsoft wrong in ending support for a product that has certainly lived past its shelf life? If you work in the software industry, dealing with today's rapid-fire software releases, it's hard to imagine supporting something that old!

From Save Windows XP! The clock is ticking:

Millions of us have grown comfortable with XP and don't see a need to change to Vista. It's like having a comfortable apartment that you've enjoyed coming home to for years, only to get an eviction notice. The thought of moving to a new place -- even with the stainless steel appliances, granite countertops, and maple cabinets (or is cherry in this year?) -- just doesn't sit right. Maybe it'll be more modern, but it will also cost more and likely not be as good a fit. And you don't have any other reason to move.

Reading the above, you get the impression that somehow Microsoft can and is actually forcing existing users of Windows XP to stop using that OS past June 30th, 2008. That is completely untrue! All Microsoft is saying is - this product has reached its end of life, and we will stop selling it by that date. It really has no impact on existing users who want to continue using it.

The fact is: your licensed copy of Windows XP doesn't come with an expiration date.

If you have an XP license today, or buy one by that date, you can install it on any computer you buy two, five, ten, or any number of years from now, provided the hardware is compatible. This does not apply to OEM licenses sold to computer manufacturers like Dell, HP, or Gateway - which are tied to the computer they ship with.

Microsoft's Windows Lifecycle Policy: Selling Windows, And Supporting It

Microsoft's Windows Life-Cycle Policy states that:
- Direct OEM and retail licenses will be sold till June 30th, 2008.
- System Builder licenses will be available till January 31st, 2009.
- The policy further states that "licenses will continue to be available through downgrade rights available in Volume Licensing programs after end of general availability".

Though Microsoft will stop selling Windows XP based on the above timeline, support for the operating system isn't going to end when that happens. Microsoft Support Lifecycle explains Microsoft's support policies, including what mainstream and extended support mean. According to the Microsoft Support Lifecycle for Windows XP:
- Mainstream support will end on April 14th, 2009.
- Extended support will be available for five years from that date, till April 8th, 2014!

For a product with General Availability dating back to December 31, 2001, Windows XP doesn't seem like a product that's being retired prematurely.

On a second look, InfoWorld's case isn't so much for Windows XP, as it is against Windows Vista. Running alongside the Save Windows XP articles: Why people hate Vista and Time to dump Windows?.
Update: To be fair to InfoWorld, they've also recently published "How to deploy Windows Vista".

A quick look at some of the arguments against Windows Vista:

Vista a resource hog? Yes, Windows Vista requires more resources - and the last time I looked around, today's PC hardware was more than adequately equipped for Vista. Most decently-configured laptops, including the entry-level ones that sell for way under a thousand bucks, ship with dual-core processors and 2 Gigs of RAM. And under a thousand bucks get you what can be considered a state-of-the-art quad-core desktop with 3-4 gigs of RAM. In fact, a few weeks ago I was pleasantly surprised by the price of 4 Gigs of RAM for my laptop - $79!

Vista isn't designed to run on yesterday's hardware, and there's no reason for Microsoft to be apologetic about it. It's the same hardware + OS + apps purchase cycles we've been used to for a long time now. What do you want to buy the next time your three or five-year-old computer dies, or you simply get fed up with it and want something new? Do you look for a single-core Pentium 4 processor that can run Windows XP well - assuming you can find one? (As a sidenote, I'm writing this on a single-core Pentium 4 box running Windows Vista, and doing fine, thank you! I also had a 400-Mhz (yes, Mhz... ) PIII box with all of 256 Mb RAM running Windows Server 2003, AD, and Exchange Server 2003 for years, till it died last year.)

It's the same cycle as buying microwaves or vacuum cleaners - they get old, stop working, or simply get in the way and impair users' productivity. When that happens, you go out and buy a new one, generally in the same price range or perhaps a little cheaper, but something that has all (or most of) the bells and whistles - the right stickers, logos, and features that a contemporary microwave or vacuum cleaner would have.

PCs are no different. In fact, thanks to Murphy's Law and the underlying technology breakthroughs, we generally get a lot more bang for our buck with every upgrade cycle.

If your microwave/vacuum cleaner/PC isn't broken yet (or more importantly, if you aren't fed up with it, and it isn't getting in your way), there's really no reason to buy a new one. Unless you like buying new computers every couple of years, or sooner, and can afford to do so.

Drivers: Yes, drivers. Somehow Microsoft is to blame for the perceived lack of drivers. Personally, I haven't come across any piece of hardware recently - a display card, printer, or other peripheral that does not sport a driver for Windows Vista, or otherwise caused any compatibility issues. For most part, everything works out of the box.

Security: Security, you say. Seems like Windows Vista has proved its credentials on that front. Agreed, UAC can be a little annoying at times, and gives Apple a great talking point for its commercials, but that doesn't take away from the fact that Vista is a much more secure OS than Windows XP ever was. In fact, Vista does very well on this front compared to other OSes, including Apple's. Read previous post about the 6-month vulnerability report "Numbers talk: Vista most secure OS of all?", or grab the more current one-year vulnerability report.

User Account Control

It is easy to criticize the UAC feature without getting a good understanding of what it does and the problem it's intended to solve for IT departments. After years of extolling the virtues of not logging on using an account with administrator privileges for day-to-day stuff, I love UAC! It ensures administrator privileges are not available to your session all the time - even if you're logged in as an administrator. Not only does this protect computers from malicious code, it also protects users from themselves. When you do need to perform a task that requires administrator privileges, you are prompted for it.

Security has a cost - often measured in user inconvenience. Many security products and features come with some inconvenience to users. The argument shouldn't be about whether to have UAC, but about the ability to fine-tune it to an organization's security requirements. Arguably, this could be refined further to allow more granular control, but being aware of the options already available, including the ability to turn it off using Group or Local Policies helps.

The following graph from the one-year vulnerability report shows vulnerabilities found in Windows Vista, Windows XP, Red Hat Linux, Ubuntu, and OS X in the first year of release. It's clear what the numbers reveal, though many of us often tend to get more influenced by anecdotal evidence- particularly in this context.


Figure 1: Vulnerabilities found in Windows Vista in the first year of its release compared to other operating systems

Vista is slow: One of the more common arguments against Vista, slow is a relative term. Slow as compared to what? Running on the same hardware as my Windows XP computer, performing the same tasks, I haven't noticed this slowness. If you benchmark performance results, Vista can be proven to be slower than anything. The questions to ask: - When was the test conducted? What version of Vista? What kind of hardware? What kind of applications? And more importantly, how slow was it really?

Yes, you may lose a few percentage points in performance, but there are gains in usability and new features.

I wouldn't blame InfoWorld for wanting to ride the "Bash Vista" bandwagon - it's fashionable to do so. To our relief, there are some saner voices out there. Like InfoWorld's own columnist, J. Peter Bruzzese. Peter writes in his Enterprise Windows column - titled "Save XP? Why bother?":

The fact of the matter is, Vista is incredible. I've been working with it since Beta 3, and I won't return to that cartoon-looking XP for anything. Not only is it more secure than XP, it includes a host of invaluable new tools and applications (more on those in a bit).

Yes, Vista is more resource-intensive than XP. Yes, upgrading from XP to Vista requires putting some cash on the table. But Vista beats XP hands down, and the Save XP campaign amounts to unfairly criticizing Microsoft for adhering to a core capitalist practice: retiring an old product to sell newer, better ones.

That "yucky Windows"

My 4-year old son agrees with Peter's assessment about XP. For the few days that I had a loaner Media Center PC running Vista, not only did the little one get quite comfortable with it, he fell in love with it. When it was time to get my XP Media Center PC back from repairs, there were angry protests about having to deal with the "yucky Windows" (that would be XP!) that one doesn't ordinarily associate with someone his age.

Though a lot of it has to do with the aesthetics - the "X button that glows" when he wants to close a window and Gadgets that expand his vocabulary - isn't the UI and usability a big reason why we choose to use Windows and the exact topic Apple can't stop talking about when it comes to OS X?


Figure 2: Windows Vista's Media Center interface

I finally upgraded the box - the last one I had with Windows XP, to Windows Vista on the last day of 2007. The delay was in large part because of the vendor - name withheld, mislabeled the TV tuner driver, causing a lot of confusion amongst its customers.

As a sidenote to this sidenote, Media Center is probably the most mission-critical app of all, as far as end-users/home users are concerned... an email outage at work is probably something you can survive and live to tell the tale. A "TV outage" at home is an event unmatched in its criticality, perhaps deserving a designation higher than P1/S1.

What kind of supporters is InfoWorld touting with its Save XP campaign? Let's turn again to Peter's column:

If you read a lot of the comments that people have been adding on the Save XP pages, you might note that an awful lot of people say, "Go to Linux," or "That's why I use Linux." You know, I've never heard a Mac user complain about Apple or their Mac, nor a Linux user complain about Red Hat or whatever version they are using. That's not to say they don't have problems; they just keep the discussion among themselves. But they are having a field day watching Microsoft users fight each other. Ever think they're the ones stirring up this whole Save XP campaign?

Come on InfoWorld, it's time to give up the skepticism, and that childish campaign. Users are moving to and using Windows Vista, and that will only accelerate going forward, now that SP1 is here. Users and organizations who want to continue using Windows XP can take their own time to upgrade - Windows XP will still be available for the foreseeable future, and supported for a much longer period (as stated in Microsoft's product lifecycle policies referenced in this post).

HOW TO: List mailboxes with Full Mailbox Access permission assigned

In "HOW TO: Grant Full Mailbox Access permission", we saw how to assign and view mailbox permissions, including Full Mailbox Access. Here's how you can get a list of mailboxes with explicitly-assigned (i.e. not inherited) Full Mailbox Access permissions.

Instead of running this against all mailboxes in the Organization, it makes sense to filter it against a sub-set of mailboxes.

Filtering mailboxes returned by Get-Mailbox

Mailboxes returned by the Get-Mailbox command can be filtered using -Server, -Database, -RecipientTypeDetails, and -OrganizationalUnit parameters. Note, the -Filter parameter can also be used and allows granular filtering of mailboxes that are returned, based on a number of filterable properties.

In this example, we use the -Server parameter to filter mailboxes on a particular server, and pipe it to the Get-MailboxPermission command:

Get-Mailbox -Server "e12postcard" | Get-MailboxPermission

This produces a long list of permissions - inherited and assigned explicitly to the mailbox(es).

Let's filter the above to reveal only the explicitly assigned permissions:

Get-Mailbox -Server "e12postcard" | Get-MailboxPermission | where { $_.IsInherited -eq $false }

The output shows all explicitly-assigned permissions, including the permissions assigned to the mailbox owner (NT AUTHORITY\SELF). Not quite what we want! Let's filter that out:

Get-Mailbox -Server "e12postcard" | Get-MailboxPermission | where { ($_.IsInherited -eq $false) -and -not ($_.User -like "NT AUTHORITY\SELF") }

Now we have a list of all mailboxes with explicitly assigned permissions.

We can filter this further to list only the ones that have Full Mailbox Access permission assigned:

Get-Mailbox -Server "e12postcard" | Get-MailboxPermission | where { ($_.AccessRights -eq "FullAccess") -and ($_.IsInherited -eq $false) -and -not ($_.User -like "NT AUTHORITY\SELF") }

Similarly, you can filter users that have other mailbox permissions assigned, such as SendAs, DeleteItem, ReadPermission, ChangePermission, ChangeOwner, or ExternalAccount.

List users with SendAs permission assigned
The following code lists mailboxes with the SendAs permission assigned. Unlike FullAccess mailbox permission, SendAs is an Active Directory permission.

Get-Mailbox -ResultSize unlimited | Get-ADPermissions | Where {$_.ExtendedRights -like "Send-As" -and $_.User -notlike "NT AUTHORIT\SELF" -and $_.Deny -eq $false} | ft Identity,User,IsInherited -AutoSize

Related Posts:
- HOW TO: Grant Full Mailbox Access permission
- HOW TO: Assign SendAs right using Exchange shell

Exchange Server 2007: Renewing the self-signed certificate

Exchange Server 2007 issues itself a self-signed certificate for use with services like SMTP, IMAP, POP, IIS and UM. The certificate is issued for a period of one year.

The self-signed certificate meets an important need - securing communication for Exchange services by default. Nevertheless, one should treat these self-signed certificates as temporary. It's not recommended to use these for any client communication on an ongoing basis. For most deployments, you will end up procuring a certificate from a trusted 3rd-party CA (or perhaps an internal CA in organizations with PKI deployed).

However, should you decide to leave the self-signed certificate(s) on some servers and continue to use them, these need to be renewed - just as you would renew certificates from 3rd-party or in-house CAs.

 To renew the certificate for server e12postcard.e12labs.com, a server with CAS and HT roles installed:

Get-ExchangeCertificate -domain "e12postcard.e12labs.com" | fl

Note the services the certificate is enabled for (by default: POP, IMAP, IIS, SMTP on CAS + HT servers). Copy the thumbprint of the certificate.

Get a new certificate with a new expiration date:

Get-ExchangeCertificate -thumbprint "C5DD5B60949267AD624618D8492C4C5281FDD10F" | New-ExchangeCertificate

If the existing certificate is being used for SMTP, you will get the following prompt:

Confirm
Overwrite existing default SMTP certificate,
'C5DD5B60949267AD624618D8492C4C5281FDD10F' (expires 8/22/2008 7:20:34 AM), with certificate '3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E' (expires 1/28/2009 7:37:31 AM)?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is "Y"):

Type y to continue. A new certificate is generated.

Thumbprint   Services   Subject
----------   --------   -------
3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E   .....   CN=E12Postcard

The new certificate is generated and enabled. Examine the new certificate:

Get-ExchangeCertificate -thumbprint "3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E" | fl

 The old certificate is enabled for IIS, POP, IMAP and SMTP. The new certificate generated using the above command is enabled only for POP, IMAP and SMTP - IIS is missing.

To enable the certificate for IIS:

Enable-ExchangeCertificate -thumbprint "3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E" -services IIS

This enables the certificate for IIS (in addition to any other services it may already be enabled for - it adds to existing values of the services property).

 Test services are working with the new certificate. If it works as expected, the old certificate can be removed:

Remove-ExchangeCertificate -thumbprint "C5DD5B60949267AD624618D8492C4C5281FDD10F"

Related posts:
- Outlook Anywhere and Exchange's Self-Signed Certificate
- Which name should I use as Common Name for my UC certificate?
- DigiCert: A Certificate Authority with excellent customer service

SMTP Connector Myth: Messages are always routed over SMTP Connectors with more specific address spaces

An Exchange Server message routing myth forever being propagated (including by me!):

If 2 SMTP Connectors (or Send Connectors in case of Exchange Server 2007) exist, one with a more specific address space, like exchangepedia.com, and one for a more generic address space like *, messages are always routed over the Connector with the more specific address space.

Now, generally that rule of thumb works for most purposes, until you consider restrictions on Connectors. These include:
Connector Scope: (Entire) Organization, or the Routing Group (to which the Connector belongs or is homed to)
Message Size restrictions: To prevent messages over a certain size from being routed over a Connector
Delivery Restrictions: To allow/prevent messages from particular senders from being routed over a Connector (Exchange Server 2003/2000)


Figure 1: Content Restrictions on a SMTP Connector, including message size limit

Scenario:
You want to prevent users from sending messages over 100 Kb to exchangepedia.com.
- Connector1 for address space exchangepedia.com, message size restriction of 100Kb.
- Connector2 for address space *, no message size restrictions.
Result:
- Messages for exchangepedia.com recipients with a message size that is under the 100kb limit are routed over Connector1.
- Messages for exchangepedia.com recipients with a message size of over 100kb are routed over Connector2 with the generic address space of *. Connector1 with more specific address space of exchangepedia.com is never considered.

If you want to limit messages sent to exchangepedia.com to only 100kb, you cannot do it using the configuration in the above scenario.

From Exchange Server 2007 documentation:
Routing to External Domains -> Selecting the Routing Path to an External Recipient):

If more than one Send connector is configured to have an address space that meets the routing requirements for an external recipient, Exchange 2007 routing will select a single connector through which to route the message. The selected connector must meet the message size constraints. After Exchange 2007 has eliminated all connectors that have prohibitive message size restrictions, routing applies the following criteria to determine to which connector it will route:

From the list of all Send connectors and foreign connectors that are configured in the Exchange organization, it narrows the list to connectors that satisfy all the following criteria:

- In the scope for the local server
- Enabled
- With an address space that matches the recipient's e-mail domain

From the resulting list, select the connector with the most specific address space match. No matching connectors may be found.

Maybe an Exchange Server 2007 change, you wonder. Not quiet - Exchange Server 2003 behaves similarly.

From Exchange Server 2003 documentation:
Exchange Server 2003 Message Routing -> Routing Path Selection Process

It determines all connectors to the message destination in the organization topology, and then analyzes message characteristics and connector restrictions to exclude all those connectors that must not be used to transfer the message.

In a nutshell: Connector selection happens after restrictions are checked.

Which Connector? Determining the Send Connector used in Exchange Server 2007 is quiet easy - if using different fqdns on a Send Connector, you can simply check the Received headers; or you can look at the SMTP logs (read previous post "Exchange Server 2007: Logging SMTP Protocol Activity"). In Exchange Server 2003, you can bump up the diagnostics logging on MSExchangeTransport -> Routing Engine/Service. Exchange logs Event ID 984, which provides details about message routing, including the Connector selected.

In the following screenshots, we see 2 different SMTP Connectors being selected for 2 messages to the same destination - the smaller message uses the Connector with the specific address space - exchangepedia.com, which routes the message to a smarthost. The larger message that exceeds that Connector's message size limit is routed using the Connector for address space *, which routes the message using DNS to lookup the MX record(s) for exchangepedia.com.


Figure 2: With Diagnostics Logging enabled, Exchange Server 2003 logs Event ID 984, which shows Connector selected (for a small message under 100kb in this case). The message is delivered to the Smarthost specified in the Connector.


Figure 3: Event ID 984 shows the Connector for generic address space * selected for a larger message (over 100kb in this case). Message is delivered using DNS lookup.

Unintended consequences? The implications aren't pretty, specially when you consider scenarios where one uses a SMTP Connector for a particular address space to enforce TLS (perhaps one of the biggest reasons why messages should never be routed over a Connector with a generic address space if a Connector for a specific address space exists). If I enforce message size restrictions on my Connector with TLS enabled, larger messages can and will be transmitted using the generic Connector that does not use TLS. Now we have the larger message(s) traveling over potentially unsecured SMTP sessions.

What about Delivery Restrictions? For Exchange Server 2003, the same is true for Delivery Restrictions. If the Connector for exchangepedia.com has Delivery Restrictions to prevent Joe Adams from sending messages to Exchangepedia, the message routes over the generic Connector for * - effectively flushing such restrictions down the tube. Restrictions on Connectors with more generic address space are a different story - if Joe has Delivery Restrictions on the * Connector, he cannot send internet mail.

The first task of the Routing Engine/transport should be to check if Connectors with more specific address spaces are available. If it finds any, there is no reason to exclude these from the routing decision. Any restrictions on that Connector exist for a purpose - to restrict message sizes, or to prevent certain users from sending to particular domains using Delivery Restrictions. By excluding Connectors with restrictions from the routing calculation, we're saying routing the message is more important than enforcing those restrictions. As a result, by routing the message over generic Connectors, other requirements for mail delivery to that address space, such as those mentioned above and other available Connector settings, may not be applied.

Related Posts:
- HOW TO: Prevent a user from sending and receiving internet mail
- Exchange Server 2007: Setting Message Size Limits
- Masquerading SMTP Virtual Servers: Changing the fqdn and masquerade domain

Schwartz: Zero tolerance for zero retention

On the first anniversary of the Federal Rules for Civil Procedure (PDF), which provide guidelines for e-discovery, InfoWorld editor Ephraim Schwartz discusses the implications in his Reality Check column. Read more in "Zero tolerance for zero retention".

Released: ForeFront Security for Exchange SP1

ForeFront Security for Exchange SP1 follows Exchange Server 2007 SP1 out the door. FSE SP1 is compatible with Exchange Server 2007 SP1. It includes support for Windows Server 2008, IPv6, and improved content filtering.

Exchange Server 2007 SP1 and ForeFront Security for Exchange

- Before you upgrade Exchange Server 2007 to SP1, make sure you either upgrade ForeFront Security for Exchange to SP1, or uninstall it.
- If ForeFront Security for Exchange is upgraded to SP1, you must stop all ForeFront services before upgrading Exchange Server 2007 to SP1.

Download it here.

220 Welcome to a California mail server: Fighting spam with SMTP Banners

If you are interested in messaging and fighting spam, you probably watch the legal response to spam with some interest. Given the nature of email and the art of remaining anonymous or otherwise untraceable that spammers seem to have mastered, anti-spam laws were written off as largely ineffective, or even ridiculous. (The FTC begs to differ, in its report to Congress on the CAN-SPAM Act's effectiveness - PDF available here). Legislation and (its) enforcement can never be the sole approach to a problem mostly attributed to technology.

The much-talked about first conviction under the federal CAN-SPAM Act was handed out in California - to Nicholas Tombros in Los Angeles in 2004. Since then, quite a few spammers have had their date with the law, with the accompanying media brouhaha.

California anti-spam laws: California also has its own antispam laws - enacted as amendments to the Business and Professions Code. The rather lame one - Section 17538.4, allows California Attorney General to sue spammers, with a list of IFs that make it more like a "License To Spam". Section 17538.45 is the one of interest, aimed at protecting email service providers from spammers. Email service providers can file civil suits against spammers and claim greater of the following amounts:
- the actual monetary loss suffered by reason of that violation
- liquidated damages of $50 per message initiated or delivered, up to a maximum of $25,000 per day.

Any organization that provides the ability to send or receive email to registered users through equipment located in California (and is an "intermediary" in sending/receiving email) is an email service provider for the purpose of this law.

Interesting, as technology-related legislative action always is.

If your mail servers are located in California (and even if they are not... ), it makes sense to change the SMTP banner (SMTP 220 response) to give notice to a sender that your system should not be used to send unsolicited electronic mail advertisements.

The California Business and Professions Code Section 17538.45 states:

(3) (A) In any action brought pursuant to paragraph (1), the electronic mail service provider shall be required to establish as an element of its cause of action that prior to the alleged violation, the defendant had actual notice of both of the following:

(i) The electronic mail service provider's policy on unsolicited electronic mail advertising.

(ii) The fact that the defendant's unsolicited electronic mail advertisements would use or cause to be used the electronic mail service provider's equipment located in this state.

(B) In this regard, the Legislature finds that with rapid advances in Internet technology, and electronic mail technology in particular, Internet service providers are already experimenting with embedding policy statements directly into the software running on the computers used to provide electronic mail services in a manner that displays the policy statements every time an electronic mail delivery is requested. While the state of the technology does not support this finding at present, the Legislature believes that, in a given case at some future date, a showing that notice was supplied via electronic means between the sending and receiving computers could be held to constitute actual notice to the sender for purposes of this paragraph.

Let's leave the legal interpretation of laws to those who practice law. Regardless of whether your organization intends to take legal action against spammers or not, one of the important principles of information security is having policies in place and communicating them clearly. Not only does it demonstrate your organization's intent, it can be a potential deterrent for folks who may otherwise claim ignorance of such policies.

(While we're on the subject of SMTP banners, for historical context, also take a look at Paul Hobbes & John Levine's draft from 1998 titled "Anti-UBE and Anti-UCE Keywords in SMTP Banners". Much later, a SMTP extension was also proposed to include such information - RFC 3865 - A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension.)

Changing the SMTP banner: Assuming the policy is in place, the SMTP banner can be changed easily to communicate it, as hosted email security and compliance services provider Postini (acquired by Google not too long ago) does.

220 Postini ESMTP 11 y6_12_2c0 ready. California Business and Professions Code Section 17538.45 forbids use of this system for unsolicited electronic mail advertisements.

On Exchange Server 2003/2000 or if using Windows Server's SMTP service component on SMTP gateways, the banner text can be changed by setting the IIS Metabase value ConnectResponse, using any Metabase editor or the adsutil.vbs script that ships with IIS (in the Inetpub\AdminScripts directory by default).

cscript adsutil.vbs set smtpsvc/1/ConnectResponse "220 California Business and Professions Code Section 17538.45 forbids use of this system for unsolicited electronic mail advertisements."

Note, the numeric value 1 after smtpsvc/ in the above command refers to the SMTP Virtual Server ID. Each SMTP VS has one, the default/first one starting at 1. To get a list of SMTP Virtual Servers using adsutil.vbs:
adsutil.vbs enum /p smtpsvc

Exchange Server 2007 makes changing the banner a relatively simple task. Note, the banner should start with the SMTP response code 220. Fire up the shell:

Set-ReceiveConnector "Connector Name" -banner "220 (Optional: Server.domain.com). California Business and Professions Code Section 17538.45 forbids use of this system for unsolicited electronic mail advertisements."

That wasn't too difficult, was it? If that simple banner change deters a a single spammer from victimizing your users, and in the process buys you the legal ammunition (that may some day help your organization take legal action, should it decide to.... ), is it worth it?

HOW TO: Hide Distribution Group membership

Exchange Server 2003's ADUC extensions made hiding a Distribution Group's membership a trivial task, accomplished by right-clicking a group, selecting Exchange Tasks and selecting Hide Membership.


Figure 1: The Exchange Tasks wizard in ADUC provides an option to hide Distribution Group membership in Exchange Server 2003

As the task suggests, it hides the group's membership in Outlook Address Book/GAL. It also prevents users from clicking the + link that appears before a Distribution Group when composing a new message, and expanding the group so messages are sent individually to all members rather than the DG.


Figure 2: Distribution Groups that have their membership hidden cannot be expanded in Microsoft Outlook

The Hide Membership task available from Exchange Tasks denies Read Property permission for the Members attribute, to the Everyone group. This also prevents Administrators trying to manage the group from seeing the group's members.


Figure 3: Hiding a Distribution Group makes changes to the Distribution Group's ACL

Hiding Distribution Group membership in Exchange Server 2007

Hiding Distribution Group membership is not supported in Exchange Server 2007. There is no option to hide Distribution Group membership in the console, nor a single parameter you can flip using the shell.

Nevertheless, you can prevent users from expanding the group in Microsoft Outlook, and hide the group's Member attribute so it's not visible in the properties pages in Outlook or OWA. The caveat - it's not a way to hide membership completely, as noted later in the post.

Adding Deny ACE for the Members property

Use the following command to deny the ReadProperty permission for the Distribution Group's Members property to a particular user or Security Group (Remember the security best practice - add users to Security Group -> assign permissions to Security Group?):

Add-ADPermission "Distribution Group Name" -user "User or Security Group Name" -Deny -AccessRights ReadProperty -Properties Member

Note, to simulate what Exchange Server 2003's Hide Membership task does, you can use the Everyone group in the -users parameter. This hides membership from the EMC as well, but the shell can still show membership using the Get-DistributionGroupMember command.

Once the permission is added, clicking on the + link in Microsoft Outlook produces the following not-so-descriptive error message, and the user is prevented from expanding the Distribution Group.


Figure 4: With the Deny ACE in place, Outlook users get an error when trying to expand the Distribution Group. Click here to see a larger image

Additionally, membership of the group is not revealed in the group's properties in the Address Book/GAL.

Adding Deny ACE using the GUI

If you've already used the shell to add the deny ACE, you can skip the following procedure and head to the next section.

For the console/GUI fans amongst us or those who simply haven't developed an intimate relationship with the shell (hopefully the following will make you a convert... :), ADSIEdit is your friend. Fire it up:

1. Navigate to the Distribution Group's properties
2. Select the Security tab
3. Click Add
4. Select the user or group you want to deny permission to (you can use the Everyone group to simulate what Exchange Server 2003 does)
5. Click OK
6. click Advanced (wait... ) to open Advanced Security Settings
7. Select the Permissions tab
8. Select the user or group if not already selected
9. Click Edit to open the Permissions Entry properties for the selected user/group
10. Select Properties tab
11. Click on the "Deny" checkbox for the Read Members property so it is checked.
12. Click OK to close the Permissions pages.
13. Click OK to close the Advanced Security Settings pages
14. Click OK to close the Properties dialog box

Inspecting any non-inherited permissions and removing the Deny ACE

To determine any modifications to the AD permissions for the Members property:

Get-ADPermission "Distribution Group Name" | where {$_.Properties -like "member"} | fl

To remove the Deny permission on the Member property for a Distribution Group, use the Remove-ADPermission command:

Remove-ADPermission "Distribution Group Name" -user "User/Security Group Name" -Deny -AccessRights ReadProperty -Properties Member

Prevent Delivery Reports from Distribution Group

Users can send a message to the Distribution Group with a Delivery Report requested, which can reveal the group membership.

To prevent a Delivery Report from being sent to the originator (consider this carefully, you may want senders to receive delivery reports if messages are not delivered to members of certain Distribution Groups. You can also enable delivery reports to the group Manager only.), use the following command:

Set-DistributionGroup "Distribution Group Name" -ReportToOriginatorEnabled $false

Once this is done, Exchange simply sends a Distributtion Group expanded/delivered to DG message in the Delivery Report, if one is requested, without revealing the group's members.


Figure 5: Preventing Delivery Reports to originator returns a "delivered to DG" message when Delivery Reports are requested

Hiding group membership in OWA

Membership of the Distribution Group can be viewed in OWA (OWA 2007). As reader Bart points out, this is easily fixed by flipping the hideDLMembership attribute to TRUE. At first look, the attribute doesn't seem to be exposed by the Exchange shell. You can use your LDAP/AD tool of choice, including ADSIEdit, to modify it.


Figure 6: Flipping the Distribution Group's hideDLMembership attribute to True in ADSIEdit

With the attribute set to true, group membership is no longer revealed.

Yes, this means this workarounds mentioned above can be used to:

- Hide Distribution Group membership from Outlook users
- Prevent Outlook users from expanding the Distribution Group when composing new messages
- Hide Distribution Group membership from OWA users
- Prevent Delivery Reports from revealing group membership

The caveat: These workarounds succeed in hiding membership by examining the Distribution Group (or sending a message to it). This may meet your requirements for hiding group membership. However, you can examine the Member Of property page of a recipient and see which groups he/she is a member of. Agreed, this is not a convenient way of discovering group membership— particularly if you have a large number of recipients. Nevertheless, from a security standpoint, this does mean there's no hiding of group membership.

Gmail flaw allows forwarding messages to attacker's mailbox

As I sat watching a cool video put together by "Gmail fans" yesterday, reports of a flaw with Google's popular web-based email service were beginning to appear. The flaw allows an attacker to create a filter to forward a victim's messages to any email address specified by the attacker.

Scary stuff - Gmail is one of the email services I use.

More in "Gmail zero-day flaw allows attackers to steal messages" on InfoWorld.com.

Little over a week ago, Google Docs' new Presentations feature, a would-be competitor for Microsoft PowerPoint, reportedly revealed email addresses of users collaborating/viewing a presentation. Not a very serious flaw, imo, but it had privacy experts concerned.

This is not as much about pointing out Google's vulnerabilities, but more about realizing that web-based software, just like software that runs on your PCs or servers, can have vulnerabilities. Additionally, so can the infrastructure of web-based service providers.

I was recently notified by another web-based service provider that their databases were compromised, but they're making sure no major damage is done (or some such verbiage that I can't seem to recollect but didn't make much sense at all when I read it). I should monitor my credit reports, it added further. Thanks, that makes me feel very comfortable. Where do I send the bill from the credit monitoring service?

The Gmail collaborative video wasn't nearly as bad.

NetCraft: IIS gaining ground on Apache

Internet research firm NetCraft reports Microsoft's IIS web server is now gaining ground on its open-source rival Apache. Out of close to 128 million web sites surveyed this month, 34.2% use IIS - an increase of 1.4%. Apache's marketshare slipped by 1.7%, to 48.4%. More in NetCraft's August 2007 Web Server Survey.

Update:
Eric Lai reports on Computerworld.com: "Survey: Apache could lose Web server market lead to Microsoft by 2008".

Lai quotes open source proponent Bruce Perens: "But businesses that use IIS are bringing trouble upon themselves, he argues. "My own Web server running Linux does not have a firewall, it's been on the Net for 10 years and has never needed one. Try running any MS operating system naked on the Net that way."

First thing, hats off for running the same server for 10 years! (I'm interested in finding out who the vendor is, since my own boxes don't live nearly as long...)

For an open source proponent, Peren's view is hardly surprising. I've hosted an IIS server on the web (the one on which this blog was previously published) for 3+ years - with (gulp!) no firewall! Windows is an easily securable platform than many open source proponents realize. The built-in IPSec support provides adequate protection, imo. (Check out Steve Riley's 2-part article on TechNet about IPSec and usage scenarios: Using IPsec for Network Protection). Coupled with some basic server hardening steps and implementing the security policies available in Group Policy/Local Policy, you can run a Windows+IIS server on the internet and not lose sleep over it. (No, I'm not recommending you try this at work). :)

Outlook Anywhere and Exchange's Self-Signed Certificate

Outlook Anywhere (known as "RPC over HTTP" in Exchange Server 2003), the Exchange + Outlook + Windows Server feature that allows Outlook clients to access Exchange servers without a VPN, does not work with Exchange Server 2007's self-signed certificate.

Yes, this is different from Outlook Web Access (OWA) and Exchange ActiveSync. Both can use the self-signed certificate if the certificate is trusted by installing it in the computer's or mobile device's certificate store (or by using Group Policies to propagate trusted Root CAs to computers). OWA users can also bypass the browser prompt that alerts about certificate-related issues, and continue to access OWA.

However, Outlook Anywhere requires a valid certificate issued by a trusted Certificate Authority. Note, this doesn't necessarily mean an external/third-party CA - it can be an in-house CA that is trusted by clients. Read "How to Configure SSL for Outlook Anywhere" for more information.

You can set up a Certificate Authority very quickly and easily using Windows Servers' Certificate Services. It's included in Windows Server, there are no additional licensing costs involved. If you're interested in security and PKI, I highly recommend setting one up in a test AD Forest, along with Brian Komar's excellent book "Microsoft Windows Server 2003 PKI and Certificate Security". As Komar explains in the book, setting up a PKI infrastructure right for a company of any size isn't as easy as simply installing Certificate Services on a Windows box - chances are you'll make plenty of mistakes without proper understanding and planning.

Setting up a CA in production just for issuing certificates to CAS servers isn't worth it - certificates from commercial CAs can be had for a very low cost (I recommended a CA few posts ago - "DigiCert: A Certificate Authority with excellent customer service"), minus all the headaches of maintaining and managing an in-house CA.

If you're planning to use a certificate with Subject Alternative Names (SAN), also known as Unified Communications certificates in Exchange/UC terminology, here's a tip you should read before creating your certificate request: "Which name should I use as Common Name for my UC certificate?"

Mozilla promises to patch in 10 days

In a sign of further security goodness, Mike Shaver - Mozilla's Director of Ecosystem Development, claims Mozilla will fix all vulnerabilities in (his own words) "10 [expletive] days".

The caveats: provided there is "responsible disclosure", and the claim is for critical vulnerabilities.

As a FireFox user, what's troubling is the fact that Mozilla has to make such claims at all. This comes in the wake of its recent security woes and playing "it's your vulnerability" with Microsoft (read previous post "FireFox 2.0.0.6: Mozilla fixes the IE security hole that wasn't").

"It is an audacious claim" (InfoWorld quotes Sophos technology consultant Graham Cluley), and as such claims go, it's at a high risk of falling flat on its face. Like Apple's recent claim about its Safari browser (read previous post "Safari, Meet Windows: Apple's cool browser comes with security holes").

You can see the claim scribbled by Shaver on the back of his business card here. Also read "Mozilla vows to patch any critical flaws in 10 days" on InfoWorld.

Disclaimer from previous post: Given that this is the second post in a row about FireFox, it should be no surprise that I continue to use FireFox as my preferred browser, in addition to Internet Explorer and (gulp!) Safari!

Which name should I use as Common Name for my UC certificate?

I recently got a UC/SAN cert from DigiCert (read previous post "DigiCert: A Certificate Authority with excellent customer service"). Here's a tip from them about which name (fqdn) to use as the Common Name.

Q: Which name should I use as the "common name" for my UC certificate?
A: It's probably best to use the name which will be used by mobile devices for their ActiveSync connections.

Here is why:
Many organizations need to support a variety of mobile devices which connect to the mail server for ActiveSync. There are many mobile devices out there, with various SSL capabilities.

- The most common form of name matching is for the SSL client to compare the server name it connected to with the common name in the server's certificate. It's safe to assume this basic matching will be supported by all SSL clients.

- If the SSL client supports SANs (Subject Alternative Names) and there is a SAN extension in the server's certificate, then the client will ignore the subject common name entirely and try to match the server name to one of the names in the SAN list. (This is why you will always see the subject common name repeated in the SAN list.)

- Windows Mobile 5 supports subject alternative names.
- Newer Palm Treo devices use WM5, but the older ones run PalmOS and use VersaMail for ActiveSync.
- The older Treos do not support SAN name matching.
- There are other mobile devices that don't support SAN name matching either, so it's safest to set your common name to the name that most mobile devices will be using.
- All popular browsers (IE, FF, Opera, Safari, Netscape) have supported SANs since 2003 (MS IE has supported them since in Windows 98)

Exchange ActiveSync, ISA 2006 and Error 0x85010004

When publishing Exchange ActiveSync with ISA Server 2006, you get an error 0x85010004 on the device. The error:

Result:
Your account in Microsoft Exchange Server does not have permission to synchronize with your current settings. Contact your Exchange Server administrator.

Support code: 0x85010004

After hours of troubleshooting, deleting the ISA rule and recreating it, playing with the ISA web listener and Exchange's ActiveSync virtual directory settings, it turns out the server fqdn had a typo in the Public Name tab of the ISA rule. ISA responds to a HTTP request if the host header matches the Public Name - akin to host headers in IIS when publishing multiple web sites using a single IP address.



About authentication settings on the web listener: The same web listener can be used for publishing OWA and ActiveSync. The Authentication settings for the listener can be set to HTML Form Authentication. At first look, this doesn't seem too intuitive given Exchange Server 2003's issues with Forms-Based Authentication and Exchange ActiveSync (KB 817379: Exchange ActiveSync and Outlook Mobile Access errors occur when SSL or forms-based authentication is required for Exchange Server 2003), but it works.

Apple: Time to iPatch your iPhones

Within weeks of the iPhone's launch, it's time to patch your iPhones! Yes, Apple has released a bunch of fixes for Mac OS X and the just-launched iPhone. The iPhone patches get delivered to you next time you synch your iPhone with iTunes.

DigiCert: A Certificate Authority with excellent customer service

I finally took the plunge and decided to get a certificate from a public Certificate Authority (CA) for my Exchange Server 2007 server at home. A certificate that supports Subject Alternative Names (SAN certificate, aka "Unified Communications" certificate), no less. Having dealt with a number of CAs in the past, and having heard some horror stories about getting a certificate that supports Subject Alternative Names, I wasn't quite looking forward to the exercise.

Thanks to Office Communications Server (OCS) MVP (and fellow Zenpriser till recently... ) Lee Mackey, the CA he recommended - DigiCert - provided exemplary customer service.

Chain of events:
- Generate SAN certificate request using the New-ExchangeCertificate command from Exchange Server 2007 (for a couple of domains, includes the Autodiscover.domain.com fqdn).
- Submit request to DigiCert
- Get confirmation emails from DigiCert (for multiple domains)
- Within a few seconds, while I'm still clicking on the confirmation messages, I get a call from a DigiCert rep to confirm the details
- The rep informs me the physical/mailing address with the domain registrar for one of the domains is not current or not the same as the one I provided when requesting the cert
- Rep waits while I correct it on the domain registrar's web site
- Confirms the address is updated in the registrar's WHOIS info
- Asks for a photo ID to be uploaded on their secure site
- I email him the photoID instead of uploading it
- By the time I'm back from the scanner/copier to my desk, and hit refresh, the photo ID shows up on DigiCert's web site
- Within a few minutes I get the certificate in by email
- Install certificate and test it with the different domains - works!

An impressive and positive customer service experience - these guys rock! If you're in the market for a digital certificate, check them out.

Requesting and using certificates for Exchange Server 2007

- KB 929395 Unified Communications Certificate Partners for Exchange 2007 and for Communications Server 2007
- Use the Import-ExchangeCertificate command to import the new certificate, and Enable-ExchangeCertificate command to enable the new certificate for Exchange services you want to use it with (IIS, SMTP, IMAP, POP, and UM)
- Also recommend reading the team blog post by John Speare: Exchange 2007 lessons learned - generating a certificate with a 3rd party CA
- SAN certificates cost significantly more than regular SSL certificates as of now. Figure out if using multiple regular certificates (may require additional IP address) works out for your deployment.

ISA Server issues

- Forms-Based Authentication: If using ISA (ISA 2006 in my case) to publish Exchange CAS URLs for OWA, disable the Forms-Based Authentication on Exchange's OWA virtual directory, else you'll get two Forms-Based Auth pages and will end up having to authenticate twice - once with ISA, and once with Exchange.
- A useful doc if you're publishing with ISA 2006: Publishing Exchange Server 2007 with ISA Server 2006.
- ISA and SAN Certs: ISA 2004/2006 still have issues with SAN certs, discussed in the ISA team blog: Certificates with Multiple SAN Entries May Break ISA Server Web Publishing.

FireFox 2.0.0.6: Mozilla fixes the IE security hole that wasn't

You've probably heard about the FireFox patch that fixed a vulnerability caused by IE? Here's more.

July 10: Mozilla's head of Security Strategy Window Snyder writes: "Today security firm Secunia released an advisory on a security issue found (apparently) simultaneously and independently by Greg MacManus and Billy Rios based on a previously reported issue in Safari found by Thor Larholm.

Any Windows application that calls a registered URL protocol without escaping quotes may be used to pass unexpected and potentially dangerous data to the application that registers that URL Protocol. This could result in a critical security vulnerability."

July 18th: Mozilla claims it has fixed the vulnerability in 2.0.0.5, which wasn't really it's own. Window Snyder writes on her blog - "This patch for Firefox prevents Firefox from accepting bad data from Internet Explorer. It does not fix the critical vulnerability in Internet Explorer. Microsoft needs to patch Internet Explorer, but at last check, they were not planning to."

She adds: "Mozilla recommends using Firefox to browse the web to prevent attackers from taking advantage of this vulnerability in Internet Explorer".

Turns out 2.0.0.5 didn't really fix the vulnerability in FireFox!

Microsoft's Jesper Johansson responds in his blog post titled "Hey, Mozilla: Quotes Are Not Legal in a URL". Jesper cites RFC 3986, an internet standard that defines how URLs should be formatted.

July 30: Mozilla releases another update - FireFox 2.0.0.6. Here's more on what's fixed: "Mozilla Foundation Security Advisory 2007-27". (You probably see where we're going with this.... :)

From Window Snyder yesterday (7/30): "We’ve just released Firefox 2.0.0.6 which contains a security patch to mitigate the issue described here. The patch enables percent-encoding for spaces and double-quotes in URIs handed off to external programs. This reduces the risk of malicious data being passed through Firefox to another application that may then trigger unexpected and potentially dangerous behavior."

After crying out loud "It's really Microsoft's fault... ", Mozilla and Snyder didn't really make as much noise about this new patch.

Disclaimer: Given that this is the second post in a row about FireFox, it should be no surprise that I continue to use FireFox as my preferred browser, in addition to Internet Explorer and (gulp!) Safari!

Apple's security woes: Has less than 7 days to fix iPhone vulnerability

The company that designs its products "to be secure from day 1" is facing some security headaches of its own.

First, the vulnerabilities in its beta release of Safari browser for Windows, ironically discovered on "day 1", within hours of Apple Wizard-In-Chief Steve Jobs announcing it with much fanfare (read previous post "Safari, Meet Windows: Apple's cool browser comes with security holes"). Followed up by vulnerabilities in its cool (but way-too-overhyped) new iPhone. On Monday, Independent Security Evaluators revealed a vulnerability and a "a proof-of-concept exploit capable of delivering files from the user's iPhone to a remote attacker".

Part of the interesting Q&A on ISE's web site (linked above):
Should I turn my iPhone off and lock it in a drawer until Apple fixes this?
Not unless you plan to do the same to all the other computers you own. The iPhone is an internet connected device running a relatively full featured software suite: this research shows that it is vulnerable just like many other similarly capable devices, both PCs and embedded systems.

Does this add credence to Apple's position that 3rd party applications are not allowed on the iPhone for security reasons?
We don't think so. Almost all of the security engineering effort on the iPhone seems to have been spent protecting the revenue model, rather than protecting the user (which is, of course, an entirely understandable position). For example, a constrained environment is used to prevent users from loading new ringtones onto the phone, but the applications are not run in a constrained environment to contain damage caused by hackers who exploit them.

ISE's Dr. Charlie Miller will reveal more details in a presentation on Monday (Aug 2nd) at BlackHat. Apple has fewer than 7 days to patch the iPhone, according to InfoWorld. More in this report "Black Hat spurs Apple to patch iPhone".

Exchange MVP Q&A chat transcripts posted to TechNet

Last month Microsoft held TechNet Exchange and Security MVP Q&As (chats). The transcripts are now available on the TechNet web site.

• Q&A with the Exchange MVP Experts (June 19, 2007) transcript


• Q&A with the Exchange MVP Experts (June 21, 2007) transcript


• Q&A with the Security MVP Experts (June 21, 2007) transcript

HOW TO: Grant Full Mailbox Access permission

Follow-up to previous post titled "HOW TO: Assign SendAs right using Exchange shell" - the ability to assign SendAs and ReceiveAs permissions is preserved in AD Users & Computers, but the ability to grant Full Mailbox Access permission isn't available. Full Mailbox Access is a mailbox permission (without getting into a debate about what's a permission and what's a right, the term is used interchangeably here). In Exchange Server 2003/2000, mailbox permissions can be controlled from the Exchange Advanced tab | Mailbox Rights, as seen in the following screenshot.


Figure 1: In Exchange Server 2003/2000, mailbox permissions can be managed from ADUC

Since Exchange Server 2007 does not use ADUC for recipient management, this can't be done using ADUC.

The shell is your friend when it comes to assigning Full Mailbox Access and other mailbox permissions. You can use the Add-MailboxPermission command from the shell to assign it.

In the following example, we assign Full Mailbox Access permission on Joe Adams' mailbox to another user (janea):

Add-MailboxPermission "Joe Adams" -AccessRights FullAccess -user "janea"

Besides FullAccess, the following mailbox permissions can be granted using Add-MailboxPermission: 1) SendAs 2) ExternalAccount 3) DeleteItem 4) ReadPermission 5) ChangePermission 6) ChangeOwner

Viewing permissions using Get-MailboxPermission

To view permissions on a mailbox, use the Get-MailboxPermission command:

Get-MailboxPermission "Joe Adams"

To view explicitly assigned permissions (i.e. permissions that are not inherited):

Get-MailboxPermission "Joe Adams" | where {$_.IsInherited -eq $false}

To view all security principals with Full Access permission on a mailbox:

Get-MailboxPermission "Joe Adams" | where {$_.AccessRights -like "*FullAccess*"}

Managing Full Mailbox Access using the EMC in Exchange Server 2007 SP1

Exchange Server 2007 SP1 adds management of Full Mailbox Access permission to the EMC.
1. From Recipient Configuration | Mailbox | select mailbox.
2. In the Action pane (or by right-clicking the mailbox), click Manage Full Mailbox Access...


Figure 2: Exchange Server 2007 SP1 allows management of Full Mailbox Access permission from the EMC

Numbers talk: Vista most secure OS of all?

Today's issue of Paul Thurrott's WinInfo newsletter/column (read "Microsoft: Vista More Secure than OS X, Linux" on WinITPro.com) served as a reminder of the stuff I missed at TechEd in Orlando - my first year with exhibitor and staff (yes, they actually issued me one of those as well) badges. Subject: Jeff Jones' Vista 6-month vulnerability report.

Jeff Jones is a Strategy Director at Microsoft's Security Technology Unit. This is an update to Jones' earlier 90-day report on Vista vulnerabilities. In this updated report, Jones outlines vulnerabilities announced and patches released for Windows Vista in the first 6 months since its release, and compares it with that of other "modern" operating systems like Mac OS X 10.4, and some Linux distributions like Red Hat Enterprise Linux 4 Workstation (RHEL4w), Novell's SUSE Linux Enterprise Desktop 10 (SLED10), and Ubuntu 6.06. The Linux distributions reported on include the full distributions and a "reduced component set" consisting of essential/default components. The categorization of a vulnerability as high, medium and low severity is from the National Institute of Standards and Technology's (NIST) National Vulnerability Database (NVD).

The score-card looks interesting to say the least.

Reportedly, Windows Vista had the least number of vulnerabilities - and patches released in its first 6 months post-RTM. Jones drives home the point that Microsoft's Secure Developoment Lifecycle initiative is paying off.

Draw your own conclusions from the score-card below.





Of course, the Linux crowd and the Mac fanatics will quickly dismiss this report on one pretext or the other, and this will do nothing to the endless runs of the Apple security commercials lampooning Vista's User Account Control feature. (I love the Mac commercials - they're funny, and very well done. However, given these numbers, the general tone and implications of Mac OS X being more secure than Windows Vista couldn't be further from the truth. What's more, Apple's claims like "Apple engineers designed Safari to be secure from day one", come off sounding like little more than the collective imagination of Apple's marketing machine, given the security flaps it faced with it. Come to think of it, Mac OS X 10.4 does come close to Windows Vista as far as security goes.)

Read the complete report (PDF) on CSOOnline blog.

French govt bans BlackBerry citing security risks

In an interesting twist, the French government has banned members and their advisors from using BlackBerrys, citing security concerns arising from the fact that data flows through servers in the U.K. and N. America. Says InfoWorld, "This concentration of data poses a threat to national security, according to Alain Juillet, senior economic intelligence advisor to the French Prime Minister, because of the risk of data interception".

Research In Motion, the Canadian BlackBerry-maker and service provider (email sent/received from/to BlackBerry devices flows through RIM's data centers), disputes that assessment, saying data is encrypted using 256-bit AES encryption - the origin of a message on RIM's network cannot be traced, the content cannot be analyzed even by RIM.

More details in InfoWorld's report titled "Update: Security risks prompt French BlackBerry ban".

Safari, Meet Windows: Apple's cool browser comes with security holes

One of the 12 reasons Apple says "you'll love" Safari for Windows - "Now you can enjoy worry-free web browsing on any computer. Apple engineers designed Safari to be secure from day one."

Apparently, it didn't take security researchers/experts like Thor Larholm, David Maynor and Aviv Raff too long to uncover the security holes in Safari for Windows, including couple of critical remote code execution vulnerabilities by simply visiting a web site. In fact, it happened within hours of Apple CEO Steve Jobs announcing availability of the Windows version of Beta 3.

More in this article titled "Researchers find flaws in Safari for Windows" on SearchSecurity.com.

Will Windows Vista's security features protect us from Safari's vulnerabilities? I can't wait to watch a spoof of Apple's security commercial - "Apple's browser will weaken system security. Cancel or Allow?".

Nevertheless, having installed the beta on a Vista box, I am super impressed by its rendering performance - it's blazing fast!

I like it's Private Browsing feature - when turned on, it doesn't add web pages visited to the browser's history, doesn't use AutoFill, and searches are not added to the Google search box. And the minimalist interface goes with Apple's simplified and generally elegant design.

Once released, and hopefully without new security bugs being discovered within hours of its release, Safari could be a serious contender for an alternate browser instead of Firefox. I would still need Internet Explorer for accessing Outlook Web Access and other Microsoft and IE-friendly sites.

CAS In DMZ Redux: Time For an OWA Appliance?

The number of times I continue to field this question is amazing - Can the Client Access Server be located in the perimeter (DMZ) network? I wrote about it not too long ago [read previous post titled "Locating Exchange Server 2007 CAS role in the perimeter?"]. Exchange folks continue to get the standard requirement/mandate from security departments - an internal server (i.e. one located behind the internal firewall) cannot be made accessible from the internet. The security rule of thumb for long has been - if it needs to be accessed from the internet, it resides in the perimeter.

Exchange Server 2007 Client Access Server (CAS) role is not supported in the perimeter. In fact, the only role that's supported and intended for the perimeter network is the Edge Transport server. Those new to Exchange Server 2007 cannot be blamed for contemplating the possibility of making the Edge Transport server "an OWA server". It resides in the perimeter any way, so why not?

The Edge Transport server role does not co-exist with any other server role, and it's typically not a member of your Active Directory domain. (You can locate it on the internal network if you wish, and you can install the Edge on a server that's a member of your AD domain - but that's not the intended purpose - Bharat).

The alternatives
a) You could open the necessary ports on your firewall(s) to make the CAS accessible from the internet. Yes, that's a non-starter for most. The thought may seem scary, or you may run the risk of being laughed out of your job by the security folks.
b) Publish CAS using an application-aware or application-layer firewall/SSL VPN. Microsoft's ISA Server does the job really well.

I've been very impressed with Whale Communications' implementation - their e-Gap/AirGap (I always got confused between the two - Bharat) will certainly win the approval of the most demanding security departments. Microsoft bought Whale about a year ago (read previous post - "Microsoft buys Whale Communications"), and Whale appliances are now sold as Microsoft Intelligent Application Gateway 2007 - a part of Microsoft ForeFront security solutions.

Perhaps the Exchange team should seriously think about an Edge-like equivalent of the Client Access Server role - a server that can be located in the perimeter to provide secure access to OWA, OutlookAnywhere (RPC over HTTP), POP3, IMAP4, and ActiveSync. (I'm guessing the idea must have been bounced arond... ). Yes, ISA and the IAG can do it - but it may be a lot easier to deal with security folks if an Edge-like server role or appliance is available that can be located in the perimeter.

While we're on the topic - since the Edge Transport server (and its CAS equivalent I proposed) do not need to be members of an AD Domain, it would be great to have these as appliances - stuff you plug-in, spend a few minutes configuring - perhaps using a web-based interface, and forget about.

Are you ready for the Edge and OWA Appliances?

Released: Update Rollup 2 for Exchange Server 2007 (KB935490)

Microsoft has just released Update Rollup 2 for Exchange Server 2007 (KB935490). This update comes less than 3 weeks after the previous rollup - Update Rollup 1. It includes updates for 4 vulnerabilities in Microsoft Exchange Server - (including a critical remote code execution vulnerability from the way MIME messages are decoded), as outlined in Microsoft Security Bulletin MS07-026 released today.

Unlike Update Rollup 1, this rollup is available for both 64-bit (x64) and 32-bit (x86) platforms.

The cumulative nature of Exchange Server 2007 updates/rollups means Update Rollup 2 includes the updates in Update Rollup 1. [For more details on changes to the update/patch model for Exchange Server 2007, read the previous post, "Changes to hotfix/patching model for Exchange Server 2007"]

Computerworld: The deal on the Windows DNS bug

The still unpatched Windows DNS Server bug has been the topic of many a security discussions during the past few days. If you're running your DNS on a Windows Server (using DNS Server service), this affects you. Computerworld's Gregg Keizer has a nice write-up about this issue that I just stumbled upon, thanks to Sunbelt Software's WServer News newsletter.

According to Computerworld, there are at least 5 exploits in proof-of-concept form floating out there. Chris Budd from the Microsoft Security Response Center says Microsoft has "teams around the world working twenty-four hours a day". An update/hotfix is expected around May 8th, in time for next month's Patch Tuesday.

RFC 2821, HELO again: Validating the HELO/EHLO domain

RFCs 2821 and 1869 specify the format of HELO/EHLO commands issued by a SMTP client to initiate a session.

RFC 2821 on HELO/EHLO command:

4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)
These commands are used to identify the SMTP client to the SMTP server. The argument field contains the fully-qualified domain name of the SMTP client if one is available. In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help to identify the client system. y The SMTP server identifies itself to the SMTP client in the connection greeting reply and in the response to this command.

(paragraph snipped here)

In any event, a client MUST issue HELO or EHLO before starting a mail transaction.

These commands, and a "250 OK" reply to one of them, confirm that both the SMTP client and the SMTP server are in the initial state, that is, there is no transaction in progress and all state tables and buffers are cleared.

Syntax:

ehlo = "EHLO" SP Domain CRLF
helo = "HELO" SP Domain CRLF

The syntax, as the last 2 lines show - depending on whether you're using EHLO or HELO, should be:
HELO foo.somedomain.com
or
EHLO foo.somedomain.com
(followed by a CR LF)

The IIS/Exchange SMTP stack validates this syntax by default. SMTP clients that do not adhere to this syntax - by appending a period or a space at the end of the domain or address literal (IP address) get a 501 5.5.4 Invalid Address error. Exchange Server 2007, which has a brand new SMTP stack of its own, also continues this domain validation, with a slight modification in the verbiage: 501.5.5.4 Invalid domain name.

However, some SMTP clients do format the EHLO/HELO commands with a trailing period/dot or a space. Though not RFC-compliant, many mail systems allow it, including webmail services like Google's Gmail and Microsoft's Hotmail/Live Mail (I wasn't able to test this with Yahoo Mail today...- Bharat).

You can stop IIS/Exchange SMTP servers from checking if the domain in EHLO/HELO is well formatted by changing the value of SmtpDomainValidationFlags metabase property in IIS to a non-zero value. The property does not exist by default, but you can create it using a tool like the Metabase Explorer (in IIS 6 Resource Kit Tools) - it's a DWORD, with an ID of 36992. You can get step-by-step instructions on how to do this in KBA 291828: "501 5.5.4 Invalid Address" error message from a sending UNIX server.

A post in Microsoft's Exchange newsgroups enquired if this was going to open up a security hole in SMTP. Other than allowing domains or address literals not formatted correctly according to SMTP standards, which many SMTP clients and webmail systems allow and probably use - as stated above, I can't imagine this change creating any serious security issues. Having said that, the particular post was in regard to not being able to receive email from Google Alerts. I continue to receive email from Google Alerts without making any changes to the default behavior of SMTP in IIS/Exchange.

However, the IIS/Exchange SMTP stack does domain validation for a reason. One possibility to consider when evaluating whether to turn it off - it's likely that it could allow sessions from spammers that indulge in such behavior.

Email Archiving and Compliance: Learning from email issues that plague the White House

Over the weekend, Wall Street Journal reported "White House Probes More Lost Emails" (external links do not work, WSJ.com requires subscription to read this article). The Journal's John D. McKinnon reports, "The White House, already under pressure to explain missing emails from officials using a Republican Party system, says it is investigating reports that many more emails might have been deleted from its own system."

A White House spokeswoman said Friday that it is possible several million emails could have been erased. How many million is "several" million? According to Deputy Press Secretary Dana Perino, "a potential 5 million emails were lost", as reported by McKinnon.

That's not a small number by any means! Can you imagine the impact of losing as many emails from your corporate messaging systems?

What's even more interesting, another White House spokesman - Scott Stanzel said "we are aware that some emails may not have been automatically archived on the... server. However, we understand that such emails should have been preserved on backup tapes."

The Washington Post's Dan Foomkin writes in his White House Watch column, "Countless e-mails to and from many key White House staffers have been deleted -- lost to history and placed out of reach of congressional subpoenas -- due to a brazen violation of internal White House policy that was allowed to continue for more than six years, the White House acknowledged yesterday.

The leading culprit appears to be President Bush's enormously influential political adviser Karl Rove, who reportedly used his Republican National Committee-provided Blackberry and e-mail accounts for most of his electronic communication."

The political spin is interesting, even amusing to many. Let's put the political tones and context aside, and think of these as email issues for a moment. There are two issues here:

1) IT/Messaging Operations: missing messages from the archiving system. Is this a case of data loss that happened during "conversion" from one system to another, as stated in the White House response? It would be great to have more technical details, so us messaging types can relate and try to figure out what may have happened, and perhaps how to avoid such issues in our environments. Some may even be interested in knowing which vendors and/or products were involved.

2) IT/Messaging Policy: As indicated in most such reports in the media, many White House staffers used accounts on the Republican National Committee's (RNC) messaging system, instead of the official White House one. Again, removing the political context from this issue, this could be the worst nightmare for CIOs/Compliance Officers/executives in any organization - users bypassing your organization's mail system completely, using their personal/external accounts. All such messages that bypass your email system can not be archived by your super-smart archiving systems. You have no control over such messages, or their content.

Unfortunately, there's no simple technical solution to stop such email abuse - many organizations try different things, like blocking known/public/free web-based email systems, blocking outbound SMTP at the firewall for all computers except authorized internal mail hosts that need to send internet mail, amongst other such measures. Neither of these guarantee the absolute lockout of external mail services or systems - those inclined to do so may find the workarounds, depending on how well you've locked down such access.

Nevertheless, such measures do provide some sort of protection from use of "unauthorized mail systems". Additionally, putting such measures in place is proof that attempts were made in good faith to prevent users from indulging in such practice.

The other piece is Messaging/IT Policy. Some questions to ask: Does your policy explicitly state that users should not use such "unauthorized mail systems" to send/receive work-related messages, or prevent users from using external mail systems at all during work hours or from the office? Is the policy well-publicized in your organization? Do users sign an agreement stating they've read, know about and agree to adhere to such policies, when they join your organization and every time the policy changes? Does it communicate the possible consequences of such policy violations?

As a sidenote, as a user I would frown on policies that prevent me from checking my personal email from work - at least during breaks. This may be a job requirement for positions such as those in the White House (or large financial institutions, as noted in the comments - Bharat), but not very practical in many private organizations. A delicate balance has to be found that meets both requirements - that of ensuring all work-related communication happens through the organization's messaging system, while allowing use of personal email for personal purposes, particularly during breaks/non-work hours.

As it appears, White House staff is governed by such policies - the 1978 Presidential Records Act, according to McKinnon's report. Ironically, while the elected representatives are all for enacting laws like the Sarbanes-Oxley Act and HIPAA, and the government all too diligent in enforcing them, an important arm of the government doesn't seem to be in compliance with laws that apply to it.

Messaging folks, and corporate IT & legal departments have a lot to learn from this incident - lessons best learnt from other people's experiences (...and at other people's cost?).

I suspect we will continue to hear a lot more more about this issue in days to come.

Internetnews.com: Surprise, Microsoft Listed as Most Secure OS!

Microsoft has no dearth of critics as far as security goes, particularly from the open source bandwagon. Apple's commercials certainly show no mercy when talking about this issue, and frankly the commercials are quite funny and well-executed, imo (..but then isn't marketing the art or science of being as far removed from the facts as possible without getting caught? :).

Nevertheless, the numbers tell a different story, and so does a recent report from Symantec - the vendor of anti-virus and security software who can be accused of being anything but too kind to Microsoft as far as security goes.

"...Symantec, no friend of Microsoft, said in its latest research report that when it comes to widely-used operating systems, Microsoft is doing better overall than its leading commercial competitors", writes Andy Patrizio in an InternetNews.com article titled "Surprise, Microsoft Listed as Most Secure OS".

According to Symantec's 11th Internet Security Threat Report, Microsoft Windows had the fewest number of patches and the shortest average patch development time of the five operating systems it monitored in the last six months of 2006.

Here's how they fared in the second half of 2006, according to the report:
1. Microsoft Windows: 39 vulnerabilities found, 12 high-priority/severe, average time for a patch: 21 days.
2. Red Hat Linux: 208 vulnerabilities, 2 severe, 130 medium severity, 76 low severity, average time to fix: 58 days.
3. Apple's Mac OS X: 43 vulnerabilities, 1 severe, average time to fix: 66 days
4. HP-UX: 98 vulnerabilities, average time to fix: 101 days
5. Sun Solaris: 63 vulnerabilities, average time to fix: 122 days

Coming from a source which cannot be accused of any bias towards Microsoft, this is an interesting revelation! Though it can be argued that Microsoft had the highest number of severe vulnerabilities, it's comforting to note the company's doing better than most vendors of releasing patches for those in a timely fashion.

Locating Exchange Server 2007 CAS role in the perimeter?

Where should you locate Exchange Server 2007 servers with the Client Access Server (CAS) role? Is it more secure to locate them in perimeter network (aka "DMZ")?

Security folks in many organizations insist that any server that needs to be accessed from external networks (i.e. the internet) should reside in perimeter networks. Locating Exchange Server 2003/2000 Front-End servers in the perimeter - though generally not recommended - was not very uncommon. It did require opening a number of ports from the perimeter to DCs/GCs and Back-End servers on the internal network, the common joke being it makes your firewall look like swiss cheese.

Nevertheless, it worked, and Microsoft provided deployment guidance, including firewall configuration details [read "Configuring an Intranet Firewall" in FE/BE Topology Guide], to make this work.

With Exchange Server 2007, Microsoft does not support locating CAS servers in perimeter networks. This is stated in Exchange Server 2007 documentation - "Planning for Client Access Servers", and many other docs as well.

CAS servers can be published to the internet using application-aware or application-layer firewalls and devices, like Microsoft's ISA Server, or SSL VPNs. One of my favorite implementations used Whale Communications' eGap appliance along with RSA's Authentication Manager - then known as ACE Server, and SecurID tokens (incidentally, Microsoft acquired Whale Communications last year. Hopefully some of Whale's savvy technology will show up in a future version of ISA or some special version of an ISA appliance).

HOW TO: Assign SendAs right using Exchange shell

In Exchange Server 2007, recipients are managed from the Exchange console or shell. The Exchange console does not show security tab for a recipient.

You can still use AD Users & Computers console to modify permissions on a recipient, as the documentation suggests ["How to Grant Send As Permissions for a Mailbox"] - and in this case, assign the Send As permission. In ADUC | select recipient | Properties | Security tab.

You can use the Exchange shell to assign SendAs right (e.g. on a Distribution Group) to a user:

Add-AdPermission "Group Name" -user "User Name" -AccessRights
extendedright -ExtendedRights "send as"

Documentation for Add-ADPermission


11/29/2007:
Exchange Server 2007 SP1 includes a Manage Send As Permissions wizard, similar to the Full Mailbox Access wizard found in the RTM version.

1. In EMC, right-click a recipient | select Manage Send As Permission



2. In the Managed Send As Permission wizard, click the Add button to add the recipient which needs to be assigned Send As permission on the selected recipient

Configuring firewalls and name resolution for Edge Transport servers

If you're planning to deploy the Edge Transport server role in a perimeter network (aka "DMZ"), here are the ports you'll need to open:

Inbound:
From external network (internet) to Edge server: SMTP - tcp port 25
From Edge server to Hub Transport servers on internal network: SMTP - tcp port 25

Outbound:
From Edge to external network/internet: SMTP
From Hub servers to Edge: SMTP, LDAP for EdgeSync (tcp 50389), Secure LDAP for EdgeSync (tcp 50636).


Additionally, it's a good idea to open RDP (tcp port 3389) from your internal network to the Edge so it can be managed without KVM/console access.

The ports used for EdgeSync - 50389 and 50636 - can be configured using the ConfigureAdam.ps1 script:

ConfigureAdam.ps1 -ldapport:5000 -sslport:5001

DNS/Name Resolution:
1. since the Edge server is not a member of the AD Domain, it may not have the primary DNS suffix populated by default. Make sure you configure the appropriate DNS suffix on the Edge Transport server - this is done from System Properties | Computer Name tab | Change | More | Primary DNS suffix of this computer. Important: You cannot change the primary DNS suffix of the Edge server after you install the Edge Transport server role.
2. the Edge server should be able to resolve fqdns of Hub Transport servers. This can be done by either using static entries in the HOSTS file on the Edge, or allowing the Edge server to use an internal DNS server. (This would require allowing DNS traffic from Edge servers to internal DNS servers). Alternatively, you could create a DNS zone in the perimeter network that the Edge server can access, and populate it with A records of the Hub Transport servers.
3. the Hub Transport servers should be able to resolve fqdns of the Edge Transport servers. This can be accomplished by adding A records for Edge servers in your internal DNS zone.

A Late New Year's Resolution: Do Not Resolve Anonymous Senders

It's probably a little late to make another New Year's resolution, but I'll try to convince you to make one nevertheless.

By default, when an internal/authenticated user sends you a message, you see the user's display name (e.g. "Joe Adams") in Outlook/OWA, et al. Messages from unauthenticated users, including those from internet senders, show up with their SMTP address - e.g. jadams@somedomain.com. Exchange/Outlook users have been used to seeing this.

You can change SMTP settings to resolve anonymous senders. On Exchange Server 2003: SMTP Virtual Server properties | Access tab | Authentication | check "Resolve anonymous senders". On Exchange 2000, this is done by creating the ResolveP2 registry value described in KBA 288635.

However, not only is resolving anonymous senders a bad idea, it's also a security risk. SMTP, the protocol, allows senders to easily spoof headers. Anonymous senders can send mail to your users, using your CEO's email address for instance, and the message will actually appear as if it was sent by an internal/authenticated sender. A spam message, or one with malicious code - if it gets by anti-spam & anti-virus scanners - buys instant credibility by getting the sender's address resolved to a valid internal sender.

This is one of the reasons I've always wanted Microsoft Outlook to provide an option to show SMTP headers at first look - without the time-wasting, mouse-clicking exercise of selecting a message, right-clicking, selecting Message Options, and viewing what is usually a long message header in a small scrollable text box. It would be great to provide users the option to turn on a "mini" header that shows the actual originating host, and for advanced users - including sysadmins / Exchange administrators who look at headers all day, an option to turn on "full" headers. Sadly, this doesn't exist, even in Outlook 2007. (You could use a little macro that KC posted on her blog a little while ago - and have a button on the Outlook toolbar that shows you the headers with a single click and saves them in a text file.)

What's worse - and I just discovered this, thanks to a newsgroup poster and Exchange MVP Andy David's response - when you check the option to resolve anonymous senders, unauthenticanted senders can now send mail to recipients that have been set to receive email from authenticated users only! That's a big surprise, and totally unexpected - Exchange actually treats anonymous senders as authenticated senders, at least for the purpose of message delivery to such restricted recipients.

Further, not only can someone using a valid internal recipient's email address send mail to such recipients, but even total strangers (addresses that do not resolve to a valid internal recipient, like foo@somedomain.com) can.

I tested this a few times yesterday, and I'm still in disbelief!

Having read KBA 828870: Resolve Anonymous Senders Functionality in Microsoft Exchange 2003 a few times, I don't find any mention of this, though the article clearly recommends that this should not be enabled on any server that receives mail from the internet, and if it is - message from anonymous senders appear as authenticated mail.

KBA 827616: How to restrict the users who can send inbound Internet e-mail to another user or to a distribution group in Exchange 2003 does mention this. It says:

Note If you enable the Resolve anonymous e-mail setting on your front-end SMTP servers, anonymous senders can bypass the From authenticated users only setting.

There may be scenarios where resolving anonymous senders is justified, for instance on internal SMTP virtual servers, where access is controlled or restricted to certain hosts. If you're in a cross-Forest deployment, you should attempt to authenticate the SMTP communication, as stated in KBA 828870 above.

As I said in the beginning of this post, if it's not already too late to make another New Year's resolution, make one today to not resolve anonymous senders on SMTP virtual servers that receive internet mail.

What is the *real* maximum password length?

I've for long been an advocate of using long passwords, using entire phrases/sentences instead of a single more complex but short password.

Some Windows Server 2003 documentation states the maximum password length is 28 characters (e.g. Enforcing Strong Password Usage Throughout Your Organization says "Although Windows 2000, Windows XP, and Windows Server 2003 support passwords up to 28 characters, ... "). The Change Password dialog box that users normally use (the one that shows up when you choose Change Password after hitting CTRL-ALT-DEL) lets you enter only 26 characters. Using AD Users & Computers, you can reset it to 32 characters.



Adding to the confusion, the help text for the Reset Password dialog box states that it provides space to type a password up to 127 characters (which it doesn't, as we've seen in the above screenshot - it's limited to 32 characters).



What's the real maximum?

The Answer: The ResetPassword dialog box does provide a space for up to 127 characters. However, the way the edit box controls work (in the above Reset Password dialog box), when you continue to enter characters past the 32-character width of the control, it does not scroll characters to the left, but continues to accept the longer password. This can be observed when you delete the long password - it deletes the 32 visible characters (though it doesn't visibly display the scrolling effect, it has indeed scrolled), then scrolls to the left to display the remaining characters in the 32-character window. Here's a Flash demo that shows that. :)

In the above demo, when the password being entered reaches the visible limit of the edit box, you feel it's not taking the rest of the password. Wait a few seconds till the password is being deleted.

The Change Password dialog box behaves similarly.

Forwarding office email to personal email accounts

CNET News.com has a report titled "Firms fret as office e-mail jumps security walls". Many organizations are concerned about employees forwarding work email to their personal, often web-based email accounts provided by free services like Yahoo! Mail, Google's Gmail, or Microsoft's Hotmail/Windows Live Mail.

At times employees may do this to simply get to their email faster when they're not at work, but most organizations have valid concerns about internal communication, trade secrets, and privileged information being leaked out. Web-based/personal email accounts can also be a source of viruses/malicious code - these do not go through the anti-virus and other security mechanisms in place on corporate messaging systems.

Further, many organizations are also concerned about email interactions related to work using personal email accounts, because these do not go through the organizations' archiving systems where such archiving is required by policies.

Some companies monitor traffic to web-based email sites such as those mentioned above. Some organizations actually block access to these sites. Many organizations are considering implementing Information Rights Management (IRM) solutions to restrict protected email content from being copied or forwarded.

Nevertheless, it all boils down to intent of the employee copying or forwarding such content. A fellow MVP and Rights Management expert Paul Adare pointed out not too long ago in a conversation about IRM - there are no technology-based solutions that can protect against such intent. No technology can prevent employees from remembering stuff and relaying that in some form.

Microsoft Exchange prevents users from automatically forwarding email using Outlook rules - forwarding to internet recipients (through Exchange) is disabled by default. (In Exchange Server 2003/2000 -> Exchange System Manager | Global Settings | Internet Message Formats | Default -> properties | Advanced tab | "Allow automatic forward" is unchecked. In Exchange Server 2007, EMC | Hub Transport | Remote Domains | Default -> properties | Message Formats tab | "Allow Automatic Forward" is unchecked).

Organizations that are concerned about such actions should explicitly include policies regarding such behavior in their messaging/email/security policy, and ensure users know these policies and acknowledge them. It may be a good idea to include some details about possible consequences employees may face for violating or abusing such policies.

Enabled by default: SMTP Tarpit in Exchange Server 2007

From a recent discussion, and something I've been wanting to post about for a while: SMTP tarpitting is enabled by default on ReceiveConnectors in Exchange Server 2007.

What is tarpitting? It's the process of introducing a delay in SMTP connections from hosts that are suspected of inappropriate SMTP behavior - for instance, by sending messages to non-existent addresses in your domain. (Tarpit is a noun, I use tarpitting as a verb to describe the process. The word probably can't be found in a dictionary, but perhaps appropriate usage to describe the process, just like telnetting, and emailing - Bharat)

If you've used Recipient Filtering on Exchange Server 2003 and selected the option to drop messages for recipients that do not exist in AD, it's a best practice to use SMTP tarpitting to get some level of protection from directory harvesting attacks. Directory harvesting is typically used by spammers to send email to addresses in your domain - which may or may not exist in your directory - to figure out which addresses are valid and which ones are not.

With the option in Recipient Filtering enabled, the SMTP virtual server will respond with a 550 error (550 5.1.1 User unknown) when it comes across an email address in the message's RCPT TO command - before the message body is transmitted. With tarpitting enabled, this response is delayed a few seconds, configurable using a registry setting (in Exchange Server 2003 on Windows Server 2003 SP1 - it is a Windows Server 2003 feature), as described in Microsoft KBA 842851. Most spammers will drop the connection if there's such a delay - it is more expensive for spammers to continue spamming/harvesting with such delays in place.

Does this sound too good to be true? What's the down side? Or are there any? On servers with high volume of SMTP traffic, you may notice more open connections, and open connections consume resources. The trick is to make sure this delay is not too high, resulting in more open connections for much longer, but high enough to make the sending hosts displaying suspicious behavior to drop connections.

Having said that, I've not come across many cases of performance degradation that could specifically be attributed to tarpitting delays, but you'll need to test this in your environment to figure out what works best.

Also note, authenticated connections are not subjected to tarpitting delays. Additionally, tarpitting only makes sense on ReceiveConnectors exposed to internet hosts.

Exchange Server 2007's ReceiveConnectors are configured with a tarpit interval of 5 seconds by default. A good way to observe this behavior is by telnetting to the SMTP port of an Exchange Server 2007 server and first sending a message to a valid recipient, and then trying to send a message to a recipient that does not exist.

To check the SMTP tarpit interval on your ReceiveConnectors, use the following shell command:

get-ReceiveConnector | select name,tarpitinterval

You can set it to a higher value - I have mine set to 10 seconds - using set-ReceiveConnector:

set-ReceiveConnector "Receive Connector Name" -tarpitinterval 00:00:10

The value is in hours:minutes:seconds.

At the time of writing, the documentation for set-ReceiveConnector command says this can be set in days as well (number of days and number of hours separated by a dot), but further it also states the maximum value for tarpitinterval is 10 minutes (00:10:00) - which is confirmed by the shell when you try to set it to a value higher than 10 minutes. (Nevertheless, technically speaking the documentation isn't wrong - you can in fact set it in days - e.g. 00.00:09:00 - as long as the value of days is zero! :) I'm told the doc will soon be changed/corrected).

To disable the tarpit behavior, set the value to 00:00:00.

Windows Vista RoI: BitLocker drive encryption enough to justify upgrades?

According to analyst Jon Oltsik of Enterprise Strategy Group, Windows Vista's BitLocker drive encryption system provides enough RoI to justify the upgrade for enterprise customers. PC encryption tools have now become a "must-have" and most enterprises are considering deploying such tools.

Standalone drive encryption utilities cost $100-$200 per system in acquisition cost alone. Add to that installation, configuration and ongoing support costs, and the upgrade to Windows Vista - which includes drive encryption (and other security and management features) - begins to look quite attractive.

More on CNET News.com - "Windows Vista and the secret of full disk encryption".

MS06-076: Cumulative Security Update for Outlook Express

As part of its monthly security patch releases, Microsoft has published a security bulletin (MS06-076) - a cumulative update for Outlook Express. Even if you use Microsoft Outlook for email and do not use Outlook Express at all, do remember this is installed by default on all Windows computers and as such it makes sense to apply this patch.

Details of vulnerability as published in the above bulletin:

Windows Address Book Contact Record Vulnerability - CVE-2006-2386

A remote code execution vulnerability in a component of Outlook Express could allow an attacker who sent a Windows Address Book file to a user of an affected system to take complete control of the system.

If a user is logged on with administrative user rights, an attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less affected than users who operate with administrative user rights.

Alternatively, if there's a reason you can't or don't want to apply the patch, a workaround exists: remove the Windows Address Book (.WAB) file association as described in the bulletin (remove the .WAB subkey in HKCR). As a result users will be unable to open Address Books by double-clicking them.

Short complex passwords easier to crack than simple long ones

Infoworld columnist Roger Grimes provides some interesting information in his Security Adviser column about (short) complex passwords being easier to crack than longer "non-complex" ones. I've always encouraged users to use phrases or short sentences as passwords rather than sticking to the short password lengths imposed by I.T. departments, and Grimes confirms that.

Some interesting tidbits:
-Conventional wisdom says that because end-users have 94 characters to choose from on a 101-key keyboard, breaking an eight-character, complex password -- out of 94^8 = 6,095,689,385,410,816 different possible passwords -- is not a trivial task.

- .....if you require an eight-character-minimum password, most users will choose an eight-character password.
- If you require a capital letter, they will put it at the beginning because we are trained in writing class to do that.
- If you require a number, most users will put the number at the end, and the number will be 1 or 2.

-Even though users have 94 characters to choose from on the keyboard, 80 percent of passwords will contain the same 32 characters and symbols -- as mentioned in my previous columns. Most passwords by English authors contain a root English word, many of which can be found in a password-cracking dictionary containing just 30,000 words.

Grimes actually ran a contest to have password hashes cracked, with interesting results. Read the entire column on infoworld.com.

And when it's time to implement a new password policy, think about raising the minimum character length, and going lighter on the complexity bit.... because the complexity part is what forces users to do crazy stuff like write passwords on sticky notes and paste them on monitors! :)

New Exchange fixes change permissions model, may disrupt Blackberry, Goodlink, and other services

A recent change in the Exchange permissions model may disrupt Blackberry, Goodlink and other services. Many folks may have already applied hotfixes that changed the behavior of "Send As" and "Full Mailbox Access" permissions. Here's a brief overview.

What: Separation of "Full Mailbox Access" and "Send As" permissions.

Why: Earlier, users with "Full Mailbox Access" permission on a mailbox were implicitly provided the "Send As" permission. This allowed them to send mail as that user. Services like Blackberry Enterprise Server and Goodlink commonly use Full Mailbox Access to be able to send mail as a user. This was a security issue for many customers and the permissions needed to be separated. With this change, users/services will now explicitly need "Send As" permission on a given user's mailbox to be able to send as that user.

Which versions: The above change was applied to the STORE.EXE file. You can tell by the version of STORE.EXE - if the version you have is equal to or later than the following, this change has already been made in your environment.
- Exchange 2000 SP3: version 6619.4 or later (first made available in hotfix KB 915358)
- Exchange 2003 SP1: version 7233.51 or later (first made available in hotfix KB 895949)
- Exchange 2003 SP2: version 7650.23 or later (first made available in hotfix KB 895949)

(Note About Today's Security Bulletin MS06-019: The security patch released today in Microsoft Security Bulletin MS06-019 also contains this fix for Exchange Server 2003 SP1. If you use Microsoft Update on your Exchange Servers, this will be applied as part of critical fixes. If you're on Exchange Server 2003 SP2, the SP2 version of the patch does not update Store.exe).

Do I need to do anything?: If your users or accounts used by services like Blackberry or Goodlink need to impersonate the user and use the "Full Mailbox Access" permission to do so, they will need to be assigned "Send As" permission explicitly.

Microsoft has included a script in KB 912918 that will dump all user accounts that have "Full Mailbox Access" permission. You can browse through the list and determine if any of those accounts need to impersonate users and therefore explicitly require "Send As" permission. You can then use the script to assign "Send As" permission to those accounts.

Are there any exceptions?: Yes, indeed. The following are exceptions where "Send As" permission is not required:
- the mailbox owner does not require "Send As" permission on its own mailbox
- Associated External Account - typically used in cross-Forest scenarios and while you're in mixed-mode with accounts in a NT 4.0 domain and Exchange in an AD Forest
- a delegate account that also has "Full Mailbox Access" permission

Exchange Server 2003 gets Common Criteria certified

Your favorite messaging server - Exchange Server 2003 (don't tell me it's NOT Exchange Server 2003 as of now... though that may change some time in the near future with E12 betas around the corner.. ) - is now Common Criteria certified.

"Common Criteria for Information Technology Security Evaluation" (CCITSE) - commonly known as "Common Criteria" or CC - is an international standard (ISO 15408) for computer security. Exchange Server 2003 got certified at EAL4, the highest level you'll see for most general products. Specifically, it wasn't RTM but SP1 with hotfix 894549 (MS05-021) applied, build 6.5.7226.0.

How does the CC work? CC has 2 parts - first is a set of common requirements of what a product should do, called a Protection Profile. The second - the evaluation rating - says how well the product satisfied those requirements in a given configuration. So unless you know what the Protection Profile for a given product's certification process is, the different evaluation ratings really mean nothing except the fact that some amount of reasonable testing was conducted under certain conditions and the product did well to get a higher rating.

The Exchange web site has more details and "Exchange Server 2003 Common Criteria Security Target" doc that describes the security requirements and components that were tested.

List users with email forwarding enabled

Here's a script written in response to a newsgroup post today on microsoft.public.exchange.admin.

Exchange Server allows you to forward inbound mail for one recipient to another recipient. You can forward messages to the alternate recipient, without delivering a copy to the original recipient (effectively redirecting inbound mail for the recipient), or deliver messages to both original and alternate recipients.


Figure 1: Exchange 2003 allows you to forward mail for one recipient to another recipient using Delivery Options

In Exchange 2003, this is accomplished using Delivery Options from ADUC | Exchange General tab. To forward to an external email address, create a (mail-enabled) Contact in AD.

In Exchange 2007, Delivery Options is found in the Mail Flow Settings tab in a recipient's properties in EMC.

Listing Users With Forwarding Enabled
Requirement: List users with email forwarding enabled.
Using Saved Queries: On Windows Server 2003, this can be easily accomplished using Saved Queries. Create a new query. From the Find drop-down, select Custom Search. In the Advanced tab, type the following LDAP query:
(&(mailNickname=*)(altRecipient=*))


Figure 2:You can view recipients with forwarding enabled using ADUC's Saved Queries feature

The other half of the requirement is to actually list the name of the user/mailbox being forwarded to. This is something ADUC can't do - there's no choice to add and display the altRecipient in a column next to each user.

The script will show all mailboxes setup to forward to an alternate recipient, the recipient being forwarded to (altRecipient), and also if messages are being delivered to both — the original recipient's mailbox and the alternate recipient.

File: ListForwardingEnabled.zip

In Exchange 2007, you can easily list this information using the shell:

Get-Mailbox -Filter {ForwardingAddress -ne $null} | ft Name,ForwardingAddress,DeliverToMailboxAndForward -Autosize

As reader Charles Howard points out in the comment (dt. Jan 29, 2009), the ForwardingAddress is output as the AD object (john smith domain.net\contacts\someguy) instead of the SMTP address. The following command can output the PrimarySMTPAddress of the recipient:

Get-Mailbox -Filter {ForwardingAddress -ne
$null} | foreach {$recipient = $_; $forwardingsmtp = (Get-Recipient $_.ForwardingAddress).PrimarySmtpAddress; Write-Host $recipient.Name, $forwardingsmtp, $recipient.DeliverToMailboxAndForward }

Updates:
- 11/25/2008: Added Exchange 2007 info and command
- 2/1/2009: Added command to output primary SMTP address of recipient being forwarded to.

SID error on cloned Virtual Server / VPC / VMWare OSes

If you simply copy an existing Windows OS image to create multiple virtual servers/workstations, and try to log on to a domain controller, you may get the following error:

The system or security ID (SID) of the domain specified is inconsistent with the trust information for that domain.

This happens because the SID of the computer was not changed when you made a copy of the virtual hard disk containing the OS. A good way to use a base drive image would be to Sysprep it first.

Nevertheless, if you haven't done that, log in to the computer locally. Use the PsGetSID and NewSid utilities from Sysinternals web site (www.sysinternals.com). Use PsGetSID (command-line - type PsGetSID to get the SID of local computer, copy to notepad, type PsGetSID \\DomainController -u username -p password to get the SID of the domain controller, and compare the two. If they're the same, now you know the reason why.

Proceed with the NewSID utility to generate a random SID for the computer. This takes a little while as NewSID replaces the old SID with the new one in the registry, amongst other things. Once done, the computer will reboot automatically (there's a checkmark to reboot... leave it unchecked if you don't want to reboot.)

You can now log in to the domain without getting the SID error.

Exchange SP2 - Connection Filtering that actually works

I was excited to find out about Connection Filtering (screenshot) in Exchange 2003 - finally I could use RBLs (real-time block lists) without having to dabble with event sinks!! (This is from back in the days when RBLs were still sexy and could keep a good chunk of spam away from your users... )

Connection Filtering works with or without RBLs - you can also specifiy IP addresses manually in a Global Accept and Deny list.

However, in most enterprise environments Exchange does not perform the role of a smtp mail gateway to the Internet. That's usually assigned to the "more capable and secure" Linux/Unix servers running MTAs like Sendmail or Postfix. So all inbound email delivered to your Exchange servers is from the IP addresses of your own trusted mail gateways. Unfortunately, this renders Exchange's Connection Filtering useless!

Exchange Server 2003 SP2 changes that - it parses the headers of inbound email for the originating server's IP address, enabling connection filtering on any inside Exchange server. Bottomline, no matter where you put your Exchange Server 2003 SP2 box, connection filtering will just work!

Windows Beats Linux in Live Security Contest

Interesting... I've since long held Windows as a more easily "securable" (provided you know how) OS.

This just came in - from WinInfo Daily Update (Paul Thurrott, creator of SuperSite for Windows, part of the Windows IT Pro mag network).
-----------------------------------------------------

Windows Beats Linux in Live Security Contest

During a live duel of sorts between backers of Windows 2003 and Red Hat Enterprise Linux during the RSA Conference 2005 this week in San Francisco, a surprising victor emerged.

Based on the previously agreed upon rules, Windows 2003 came out ahead, emerging as the more secure OS.

How could this happen, you ask? After agreeing to terms, backers of both OSs evaluated the security-oriented performance of Windows 2003 and Red Hat Enterprise Linux during the past year, looking at such key criteria as number of reported security vulnerabilities and the amount of time that elapsed between the public disclosure of a security flaw and the release of a fix. But doesn't the open-source model practically guarantee that fixes are released more quickly than they are with proprietary OSs? I guess not.

Results of the competition will be released next month, but here's the gist: Windows 2003 won every part of the competition. It had fewer flaws overall. The average time between Windows 2003 flaw reports and fixes was less than half that of Red Hat Enterprise Linux. Less than half.

Does this mean that Windows is more secure than Linux on the server? Not necessarily. But it certainly provides an interesting real-world example of why assumptions about Linux security are completely bogus, as I've often noted.

HOW TO: View the Security tab in Exchange Admin tool

Every time I get asked this, I remember the name of the key - ShowSecurityPage - but forget the complete path. It's easier to simply keep the registry hack in a .REG file, so here it is. Right-click on the link, save, remove the .txt from the filename.
ShowSecurityPage.reg

If you'd rather do it manually, the path is HKCU\Software\Microsoft\Exchange\Exadmin
ShowSecurityPage - Reg_DWORD - value: 1

In response to comments to this post, note the following:
- This is a user-specific setting - note the reg value is being created in the HKEY_CURRENT_USER hive. If another user logs on and needs to access the Security tab, the reg value will need to be added in that user's profile as well.
- The user needs to have (at least) Exchange View Only Admin privileges. Else, you can't see much in the Exchange System Manager console, and when trying to access the Security tab, you'll see the following error:



Bharat