Specify a blank sender in SMTP communication using a Telnet client

If you ever need to specify a blank sender in the mail from command when debugging an SMTP server by using a Telnet client; use <>.
For example:
220 mta.domain.com Microsoft ESMTP MAIL Service ready at Mon, 22 Dec 2008 23:21:41 +0100
ehlo
250-mta.domain.com Hello [10.10.10.10]
250-SIZE
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-X-ANONYMOUSTLS
250-AUTH NTLM
250-X-EXPS GSSAPI NTLM
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250-XEXCH50
250 XRDST
mail from:<>
250 2.1.0 Sender OK
This has been tested on Microsoft Exchange, maybe other mail servers will not accept it.
Update: I have recently discovered that the <> combination can be used in other SMTP verbs as well. For instance to specify that you do not want to authenticate you could send the command AUTH:<>

How to reinstall Virtual Server 2005 Virtual Machine Additions

The GUI insatller (setup.exe) for the Virtual Server 2005 Virtual Machine Additions do not offer a reinstall or repair option. That means that if you ever experience any problems with any of the additions you are forced to first remove the additions, reboot, reinstall them and the reboot again. But if you use the MSI directly with msiexec.exe instead of setup.exe you have some more options. This command will reinstall the additions on your virtual machine:

Msiexec.exe /faums VirtualMachineAdditions.msi

You need to mount the Additions.iso file and change to the Windows directory in the ISO image.

More info about msiexec.exe parameters here: http://technet.microsoft.com/en-us/library/cc759262.aspx

What are the security benefits of running a service as the Local System Account as opposed to a user account?

With the release of Windows 2000 products from Microsoft, most prominently Exchange 2000, started running their services under the Local System1 account instead of using a dedicated Active Directory User account, or what is commonly known as a service account2. The reason for this was security. As time passed more and more products adapted this approach and now most products do, at least from Microsoft. A result of this is the widespread use of computer objects in Active Directory to grant permissions. The Local System account act as the host computer account on the network and as such has access to network resources just like any other domain account. On the network, this account appears as DOMAIN<machine name>$. Instead of granting permissions to the service accounts, who were typically Domain Admins, we now grant granular permissions to the computer object where the service is running. When the service on the computer accesses e.g. Active Directory it does so at the host computer account and because that computer now has rights and permissions it can access the necessary data. But why is this configuration more secure? Well, that’s what this post will try to answer.

  • Password changes
    A traditional service account (user account) typically had the User cannot change password and Password never expires settings set. This meant that you set the password of the account when you created it and never changed it afterwards. That is not a good security practice. Computer accounts on the other hand are also members of Active Directory and change their password on a regular basis, completely automatic. By using the computer account for your services you get regular password changes for your services.
  • Granular permissions
    Traditional user service accounts were usually added to the Domain Admins group. This facilitated easy access to all resources and the services always worked. If the service account, which could be used on several and sometimes all, computers on the network was ever compromised it would give an attacker virtually unlimited access to the network. By using Local System the account can only be used on the host computer and typically never have any rights on other systems. Furthermore, using the principle of least privilege, the host computer’s account can be given only the necessary permissions required to run the service.

1 Local System, or NT AUTHORITYSYSTEM which is its actual name, is a predefined local account that can start a service and provide the security context for that service. When you run something, a service, a scheduled task or a process as Local System you are running it as the host computer. This has many benefits. For example the system has access to the entire computer, meaning the local SAM, Session 0, and other protected areas which are not immediately accessible to a user, even an administrator. For an administrator to access these protected areas we have to start a process as Local System, which is something only administrators can do. There are also other accounts which represent the system, namely LocalService and NetworkService. LocalService has reduced privileges similar to an authenticated local user account, and operate on the network using a NULL sessions (anonymous). NetworkService also has reduced privileges similar to an authenticated user account, but accesses network resources using the credentials of the computer account in the same manner as a Local System service does. More information about service accounts etc is available in the Services and Service Accounts Security Planning Guide (http://www.microsoft.com/technet/security/guidance/serversecurity/serviceaccount/default.mspx).

2 What allowed this was a change in the Local System Account which enabled it to authenticate to network resources just as a regular user account.