Hi everyone. I am new to ISA, so forgive me if the question is a bit naive, but any help or points in the right direction would be greatly appreciated.
Our current environment has a single pair of ISA servers redirecting traffic to backend services (publishing ActiveSync or OWA or...). It was originally setup as a Configuration Server and a Member Server in a workgroup environment at one location. I am trying to not only change to a domain controlled environment, but plan to use a redundant datacenter to build in fault tolerance-redundancy. I have a few questions, but will ask them one or two at a time, because follow ups will be based on answers given.
1. When using an AD environment, who houses the configurations with ISA 2006? Is it the AD controller that takes over this function? Or do you still have a Configuration Master? I want to tie into the LDAP of my current domain, as well as participating domains for authentication and management purposes, but it would be ideal if one of my AD servers in a dedicated ISA domain could house the configs so I don't have to have a configuration store. I can't make out the documentation as to who actually houses this info in an AD structure.
2. What is the best way to build in redundancy and fault tolerance, if one site were to fail from a two datacenter configuration (see attached image)? Ideally, I am looking to have four servers spread across two datacenters, and supposing Location 1 were to fall into the ocean and sleep with Atlantis, I would like Location 2 to still be active and floating. I know that in my current architecture, if the Configuration Master were to die, and the Member ISA were to have a power failure, then once the Member ISA rebooted it would not know what to do because it can't find a Configuration store (unless my testing was a fluke and this really shouldn't happen). So given four servers in two locations, would I have to have two configuration masters and constantly duplicate settings across the two groups? Or could they all be tied into one farm and somehow have a new lead bull if the current leader was shot (i.e. if Location 1 was litterally under water and completely dead, CAN or how can Location 2 survive if it's power were interrupted)?
From: Southern California
Converting your ISA firewalls to domain members is an excellent idea. The good news for you is that the ISA configuration is held in the Configuration Storage Server (CSS) regardless if the CSS or array members are in a domain or not. Of course being domain members makes authentication between the CSS and the array members much simpler and more secure.
With regard to redundancy, you can handle that in any number of ways. You can configure another CSS and array in your remote site and still manage them centrally. The biggest challenge you'll face is client access. You'll need to direct clients to the appropriate location, which will require some sort of GSLB solution or, at a minimum, DNS changes.
So what do you mean by managing the CSSs from a central point? Is there a master CSS, and two sub CSSs? Or is the management through the AD domain? I know the plan is to have a warm backup site, and the DNS/Routing will be handled by someone in case of the emergency situation (I think the plan is to switch DNS and routes in the emergency situation, but I am not 100% clear on that as it is still a plan in progress), so it seems that two smaller arrays will most likely be the solution to go with. How do two CSSs and arrays update each other when implementing new rules and changes and such? That is what I was kind of confused on. The two arrays scenario would be really good in terms of always knowing you have a CSS available.
Do you know of a good document or something that also tells what AD handles in relation to the ISAs when added to the domain? Are there added GPs in AD when ISA is installed into the domain? I am planning on using a separate domain for the ISA servers, and then linking through LDAP via ISA to the other domains for each individual domain's authentication (this ISA scenario uses several different domains on the back end to publish specific elements for each of these "departments"). This seems best to me, but I would love more input as to why this may or may be good/bad. I am open to suggestions right now.
From: Southern California
The CSS (Configuration Storage Server) uses Microsoft's Active Directory Application Mode (ADAM) technology. Essentially it is a stand-alone Active Directory. It functions in much the same manner, serving in this case as an LDAP directory that store configuration information for the ISA array. It is, just like AD DS, a multi-master directory database. You can connect to any CSS and make changes that are ultimately replicated to all other CSS hosts.
If you are planning a warm backup site, you can create a separate array in your existing enterprise, then when you create access policies that apply to all arrays in your enterprise. If you are doing publishing (reverse proxy), you will have to duplicate those rules and configuration on your backup site array.
There are no changes made to your existing Active Directory when you add ISA firewalls to your domain. No additional group policy objects are added either. You shouldn't require a separate domain for your ISA firewalls, but if they are in separate domains they can authenticate users natively with any domain that there is a trust established with.
I think I just have one more question as of now, because you have given me some key info. The last question would be:
Like AD, do you have to trust between arrays for the Enterprise wide policies to work between CSSs? We are so large, I am sure there could be other ISAs out there that are being used for something a little different than the ones I manage, and maybe even in the same DMZ, and I would hate to go applying an Enterprise Wide policy that really does indiscriminately publish to all ISAs housed within an enterprise zone.
This has all been a great help. I am going to setup a test environment and try our the dual lan multiple CSS ISA setup. I may be asking more questions after setting up some enterprise level policies if I cant get it to work out right. I am going to create an AD environment for this just so I can manage the user roles to the servers more effectively, since we are so large and I am not in the "network administrators" group. Also, although I know Thomas said it is not more secure, I feel like it couldn't hurt to have domain that doesn't let any information out about the backend if breached somehow, and allows me more control over the AD environment for ISA.
From: Southern California
No, there is no trust between ISA enterprises at all. When you create an enterprise, you have to explicitly add arrays to the enterpise and members to arrays. One enterprise knows nothing of any other enterprise that might be in your environment. When we talk about an enterprise policy, it would apply only to arrays within the enterprise that you are managing. Also, you can have multiple enterprise policies and apply them individually to different arrays as well.