ISA Policy Storage 101

Introduction

ISA Server Enterprise and Standard Editions use different locations for the persistent policy store, but there is only one functional location for ISA Policy; in each local ISA server’s registry and file system. Since the registry limits maximum hive size, and because ISA policies can be quite large (especially with some 3^rd-party products), the ISA installer creates separate hive files for ISA storage. These hive files are located in %IsaInstallFolder%\StgData\. 

Any policy data that would exceed 10k in the registry is written to a BLOB (binary large objects) file in the same folder as the registry hives and a pointer to that file is placed in the registry instead. Although the BLOB files are accessible directly, they can only be interpreted through ISA Storage.

All policy storage activity (read/write, import/export) operates through calls to the ISA Storage Service (isastg). ISA installer sets access controls on these files to prevent inadvertent or malicious manglement.

Standard Edition

Because ISA Server Standard Edition has no need to share the policy store, it uses only the local policy storage. This storage is spread across three registry locations:

On startup, Microsoft Firewall (fwsrv) calls to the Microsoft ISA Storage (isastg) to read the current policies. If isastg returns an error while being asked to read the policies during startup, fwsrv logs an alert and enters lockdown mode.

Enterprise Edition

There are two locations for ISA policy in Enterprise Edition; one in Configuration Storage Server (CSS) and another in each array member’s registry. When you create a new Firewall Policy rule for example, this rule is first sent to CSS so it can be added to ADAM and then replicated to local registry. This means that if the ISA Server Firewall that you are locally creating this rule does not have access to the CSS during that operation, the policy will not be propagated to the local registry. By losing access to CSS you cannot create new rules, but ISA will honor the current rules since it is located in the local storage, the registry. The registry for EE is actually made up of three storage locations:

The active policy location is indicated in HKLM\Software\Microsoft\Fpc\Storage\ActiveEffective. This value rotates between HKLM\IsaStg_Eff1* and HKLM\IsaStg_Eff2* for each successful policy change. This behavior provides two benefits:

1. ISA can compare current policy changes to the old policy and thus detect changes which may break ISA functionality (CSS connectivity, for instance)

2. ISA can roll back to a previous policy if the new policy update fails for any reason

As with Standard Edition, Microsoft Firewall (fwsrv) calls to the Microsoft ISA Storage (isastg) to read the current policies on startup. If isastg returns an error while being asked to read the policies during startup, fwsrv logs an alert, but unless both registry storage locations are unreadable, it won’t enter lockdown. In this regard, Enterprise Edition is much more resilient than Standard Edition.

Note: the polices stored in the IsaStg_Eff locations are stored in a format identical to Standard Edition policy, and thus the Enterprise context for these policies is lost.

What it all boils down to:

1. ISA Standard Edition has only one policy storage, so if policy storage updates or initial load fails, it cannot function.

2. ISA Enterprise Edition can still perform as a firewall/proxy using the last known good policy in the registry even if CSS is not available. Only if this system-local copy fails to initialize properly will the firewall service enter lockdown for policy load failure

3. You cannot reverse-engineer the registry-based Enterprise Edition policies to CSS-format storage

4. In a disaster recovery situation, you cannot export the registry keys and import in a new system as an attempt to recreate the firewall policies.

5. If you deploy a single CSS for your Enterprise firewall solution, you’re risking a complete Enterprise rebuild when (not if) that CSS fails.

6. If you use any method besides ISA Export / Import for disaster recovery, you risk losing data

Author

Jim Harrison, Program Manager, Forefront Edge CS

Tech Reviewers

Mohit Saxena, Security Technical Lead (Forefront Edge CSS Team)

Yuri Diogenes, Security Support Engineer (Forefront Edge CSS Team)

Nathan Bigman, Content Publishing Manager (Forefront Threat Management Gateway)

Vic Singh Shahid, Escalation Engineer (Forefront Edge CSS Team)