Should Forefront TMG be a member of my domain?

What communication would need to take place between users?  I was planning on using it as a L2/L3 firewall specifically (we do not have anybody connecting externally).

You can configure Microsoft Forefront Threat Management Gateway as follows:

- In workgroup mode.

- As a member of an existing corporate domain.

- In a dedicated domain that has one-way or two-way trust with the corporate domain configuration.

There are a number of considerations when deciding whether to install in domain or workgroup mode:

When access rules require internal clients to authenticate for outbound access, Forefront TMG can authenticate domain user accounts against an Active Directory directory service domain controller. Web proxy requests in a workgroup environment can be authenticated against a RADIUS server.

Firewall client requests automatically include user credentials. To authenticate these requests, Forefront TMG should belong to a domain. In a workgroup environment, you can authenticate requests with user accounts that are mirrored to accounts stored in the local Security Accounts Manager (SAM) on the Forefront TMG server, but this requires some administrative overhead for secure management.

To authenticate inbound requests to internal Web servers using domain account credentials or certificate authentication, Forefront TMG must belong to a domain. In a workgroup environment, a RADIUS or SecurID server can be used for authentication.

To authenticate virtual private network (VPN) requests using domain account credentials or certificates, Forefront TMG must belong to a domain. In a workgroup environment, a RADIUS server can be used for authentication.

You can configure VPN client user mapping to map users of operating systems other than Microsoft Windows to domain user accounts. User mapping is only supported when Forefront TMG is installed in a domain.

In a domain, you can lock down the Forefront TMG server using Group Policy, rather than by configuring only a local policy.

In a domain environment, if Active Directory is compromised, for example by an internal attack, the firewall can also be compromised, because a user with Domain Administrator rights can administer every domain member, including the server running Forefront TMG. Similarly if the firewall is compromised, the domain in which Forefront TMG is located is also at risk. By default, the Domain Admins group is in the Administrators group on the Forefront TMG server.

You can use these article and refernces where you can find your planned deployment described as a commonly used scenario and Network topology considerations:

http://technet.microsoft.com/en-us/library/dd897048.aspx
http://technet.microsoft.com/en-us/library/cc995141.aspx
http://technet.microsoft.com/en-us/library/ee796231.aspx#kjdfg947jfht

Hope these links will help you understand the key features you will lose when you implement a workgroup model.

Regards,
MKhairy

Thanks; from the reading material it looks like I'll be doing an edge configuration in a workgroup with ISP redundancy.  I will configure rules using subnets rather than users/groups (1/2 of my infrastructure is not ina domain).

Do you have any experience with this type of deployment?

There is no question here. If you can add your ISA/TMG server to the domain then you should.
It is line with best practice, it gives you most flexibility, it less fiddlely in respect to configuration, you need to open less ports, it simplifies things if you are publishing services.

Even with the TMG server is added to the domain, should it receive its' own dedicated DMZ?

Looking at it, that TMG is a firewall it will probably be a gateway between various networks Client LAN, Server LAN and /or PErimeter network, maybe even Internet. How can it have a separate DMZ?

But I would definitely put it in a domain... Most namely you can use Kewrberos delegation, which for me is a great feature. Very user friendly but a bit more work for administrator. It works very good alongside a RADIUS one time password server or certificates with smartcards.

I'm planning on using TMG specifically as an edge device, with no user authentication required for Internet access.  60% of our users are on public wireless/kiosks, and are not part of our domain.  

In this scenario, what would be the benefit of kereberos delegation (I'm unfamiliar with that concept)?

KErberos delegation is used for Delegating credentials, and is solely used in web publishing. If you don't publish any resources to the Internet with the TMG you won't need this. Also, I would suggest you read this article about domain memberships.

http://www.isaserver.org/tutorials/Debunking-Myth-that-ISA-Firewall-Should-Not-Domain-Member.html

But if you ask me, I would have TMG / ISA as a domain member...

There is no benefit in Kerberos delegation based on your stated activities.

By adding the server to the domain, will that enable per user logging for domain crdentials?  I can't find any reference to that in the administrator's guide.

You can use domain groups and users on the rules and you don’t need to create to use Radius or LDAP servers to validate users credentials which in case of radius or LDAP increase the risk of account lockout.

One last question - I'm still a little unclear on the network design for a TMG server.  Currently, i have a VLAN dedicated to the connection between my firewall and my switch stack (think of it as a /30 network).  Would the same apply to a TMG server that's part of my LAN domain?  Seems like it would, as DNS could be set manually which would allow for domain membership without any hassle.