Friday, 20 June 2008

Using ISA Server 2006 to Protect Active Directory One-Way Forest Trusts

An area that I get involved with my 'day job' quite a lot is protecting Microsoft Office SharePoint Server (MOSS) 2007 and Windows SharePoint Services (WSS) extranets with ISA Server. Depeding on the customer needs, and security policy, this often results in an architecture design that includes a one-way Microsoft Active Directory forest trust. The key concept of this model is to solve two things; namely functionality and security.

So, lets look at functionality first - this is the 'forest trust' bit:

By using a forest trust we have a way for both internal and external users to share extranet resources. By its very nature, a forest trust is often popular because it ensures that internal users will be able to access extranet information transparently. By this we mean that users will be able to use their normal Windows credendials (that they are normally logged in with) to access extranet resources without the user even realising that this is occuring.

Next, lets look at security next - this is the 'one-way' bit:

Placing external users into an internal Active Directory environement, the 'Intranet forest', is never really a good idea, as the forest is the only real security boundary in Active Directory. Subsequently, a common solution is to create an 'Extranet forest' that is used to host external user credentials and create an isoltation point or segmented boundary from internal users. This makes the security people happy, and by way of a forest trust, this makes the users happy because it 'just works'. However, to make the security people even happier and to protect against account compomise in the Extranet forest, we ensure that the trust relationship between these two 'zones' is configured such that the Externet forest trusts the Intranet forest, but the Intranet forest DOES NOT trust the Extranet forest; hence the term 'one-way'. In this scenario, the Intranet forest would be termed 'Trusted' and the Extranet forest termed 'Trusting'.

So, what does this have to do with ISA then? Well, in addition to creating logical separation with forest boundaries, the model also normally includes some form of physical segmentation. This often results in the Extranet forest being placed into a perimeter network away from the internal network. In order to create this boundary and define the perimeter network, ISA Server is an ideal choice as the border firewall between these two security zones.

When you consider the communications that are required in order to support a forest trust, you will soon realise that you need a good application-layer firewall, ideally one that is able to inspect and control RPC traffic as this protocol is notoriously difficult to secure with most firewalls. If you combine this with the level of protection ISA Server can provide specifically for MOSS/WSS, it is not difficult to understand why ISA Server is often a key component in the overall security landscape for MOSS/WSS extranet solutions.

Obviously, I have over simplified things quite a bit and there are lots of other potential models (like the External Collaboration Toolkit for SharePoint for example) which could be used. However, a one-way forest trust model architetcure doesn't have to be just for extranets, they can pop up all over the place! You can also find a similar model in our old friend the Windows Server System Reference Architecture document set.

An overview of the architecture and concept being discussed is provided below:






So the the aim of this blog entry is to provide an overview of how to configure ISA Server to support this one-way forest trust architecture and define the necessary firewall policy rules and associated protocols to make it all work. This blog entry is by no means a 'ground up' walkthrough, but just gives a good overview of how ISA should be configured to allow for trust creation, validation and successful operation. In addition, I have tried to make my examples a little more generic by using a Web server, as opposed to SharePoint, but the overall concepts apply to lots of difference scenarios where a one-way forest trust is used across firewall boundaries.

One of the first things to realise with forest trusts is that they are not supported with Network Address Translation (NAT), hence your ISA Server will need a route relationship between the Extranet network and the Intranet network (or the other way around, as route relationships are bi-directional). Assuming this is in place, we now look at the necessary firewall policy rules to get it all working!

Like most security people, I like least privilege :-) Consequently, I will always create more firewall policy rules than are necessarily needed, just to ensure that we have sufficient granularity to provide a minimal set of communications by disabling certain rules that we don't need all the time.

A lot of the communications or protocols defined in this blog entry are based upon the following whitepaper and KB article. However, I found that these articles weren't clear enough in places and needed 'improving' based upon real-world findings from using ISA Server as part of the solution with customers.

As we have a route relationship between our networks, we gain little advantage of using ISA Server server publishing in this particluar example, and therefore all firewall policy rules are defined as access rules. The RPC filter is also one of the only application filters that works with access rules, so this makes the decision the correct one in my opinion.

Please Note: ISA Server SP1 now allows for RPC UUID filtering even when using access rules, which historically required server publishing to be used. With this change, RPC access rules are now as powerful as RPC server publishing rules, which is nice!. Consequently, it is possible to extend the current solution even further by defininig a specific list of UUIDs used for forest trusts. However, this is going to take a fair bit of testing, so I think I will leave it for a future blog post!

So, based upon the above, we can summarise the necessary firewall policies as follows:

  • AD Forest Trust: Allow Access for Forest Trust Creation/Validation
  • AD Forest Trust: Allow Access for Conditional DNS Forwarding
  • AD Forest Trust: Allow Access for Kerberos Client Authentication
  • AD Forest Trust: Allow Access for NTLM Client Authentication
  • AD Forest Trust: Allow Access for Object Picker (Extranet Web Servers)
  • AD Forest Trust: Allow Access for Object Picker (Extranet Domain Controllers)
  • AD Forest Trust: Allow Access for Object Picker (Extranet ISA Servers)

An overview of each rule is provided below:

AD Forest Trust: Allow Access for Forest Trust Creation/Validation

This rules allows the necessary communication required to initially setup and validate the trust relationship. Once the trust has been established, this rule can be disabled unless it is necessary to recreate/revalidate the trust for troubleshooting purposes. Following a least privilege approach, this step is strongly recommeneded for day-to-day operations.

AD Forest Trust: Allow Access for Conditional DNS Forwarding

This rule allows DNS servers in the Extranet forest to communication with DNS servers in the Intranet forest (and vice sersa). This is a based upon the use of conditional DNS forwarding which is needed to provide underlying name resolution services between the two AD environments.

Please Note: This is one of the few examples where using server publishing would have some security benefit as this would allow ISA Server to inspect and filter DNS as necessary. However, for this example an access rule is used for simplicity.

AD Forest Trust: Allow Access for Kerberos Client Authentication

This rule allow clients from the Intranet forest to authenticate to systems in the Extranet forest using Kerberos authentication. If Kerberos is not required, this rule is not required and should be disabled in order to adhere to least privilege.

AD Forest Trust: Allow Access for NTLM Client Authentication

This rule allow clients from the Intranet forest to authenticate to systems in the Extranet forest using NTLM authentication. It is very likely that this rule will need to remain enabled continuously and cannot be disabled, even in the event of using Kerberos.

AD Forest Trust: Allow Access for Object Picker (Extranet Web Servers)

This rule is needed to allow resources in the Intranet forest to be defined or 'picked' from the Extranet-Web server(s) themselves. For example within MOSS the object picker would be used to define SharePoint security permissions to a user or group in the Intranet forest. Without this rule, it will not be possible to select resources from the Intranet forest. Ideally this rule should be disabled most of the time and only enabled when adminiistrative changes are required.

AD Forest Trust: Allow Access for Object Picker (Extranet Domain Controllers)

This rule is the same as the Extranet Web Servers rule, but allows the object picker to be used from the Extranet Domain Controllers themselves. Depending on how the system will be administered, this rule may or may not be required. If this rule is not required, it should be disabled or deleted.

AD Forest Trust: Allow Access for Object Picker (Extranet ISA Servers)

Again, this rule is the same as the Extranet Web Servers rule, but allows the object picker to be used from the ISA Servers themselves. Depending on how the system will be administered, this rule may or may not be required. If this rule is not required, it should be disabled or deleted.

So, now that we know what firewall polices are required to map the key communications required for everthing to function, we now need to look at the required policy objects in more detail. Before approaching this, it is worthwhile defining a few elements of the example environement that will be used as part of firewall policies:

Extranet-Web => Computer object for the Web server located in the Extranet forest. This would be running MOSS 2007 in our SharePoint analogy.

Extranet-DC1 => Computer object for the First Domain Controller in the Extranet forest.

Extranet-DC2 => Computer object for the Second Domain Controller in the Extranet forest

Intranet-DC1 => Computer object for the First Domain Controller in the Intranet forest.
Intranet-DC2 => Computer object for the Second Domain Controller in the Intranet forest.

Extranet Domain Controllers => Computer set for the Extranet Domain Controller computers.

Extranet Web Servers => Computer set for the Extranet Web server computers.

Intranet Domain Controllers => Computer set for the Intranet Domain Controller computers.

Internal Clients => Computer set to represent Intranet machines that are allowed access to the Extranet Web Servers. In reality, this may be all Intranet clients.

Based upon the firewall polices discussed above, the following pictures show a more detailed view of the rules including the necessary source, destination and protocol definitions for each set of communications (click to enlagre the pictures)


AD Forest Trust: Allow Access for Forest Trust Creation/Validation



AD Forest Trust: Allow Access for Conditional DNS Forwarding



AD Forest Trust: Allow Access for Kerberos Client Authentication



AD Forest Trust: Allow Access for NTLM Client Authentication



AD Forest Trust: Allow Access for Object Picker (Extranet Web Servers)



AD Forest Trust: Allow Access for Object Picker (Extranet Domain Controllers)



AD Forest Trust: Allow Access for Object Picker (Extranet ISA Servers)


Please Note: Based upon real-world testing and experience it was necessary to add both UDP and TCP transports for some protocols in order to prevent the object picker from experiencing delays during Intranet resource browsing tasks. Without both transports, it often became quite painful to administer Intranet resources whilst waiting for components to timeout and use an alternative transport. It was also necessary to add the 'LDAP GC (Global Catalog)' to the object picker firewall policy rules for everything to function correctly, but this deosn't appear to be documented in any of the Microsoft documents I have seen.

So, that should be all you need to get the trust established and have a fully functioning one-way forest trust. With this platform in place, it is now possible to start using ISA Server web publishing to provide secure access to Extranet web services. If you got everything correct, users should be able to authenticate to ISA Server using either Intranet or Extranet forest credentials by way of the forest trust.

5 comments:

  1. Nice Article! Was very helpful......

    ReplyDelete
  2. For authentication to ISA Server using either Intranet or Extranet forest credentials, should the ISA server be a member of the Intranet or Extranet domain?

    ReplyDelete
  3. I would normally make ISA a member of the extranet forest for this scenario.

    ReplyDelete
  4. Excellent Blog - thanks for posting. Think it would be great to see a similar Blog for Forefront TMG 2010 and/or the possible use of AD DS, RODC or Active Directory Federation Services to supplement or offer an alternative to this design based on the recent releases of these products in relation to MOSS extranet etc...

    Thanks and keep up the great work.

    ReplyDelete
  5. @Anonymous

    To be honest, the setup for TMG would be pretty similar...

    I will think about doing an update for AD CS and ADFS, but more than likely I would combine TMG and UAG now...

    ReplyDelete