In a recent post to NTBugTraq, Rene points out what he calls a "problem" with Exchange 2000 and Exchange 2003: under some circumstances, Exchange will convert a distribution group to a security group.
Regular users with no rights to modify ad security groups have the ability to change a distribution list to a security group.Steps to recreate problem.
1: User opens a mailbox with Outlook 2000 / XP / 2003
2: Navigates to mailbox permissions
3: Add distribution list from Gal access as contributor.
4: Save changesOnce the user adds the distribution list Exchange will convert the distribution list to a like security group.
As another reader correctly noted, this behavior is by design, and it's controlled by the msExchDisableUDGConversion attribute on the Exchange organization object. In Exchange 5.5, you could apply public folder permissions by assigning DLs. That doesn't work in Exchange 2000 and later, since a distribution group doesn't have a SID and thus cannot be used for permission assignment. Normally this conversion only takes place during an upgrade from Exchange 5.5 (a process described in chapter 10 of the Exchange 2000 resource kit). The default attribute value of 0 lets the conversion take place at any time; a value of 1 only allows conversions requested by the store (not by clients; this setting would fix Rene's problem). A value of 2 disallows all such conversions (but as described in this webcast, this value isn't recommended.) Kieran McCorry has a good article that talks more about the conversion process, why it's necessary, and how to control it.
If you're using removable USB sticks, keys, or pen drives, you can format them as NTFS. This is handy if you want to apply permissions to the files contained thereon, as you might want to if you're, say, an administrator. However, the default setting for removable devices is "optimize for quick removal", meaning that write caching and NTFS formatting are turned off. If you use Device Manager to inspect the properties of the USB stick while it's mounted, you can change that setting to "optimize for performance", and NTFS will become available. You may be able to format sticks as NTFS from the command line, but this doesn't work consistently across all models and drivers.
Update: of course, the biggest benefit from formatting a thumb drive with NTFS is that you can use EFS on it. I should have mentioned that in the original post.
Computers and other electronic devices are being used increasingly to commit, enable, or support crimes against persons, organizations, or property. This NIJ Guide (NCJ 187736) is intended for use by law enforcement and other responders who have the responsibility for protecting an electronic crime scene and for the recognition, collection, and preservation of electronic evidence.For experienced admins, there's not much new here, but it's a good overview of different classes of devices and some of the forensic concerns surrounding them. One question I'm often asked when I teach is whether forensic recovery is important. The answer is a little surprising. CERT, Microsoft, and SANS all recommend flattening a machine that you know or suspect has been compromised. Why? It's very difficult to be sure that it's clean even after you clean it. For a simple compromise like Blaster or Slammer, it's easy to remove the executable, but there are much more sophisticated tools that aren't easily removed (or detected, for that matter), thus the flattening recommendation. However, as soon as you erase the disk, guess what? You'll lose much of the forensic information that you might want to help identify the scope and source of the compromise. This is critical if you want to get help from law enforcement, since there are standards of evidence that must be maintained in order to successfully prosecute an attacker. That's why most forensic investigations begin by unplugging the suspect machine and cloning its data using a tool like Encase, which is approved as a method of gathering admissible evidence (Ghost, for example, works fine but its copies aren't generally accepted as "pure" evidence). However, if all you care about is quickly getting the compromised machine back in service, flattening it is obviously the way to go. Deb Shinder's excellent book Scene of the Cybercrimediscusses forensics in more detail, and I recommend it if you're interested in the field.
Tip for potential identity thieves: be careful whose identity you steal, or you may be worse off than you were before.
Thundermain has a new RSS feed that lsts the ten most recent downloads posted in the Microsoft Download Center. This is a simple way to keep up with new white papers, documents, and patches. Check it out.
For bonus points, check out Jiri Ludvik's list of security blogs, from which this blog is inexplicably absent. It's still a good list. (Hat tip: Susan Bradley via NTBugTraq.)
Microsoft has released a terrific new white paper:
This white paper provides information about the communication that flows between components in Windows XP Professional Service Pack 1 (SP1) and sites on the Internet, and how to limit, control, or prevent that communication in an organization with many users.
In other words, this paper debunks the FUD surrounding XP's communications with the Internet by explaining when XP connects, why, and what it sends or receives. Highly recommended.
Scott Culp's two essays on the ten immutable laws of security (one set for administrators, one for users) turned two years old last month. They're still timely and useful. Read them, live them, and know them.
Want to set up IPsec? Here's a detailed step-by-step guide.
Here's a useful tip: many SMTP proxy servers don't support ESMTP. In particular, most of the SMTP proxies that clean and scan viruses don't support it. What this means to you is that if you're using a virus-scanning proxy, users aren't likely to get delivery receipts. RFC 1891 specifies how SMTP delivery status notifications (DSNs) are to be requested; if your virus scanner blocks out additional parameters to rcpt to (like, for example, rcpt to: joe@blow.com notify=failure), you won't get a DSN from that message.
If you allow Windows Messenger on your network, you might want to review this MS whitepaper on controlling Messenger via group policies. At a minimum, you'll probably want to turn off file transfers.
For bonus points, consider blocking AOL IM, ICQ, and Yahoo! Messenger from your network. Tom Shinder explains how.
I had just gotten done writing a sidebar for Chapter 15 that said there was no good way to use SSL+IMAP on a PocketPC. Lo and behold, a little Googling produced at least one way to do it, although it requires you to install stunnel. If anyone's gotten this to work, I'd love to hear about it.