NTFS Security Not Transferred When Copying Files

When copying files from one server to another, the NTFS security ACLs on them are not transferred, and the files inherit the permissions of the destination folder.  If the permissions are simple, and set at just one level at the top of the folder hierarchy, it’s not a big deal to just set them again manually.  But if you have multiple folder levels of settings that may or may not be the same, or if you have particularly sensitive data and you want to be sure the security of that data is maintained, here is what you can do.

1.        Transfer the files over using whatever file copy utility you like.  I like RichCopy, which is just a nice, GUI front-end to robocopy.

2.       Even though you have avoided using the command-line for the transfer itself, you are still going to have to use it now to get the file/folder security settings moved over.  For each folder that you transferred using Richcopy, run the following command from the source server:

robocopy "X:\sharedfolder" "\\servername\newshare"  /E /COPYALL /SEC /XC /XN /XO /R:1 /W:0

The "/xc /xn /xo" part of the command excludes files from being copied over again.  The “/E /COPYALL /SEC” switches actually re-sync all the security settings for all the files/folders, so they end up matching the security that is set on the source.

(Robocopy is part of the Server 2003 Resource Kit)

Posted via email from Aaron Johnstone

Set up VPN Client Access on a Cisco ASA

This article walks through how to configure a remote access VPN connection on a Cisco ASA 5500-series firewall.

1.  Log in to the Cisco ASDM
2.  Go to the Wizards menu and run the VPN Wizard.
3.  Choose the ‘Remote Access’ type on the VPN Tunnel Type page:

4.  Choose “Cisco VPN Client” for the VPN client type.
5.  Set your pre-shared key and your Tunnel Group Name
6.  Choose the client authentication method, either using the local user database or an AAA server group
7.  Add a DHCP pool to be used for users connecting using a VPN client; use a different subnet than one already in use on your LAN

8.   Configure the DHCP scope options, such as DNS, WINS, and default domain name
9.   Set the IKE and IPSec policies; I normally use the defaults, which currently are 3DES-SHA
10. Set the Address Translation Exemption and split tunneling options.  Typically, I use the internal network that the VPN-connected client will need access to and enable split tunneling.
11. Click Next, then Finish.
12. Go check the NAT exemption rules.  You should have a rule on the inside interface, exempting any traffic that is going to the VPN subnet (in this case from NAT.  Should look like this:

13. That is it; you are done!  You should be able to set up your Cisco VPN client, connect to the network, and test by pinging one of the servers on the internal LAN subnet.

    Posted via email from Aaron Johnstone

    Configure Cisco ASA remote access VPN to use RADIUS

    This article will help with setting up a Cisco ASA 5500-series firewall to use RADIUS to query a Microsoft Windows Active Directory domain controller to authenticate users who are connecting in using the Cisco VPN client.

    1. Install the Internet Authentication Service (IAS) Windows component

    2. Open the IAS console

    3. Add the Cisco ASA as a RADIUS client

    4. Edit the remote access policy in the IAS console as needed; enable “Unencrypted authentication (PAP, SPAP)” on the Authentication tab of the profile

    5. Connect to your ASA (assuming you are using the ASDM)

    6. Go to the Properties tab, then to AAA Setup à AAA Server Groups

    7. Create new server group

    8. Add a server to the group

    9. Test the authentication

    10. Go into your VPN settings on the ASA (General à Tunnel Group à properties of the remote access VPN)

    11. Go to the General à Authentication tab and change the Authentication Server Group property to the new AAA Server Group that you just created

    12. Check the box to enable LOCAL authentication if the server group fails

    13. Test it with an Active Directory user account from outside using the Cisco VPN client

    How to create a DFS replica in Server 2000

    When you are creating a DFS replica of a shared folder to a new location:

    Create a shared folder on the destination server

    Right-click on the share in the DFS management tool and choose Add Replica…

    Select the shared folder you just created

    Configure the replication to happen automatically.

    After you have created the replica, right click on the new replica and TAKE IT OFFLINE until the replication has completed.  This is the most important step.  If you leave it online, users can and will get directed to the new location, which will appear to be missing files/folders.

    Once you are satisfied that the replication is complete (i.e. the size of the folder on both servers and the number of files and folders match), then you can bring the new replica online.

    Posted via email from Aaron Johnstone

    Capturing Packets on a Linux Server

    Use the command:

    tcpdump | grep isakmp

    This displays all packets passing through the tcp/ip stack on the linux server, pipes the output to the “grep” command, and ends up only displaying packets which are related to “isakmp”, the key exchange when attempting to establish an IPSEC PSK VPN connection.  Use other strings after ‘grep’ to find other types of packets.  Or, leave off the pipe and grep if you want to drink from a firehose. 🙂

    Posted via email from Aaron Johnstone

    Reverse PTR Troubleshooting

    If you administer a mail server, do you know if your reverse PTR (‘pointer’, aka Reverse DNS) record is set up correctly?  If you don’t know, then probably not.  It’s not one of those things that happens ‘automagically’ when you run through the Exchange 2000/2003/2007, Sendmail or <insert name of any other mail-handling software> installation process.

    One way you can tell if your reverse PTR is NOT set up correctly is if you regularly have delayed our bounced email when sending messages to aol.com, rr.com, or hotmail.com.  Those are some of the higher profile domains which do reverse lookups on connecting mail servers.  And they are not very forgiving.  If your PTR record is not set up correctly, they and others will delay or reject messages from your mail server IP address.

    So, let me give a quick overview of how the reverse lookup process works in the context of sending an email, and what you can do to make sure your PTR exists and is correct.

    When you send an email:

    1. Your mail client submits a message to the server; if it is for a non-local address, your server puts it in the outbound SMTP queue.  Let’s say your email address, the source, is aaron@source.com it’s going to john@destination.com.   For the purpose of this post, I’ll assume you are not using a smarthost.
    2. Your server performs a DNS query to find the MX records for destination.com.  It gets a response like ‘mail.destination.com’
    3. Your server resolves the MX record mail.destination.com to its IP address, which we will say is
    4. The SMTP service on your server then makes a connection to on TCP port 25.  For our example, the WAN IP address of your mail server will be
    5. SMTP then ‘introduces itself’ (using EHLO or HELO) and provides the receiving server with its name.  THIS is something that was probably configured during the installation of your mail server, and is typically mail.source.com or something similar.  So, at this point, the receiving mail server, mail.destination.com, sees an incoming SMTP connection from a server at claiming to be mail.source.com.  How does the server at mail.destination.com know that the sending mail server is really who it says it is?  That is where the reverse lookup comes into play.
    6. The receiving server at mail.destination.com takes the connecting IP address,, and does a reverse lookup on it.  A reverse lookup is a DNS query that is looking for a specific type of record, called a PTR.  It is called a reverse PTR because, during the DNS query process, an IP address is resolved to a name.
    7. The reverse DNS lookup on results in a response that is (hopefully) “mail.source.com”.  Notice that the response matches what the sending server said that it was in the introduction in step 5.  This is ideal.
    8. Next, the destination server takes that response and does a regular forward lookup on it.  So it just finds the ‘A’ record for mail.source.com.  That query should return an IP address that matches the source IP, in our case
    9. At this point, the reverse lookup process is complete.  The receiving mail server is satisfied that the sending server is who it says it is and allows the connection to proceed.  The destination server may actually allow the sending server to specify the source and destination email addresses before performing the reverse lookup; this depends on how the server was set up by the administrator.

    Now, how can you make sure reverse lookups done on your mail server IP address go as smoothly as outlined above?

    Gather the following information:

    • Find out how your mail server is introducing itself when it is connecting to other mail servers.  This is a setting in the SMTP server properties (‘Send Connector’ in Exchange 2007) and is likely going to be ‘mail.yourdomainname.com’ or something like that.  Again, it was probably set when Exchange (or other mail-handling software) was installed.  More technically, this is the name being given along with the EHLO or HELO command when your server connects to another mail server.
    • Look up the current IP address associated with the name you found in the item above.  If you looked on your Exchange server send connector and found that it was set to use mail.source.com, just ping that address and see what IP address you get.  Depending on how your internal DNS is set up on your network, you may get an internal address when doing this.  You need to know the external IP address that is given in response to a query for the name, so you may have to do this step from a computer outside your network.
    • Find out the WAN IP address that your mail server is using to send email.  One fairly reliable way to do this is just to get on your mail server and go to www.whatismyip.com.  Another way would be to look at the NAT rules on your firewall to see what address traffic from your mail server is being translated to on the outside.
    • Look up the current reverse PTR record for your mail server IP address.  A couple of websites that I use for that are MXtoolbox and ZoneEdit.  Often, the result you get here will be the default for your ISP, and may look like this:  cpe-71-123-67-229.hot.res.rr.com.  That is bad.

    Armed with this information, you can now determine whether you are in good shape, or if you need to take action.

    Verify everything is Ok or fix the problem:

    1. Does the WAN IP of your mail server already have a valid reverse PTR record that matches your domain?  Or, does it look like my example, cpe-71-123-67-229.hot.res.rr.com.  Typically, the most difficult thing to get changed is the reverse PTR record.  These are usually controlled and created/changed by your ISP (Time Warner Cable, AT&T, Comcast, etc.).  There are different ways to request that a reverse PTR be set or changed depending on the provider.  It can be as simple as sending an email to reverserequest@twccs.com (for Time Warner), to having to sacrifice your first-born child (for AT&T).  Just kidding, although for some reason, AT&T has made it exceptionally difficult in the past to get a reverse PTR set up.  I’ve had to go so far as to have AT&T host the DNS records for my domain in order to have them host a simple reverse PTR record for me.  Bottom line, go to your provider and ask for the process to create or change a reverse PTR record, and go from there.  All administrative overhead aside, the technical information they will need to set it up will be the WAN IP address of your mail server and what you want the record response to be.  In our example case, we would have provided them with as the WAN IP and told them that we wanted the reverse PTR for that IP to be “mail.source.com” (without the quotes).
    2. When you ping your EHLO address, mail.source.com, does the IP that is resolved match the WAN IP address of your mail server?  If not, you can fix this in a couple of ways.  Either change the ‘A’ record for mail.source.com to be the IP address of your mail server, or change the WAN IP address of your mail server.  Obviously, you should be careful when changing DNS records or IP addresses.  Make sure you get someone else in your IT group involved for a sanity check so you can make sure you are not going to be causing some other problem trying to fix this one!
    3. Is your SMTP server EHLO address set to a valid external DNS name?  In our example, I used mail.source.com.  However, I have seen mail servers configured to use ‘sbserver.domainname.local’, which is not a valid DNS name on the Internet.  In this case, you will have to set your EHLO address to something similar to the example; something that likely matches your domain name.

    That’s it!  If you went through all this and your reverse PTR was already in good shape, great!  If not, then I hope that this helped you to find your way.  It was painful for me when I learned this, because I did it the hard way.  Thanks for reading.

    Posted via email from Aaron Johnstone

    How to Recover Your Firefox Master Password

    From Lifehacker:

    How to Recover Your Firefox Master Password

    If you’re using Firefox’s built-in password management, you should also be using its master password feature to protect your saved passwords from prying eyes. But what happens if you lose your master password?

    Since the master password prevents anyone from accessing your saved passwords, you’re out of luck if you lose your master password—that is, you can’t access any of your saved credentials without it.

    That’s where the free, open source tool FireMaster comes in. FireMaster is a command line tool designed specifically to recover your master password from Firefox. Here’s how to use it:

    1. Download FireMaster and extract it to a folder on your desktop.
    2. Open a command prompt. (Shortcut: Hit Win+R, type cmd, then hit Enter.)
    3. At the command prompt, change the FireMaster folder to your active directory. The quickest way to do this is to type cd , then drag and drop the FireMaster folder from your Desktop onto the command prompt—which will automatically fill in the path to that folder. Then just hit Enter.
    4. Construct your FireMaster crack command. FireMaster supports a lot of different options, but you can speed up the process if you can narrow down a few points to customize your password cracking. For example, if you know you’ve only used alphabet characters (a through z), adding the following to your command can speed up a brute force attack significantly: -c "abcdefghijklmnopqrstuvwxyz" For the purpose of testing and providing an example, I wanted to see how long it would take for FireMaster to crack a password containing only letters (a through z) that I knew was exactly six characters long. The resulting command looks like this:

    FireMaster.exe -b -q -l 6 -c "abcdefghijklmnopqrstuvwxyz" -p "??????" %appdata%\Mozilla\Firefox\Profiles\1sq2zzh2.default

    As you can see, I’m telling FireMaster to try a brute force crack on a 6-character master password using only the letters a through z. (You should read through the usage information to get a better idea of what options you’ve got for customizing the process to what you know about your password to speed things up.)

    In the last part of the command, I’m pointing FireMaster to my Firefox profile folder, where the key3.db file exists (this is the file that contains the encrypted password information). The last folder in that path will differ for you, but everything up to that folder (i.e., %appdata%\Mozilla\Firefox\Profiles\ will get you most of the way there. (If you only have one Firefox profile, you should just see one folder inside Profiles; use that folder.)

    1. After you’ve constructed your command, just hit Enter to get cracking. Using the command constructed above, FireMaster took roughly 23 minutes to crack my Firefox password. If I didn’t know how long the password was, it would take significantly longer (you can offer a minimum and maximum password size to help narrow things down a little further). That said, it clearly wasn’t all that difficult to crack my password given all I knew about it. It gets much harder the more secure your password is (think unusual characters and long passwords).

    Posted via email from Aaron Johnstone

    Virtual Machine Performance Tweaks

    Came across this in a TechTarget article:

    Easy Mistake 1: Virtual machine screensavers
    Screensavers are an absolute requirement for desktops in the hallways of our brick-and-mortar offices. They ensure that a user who walks away from his computer returns to one that has been secured against prying eyes. Screensavers can also provide protection in data centers. If screensavers on servers activate and lock the console after a few minutes of inactivity, they can protect that environment from an intruder who gains physical access.

    But screensavers are a quiet consumer of processor resources. No matter how insignificant that screensaver seems, the processor power required to draw the pipes crawling across the screen or to scroll your favorite company slogan consume a percentage points of overall processor power. While that might not seem like much, consolidated virtual environments might have 10 or 15 virtual machines (VMs) running on a single virtual host. These percentage points add up when they are multiplied by the number of VMs. Even worse, if your environment uses hosted desktops through a virtual desktop implementation, this practice likely costs even more.

    So turn them off. Remember that many environments enforce screensavers through group policies, which may mean an exclusion from existing group and corporate security policies.

    Easy Mistake 2: Managing from the console
    This second mistake is one of my favorites, because it is common among IT administrators everywhere. Do you manage your infrastructure components by remoting and logging into their individual servers? Do you run the Exchange Management Console from your Exchange server? Do you check domain name server (DNS) settings from the server’s console? Do you manage Active Directory by remoting your domain controllers?

    If you are, stop.

    As with screensavers, this practice is a big no-no in virtualized environments because of the level of resources required to create and maintain an instance of the Explorer shell. Just logging into a virtual machine is hard on that VM’s processor utilization. The process of creating a shell for the console can spike processor utilization during the login and logout process. Actually using any of the consoles on that server further consumes valuable resources. Logging in and accomplishing activity on your VMs’ desktops increases the amount of memory they consume.

    Microsoft provides the Remote Systems Administration Toolkit, PowerShell and VBScript, as well as many other tools for efficient virtual machine management. All these lightweight tools require much less VM capacity than a traditional login. So use them, and avoid wasting processing power and memory like an amateur.

    Easy Mistake 3: Antivirus and anti-malware scanning of VM disk files
    Your corporate security policy might not allow for the exclusion of Virtual Hard Disk or Virtual Machine Disk Format (VMDK) files from antivirus and anti-malware scans. But be aware that the real-time scans of such products can substantially reduce the overall performance of these files — and, thus, their virtual machines. Since a VM’s processing is highly dependent on its disk subsystem, any extra activities that slow down that process slow it down as well.

    That’s not to say that VM disk files shouldn’t be subject to security scanning. Scheduled scans of such files can ensure that they don’t get infected, without the processing overhead of real-time scans. Also, some of today’s more advanced scanning products are beginning to incorporate virtualization awareness to reduce their overall impact. If your security policy will allow it — or if you can bribe your security officer to look the other way — definitely consider excluding these files from your real-time scans.

    Easy Mistake 4: Windows Server’s power options
    At conferences around the country, I’ve encountered the final mistake repeatedly. The default power option of Windows Server 2008 upon installation is set to "Balanced." Of the three options available — Balanced, Power Saver and High-Performance — this is the second of the three in terms of overall system performance. You might save a few dollars on energy, but at the cost of wasting some of the server’s processing power. Resetting the radio button to the high-performance option has a noticeable effect on how well VMs will perform.

    Group policy is probably the easiest way to do so. If you create a new policy and navigate to "Computer Configuration > Policies > Administrative Templates > System > Power Management," look for the policy called "Select an Active Power Plan." Configuring this policy across your server infrastructure ensures that you always run with highest performance.

    Posted via email from Aaron Johnstone