[isalist] Re: UAG now "officially" in production at HoG
- From: Jerry Young <jerrygyoungii@xxxxxxxxx>
- To: isalist@xxxxxxxxxxxxx
- Date: Mon, 4 Jan 2010 13:56:15 -0500
Uhhh....
"As I understand it, in theory, all external to UAG DA calls should bypass
TMG all together because that is coming in over IPv6 (thus the requirement
for externally accessible AAAA records). I could be wrong in that
assumption, though, as I'm still working to better understand how DA is
going to do its magic."
I was wrong. Apparently IPv6 is used only internally and the DA clients
establish a tunnel with the DA server over IPv4, through which IPv6 is used.
Some more requirements and limitations, too.
http://technet.microsoft.com/en-us/library/ee382304(WS.10).aspx
By the way, I failed to mention it specifically before, but DA requires
Windows Server 2008 R2 and Windows 7. Also notice that OCS 2007 is not IPv6
capable, thus the reverse proxy capability for it in UAG, I now assume. I'm
guessing the other publishing scenarios for Exchange supported by UAG are
also driven by no IPv6 capabilities (this included Exchange 2010 on Windows
Server 2008 R2).
This is a great conversation to justify my point that it doesn't make any
sense to separate protected access from remote access in different products.
:) Indeed, the following link speaks volumes toward that point:
http://technet.microsoft.com/en-us/library/ee382298(WS.10).aspx
In a situation where all corporate resources aren't running with at least
IPv6 capable clients, regular IPv4 clients will require access capabilities
via other means. At least according to this information, that is. :)
On Mon, Jan 4, 2010 at 1:02 PM, Jerry Young <jerrygyoungii@xxxxxxxxx> wrote:
> No, DA isn't like a VPN. And it may even hold your "client-certificate"
> requirement.
>
> Keep in mind that DirectAccess *requires* machine certificates (not sure if
> it can leverage user certificates, however, as the point is to have the
> managed machine "check-in" prior to a user ever logging on, thus
> facilitating instantly on access to corporate resources). DirectAccess also
> requires IPv6 (thus all the modifications to TMG on UAG to allow IPv6
> transition technologies - I can get that link again, if you like; it came
> from Jim's product group, so that adopters of DA without UAG could secure
> their DA servers, which straddle the edge :) - actually, here it is:
> http://blogs.technet.com/isablog/archive/2009/09/23/forefront-tmg-and-windows-7-directaccess.aspx).
> Security is realized through the leverage of the machine certificates with
> IPSec policies. You also "publish" specific servers or applications you
> want DA clients to be able to access on the DA servers (in this case the UAG
> servers).
>
> As I understand it, in theory, all external to UAG DA calls should bypass
> TMG all together because that is coming in over IPv6 (thus the requirement
> for externally accessible AAAA records). I could be wrong in that
> assumption, though, as I'm still working to better understand how DA is
> going to do its magic.
>
> You're right, though, PKI is another requirement and the CRL has to be
> published.
>
> Here's the landing page for DA:
>
> http://technet.microsoft.com/en-us/library/dd637827(WS.10).aspx
>
> And here's a large list of requirements for DA to work in an environment,
> although, as I dig I'm finding it isn't all-inclusive.
>
> http://technet.microsoft.com/en-us/library/dd637797(WS.10).aspx
>
> The deployment guide(s) found at this link has been helpful in ferreting
> out the additional requirements. I'll probably end up spending some time at
> a Microsoft Technology Center with my client to get into the nitty gritty of
> this stuff; while it bothers me that I have to dig for potential gotchas in
> determining the total requirements, I'm used to it. Although, to be fair, I
> suppose you can't expect Microsoft to capture all possible requirements in a
> single document since so many can depend on how a solution needs to be
> deployed.
>
> http://technet.microsoft.com/en-us/library/dd630627(WS.10).aspx
>
> Out of curiousity, are you going to be able to share "how you dunnit" with
> UAG and embedded TMG? I would certainly be curious as to the specifics. :)
>
> On Sat, Jan 2, 2010 at 3:37 PM, Thor (Hammer of God) <thor@xxxxxxxxxxxxxxx
> > wrote:
>
>> Not yet – BUT, I don’t really “need” DA with what I have published
>> through UAG. Does your DA model allow you to control what protocols and
>> services are available from your DA clients to the internal network? Or
>> does DA effectively give the clients a “full pipe” to the internal network?
>> The latter is my assumption, and it’s kind of a big deal to me.
>>
>>
>>
>> I would argue that TMG is “more” secure in that, as I have previously
>> mentioned, it gives you more authentication options. UAG does not allow one
>> to secure the portal or any back-end web server by requiring a certificate
>> to even connect in the first place. Yes, you can map certs to accounts in
>> IIS, but that is different. If I could attach a cert to a trunk in UAG like
>> I can in a TMG listener, then I would be tickled pink.
>>
>>
>>
>> In TMG, they brilliantly attach the client-side cert to the actual user
>> account created in AD; unlike most (if not all) client-side certificate
>> implementations I have seen (thanks Jim). Normally, if one has a
>> certificate PKI trust structure, the cert itself is all that is necessary,
>> and CRLs must be published and maintained in order for them to work
>> properly. Meaning, if I have 1,000 client certs out there, any one of them
>> could connect to my server if the trust was there and the cert was not
>> revoked. With TMG, simply disabling any particular use account
>> automatically denies the certificate authentication. To me, that is a major
>> plus.
>>
>>
>>
>> Does the DA access put the client in a “VPN Network” like TMG does in
>> order to determine where people can go and what they can do?
>>
>>
>>
>> t
>>
>>
>>
>>
>>
>> *From:* isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx]
>> *On Behalf Of *Thomas W Shinder
>> *Sent:* Saturday, January 02, 2010 11:40 AM
>> *To:* isalist@xxxxxxxxxxxxx
>> *Subject:* [isalist] Re: UAG now "officially" in production at HoG
>>
>>
>>
>> Dude,
>>
>>
>>
>> UAG is all about DirectAccess. Do you have that working in your “off
>> label” config?
>>
>>
>>
>> While I admit that UAG is the preferred publishing platform and is more
>> secure for publishing (in general) than TMG, without DA – you’re not getting
>> all it has to offer.
>>
>>
>>
>> Of course, I could argue that a DA + SSTP deployment should be separate
>> from the publishing deployment. The publishing deployment is for unmanaged
>> hosts, while the SSTP + DA deployment is for managed hosts.
>>
>>
>>
>> *From:* isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx]
>> *On Behalf Of *Thor (Hammer of God)
>> *Sent:* Saturday, January 02, 2010 12:07 PM
>> *To:* isalist@xxxxxxxxxxxxx
>> *Subject:* [isalist] UAG now "officially" in production at HoG
>>
>>
>>
>> So on the heels of our previous conversations, I’ve finally “officially”
>> replaced TMG with UAG at HoG.
>>
>>
>>
>> Jerry, this is where you might want to reiterate your questions/concerns.
>> Thing is, I really DO seem to remember you saying something about the “dual
>> network/separate infrastructure” bit, but you apparently have message ninja
>> skills.
>>
>>
>>
>> I think I see why MSFT has chosen not to support typical TMG deployments
>> on UAG, but man – it seems like a TOTAL waste to have so much “power” in TMG
>> seemingly “wasted” on a UAG install. For what UAG expects, it seems like
>> Windows Firewall could have done the job. Having a full install of TMG
>> doesn’t make sense to me, other than the fact that Whale was an acquisition
>> and built on top of TMG.
>>
>>
>>
>> That said, though completely unsupported, I’ve got UAG/TMG doing
>> everything and more that TMG was doing. One just has to be careful in the
>> way you group your rules, but only because of all the local protocol access
>> rules UAG builds. They get rebuilt every time a UAG configuration is
>> “activated” so I’ve got my logically located after the UAG rules. In this
>> way, I’ve been able to easily build my perimeter DMZ, publish SMTP, etc in
>> the TMG instance of UAG.
>>
>>
>>
>> Additionally, I now have a single point of access to get OWA and other
>> applications via the UAG portal, while simultaneously accessing RPC/HTTP(s)
>> for OA and Remote Desktop services (RDP over RPC/HTTP(s)) all on the same
>> “trunk” (listener). TMG can’t do that by itself. Further, for non-win7
>> clients wishing to utilize Remote Desktop Gateway functionality, I can
>> tunnel RDP over SSL using UAG as the gateway. To be sure, MSFT **could**
>> have made it possible for non-win 7 clients to use RDG (TSG) but I think
>> they chose not to on purpose.
>>
>>
>>
>> My only “real” issue now is the absence of “listener” type configuration
>> options in UAG, such as requiring a client-side certificate for a
>> connection. I’m going to have to figure a way to “hork” that config – as it
>> is now, there is no way to require a client certificate in order to access
>> the UAG portal, which I think is poo. That was a very strong
>> multiple-authentication measure to have available.
>>
>>
>>
>> The final step is to create the super-secret HoG authenticated external
>> proxy publishing config on UAG so Steve and Greg can bypass international
>> copyright laws, but that’s another story and wholly inappropriate for me to
>> discuss here. Oh, the things I do for Greg just so that he can watch that
>> stupid NCIS show (we won’t get into what Steve watches).
>>
>>
>>
>> Jerry, so far I’ve been able to recreate all the functionality of TMG on
>> UAG, so the “dual networks” and such are not necessary unless you want to be
>> supported. I’m not worried about it because I have you guys.
>>
>>
>>
>> ____________________
>>
>> *Timothy (Thor) Mullen*
>>
>> *thor@xxxxxxxxxxxxxxx*
>>
>> *www.hammerofgod.com*
>>
>>
>>
>> “Gandhi grills Tom Shinder’s steaks.”
>>
>>
>>
>> *[image: whitethr-crop]*
>>
>>
>>
>
>
>
> --
> Cordially yours,
> Jerry G. Young II
> Microsoft Certified Systems Engineer
>
--
Cordially yours,
Jerry G. Young II
Microsoft Certified Systems Engineer
Other related posts:
