Accessing Domain Resources When Connected To External VPN Via Windows 7 VPN Client

Recently one of my users was having trouble printing from remote workstations. In this scenario, the user needed to print some reports from a system that resided on a client’s network. She would start up the Windows 7 VPN client, provide credentials, and once connected to the client’s network through VPN, she would start the Microsoft Terminal Services Client and login to the system she needed to print reports from. During this time, the printers on our network (managed by a domain-wide printserver; mapped to workstations via GPO) would become inaccessible. The printers would “show up” on the remote side (as TS Session Printers) as they should, but they just would not accept print jobs.

After some troubleshooting, I found that this only happened when she was connected to the VPN. Whenever I tried to access the print server through a UNC path (i.e., \\printserver\printer ) a username/password box would appear, asking for her domain credentials — but here’s the kicker: the username field would be pre-filled with the username she used to login to the VPN. After some more digging, I came across this blog post and it immediately solved the problem. This was such a pain in the ass that I’ve decided to recreate the text of the resolution here, just in case that post should disappear for whatever reason:

  1. Locate the .pbk file (VPN session file) for the session you want to fix
    • Windows Vista/7: C:\Users\\AppData\Roaming\Microsoft\Network\Connections\Pbk
    • Windows XP: C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Connections\Pbk
  2. Open the file in notepad and search for the following text: UseRasCredentials=1
  3. Change the “1” to a “0”, save, exit.

This tells the operating system not to rely on the RAS credentials that get cached upon initiating the VPN session. In Windows Vista / 7, this option is enabled by default; it wasn’t in Windows XP. I have yet to see/hear a good explanation for why it was changed.

Saving autocomplete history in Outlook 2010 (and later)

Anyone who has had to transfer a user’s MS Outlook data from one computer or another has probably heard this question before:

“Where are all my addresses?”

The user then shows you that whenever they try to compose an e-mail, addresses do not “auto-fill” — hence “Where are all my addresses?”

Explanation: Outlook stores autocomplete addresses separate from contacts. Most users don’t even realize this (and nobody ever explains it to them) so they assume that autocomplete is their addressbook.

Luckily, most of the time you could just locate the autocomplete cache file in their old profile and copy it to their new profile to restore their history. This process has become slightly more complicated in Outlook 2010, but it’s still a simple thing to recover, provided you still have access to the original user profile.

Important: Outlook cannot be running while you are doing any of this.

Copying autocomplete history from Outlook 2007 and earlier, to Outlook 2010 and later

Retrieve the old autocomplete history from the old user profile. It will be in the following directory:


It will be named outlookprofile.nk2, where outlookprofile is the name of the Outlook profile that the autocomplete history file corresponds to. If you have multiple versions, you could merge them with NK2Edit.

Copy that file into the same folder in the new user profile:


Hold the “super” key (it usually has the Windows logo printed on it) and hit the “R” key, to bring up the run dialog. Type the following command:

outlook.exe /importnk2

Click “OK” and you’re done. Verify that your autocomplete history shows up when you compose a new e-mail.

Copying autocomplete history from Outlook 2010 to Outlook 2010 and later

Retrieve the old autocomplete history from the old computer and/or old Windows user profile. If all you’ve done is created a new Outlook profile on the same machine, in the same Windows user profile, then both old and new files will be in the same directory. Either way, that directory is:


And the autocomplete history file will have a name similar to:


If you’re moving from a new computer and/or Windows user profile, then you already know which file contains the data you need. But, if you’ve created a new Outlook profile on the same machine, in the same Windows user profile, you could have multiple autocomplete files in the RoamCache directory.

In the event of multiple autocomplete files, you could use NK2Edit to merge all of them. Sometimes all you need is the largest or most recently modified file. But you’ll have to decide how you want to handle this. The safest route is to merge all of them, however that may not be desirable.

Now locate the new autocomplete file. It will be in the same directory in the new user profile as the old file was, in the old user profile. If you do not see it then it might not exist just yet so start Outlook, compose and send an e-mail, and it should appear.

If this file also contains data that you’d like to keep, you can use NK2Edit to merge the old autocomplete file(s) into the new one, overwriting it in the process — be sure to keep the filename of the new autocomplete file intact.

If it doesn’t have any data that you’d like to keep, simply rename the old autocomplete file to be identical to the new one, then copy the old (but now renamed) file into the new RoamCache directory — overwriting the new autocomplete file.

Here's an example of what this might look like

Here’s an example of what this might look like

Start Outlook and compose a new message. Start typing in the To field. If any cached addresses appear, then you’re good. If none appear, then close Outlook and repeat the previous step. Sometimes Outlook overwrites the autocomplete file upon first being opened after restoring the old data. In my experience, it will only do this on the first attempt, so just repeat the previous step to get your data back.

More information:

Sonicwall logs flooded with: destination for 255.255.255. 255 is not allowed by access control

I recently deployed a Sonicwall TZ200 (fw version: SonicOS Enhanced and after setting up SSLVPN access, the logs were being flooded with the following message:

1		03/20/2013 13:13:55.416	Info	SSLVPN	destination for is not allowed by access control				
2		03/20/2013 13:13:51.672	Info	SSLVPN	destination for is not allowed by access control				
3		03/20/2013 13:13:50.896	Info	SSLVPN	destination for is not allowed by access control				
4		03/20/2013 13:13:50.176	Info	SSLVPN	destination for is not allowed by access control				
5		03/20/2013 13:13:46.752	Info	SSLVPN	destination for is not allowed by access control				
6		03/20/2013 13:13:46.016	Info	SSLVPN	destination for is not allowed by access control				
7		03/20/2013 13:13:45.464	Info	SSLVPN	destination for is not allowed by access control

I found a few discussion threads pertaining to this issue on the Sonicwall forums and I tried some of the solutions offered but none of them worked. If you have an account on the forums, you can see these discussions here:

Through trial and error, I noticed that the messages stopped appearing in the logs (not immediately after, I might add) after disabling “Communication Between Clients” under SSL VPN -> Client Settings, and adding “WAN RemoteAccess Networks” to the Access List for the SSLVPN Services group (on the VPN Access tab) under Users -> Local Groups. The messages returned upon reversing these changes. I also noticed that whenever I enabled/disabled “Communication Between Clients”, the following error message was logged:

Adding L2TP IP pool Address object Failed.

I’m not sure if they’re related but they appeared to coincide. This doesn’t seem like the best remedy but at the time I wasn’t able to update the firmware on this device, so this was the next best thing. I’ll update this post once when I get a chance to update the firmware.

Zimbra Notes

This is going to be an ongoing post where I list useful commands that I happen across while managing various Zimbra installations. This is mainly for my own sanity but it has the added benefit of possibly being able to help out someone else. Enjoy!

Configure a domain-wide COS

First, retrieve the ID of the COS:

zmprov gc "My Custom COS" | grep zimbraId

That command will return something like this:

zimbraId: 4158eba0-ee56-4f14-9c28-2f4088888149

Then configure it:

zmprov md mydomain.tld zimbraDomainDefaultCOSId 4158eba0-ee56-4f14-9c28-2f4088888149

Increasing the Maximum Allowable Attachment Size

By default, this setting is low. Nowadays it’s acceptable to send attachments larger than 10MB (but not obscenely larger). I don’t like it and I discourage my users from sending large attachments via e-mail but if you feel the need to loosen up this restriction, here are the commands to do that:

su -l zimbra
zmprov ms `zmhostname` zimbraFileUploadMaxSize 20971520
zmprov mcf zimbraFileUploadMaxSize 20971520
zmprov ms `zmhostname` zimbraMailContentMaxSize 20971520
zmprov mcf zimbraMailContentMaxSize 20971520
zmprov mcf zimbraMtaMaxMessageSize 20971520
zmmtactl restart

20971520 = 20MB in bytes.

Disabling the Spam Filter

Sometimes it might be desirable to disable spam filtering across an entire domain or COS. For example, if you pay a 3rd party service to do your spam filtering for you.

zmprov md domain.tld +amavisBannedFilesLover TRUE
zmprov md domain.tld +amavisSpamLover TRUE

The first command turns off all filetype filtering for the domain “domain.tld” while the second turns off all spam filtering. If you wanted to do this on a per-account basis, you’d do this:

zmprov ma user@domain.tld +amavisBannedFilesLover TRUE
zmprov ma user@domain.tld +amavisSpamLover TRUE

“ma” stands for “manage account” and “md” stands for “manage domain”. This is used to specify which type of object you are editing/managing. To reverse these changes you would just change the “+” to a “-” in the previous commands or change the “TRUE” to “FALSE”. My understanding is that this:

zmprov ma user@domain.tld -amavisBannedFilesLover TRUE
zmprov ma user@domain.tld -amavisSpamLover TRUE

Accomplishes the same exact thing that this does:

zmprov ma user@domain.tld +amavisBannedFilesLover FALSE
zmprov ma user@domain.tld +amavisSpamLover FALSE

(This is an assumption, someone please correct me if I’m wrong.)

Now, it’s also possible to completely disable spam and virus filtering, here’s how to do it:

zmprov -l ms `zmhostname` -zimbraServiceEnabled antivirus
zmprov -l ms `zmhostname` -zimbraServiceEnabled antispam

However, if you do this, you will end up with an ugly “UNCHECKED” tag inserted into the subject line of every e-mail. To get rid of that you’ll need to edit /opt/zimbra/amavisd/sbin/amavisd and change the following value:

$undecipherable_subject_tag = '***UNCHECKED*** ';


$undecipherable_subject_tag = '';

And then restart Zimbra:

/etc/init.d/zimbra restart

Enabling RBLs

zmprov mcf zimbraMtaRestriction "reject_rbl_client" zimbraMtaRestriction "reject_rbl_client" zimbraMtaRestriction "reject_rbl_client" zimbraMtaRestriction "reject_rbl_client" zimbraMtaRestriction "reject_rbl_client"

This will enable the following RBLs:


To see which zimbraMtaRestriction options are enabled:

zmprov gacf | grep zimbraMtaRestriction

You can also add/remove RBLs from the administration console; you’ll find the option under Configure->Global Settings->MTA in the “DNS Checks” section. I haven’t found how how to remove a single RBL via the CLI without wiping out the whole list — if anyone knows of a way, please let me know!

Archiving/exporting/importing a user’s inbox

This is handy if you want to move a user from one server to another, or if you need to export and archive the mailbox of a user who no longer exists.

zmmailbox -z -m user@domain.tld getRestURL "//?fmt=tgz" > /tmp/user_inbox.tar.gz

Then, to import to another server:

zmmailbox -z -m user@domain.tld postRestURL "//?fmt=tgz&resolve=reset" /tmp/user_inbox.tar.gz

Working with grants

Retrieve grants for a user’s folder (Calendar, in this example):

zmmailbox -z -m user@domain gfg /Calendar

Grant read only access to user1@domain’s calendar to user2@domain

zmmailbox -z -m user1@domain mfg /Calendar account user2@domain r

Remove all grants to user2@domain on user1@domain’s Calendar

zmmailbox -z -m user1@domain mfg /Calendar account user2@domain ''

Permissions are represented by the following letters: r, w, i, x, d, a

(r)ead – search, view overviews and items
(w)rite – edit drafts/contacts/notes, set flags
(i)nsert – copy/add to directory, create subfolders action
(x) – workflow actions, like accepting appointments
(d)elete – delete items and subfolders, set \Deleted flag
(a)dminister – delegate admin and change permissions

So if you wanted to give all rights to user2@domain from the previous example, you’d replace the ‘r’ with ‘rwixda’.

Working with mountpoints

Mount “/Inbox/Shared Data” from user1@domain.tld’s account to “/Inbox/User1 Shared Data” on user2@domain.tld’s account:

zmmailbox -z -m user2@domain.tld cm "/Inbox/User1 Shared Data" user1@domain.tld "/Inbox/Shared Data"

To delete the mountpoint*:

zmmailbox -z -m user2@domain.tld df "/Inbox/User1 Shared Data"

*Be extremely careful when doing this! Make sure that you are deleting the mountpoint and not the source directory (in the example above, this would be the “/Inbox/Shared Data” directory on user1@domain.tld’s account)

Enabling the Dumpster

The dumpster feature allows users (and more importantly, admins) to recover deleted messages. There are four settings that control this behavior:

  • zimbraDumpsterEnabled – TRUE/FALSE determines whether the dumpster feature is enabled
  • zimbraDumpsterPurgeEnabled – TRUE/FALSE determines whether users can empty/purge their dumpster
  • zimbraDumpsterUserVisibleAgend where n is the number of days you’d like to allow users to view/recover the messages stored in the dumpster.
  • zimbraMailDumpsterLifetimend where n is the number of days you’d like to keep items stored in the dumpster before automatically purging them.

Let’s say for example, you want to keep all deleted messages (for legal/auditing purposes) for two years and you don’t want the users to be able to purge the messages they’ve deleted. You’d run a command similar to this one (as the zimbra user):

zmprov mc default zimbraDumpsterEnabled "TRUE" zimbraDumpsterPurgeEnabled "FALSE" zimbraDumpsterUserVisibleAge "1d" zimbraMailDumpsterLifetime "730d"

This will enable the dumpster for the ‘default’ COS; disable purging; allow users to see the messages in their dumpster less than a day old; and keep messages in the dumpster for two years (730 days). This is just an example, of course but it should provide a good understanding as to how to use these options.

Listing all user accounts for a domain

zmprov -l gaa

Setting a password from the command line

zmprov sp user@domain 'b3%356sf^578685'

Enable local authentication fallback (useful for using both LDAP and local authentication simultaneously)

zmprov md domain.tld zimbraAuthFallbackToLocal TRUE
zmcontrol restart

Getting a list of all folders for an account

zmmailbox -z -m user@domain.tld gaf

Get a list of message IDs for the first 1000 messages in “/OLD Mail/Inbox” and save them to a file

zmmailbox -z -m user@domain.tld search -t message -l 1000 'in:"/Old Mail/Inbox"' | awk '{print $2}' | sed -e '1,4d' | tr '\n' ',' | sed -e 's/,,//g' > messageids.txt 

Then, do something with those messages; in this example, we’re going to move them to “/To Be Deleted”:

zmmailbox -z -m user@domain.tld mm `cat messageids.txt` "/To Be Deleted"

Raise the number of items that Zimbra Desktop or the Zimbra Web Client will display per page

zmprov ma user@domain.tld zimbraPrefMailItemsPerPage 500

Zimbra will only allow any single user account to have 10000 contacts total, this is how you raise that limit

zmprov ma user@domain.tld zimbraContactMaxNumEntries 20000

*Note: Before you do this, take some time to examine whether it’s really necessary. Make sure the account doesn’t have a bunch of duplicate contacts.

List all contacts for an account

zmmailbox -z -m user@domain.tld gact

List all contacts for an account and save the IDs to a file

zmmailbox -z -m user@domain.tld gact | grep 'Id: [0-9].*$' | tr '\n' ',' | sed -e 's/Id: //g' -e 's/,$//g' > contactids.txt

Then, do something with those contact IDs; in this example we’re going to delete them:

zmmailbox -z -m user@domain.tld dct `cat contactids.txt`

Route a user’s e-mail to another mail server

zmprov ma user@domain.tld zimbraMailTransport smtp:someothermailhost.domain.tld:25

… or set a user’s mail transport back to the default setting:

zmprov ma user@domain.tld zimbraMailTransport lmtp:domain.tld:7025

Route an entire domain’s mail through another SMTP server

zmprov md zimbraMailTransport

Further Reading:

Zimbra Administrator’s Guide

Zmmailbox Reference

What a n00b! | Zimbra junk mail options you didn’t know existed

Zimbra Wiki: Turning on or off RBLS

Zimbra Forums » [SOLVED] unchecked

Zimbra Wiki » Improving Anti-Spam System

Zimbra Account Export / Import from Command Line

Configuring Zimbra for Split Domain During Mail Migration

DDoS via DNS Amplification and Windows Server 2003

A quick show of hands; who else is still running Windows Server 2003 somewhere on their network? Ok, how many of you depend on those servers for DNS? It’s 2012 for fuck’s sake… what the hell is wrong with you people?

… I kid, I kid.

Unfortunately for the time being, I’m included in that group. I’ve got more than a few clients who still rely on the Windows Server 2003 DNS — which is the reason I’m writing this post.

This morning I had a client complaining about their Internet connectivity being quite unreliable. It was easy to determine that this was a DNS-related problem: pinging (Google’s public DNS) was successful while resolving was not. This particular network only has a single DNS so naturally that is where I looked next. Running netstat -a revealed a ton of outbound traffic — all DNS queries — directed towards their upstream DNSs and the root servers. Their DNS was making these queries, but why? I’d disabled recursion on that server literally years ago, but for some reason it was still responding to recursive queries — look at the “Flags” section of the log snippet below (this particular snippet was generated by windows’ DNS debug log). Notice where it says RD 1. This means the query was recursive:

20121105 08:40:29 F94 PACKET  02612A00 UDP Rcv     ebe4   Q [0001   D   NOERROR] ALL   (4)ripe(3)net(0)
UDP question info
  Socket = 512, recvd on port (65535)
  Remote addr, port 53
  Time Query=12890, Queued=0, Expire=0
  Buf length = 0x0500 (1280)
  Msg length = 0x0025 (37)
    XID       0xebe4
    Flags     0x0100
      QR        0 (QUESTION)
      OPCODE    0 (QUERY)
      AA        0
      TC        0
      RD        1
      RA        0
      Z         0
      RCODE     0 (NOERROR)
    QCOUNT    1
    ACOUNT    0
    NSCOUNT   0
    ARCOUNT   1
    Offset = 0x000c, RR count = 0
    Name      "(4)ripe(3)net(0)"
      QTYPE   ALL (255)
      QCLASS  1
    Offset = 0x001a, RR count = 0
    Name      "(0)"
      TYPE   OPT  (41)
      CLASS  4096
      TTL    0
      DLEN   0
      DATA   (none)

Next I had a look at the firewall’s logs. The firewall has logging configured on all policies that allow requests from the public Internet, so when I saw this:

(For security purposes, we’ll pretend that the public IP address of the DNS targeted by the attack is

Traffic Log for Policy:

(Src = "Untrust/Any", Dst = "Global/MIP(", Service = "DNS")

Current system time is Mon, 5 Nov 2012 08:43:21

Time Stamp Action Source Destination Translated Source Translated Dest Duration Bytes Sent Bytes Received Application

2012-11-05 08:43:11 Permit 17 sec 13446 72 DNS 
2012-11-05 08:42:55 Permit 17 sec 13446 72 DNS 
2012-11-05 08:42:39 Permit 17 sec 13446 72 DNS 
2012-11-05 08:42:23 Permit 17 sec 13695 72 DNS 
2012-11-05 08:42:07 Permit 17 sec 13197 72 DNS 
2012-11-05 08:41:51 Permit 17 sec 13529 72 DNS 
2012-11-05 08:41:35 Permit 17 sec 13446 72 DNS 
2012-11-05 08:41:19 Permit 17 sec 13363 72 DNS 
2012-11-05 08:41:11 Permit 1 sec 75 208 DNS 
2012-11-05 08:41:09 Permit 2 sec 90 120 DNS 
2012-11-05 08:41:05 Permit 2 sec 86 219 DNS 
2012-11-05 08:41:03 Permit 17 sec 13446 72 DNS 
2012-11-05 08:40:47 Permit 17 sec 13446 72 DNS 
2012-11-05 08:40:31 Permit 17 sec 13446 72 DNS 
2012-11-05 08:40:15 Permit 17 sec 13446 72 DNS 
2012-11-05 08:39:59 Permit 17 sec 13446 72 DNS 
2012-11-05 08:39:55 Permit 3 sec 75 91 DNS 
2012-11-05 08:39:43 Permit 17 sec 13446 72 DNS 
2012-11-05 08:39:27 Permit 17 sec 13446 72 DNS 
2012-11-05 08:39:11 Permit 17 sec 13363 72 DNS 
2012-11-05 08:38:55 Permit 17 sec 13612 72 DNS 
2012-11-05 08:38:39 Permit 7 sec 9462 1112 DNS 
2012-11-05 08:38:33 Permit 17 sec 25730 72 DNS 
2012-11-05 08:38:33 Permit 1 sec 83 1251 DNS 
2012-11-05 08:38:27 Permit 4 sec 90 106 DNS 
2012-11-05 08:38:19 Permit 3 sec 90 130 DNS 
2012-11-05 08:38:17 Permit 17 sec 24817 72 DNS 
2012-11-05 08:38:01 Permit 1 sec 166 1271 DNS 
2012-11-05 08:37:19 Permit 4 sec 79 95 DNS 
2012-11-05 08:37:17 Permit 2 sec 79 95 DNS 
2012-11-05 08:37:15 Permit 1 sec 79 95 DNS 
2012-11-05 08:35:21 Permit 3 sec 84 100 DNS

…It was pretty obvious what was going on. There were a few other suspicious IP addresses in the logs other than including, but not limited to:

  1. Loads of traffic originating (i.e., “distributed”) from multiple source IPs? Check.
  2. Internet connectivity (i.e., “service”) pretty much dead (i.e., “denied”)? Check.

This has all the makings of a Distributed Denial of Service attack (DDoS). This particular type of DDoS is known as a DNS Amplification Attack, technically it’s a distributed reflected denial of service attack (DRDoS). It can occur when you are running an open DNS and somebody with malicious intent notices.

After blocking inbound requests from all of the suspicious IPs and verifying that service had been restored, I shifted my focus back to the DNS. There are two places in the DNS Management Console where you can disable recursive queries:

…But as far as I can tell, the DNS built into Windows Server 2003 will allow you to change these settings and then it disregards your configuration and does whatever it damn well pleases. You’d think that between the two of these configuration options, the server wouldn’t respond to any recursive queries. Sadly this is not the case as you can see in the test results from DNSStuff:

DNSStuff also provides a link in the test output that describes which steps you should take in order to close an open DNS. Unfortunately…

NOTE: These instructions show you how to completely disable recursion. This is the best practice. However, if you need to run a DNS server that is both authoritative and recursive/caching, you will need to check the DNS server documentation to find out how to enable recursive lookups only for your local network. It seems that there is no way to do this with Microsoft DNS; if so, you will need to use other DNS server software or use a hosted DNS service. If anyone is aware of a way to get Microsoft DNS to allow recursion only to specific IP ranges, please let us know -- lots of people would like to do that.

This is the default behavior of the Windows Server 2003 (and 2008, 2012 from what I’ve read) DNS. In other words, it is insecure out of the box — this is analogous to allowing unauthenticated, unrestricted relaying on a mail server by default. Thanks Microsoft!

Anyway… since the company-in-question has it’s website hosted on the local network and their only DNS also serves as the authoritative DNS for their domain name, my next course of action will be to configure a separate non-windows DNS and use that to host their zones. Let this serve as a cautionary tale to any of you out there who might be using a Windows server as an authoritative NS for domains and a resolver for queries originating on the local network.