• 1. London, UK
  • 2. New York, NY
  • 3. Sydney, Australia
  • 4. Melbourne, Australia
  • 5. Chicago, IL
  • 6. Bellevue, WA
  • 7. Paris, France
  • 8. Houston, TX
  • 9. Stockholm, Sweden
  • 10. San Francisco, CA
My Photo
Name:Bharat Suneja
Location:Fremont, California, United States

MVP - Exchange | MCT specializing in messaging (Exchange), Active Directory and security, having way too much fun with scripting, and Exchange "12"/2007


Saturday, March 29, 2008

 

PWN to OWN Contest: Vista gets compromised

Posted by Bharat Suneja at 9:57 AM
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.

Labels: ,

Friday, March 28, 2008

 

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

Posted by Bharat Suneja at 7:56 AM
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.

Labels: , ,

Wednesday, March 12, 2008

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.

Labels: , ,

Monday, March 03, 2008

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)

1 Allow generic read permission for objects in the OU:

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

2 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".

3 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

4 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

5 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

6In 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"

Labels: , , , ,

Thursday, February 28, 2008

 

InfoWorld's campaign to "Save Windows XP"

Posted by Bharat Suneja at 3:00 PM
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.

Graph: Vulnerabilities compared
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).

Labels: , , ,

Tuesday, February 05, 2008

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.

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

Labels: , , ,

Monday, January 28, 2008

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.

1 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

1 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).

1 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

Labels: , , , , ,

Wednesday, January 09, 2008

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)

Screensot: Content Restrictions on Exchange Server 2003/2000 SMTP Connectors
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

Labels: , , ,

Wednesday, December 05, 2007

 

Schwartz: Zero tolerance for zero retention

Posted by Bharat Suneja at 8:23 AM
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".

Labels: ,

Thursday, November 29, 2007

 

Released: ForeFront Security for Exchange SP1

Posted by Bharat Suneja at 7:15 PM
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.

Labels: , , , ,

Wednesday, November 28, 2007

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?

Labels: , , ,

Friday, September 28, 2007

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.

Labels: ,

Wednesday, August 08, 2007

 

NetCraft: IIS gaining ground on Apache

Posted by Bharat Suneja at 2:32 PM
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). :)

Labels: , ,

Monday, August 06, 2007

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?"

Labels: ,

 

Mozilla promises to patch in 10 days

Posted by Bharat Suneja at 7:23 AM
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!

Labels: ,

Friday, August 03, 2007

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)

Labels: ,

Thursday, August 02, 2007

 

Exchange ActiveSync, ISA 2006 and Error 0x85010004

Posted by Bharat Suneja at 4:50 PM
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.

Labels: , ,

Tuesday, July 31, 2007

 

Apple: Time to iPatch your iPhones

Posted by Bharat Suneja at 7:28 PM
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.

Labels: , ,

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