Richard Hicks has a great blog entry on this at http://tmgblog.richardhicks.com/2010/03/20/migrating-from-isa-to-tmg/ so I won’t go into detail on the overall process. However, there are a couple of gotchas to be aware of, although these aren’t anything to do with TMG itself.

First, as you are probably moving from Server 2003 to Server 2008, the number of trusted commercial Certificate Authorities has been trimmed down – if you are importing an SSL certificate from one of the less well known authorities,  the root CA may not be trusted. The import will succeed, TMG will allow you to specify the cert in publishing rules, but the results can then be unpredictable. Note that if you do have to add the root CA to your trusted CA store after TMG has been configured to use the SSL certificate, it is worth rebooting the server – without a reboot, TMG registers no errors, but client devices may display untrusted cert errors.

Therefore, when you import SSL certificates onto the TMG server, verify three things:

• The certificate is in the local machine’s Personal store
• 
• The certificate has a matching private key
• 
• The certificate path is fully validated
• 

Second, if you are planning a TMG to ISA migration, you will probably be moving to new hardware, as it will have to be a side by side migration. This obviously means that the MAC addresses of all your NIC’s are going to change, so talk to your networking guys – at the very least, you will probably need ARP tables on the relevant routers/switches to be flushed at the point you actually swap cables, otherwise you  may end up with the situation I was in, where TMG was up and running with no errors, but no traffic for publishing rules on addresses other than the native IP address of the external NIC ever hit TMG, which was definitely a head scratcher for a while .

HTH

Just a quick one, there are two great (free!) tools from MS for taking your default server install and securing it.

The first, SCW, is installed by default on all servers – run the tool and it will walk you through the process of identifying which roles and features have been installed and then produce a template which disables unused services and configures the Windows Firewall for the required services. Useful to note that it enables you to specify all the management tools required to manage the server, so you get all the goodness of having the firewall enabled without the pain of not being to get to the server with your favourite management tools. Once you have a template created, you can then use the command line component, scwcmd, to transform it and export it to AD as a GPO.

The second, the Security Compliance Management Toolkit, is available for download from http://technet.microsoft.com/en-us/library/cc514539.aspx. There are lots of elements to the toolkit, not least the ability to monitor ongoing compliance using SCCM’s DCM feature, but the interesting bit for this post is that it includes a tool to create GPO’s with a full suite of recommended registry settings to harden the OS – many of these settings are not exposed by GPO’s as standard.

HTH

Just finished implementing Direct Access in the office, using Forefront UAG to publish it. The wizard in UAG is a dream, everything just works, only things to note are that when you are asked to specify names for the DNS exclusion list, be careful to add all the names you would use to VPN in and to retrieve CRL’s – if you don’t, you’ll find that once the policy is applied, you won’t be able to access the LAN externally – and if you are doing the installation remotely, we would class this as a BAD THING. Easy enough to rectify, just delete the cached GPO policy (HKLM/Software/Policies/Microsoft) – everything under this key is volatile and will be restored next time GP is updated. Also, occasionally I noticed that running the GPO export script would error on the NPRT sections, saying the file was in use – rerunning the script worked every time.

The one thing to note, however, which is true for UAG and TMG, is that all the IPSec functionality is delivered by the Windows Firewall, not UAG or TMG. If, then, the Windows firewall has been disabled prior to the installation of UAG, you will find that the installation proceeds without a hitch, and running the Direct Access wizard works, clients that receive the group policies will connect over Teredo and IPHTTPS, everything looks great – but the clients can’t actually contact any of the internal servers, which is a shame being that contacting the internal severs is the entire point of the exercise Frustratingly, at this point you find a distinct lack of errors – all the components appear to be functioning perfectly. However, if you look at the Windows Firewall, you will see that the IPSec Connection Security Rules from the UAG wizard are present in Windows Firewall/Connection Security Rules, but are not present in Windows Firewall/Monitoring/Connection Security Rules, even though the Public Profile is marked as active. The solution? Enable the Windows Firewall for the Public Profile, if not all Profiles. Take home lesson? In Windows 7 and Server 2008, the Windows Firewall should no longer be treated as a bolt on extra, to be disabled unless there is a specific requirement for it to be on – it should now be treated as a core component, and only disabled when a specific requirement to do so exists.

A follow up to Certificate Strangeness – if you found that useful, you’ll probably be looking at making some changes to fix whatever issues you were having.

While it is theoretically possible to script ACL changes in Powershell and VBS, there’s no point in re-inventing the wheel when there are perfectly good command line tools available. Most of us are aware of CACLS, which has been around for donkeys years, but you may not be aware  its use is now deprecated, as it can incorrectly order the ACE’s on the ACL.

Ideally, you would use ICACLS.exe, as this is the utility currently shipped and supported by MS. However, there are 2 versions – Vista and upwards, and 2003 downwards. The Vista version will remove the inheritance flag from an ACL, but the 2003 version will not. Also, if the user is the owner of a file, the Vista version will successfully write an ACE onto an empty ACL, whereas the 2003 version will not. Of course, if you are fixing ACL’s on the MachineKeys folder and its files, these are the very 2 actions you need to accomplish. If we could just copy the exe across and use the Vista version on an XP system, everything would be gravy, but life is never that simple – it just errors out.

The solution? Let somebody else write the script

xcacls.vbs is available for download from the MS website, and successfully achieves both the actions outlined above on an XP system – be aware that its use is NOT supported by MS, but be that as it may, if its the only tool available on XP and 2003 ….

Here’s a scenario, you have a PKI, it all seems to be healthy, but when you try and use the certificates on your client systems, you get ‘unexpected results’

Alternatively, you have issued certificates previously, but when you come to renew, systems fail with ‘unexpected results’

At this point, you might be ready to tear your hair out, or just go home for the night (or the month…). Instead, its worth checking the permissions on the folder where the client OS stores the systems private keys. If the ACL has been changed from the system default, results can be, lets say, unpredictable.

On XP and 2003 systems, the folder in question is “c:\documents and settings\all users\application data\microsoft\crypto\rsa\machine keys”. This folder must NOT be inheriting permissions from its parent, and the ACL for the folder should contain Everyone:RW:This Folder Only, Administrators:F:This Folder Only – and nothing else! If you need to grant a service account access to one of the keys, add the account to the ACL on the specific file within the folder. Each file in the folder has explicit permissions defined, which will vary depending on the application that generated it, as a minimum they must include System:F and Administrators:R

Quite why the systems private keys would be stored in the All Users profile, I don’t know, but it has been moved in Vista and Server 2008 to “C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys”, which seems far more logical, and prevents errors where misguided administrators reset the permissions on the entire All Users profile. The ACL structure for the folder and its files remains the same.

A final word of warning – as with anything you read on the web, its always worth checking these ACL’s against a system in your environment that you know to be working, if you have one. It doesn’t matter how much you trust the writer, there’s nothing like the comfort of seeing a working system with your own eyes before you propose a change to hundreds or thousands of systems…

See the next post for info on scripting changes to the ACL’S