Hello we you using a java web application
when you go to a URL the page opens a JNLP file
https://mypage.com:port/codebase/launch.jnlp
when you go to mypage.com:port/codebase/ it would display the link to the lauch page
I would like to see when a user enter UAG simply launch_app and then it opening the java page directly.
Michael Massey
I was wondering if anyone could shed some light on pros, cons, caveats or anything on if it is possible to use a UAG array consisting of two devices to provide RDS gateway farm services for a published rds session host farm utilizing a connection broker.
Both the UAG array and RDS gateway farm require NLB and I was wondering if its possible or if there are any drawbacks to using NLB with both the internal and external nics? Is it supported? Would this provide the best possible highly available secure RDS publishing method using the UAG?
I am running UAG w/ sp1
Thanks.
Chris
I have UAG setup to use a SQL database as an identity store and it is working well for the most part. Users are able to login to UAG and authenticate properly, however when they enter an incorrect username and password it goes to "Page cannot be displayed" instead of telling the user their username or password is incorrect.
Has anyone experienced this? How can I get UAG to spit out a proper error message if the credentials are wrong?
Hello,
We are trying to publish Outlook Anywhere over UAG and we are experiencing major issue with UAG authentication.
We need to use custom repository as we have to map AD users to Exchange users. OWA is working fine.
But Autodiscovery and RPC applications uses NTLM and Basic authentication, and not UAG portal. That is understood.
But it seems that it is not possible to use custom repository for pre-portal authentication. We tried to switch from our custom repository to AD repository and NTLM authentication works.
When we try to use custom repository we see this error message in Web monitor:
User with source IP address failed to log into trunk uag (secure=1) using authentication server test with session ID C28512EC-218C-4DB5-9251-0D6FB90CA1C6. Error code is .
Uag traces have the following lines:
[2]d58.1648 02/03/2011-19:08:06.127 [usermgrcore whale::usermgr::CRepositoryMgr::GetRepository Repository.cpp@730] ERROR:in dummy repository --- repository [test]
[2]d58.1648 02/03/2011-19:08:06.127 [usermgrcore whale::usermgr::CRepository::CRepository Repository.cpp@66] ERROR:Failed to get the repository base type [DUMMY], type [DUMMY] [CacheCredentials], will use [0x00000001(true)] [2]d58.1648 02/03/2011-19:08:06.128 [usermgrcore whale::usermgr::CRepository::AuthenticateUser Repository.cpp@99] ERROR:This repository does not know how to authenticate user
[2]d58.1648 02/03/2011-19:08:06.128 [usermgrcore whale::usermgr::CUserMgrCore::AuthenticateUser UserMgrCore.cpp@527] ERROR:Failed to authenticate [<NULL>]
The question is:
How we can accomplish our task, when we need users to authenticate against AD repository, but pass custom credentials during SSO to Exchange server for Outlook Anywhere?
Thank you!
Hi
I have setup UAG SP1 with SSTP for our Win7 clients. Clients successfully connect to VPN, and they get IP address but they cannot access internal resources. They can access external resources without any problem.
UAG Setup
Internal NIC IP: 172.19.35.2
External IP: 2 Public IP address
I have added static route to 172.19.1.0 network. "route add 172.19.1.0 mask 255.255.255.0 172.19.35.1 metric 1 -p"
VPN Address Range: 172.19.35.21 - 172.19.35.200
Internal IP Adresses in UAG Network Setup: 172.19.1.0 - 172.19.1.255 and 172.19.35.0 - 172.19.35.20
Any help would be appreciated.
Thanks in advance.
Hi,
has anyone published Search Server 2010 (based on SharePoint 2010) over UAG yet? Are there any caveats or restrictions?
Best regards
Thomas
I need to reconfigure DirectAccess & getting activation failed error while activating configuration.
Any help appreciated.
Thanks
MS
This is the big day! The results are in for the last quiz in Contest 1.
First, I’ll go over the questions and answers and explain some interesting things that came up when I reviewed the answers I received, which had the effect of leading to two correct answers for one of the questions.
At the end I’ll post the “unofficial” results. The reason why they’re unofficial is that I like to wait until the next day to hear from anyone who might not have their answers scored correctly, in which case I update the leaderboard.
When the results are official on Wednesday, I’ll post the winners and the prizes (yes – there is going to be more than one prize!).
So let’s get to it!
================================================
Question 1:
Regarding Certificate Revocation List (CRL) checks, which is the following answers is true? (Choose all true answers): A. If the client certificate CRL check fails, the IPsec tunnels cannot be established B. If the server certificate CRL check fails, the IP-HTTPS tunnel cannot be established C. You must publish the private CRL Distribution Point if you use a commercial CA for your IP-HTTPS listener D. A CRL check is not performed when the DirectAccess client connects to the NLS
The answer to question 1 is B.
Answer A is incorrect because if the CRL check on the client certificate fails, the DirectAccess IPsec tunnels can be established. This is one of the reasons why revoking the computer certificate of the DirectAccess client is not the recommended way to blocking connections from potentially compromised DirectAccess clients. For more information check out http://blogs.technet.com/b/tomshinder/archive/2011/01/25/certificate-related-questions-and-test-lab-guide-guidance.aspx
Answer B is correct because the if the CRL check on the certificate bound to the IP-HTTPS listener on the UAG DirectAccess server fails, then the IP-HTTPS session establishment will fail. This is a hard coded option which is not configurable. For more information check out http://technet.microsoft.com/en-us/library/ee382307(WS.10).aspx
Answer C is incorrect because the commercial certificate provider publishes the CRL for you – there is no need for you to publish the CRL for the commercial certificate provider. The only time you would need to publish the CRL yourself is if you choose to bind a private certificate to the IP-HTTPS listener.
Answer D is incorrect because a CRL check is done when the client connects to the Network Location Server (NLS). For more information on this requirement, please see http://technet.microsoft.com/en-us/library/ee382275(WS.10).aspx ================================================
Question 2:
True or False: The DirectAccess client can use IP-HTTPS to connect to the UAG DirectAccess server when located behind an authenticating proxy where authentication is required: A. True B. False
The answer to this question is A or B.
When I wrote this question I had it in mind that the proxy would be transparently authenticating connections in the background for each new connection, like what the TMG firewall does. IP-HTTPS will not work in this scenario because there is no mechanism available to configure the IP-HTTPS client component to send credentials to the authenticating proxy.
However, there are other types of authenticating proxies that require you to authenticate you once (for example, what you see in hotels with captive portals). After you authenticate with the portal, the proxy will allow you outbound access without requiring credentials (except in the case where there is a time-out period and you have to authenticate again). Since several of your explicitly called out this scenario (the one that I didn’t think of when writing the question), I decided that both answers are correct because of the ambiguity of the question. So congrats to everyone! You all got this one right .
For more information on this issue, please see http://technet.microsoft.com/en-us/library/ee844126(WS.10).aspx
Question 3:For the default settings for end-to-end Authentication and encryption with UAG SP1, which of the following statements are true (select all true statements): A. End to End security uses IPsec tunnel mode from DA client to intranet server B. End to End security uses Authentication with null encapsulation C. End to End security authenticates only the first packet to the destination server D. End to End security uses ESP-NULL
The answer to this question is D.
Answer A is incorrect because End-to-End security uses IPsec transport mode to connect the DirectAccess client to the secure server on the intranet. IPsec tunnel mode is used to connect the DirectAccess client to the UAG DirectAccess server. For more information on this, check out http://blogs.technet.com/b/tomshinder/archive/2010/12/01/uag-directaccess-and-the-windows-firewall-with-advanced-security-things-you-should-know.aspx
Answer B is incorrect because by default, End-to-End security uses IPsec with null encapsulation, sometime referred to as ESP-NULL. This is different from Authentication with null encapsulation, when is enabled by AuthIP and available only when the secure server is Windows Server 2008 R2 – ESP-NULL is available when connecting to Windows Server 2008 and Windows Server 2008 R2. This is a configurable option. You can find more information on this at http://technet.microsoft.com/en-us/library/ee382325(WS.10).aspx and http://blogs.technet.com/b/tomshinder/archive/2010/09/12/a-short-introduction-to-uag-directaccess-end-to-end-security.aspx
Answer C is incorrect because this describes the behavior you see with IPsec Authentication with null encapsulation, which is not used by default, as discussed in the previous question.
Answer D is correct because ESP-NULL is the default method used by End-to-End security.
Question 4:Bob wants to enable a “manage out” scenario where intranet management servers can initiate connections to DirectAccess clients over the Internet. To do some basic testing, he wants the intranet management servers to be able to ping the DirectAccess client. When Bob tries to ping the DirectAccess client from the management server, the ping requests fail.
Bob checks the Firewall Rule he created to support inbound ping to the DirectAccess client and sees the following:
Figure A
Figure B
Figure C
Figure DWhich of these figures most likely explains the ping failure (Pick one)?: A. Figure A B. Figure B C. Figure C D. Figure D
The answer to question 4 is D.
There isn’t a whole lot of information contained in these screenshots except for the last one.
The first screenshot (A) just tells us that the connection is allowed.
The second screenshot (B) shows that ICMPv6 is allowed, so that shouldn’t be a problem.
The third screenshot (C) shows that the connection is allowed between the DirectAccess client and the IP address of the management station. There is a possibility that this is the wrong IP address, but there is nothing in the question that indicates that maybe the wrong IP address was included in the firewall rule. I’d keep this in mind, but look for a better explanation.
The fourth screenshot (D) has the interesting information – this graphic shows that Edge Traversal is blocked. When the DirectAccess client is using either Teredo or IP-HTTPS, Edge Traversal must be enabled for protocols that you want to allow inbound to the DirectAccess client from management stations on the intranet. This is not required when the DirectAccess client is using 6to4 to connect to the DirectAccess server. For more information on this, check out http://technet.microsoft.com/en-us/library/ee649264(WS.10).aspx (note that IP-HTTPS isn’t called out, but if you perform your own test, you’ll see that it is required for IP-HTTPS as well). While we don’t know for sure that the client isn’t using 6to4, it is the most likely answer to this question.
Question 5:Review the following figure:
Based on this figure, which of the following can you state are correct (pick all correct answers)?: A. The intranet tunnel is active B. The infrastructure tunnel is active C. The DirectAccess client is using IP-HTTPS as its active IPv6 transition technology D. The DirectAccess client is a domain member
The answer to question 5 is A, B, and D.
Answer A is correct because the DirectAccess client needs to authenticate using a computer certificate and machine account (NTLMv2) to establish the infrastructure tunnel. The intranet tunnel enables the DirectAccess client to connect to machines that you define in the “management servers” list in the UAG DirectAccess server configuration.
Answer B is correct because the DirectAccess client need to authenticate using a computer certificate and user account (Kerberos V5) to establish the intranet tunnel.
Answer C is incorrect because DirectAccess clients that use IP-HTTPS always use 2002 for their high order “quartet”, and the screenshot shows that the client is using 2001.
Answer D is correct because all DirectAccess clients must be domain members. The DirectAccess client doesn’t need to be a member of the same domain as the UAG DirectAccess server, but it must be a domain member for authentication and Group Policy assignment.
Now for the scores! The figure below shows the final score for Round 2 in Contest 1 (which is also Round 1 in Contest 2).
The final score for Contest 1 is based on the points assigned to the top three finishers in Round 1 and the points assigned to the top three finishers in Round 2. You can see the Round 1 and Round 2 points in the chart. If there was a tie for the first, second or third places in a Round, each member of the tie received the points for that position. The top score for a Round received 5 points, the second highest score received 3 points and the third highest score received 1 point.
The unofficial Contest 1 Results (note that these results are not official until FRIDAY – this is to make sure you have time to tell me I might have made a mistake on the scoring of your entry – therefore, like they say in horse racing, hold on to your tickets until the results are declared official!) are:
WINNER:
jasonj – 8 points PRIZE: Personalized Starbucks Card and Hard Copies of our UAG and TMG books!
2nd PLACE:
oblaba – 6 points PRIZE: Hard Copies of our UAG and TMG books!
christophf – 6 points PRIZE: Hard Copies of our UAG and TMG books!
3rd PLACE:
mika – 4 points PRIZE: Hard Copy of either our UAG or TMG book (your choice)
In addition, I’d like to acknowledge the participation of those who didn’t end up in the top three – but participated in each of the quizzes in the second round. It was a long haul and for those who stuck it out this long deserve some recognition. Therefore richardf, kenc, mrshannon and benl will all receive PDF copies of our UAG and TMG books.
I will be writing to each of you to obtain your mailing information after the results are made official. As for the unofficial winner – Jason Jones is a Forefront MVP and will be attending the MVP worldwide conference next month, so I will be able to present him his prizes in person.
So there you go! Thanks for participating in the Contest! It was a ton of fun and I hope you all learned some things along the way (I know I did!).
We’ll start Round 2 of Contest 2 next week – so you can take the rest of this off .
See you then!
Thanks!
Tom
Tom Shindertomsh@microsoft.comPrincipal Knowledge Engineer, Microsoft DAIP iX/Identity ManagementAnywhere Access Group (AAG) The “Edge Man” blog : http://blogs.technet.com/tomshinder/default.aspxFollow me on Twitter: http://twitter.com/tshinderFacebook: http://www.facebook.com/tshinder
Visit the TechNet forums to discuss all your UAG DirectAccess issues http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/threads
Stay up-to-date with “just in time” UAG DirectAccess information on the TechNet wiki http://social.technet.microsoft.com/wiki/tags/DirectAccess/default.aspx
Good afternoon,
I can use GPO to disable httpstunnel in our domain. However, for machines not in the domain I've tried typing in:
netsh interface httpstunnel set interface state=disabled
and I just get an "element not found" response. I'll confess I don't know what this means. Central security says we need to disable this (and other IPv6 items) but I don't know how to troubleshoot this issue.
UAG 2010 SP1 installed on domain joined server.
I have configured an ADFSv2 authentication server. Next I set up the Portal trunk using the newly created ADFSv2 authN server. No problem here, a smooth ride just like describe in the documentation (http://technet.microsoft.com/en-us/library/gg295327.aspx). T
The last page of the trunk wizard - and the documentation - states that federation metadata will no be located at https://<Portal_FQDN>/InternalSite/ADFSv2Sites/<trunk_name>/FederationMetadata/2007-06/FederationMetadata.xml or at the equivalent place in the file system.
Now, the problem is that metadata download fails, and in fact there is no ADFSv2Sites folder. In the InternalSite folder an almost empty ADFSv2 folder is found, but that's it.
Any ideas - Google/Bing has nothing for me?
Thanks,
Niels
Hi ,
I am trying to publish TS Web Access through my UAG. I have published it and I can access TS web Access page. But when I try to access any resource publish in “TS Web Access" getting an error” The remote computer could not be found." although this is the RDP to same TS server.
Please help.
Regards/Anwar
Hi this is the second time this has happened, UAG not open, tmg reports it cant see UAG, if I export the TMG config it complains about securid, if you try and access securid through the system policy and click "to" it bombs out. This is a brand new build just finished configuring it, am totally sick of UAG this week.
Keep getting the UAG configuration cannot be retrieved from forefront tmg
Looks like Im going to have to rebuild it again !
The UAG session manager not start, nor the world wide web web publishing service
The Microsoft Forefront UAG Session Manager service terminated unexpectedly. It has done this 1 time(s). The following corrective action will be taken in 60000 milliseconds: Restart the service.
I have a requirement on deploying UAG which use only the Publishing feature AND a single network interface card. Is this possible can be done? If yes, how to meet with the requirements? The UAG configuration/installation wizard prompt it required two network cards....
-Kevin
I would like a pop up box to appear when users get to the main trunk page. It is so they can agree to company policy before they log on.
I think that I need to configure the following file von\internalsite\login.asp but I need some help with the code and exactly where to place it.
Any help would be greatly received.
I have followed the samples for creating UAG SSO Forms Authentication outlined at
http://blogs.technet.com/b/fesnouf/archive/2010/10/01/implementing-uag-sso-with-scom.aspx
http://blogs.technet.com/b/ben/archive/2010/01/23/custom-form-login-sso-how-to.aspx
http://blogs.technet.com/b/fesnouf/archive/2010/03/18/understanding-and-extending-uag-web-sso-capabilities.aspx
However when testing this out, after I logon to Forefront and then launch the Legacy Application the Username and Password parameters are not being sent through.
Im not sure however if the section of XML I have written in WizardDefaults\FormLogin\CustomUpdate\FormLogin.xml is even being executed.
Is there a way to see if this file was accessed or where the problem may lie? I have checked the trace logs and Fiddler has confirmed no extra info is being sent through.
Here is the section of XML
<APPLICATION> <APPLICATION_TYPE>Legacy</APPLICATION_TYPE> <USAGE description="form_login"> <PRIMARY_HOST_URL>.*/abi-bin/login.*</PRIMARY_HOST_URL> <SECONDARY_HOST_URL></SECONDARY_HOST_URL> <SCRIPT_NAME source="data_definition">FormLoginSubmitStandard</SCRIPT_NAME> <USER_AGENT> <AGENT_TYPE search="group">all_supported</AGENT_TYPE> <POLICY>multiplatform</POLICY> <SCRIPT_NAME source="data_definition">FormLoginHandler</SCRIPT_NAME> </USER_AGENT> <MULTIPLE_LOGIN>true</MULTIPLE_LOGIN> <LOGIN_FORM> <NAME>F1</NAME> <METHOD>POST</METHOD> <CONTROL handling="dummy_value"> <TYPE>USER_NAME</TYPE> <NAME>user</NAME> <DEF_VALUE>usr</DEF_VALUE> </CONTROL> <CONTROL handling="dummy_value"> <TYPE>PASSWORD</TYPE> <NAME>pwd</NAME> <DEF_VALUE>whlpass</DEF_VALUE> </CONTROL> </LOGIN_FORM> </USAGE> </APPLICATION>
When I try to access to email activity on CRM from external browser, on the body email (under Subject), I get this issue in UAG appication Event or web monitor :"The URL you are trying to access contains an illegal path".
I have published CRM on UAG 2010 sp1 and I use SSL from external to Internal.
How I could resolve my issue ?
Thx,
Brahim.
Hi all,
I'm having a problem getting Activesync working on one of my IAGs. One of the devices is working fine, but the other device is having problems. I compared the IAG configs for the ActiveSync trunk between the 2 and they are setup identically with the exception of IPs. I get the messages below. The iPad I'm testing with says the connection to server failed. I use the same auth group for other trunks and they work fine. I get the messages below.
Warning 01/31/2011 09:57:36 24 ApplicationAuthenticationFailed"Application Authentication Failed Security"Security testsync(S)"testsync (S) Request failed, failed to reply to application's authentication request (HTTP 401 request). Trunk: testsync; Secure=1; User Name: <domain/user>; Application Name: Microsoft ActiveSync; Application Type: Activesync; Source IP: x.x.x.x; Session ID: 030CD8D9-8C5D-4FA4-89C7-F044A75AD453
Information 01/31/2011 09:56:11 13 SuccessfulLogin"Successful Login Security"Security testsync(S)"testsync (S) The following user logged into trunk "testsync" (secure=1): User: <domain/user; Source IP: x.x.x.x; Authentication Server: ga; Session: 18A60341-8F03-464A-9761-3773A4E3A580.
im running UAG on Win2k8 R2 and have the following Problem:
Im able to browse and delete Folders via the UAG Portal File Access with my User Account (User Account has Domain Administrator rights). But my Account has no rights on the Folders either browse or delete. With a normal Workstation (XP. Win7) im not able to browse or delete my Fileserver - like designed.
Is this a known Issue? Does anyone have the same Problem?
Regards Patrick
Hello
Is the any options to restrict ports which goes thru infrastructure tunnel?
Rgrds
Jarkko
UAG installs a FileAcc admin user when it installs. I don't feel comfortable having admin users that I do not know about that could be used as a means of attack - especially as I do not use file services. Can I delete or disable this user?
--Chris
We use IAG 2007 SP2 Update3. We allow some users to have RDP access to thier office PC's. We use "Microsoft Windows XP/Vista Terminal Services Client" Application Type and Socket Forwarding is set to Basic. Works fine for 32bit machines.
I realise that 64bit machines do not work with Socket Forwarding on IAG, but is there any alternative to us having to create a new application for each RDP and having Socket Forwarding set to Disabled? More and more users now have 64bit PCs and our application list is getting longer and longer.
Hello Experts,
We are using IAG server as reverse proxy for exposing SAP Enterprise portal(EP) content on intranet.In SAP Enterprise portal,we have multiple applicaions configured which are pointing to different systems in the landscape.When i launch SAP EP,IAG properly masking Url of SAP EP system and showing IAG server Url to users.in SAP EP,when i click on application link,SAP EP sends back Url of that applciation to browser and browser sends second request to load that contenet.so far good.After user is done with that application,if he/she clicks on another application link on SAP EP,server is giving error message about resource doesn't exist in a particular server.When we look at the server,it the host name of previous applciaiton.It should be host name of SAP EP.There is something going wrong in the URL Replacement.
Any thoughts on this would be very helpful.
Naidu
Has anyone had success deploying bandwidth management or QOS policy’s with UAG DA clients? I would think that TMG can do this, but TMG is not to have out-of-band configurations to it when deployed with UAG per microsoft. How could I provide a general rate limit to DA clients, better yet have different client groups with different rate limits. Of course I can throttle the entire bandwidth available to the WAN interface, but can I get more granular for example giving priority to SharePoint traffic over a background FTP file transfer traffic?
Greetings,
I seem to be having a problem with UAG and publishing Exchange 2010 and 2003 on the same Trunk. We are publishing them on the same trunk for a SSO as we migrate from Exchange 2003 to 2010. All is working well, we even have Enterprise Vault OWA working correctly...except for one problem...so far:
1) When I login to Exchange 2003 via UAG with IE as a "premium" client, I cannot delete any messages or folders. 2) When I login to Exchange 2003 via UAG using IE, Safari, or Firefox as a "light" client, everything works fine.
The error message I get is "Some items can not be deleted, they were either moved, already deleted, or access was denied". If i try to delete a folder, I get a message "Moving or copying items between Exchange Servers is not supported"
Anyone have any ideas or suggestions?
-Rob
Hi any idea when this will be fixed?
http://blogs.technet.com/b/fsl/archive/2011/01/27/uag-socket-forwarder-on-windows-7x64-and-rdp-tunnel.aspx
Doing the above worked for me, but I dont fancy talking users through or expecting our helpdesk to do it, I have just gone live as well... :(
An error you might run into when activating a DirectAccess configuration is the dreadful “Forwarding on the 6to4 network interface cannot be enabled”:
This often happens after you rebuild a server, and try to restore a configuration from backup, and is typically caused because of a duplicate 6to4 interface.
The first step of resolving this is to enable the interface manually, which is done this way:
1. Find the name of your 6to4 adapter by running the command netsh int ipv6 show int. This would often be “6to4 adapter”
2. Enable forwarding by running the command netsh int ipv6 set int <NAME> forwarding=enabled where <NAME> is what you found in step 1
Now, try activating DA again from the UAG console. You would probably be disappointed to see it fail again. If so, the reason is probably because the computer has duplicate 6to4 adapters, confusing the server. If so, you can easily fix this by removing the interfaces from the Device Manager:
1. Open Device Manager
2. Click View and select “View Hidden Devices”
3. Notice the two 6to4 adapters? There’s your problem. Remove both of them by right-clicking and selecting “uninstall”.
4. Close the device manager, and reboot the UAG server.
5. After a reboot, the 6to4 adapter will be re-added, but only once, so you should be good to go.
6. Activate the UAG configuration again, and this time, it should be fine!
Blog post written by Ben Ari
I have read thought he entire load ballancing guide and configured my external and internal DIP's and VIP's for all UAG nodes in my two node cluster. One thing it does not indicate is what side should have DNS server access (LAN or WAN or both)) and what side should have a gateway addess entered (LAN or WAN or Both). Right now I have a DIP and two VIP's on the WAN along with a gateway address on the DIP and on the LAN I have a DIP and VIP and DNS entered but no gateway. When I enter a gateway on the LAN it gives an error that two gateways are not recomeneded. I would think this is correct, but UAG servers are not able to access Windows Update (yes system rules are enabled in TMG) or any websites likewww.microsoft.com with ie.
Wow! This is it – the last quiz in Contest 1. That’s right – this is quiz 4 of the second round.
To celebrate this occasion and to make things more interesting, we’re going to have FIVE questions. This will give those who are behind a better chance of catching up and put some pressure on the leaders.
Let the game begin!
There you go! Five questions with five answers ready for you to send to me.
Send me your answer with the following email link:
tomsh@microsoft.com
by 11AM Central Standard Time (-0600 UTC) on Monday January 31.
Any help would be gratefully appreciated. Even if someone can confirm if our setup is viable or not would be a big a help.
Our setup: We have Forefront UAG 2010 (current update) with a remote desktop solution published in our portal, using the tunnelling option for XP. This points to a Terminal Server Farm (all 2008 R2) which is managed with Connection Broker. Users connect to UAG from XP Pro SP3 clients on the Internet.
Problem:Users connect to UAG portal without issue and can successfully initiate the Remote Desktop application. Once they enter their domain credentials at the initial Terminal Session Broker one of two things happens
Further Information:During the remote desktop connection process the Portal Activity Monitor shows the following until the user enters their credentials and the Connection Broker is consulted.Launched ApplicationsRD Application
Active Connectionshttps://myportal.mydomain.com:443 ->10.0.1.100:3389 via Simple Relay
When the Connection Broker tries to initiate a connection to a different server then the active connection on port 3389 via Simple Relay disappears and the RD client times out. However, the application still shows as active.
Also, TS Farm and connection broker work fine within our network via RDP. Only seems to be an issue when UAG/Secure tunnelling is in the mix.
Already Tried:
Any insights would be a big help. Thanks.
UAG 2010 (UAG) supports two types of network level SSL VPN:
Network Connector is aimed at legacy clients and SSTP for Windows 7 clients.
Network Connector supports both split and non-split tunneling configurations while SSTP, when accessed through the UAG portal, supports only non-split tunneled connections.
This can be a problematic for firms that want to enable a split tunneled configuration to reduce the bandwidth drain that VPN clients can extract when split tunneling isn’t supported. And with current network security opinions moving away from disabling split tunneling as a security solution (see my articles on split tunneling for more information at http://blogs.technet.com/b/tomshinder/archive/2010/03/02/why-split-tunneling-is-not-a-security-issue-with-directaccess.aspx), it makes sense that admins would want to enable split tunneling for their UAG SSTP clients.
Faisal Hussain provides a solution on his blog and you can find it at:
http://blogs.technet.com/b/fsl/archive/2011/01/26/uag-sstp-split-tunnel.aspx
WARNING:This is an unsupported solution and has not been tested or validated by CSS.
HTH,
A couple of good questions were asked on a recent blog post and I figured it was worthwhile to answer them in more detail in a separate post.
====================================
“Can you clarify a couple points related to Certificate Authorities and CRLs? I plan on getting a commercial certificate for the IP-HTTPS listener as you recommended, but how does that affect all of the other certificate related configurations in the test lab guide? The CA created on the domain server is completely separate from this commercial certificate, right?…”
The IP-HTTPS listener needs a web site certificate (intended use is server authentication) so that DirectAccess clients can establish an IP-HTTPS connection to the UAG DirectAccess server before establishing the DirectAccess IPsec tunnels. This requires mutual client and server authentication, something that is the default setting for UAG DirectAccess (the default for Windows DirectAccess is server authentication only).
The primary advantage of using a commercial certificate for the IP-HTTPS listener is that the commercial certificate provider maintains the Certificate Revocation List (CRL) and Distribution Points for you. Not only do they maintain that list for you, they also make sure that the CRL is highly available. While you could use your private PKI for the IP-HTTPS listener, you would then be responsible for maintaining the CRL and making sure that it it highly available.
Now how does this relate to what we did in the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess Test Lab Guide (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=71be4b7b-e0e9-4204-b2b5-ac7f3c23b16d)?
In the Test Lab we actually created a certificate template that removed CRL related information so that the DirectAccess client would not fail its IP-HTTPS connection when the CRL wasn’t published. This simplified the TLG environment because we didn’t need to go through the steps of publishing the CRL. In your production environment, you do want to make sure that the CRL is available for your private PKI; so you wouldn’t use the special configuration we did for the web site certificate template we used in the TLG. However, you don’t need to publish your private CRL because the commercial provider is handling the IP-HTTPS certificate’s CRL Distribution Points.
You still want to use your private PKI to distribute computer certificates to the DirectAccess clients and the UAG DirectAccess server. You also want to distribute computer certificates to any machines that you want end-to-end IPsec transport mode protection. And you want to make sure that the CRL is available so that you can revoke certificates (however, revoking certificates for DirectAccess clients is not an effective way to prevent them from connecting to the DirectAccess server – other methods should be used, such as disabling the computer account for the suspect DirectAccess client and changing the password of the user who lost the DirectAccess enabled computer). And you want to be able to use autoenrollment to make is easy to distribute the certificates.
The commercial certificate and the private certificates have no relationship to each other and don’t need any. The commercial certificate provider should be included in the Enterprise Root Certificate Authorities store on all your DirectAccess enabled machines.
========================================================
“And you mentioned that you wouldn't want to host the CRL on the DirectAccess server in a production environment. Is this only because of performance reasons or because of something else? And is this CRL not related to the IP-HTTPS listener? So, just to make sure I'm getting it, there is one CA and a corresponding CRL for the active directory domain, and then another CA/CRL (in this case commercial) for the DirectAccess connections. Is that right?…”
There are a number of reasons why you wouldn’t want to host the CRL Distribution Point web site on the UAG DirectAccess server, but probably the main one is that every time you reconfigure the DirectAccess settings using the UAG DirectAccess wizard, it will end up resetting your CRL Distribution Point web site. There are also traffic related reasons – since the CRL check requires anonymous access to the CRL Distribution Point web site, you increase both the amount of traffic and the attack surface on the UAG DirectAccess server.
You are correct that there are two CRLs in use in the DirectAccess scenario discussed here:
It’s important to note here that only a “soft” CRL check is done when the DirectAccess client connects to the UAG DirectAccess server. If the DirectAccess client fails the CRL check, it will still be allowed to connect. So whether or not the CRL is available doesn’t determine connectivity for your DirectAccess clients.
Tom Shindertomsh@microsoft.comPrincipal Knowledge Engineer, Microsoft DAIP iX/Forefront iX UAG Direct Access/Anywhere Access Group (AAG) The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspxFollow me on Twitter: http://twitter.com/tshinderFacebook: http://www.facebook.com/tshinder
Now for the moment you’ve all been waiting for – the answers to UAG SP1 DirectAccess Contest 1–Round 2/Quiz 2 and Contest 2 Round 1/Quiz 2!
Last week’s quiz was a bit different with some practical problem solving scenarios based on screenshots. Let’s see how you did:
===========================================
Question 1:Review the information in figure 1. (UAG1 is the UAG DirectAccess server and DC1 is on the intranet)
Figure 1
From the information provided to you in Figure 1, which of the following answers is most likely? (choose 1 answer) A. The Teredo server was moved off the UAG DirectAccess server B. The 6to4 relay router was moved off the UAG DirectAccess server C. The NAT64/DNS64 service was moved off the UAG DirectAccess server D. The ISATAP Router was moved off the UAG DirectAccess server
The answer to question 1 is D.
To be better understand the scenario, the figure below shows the network diagram for the test environment from which this screenshot was taken.
If you look at the screenshot we have three pieces of information we can use to determine the answer.
The first piece of information is the ping uag1 result. This returns a native IPv6 address assigned to the UAG DirectAccess server. In typical scenarios, when you ping the UAG server you will either see an ISATAP address returned, of if you’re using an IPv4 only network with the help of NAT64/DNS64, then you would see an IPv4 address. This indicates that the UAG DirectAccess server has a native IPv6 address assigned to its internal interface and is not using ISATAP to communicate with the internal network.
The second piece of information from from ping dc1. The ICMP Echo Reply is returned from an ISATAP address, indicating that ISATAP is being used on the internal network.
The third piece of information we have comes from tracert –d dc1. You’ll notice that the second hop returns an address on the same network ID as the IP address returned from the ping uag1. The last hop is to DC1, which is on an ISATAP subnet.
When you put these three pieces of information together, the best conclusion that you can draw is that there is a network device between the UAG DirectAccess server that is routing native IPv6 packets to an ISATAP enabled subnet. This device is an ISATAP router, which you can see in the network diagram as ISATAP1. Normally, the UAG DirectAccess server hosts the ISATAP server role – but in this scenario, the ISATAP router was moved to a separate machine.
Note that this network diagram is part of a larger network diagram that describes how to configure a multi-site UAG DirectAccess solution using ISATAP routers and a single ISATAP cloud for the intranet. I hope to be able to complete the documentation on that scenario soon and will post it here.
Question 2:Review the information in figure 2. (UAG1 is the UAG DirectAccess server and DC1 is on the intranet) (choose 1 answer)
Figure 2
From the information provided to you in Figure 2, what is the most likely roll for the machine with the IP address 2002:836b:4:8000:0:5efe:10.0.0.20 ? A. ISATAP router B. Windows Server 2008 R2 IPv6 RRAS router C. IP-HTTPS relay D. Teredo relay
The answer to question 2 is A.
Again, we have three pieces of information that we can work with to solve the problem.
The first piece of information comes from the ipconfig output. Here we can see the IPv4 and IPv6 addressing assigned to this computer – which is DC1 because we recognize the ISATAP address from the previous question. We also see a default gateway assigned to the ISATAP adapter, which is a link-local ISATAP address assigned to the machine with the IPv4 address 10.0.0.20. This indicates that 10.0.0.20 must be an ISATAP gateway (router).
The second piece of information comes ping uag1. Like in the first question, we see that UAG1 resolves to a native IPv6 address, which is consistent with the UAG DirectAccess server being assigned a native IPv6 on its internal interface and not using ISATAP itself.
The third piece of information comes from a tracert –d client1. The first hop address is the ISATAP assigned address to the machine that is assigned as the default gateway for the ISATAP adapter on DC1. The second hop comes from the native IPv6 addresses assigned to the internal interface of the UAG DirectAccess server. The third hop comes from a machine that is assigned an Teredo address, which you might not know since you don’t know the IP addressing on the external interface of the UAG DirectAccess server, but you do recognize that it is a native IPv6 address that is on a different network ID as the internal interface of the UAG DirectAccess server.
When we put these three pieces of information together it becomes clear that in order for DC1 to ping CLIENT1, it must travel over an ISATAP subnet, to an ISATAP router, which forwards the IPv6 packet over the native IPv6 subnet to the internal interface of the UAG DirectAccess server, which then routes the connection to the IP-HTTPS enabled DirectAccess client on the Internet.
Question 3:
Review the information in figure 3.Figure 3
Why is the first “quartet” for CLIENT1 different than the other IPv6 addresses on the network? (choose one answer) A. CLIENT1 is on a different ISATAP subnet B. CLIENT1 is on the Internet and has registered its IP-HTTPS address C. CLIENT1 is located behind a web proxy and has registered its 6to4 address D. CLIENT1 is located behind a NAT device and has registered its Teredo address
The answer to question 3 is D.
Answer A is incorrect because CLIENT1 is not assigned an ISATAP address. For more information on ISATAP addressing, see http://technet.microsoft.com/en-us/library/bb727021.aspx
Answer B is incorrect because CLIENT1 is “on the Internet” which implies that the machine is assigned a public IP address. When the machine is assigned a public IP address, it will register its 6to4 address. In addition, IP-HTTPS clients’ IPv6 address always start with 2002:
Answer C is incorrect because CLIENT1 is located behind a web proxy – which means that only IP-HTTPS is available to client and not 6to4.
Answer D is correct because CLIENT1 is located behind a NAT device and Teredo is used preferentially when the DirectAccess client is located behind a NAT device.
Wow! That was a good one – everyone did great and it shows that our DirectAccess contestants are pretty sharp when it come to IPv6. That’s a good thing, because I think that 2011 is going to be the Year of IPv6 given that we’ll run out of IPv4 allocations very soon.
Next Thursday I’ll post the last quiz in Content 1 and announce the winner! To make it even more interesting – I’m going to include FIVE questions. That will make it possible for anyone to get in the last jump to take home a winner for this round.
So set yourself up a reminder to check for the quiz on Friday January 28, 2011.
Our UAG environment consists of 2 UAG VM servers in an array on separate hardware. I installed TMG SP1 on each server and rebooted (not at the same time). I verified that TMG opened OK so proceeded to install UAG SP1 on both servers and reboot. When the master came back up, I opened the UAG Manager and the trunks were there, IPs were assigned to the trunks but the public host name was missing and all of the published apps were missing. There was too much missing for me to try to recreate during the downtime window so I reverted to the ESX snapshots I made and got the system back to a working state but I'm wondering what may have gone wrong or if anyone else has seen something similar. I didn't get any errors during the installation of either SP on either server. It all seemed to be going smoothly.
Back in March of 2010, I was approached by Packt Publishing, from the UK, to write a book about UAG. Somehow, even though the product-family (eGap, IAG and UAG) have been out there for many years, no book was ever written about any of the members, and this would be a 1st. I’ve recruited my good friend and colleague Ran Dolev to help, and together we started developing the content and writing it. It was a long journey, but even with my son being born in the middle of it, we still were able to finish the 1st draft within less than 5 months. The writing quality was so high, that the publisher decided to publish the book as-is, without any editing, as a “RAW” book, which is somewhat equivalent to a Beta version. We could have had the book out as early as November, but that was the expected release date for SP1, so we decided to push the release and include SP1 information in the book as well.
On Nov 16th, we sent out the final version of the last chapter, and now, 2 months later, the book is finally in print!
http://amazon.com/o/asin/1849681627
As you can see, the book is not cheap. The reason for the high price is the high cost – the book is digitally printed “on demand” (as opposed to most books, which are printed in large quantities). This method has a higher cost per copy, but is more suitable for books that have a limited target-audience, like UAG.
I personally feel that this amount is easy to justify. After all, a single support call to Microsoft costs hundreds of dollars, so if this book can save you even one of those, it would have paid for itself.
If you’re still not sure, check out the publisher’s page to download a sample chapter (chapter 3)
https://www.packtpub.com/microsoft-forefront-uag-2010-administrators-handbook/book
If you’re reading this, then you’re most likely a UAG customer, and as such, there’s a very good chance I’ve worked with you personally at some point. If so, please know that this book is written from me to you. It comes from a personal place, out of love for the product, and for you, the customers. I hope you will feel that, as you read through the book, and that the experience will be more than just education, but also a fun ride.
Sincerely,
Erez Ben-Ari
Hi, we are planning to move our UAG server to a new location but the location has a different external address pool. I read an old article that changing addresses is not supported, is this still the case? Would the whole thing have to be reinstalled?
Thanks in advance
It’s time for your weekly UAG DirectAccess quiz! We’re getting close to the end of contest 1, so make sure you don’t miss a step for the next two weeks.
Last week’s quiz was definitely tricky and introduced some obscure or difficult to find information. This week I’m going to try something a little different.
Remember to send your entries before 11AM Central Standard Time (-0600 UTC) on Monday January 24th.
To the questions!
Let’s see if this more “practical” approach to the questions is a bit less tricky than the quiz we had last week. This quiz is a nice test of your basic IPv6 knowledge – so good luck and have fun!
Send me your answers at:
by 11AM Central Standard Time (-0600 UTC) on Monday January 24th.
I have a single trunk UAG environment with two array members that I have recently put into production with numerous applications with which customized form fill and custom AppWrap is working perfectly. Let's say the domain for this trunk is portal.com and the main app for my environment is www.portal.com.
Now I want to setup another trunk that will house test/pre-production versions of the sites in my first trunk with the same domain name, but will be accessed via names that are indicitive of their non-production nature (e.g. preprod.portal.com).
I created the new trunk with a second IP address (trunk named PreProd) and have created an application on this trunk with a public hostname of preprod.portal.com. I should also note that the login page I am trying to fill is a similar URL to the production version (both PRIMARY_HOST_URL values in each form fill section is .*/[S,s]ecured/[L,l]1\.aspx.*) The application type is unique across both trunks. I can see that the custom AppWrap is detecting the page I want filled as it is doing the search and replace just fine. However the form fill of username and password never happens, I just get presented with the page I would expect to be filled.
I have triple checked my FormLogin.xml and I have even had someone else look at the file to make sure I wasn't overlooking anything. I have made sure that I used proper case as it relates to the <APPLICATION_TYPE>, <PRIMARY_HOST_URL> regex, form name and field names. FormFill.xml opens up in IE with no errors. I can also see that UAG detected that the entry I added for the preprod.portal.com form fill is in the PreProd trunk as it it listed with the correct AppID and form fill criteria in /von/conf/Websites/PreProd/conf/HTTPS_WhlFiltFormLogin.xml.
Any ideas of things to check or logs to go over?
This question comes up frequently when introducing admins to UAG DirectAccess. It makes sense, since public IPv4 addresses are getting more difficult to come by and in fact it’s predicted that there will be an exhaustion of the entire IPv4 address space by next month. So, why do you need two public IP addresses on the external interface of the UAG DirectAccess server?
There’s a short answer and a long answer. Let’s begin with the short answer (hat tip to Ben Ben Ari, Senior Support Engineer at Microsoft):
“When the Teredo adapter is active on the DirectAccess client, it will check the Teredo server’s public IPv4 addresses to determine what type of NAT device the client is located behind. The assessment is performed to determine which on of the follow four types of NAT are in use: One-to-one NAT, also known as Full-cone NAT Address restricted cone NAT Port-restricted cone NAT Symmetric NAT The detection process starts with the Teredo client sending a Router Solicitation (RS) message to the Teredo server’s IP first address (the first of the two consecutive IPv4 addresses on the external interface on the UAG server used by DirectAccess). UAG then replies from the 2nd IP address. If the Teredo client receives the reply, it deduces that the NAT type is “Cone” (option 1 or 2 above). If the client does not receive this reply, then it issues a second RS message, but this time, UAG will reply from its first IP, instead of the second. If the client gets this reply, it now knows that the NAT type is either Port-restricted cone (type 3) or Symmetric (type 4) NAT. Next, the client sends a request to the UAG server’s second IP address (which also acts as a Teredo server), and waits for another answer. When the answer comes, if it is from the same IP as the first, this signals to the client that the NAT type is Port-restricted cone (type 3). If they are different, this means that NAT is mapping the same internal address and port number to different external addresses and port numbers, which means that this is a Symmetric NAT (type 4).”
“When the Teredo adapter is active on the DirectAccess client, it will check the Teredo server’s public IPv4 addresses to determine what type of NAT device the client is located behind. The assessment is performed to determine which on of the follow four types of NAT are in use:
The detection process starts with the Teredo client sending a Router Solicitation (RS) message to the Teredo server’s IP first address (the first of the two consecutive IPv4 addresses on the external interface on the UAG server used by DirectAccess). UAG then replies from the 2nd IP address. If the Teredo client receives the reply, it deduces that the NAT type is “Cone” (option 1 or 2 above). If the client does not receive this reply, then it issues a second RS message, but this time, UAG will reply from its first IP, instead of the second. If the client gets this reply, it now knows that the NAT type is either Port-restricted cone (type 3) or Symmetric (type 4) NAT.
Next, the client sends a request to the UAG server’s second IP address (which also acts as a Teredo server), and waits for another answer. When the answer comes, if it is from the same IP as the first, this signals to the client that the NAT type is Port-restricted cone (type 3). If they are different, this means that NAT is mapping the same internal address and port number to different external addresses and port numbers, which means that this is a Symmetric NAT (type 4).”
If you want even more detail, this may help check out the Teredo Overview:
http://technet.microsoft.com/en-us/network/cc917486.aspx
A nice feature of SharePoint is SharePoint Mobile Access, which allows you to access SharePoint sites on a mobile phone, without having to cope with the busy SharePoint web interface on the phone’s small screen. This is a built-in feature of UAG, as well as Windows Mobile. Configuring this on UAG is not that difficult, but many users are not familiar with how to actually use it on the phone itself.
Let’s start with the UAG side. It’s pretty straightforward, and you might have guessed it yourself, but just to be sure we are all on the same page, this is how it’s done. To configure the UAG portal to support the mobile phone access, you need to enable the mobile browser on your published SharePoint application (on the UAG). To do so, open the application’s properties, and go to the Portal Link page. Enable the settings like this:
Simple, right? Now here comes the hard part…viewing this on the phone. It’s not REALLY hard, but since that part will be performed by your users, it may be a challenge to help all of them configure this correctly. The procedure is as follows:
1. Open the phones start menu, and go to the Office application:
2. On the office application, go to the SharePoint page, and tap on All:
3. On the All page, expand the bottom tab with the 3-dot button, and tap on Settings:
4. On the settings page, tap on UAG server :
5. On the UAG server page, fill in the UAG server details and tap Save:
After savings the settings, go back, and tap on “Open URL”, and type in the internal URL of your SharePoint server (the same one you would type if you were working on your computer in the office). The phone will open the URL through the UAG server you have configured, and you will be presented with your documents, which you can now open, edit and save!
DirectAccess is about being “always-on”. When I start my laptop in the morning, I’m ready to get to work. Even though I don’t work on the Microsoft campus, I’m able to connect to anything I want (that I have permissions to connect to) on the Microsoft intranet without thinking about connecting to an SSL VPN portal, some web application gateway, or a traditional network layer VPN connection. I just start the laptop and BAM! I’m connected. And IT is always connected to me too, so my laptop is always up to date and managed by Microsoft IT.
DirectAccess connections consist of two IPsec tunnels that fire up when the Private or Public Windows Firewall with Advanced Profiles are assigned to the machine configured as a DirectAccess client. When the Public or Private Profile is active, the machine configured to be a DirectAccess client will attempt to establish two IPsec tunnels with the DirectAccess server:
The infrastructure tunnel is established after computer certificate authentication and computer account NTLMv2 authentication. The infrastructure tunnel allows the DirectAccess client to connect to key resources on the intranet, such as domain controllers and management servers (WSUS, SCCM, SCOM, etc.). Intranet tunnel connectivity enables you to always manage the DirectAccess client, even if the user isn’t logged on to the computer. In addition, the intranet tunnel provides the connectivity required for the user to log on and establish the intranet tunnel.
The intranet tunnel is established after both computer certificate and user account Kerberos authentication is successful. In order to complete the user account authentication (Kerberos), the user needs access to a domain controller. That’s why you need the infrastructure tunnel to come up before the second tunnel can be established. The intranet tunnel cannot be established by using cached credentials on the client.
So what does this all to do with 3G connectivity? Mobile computers with 3G adapters are becoming increasingly popular. These 3G adapters are tremendously convenient, as you no longer need to depend on being able to connect to whatever local network where you might be physically located . All of us have gone through “the drill” of trying to connect to a customer’s network, a hotel network, or some public Wi-Fi network. Sometimes it’s easy, but more often than not there are some bumps that eat into your productivity. The 3G adapter allows you to get around those time-eating complications.
The problem is that not all 3G adapters and their supporting software are the same. The following describes an interesting issue that came up when a customer was using a particular 3G adapter:
“This morning I tested the “always-on” 3G connection scenario with my Rogers 3G adapter (http://www.rogers.com/web/content/wireless_network) and the built-in 3G GOBI (built-in mobile broadband technology - http://www.gobianywhere.com/) adapter in my HP Tablet and found that when using the Rogers USB 3G adapter an “always-on” connection is not possible, but when using an integrated 3G GOBI module it is possible (it really comes down to the software that is provided). The details of my test methodology and results are below…Rogers Rocket™ Stick – The Rogers Communication Manager software runs in User Mode only (does not run as a Service), so the connection is invoked when a user is logged on and disconnected when the user logs off. There is an “Auto-Connect” checkbox, but it only makes the connection when a user logs on to the device. Therefore the current software provided by Rogers does not support an “always-on” scenario. I verified this by looking at the activity light on the USB stick itself – Red is device is not ready, solid Blue is network detected, blinking Blue is network connected and active. For the duration of the test the activity light remained sold Blue, indicating that a connection to the 3G network was never established. It only began blinking after I logged in to the computer.HP Built-In 3G GOBI Adapter – The HP software is installed as a Service that can be configured to automatically start at boot (in the Services console), and there is also an option to “Auto-Connect” to the 3G broadband. Since the HP Tablet does not have external lights to indicate network activity I had to find another method to determine if the 3G connection was active prior to logon, so I did the following:Disabled the wireless adapter, so that the HP Tablet could only connect using the 3G broadbandInstalled the Windows Live Mesh software on the HP Tablet, added the HP Tablet to my managed device list and configured it to allow remote connectionsI completely shut down the HP Tablet, then turned it on (cold boot) and left it alone (did not log on)At my other computer (Lenovo laptop), I logged on to http://mesh.live.com and was able to successfully Remote Desktop to my HP Tablet via the websiteTo verify that only the 3G broadband connection was active, from the Remote Desktop session I checked the active network connections on the HP Tablet, then double-checked by logging on to the HP Tablet locally – and yes, throughout the entire time the only active connection was the 3G broadband.Therefore the HP built-in 3G adapter (with a Rogers SIM), appropriately configured, will allow for an “always-on” 3G connection that could be used for device management prior to user logon. A similar test would have to be run for the any other 3G adapter you will be using to verify if the 3G adapter’s software provides the same capability.”
“This morning I tested the “always-on” 3G connection scenario with my Rogers 3G adapter (http://www.rogers.com/web/content/wireless_network) and the built-in 3G GOBI (built-in mobile broadband technology - http://www.gobianywhere.com/) adapter in my HP Tablet and found that when using the Rogers USB 3G adapter an “always-on” connection is not possible, but when using an integrated 3G GOBI module it is possible (it really comes down to the software that is provided). The details of my test methodology and results are below…
Rogers Rocket™ Stick – The Rogers Communication Manager software runs in User Mode only (does not run as a Service), so the connection is invoked when a user is logged on and disconnected when the user logs off. There is an “Auto-Connect” checkbox, but it only makes the connection when a user logs on to the device. Therefore the current software provided by Rogers does not support an “always-on” scenario. I verified this by looking at the activity light on the USB stick itself – Red is device is not ready, solid Blue is network detected, blinking Blue is network connected and active. For the duration of the test the activity light remained sold Blue, indicating that a connection to the 3G network was never established. It only began blinking after I logged in to the computer.
HP Built-In 3G GOBI Adapter – The HP software is installed as a Service that can be configured to automatically start at boot (in the Services console), and there is also an option to “Auto-Connect” to the 3G broadband. Since the HP Tablet does not have external lights to indicate network activity I had to find another method to determine if the 3G connection was active prior to logon, so I did the following:
Therefore the HP built-in 3G adapter (with a Rogers SIM), appropriately configured, will allow for an “always-on” 3G connection that could be used for device management prior to user logon. A similar test would have to be run for the any other 3G adapter you will be using to verify if the 3G adapter’s software provides the same capability.”
Later another interesting finding was that with the HP GOBI 3G adapter, if the user logged off the computer the 3G adapter shut down and does not start again until the user logs on again or until the machine is restarted.
When considering a 3G solution to work with your DirectAccess capable mobile computer, make sure to check on the adapter software’s connectivity behavior. The adapter should be able to initialize and connect to the 3G network before the user logs on to the DirectAccess client computer. You can use the methods described in this article to determine if the adapter is capable of this behavior.
(Hat tip to Pat Telford for informing me of this issue.)
I have now one newly installed UAG SP1 server that has both portal and DA configured. DA is utilizing ISATAP and there are no firewall between UAG internal network and DCs. All works fine, but one strange thing is in the system.
Everytime, when connected with DA to the organization, I run gpupdate /force /target:computer it breaks current DA connection. The connection is not restored until the computer is rebooted or connected to corporate network and then again to the Internet.
Also during the gpupdate /force /target:computer it will not update computer policies. If I run just gpudate /force, the user policy is updated correctly, but not the computer policy.
Any tips or tricks to look at?
BR, TommiK
Here you go:
ISATAP is an IPv6 transition technology that enables computers to tunnel IPv6 packets inside an IPv4 header. Which of the following scenarios are enabled when ISATAP is enabled on your network (select all correct answers):
A. ISATAP hosts on an IPv4 only network can communicate with hosts on an IPv6 only network B. ISATAP hosts on an IPv4 only network can initiate connections to DirectAccess clients C. DirectAccess clients can only communicate with ISATAP hosts on the intranet D. ISATAP is required for all DirectAccess deployments
The answer to question 1 is A and B.
An ISATAP router can be placed on an intranet and enable routing from an IPv4 network to an IPv6 network. The ISATAP hosts on the IPv4 network can tunnel their IPv6 communications inside an IPv4 header and send the IPv4 encapsulated packets to the ISATAP router. When they reach the ISATAP router, the IPv4 header is removed and the IPv6 packet is forwarded to its destination on the IPv6 portion of the intranet. DirectAccess clients “live” in an IPv6 only network, since all communications sent and received by DirectAccess clients are IPv6. When an ISATAP host on the intranet initiates a connection to a DirectAccess client, it tunnels an IPv6 packet in an IPv4 header and forwards it to an ISATAP router (typically installed on the UAG DirectAccess server itself). Then the IPv4 header is removed and the IPv6 packet is forwarded to the DirectAccess client.
DirectAccess clients can communicate with non-ISATAP (and non-IPv6 capable) hosts on the intranet because UAG DirectAccess includes the NAT64/DNS64 service that performs IPv6/IPv4 protocol translation. For this reason, ISATAP is not required for all IPv6 deployments. However, only ISATAP hosts and machines that have native IPv6 addressing can initiate connections to DirectAccess clients.
Question 2:The number of concurrent Teredo clients per UAG DirectAccess server is determined by the Neighbor cache limit. What is the default number of Teredo clients per server support for UAG DirectAccess? A. 64 B. 128 C. 256 D. 512
The answer to question 2 is C.
If you check the TechNet article at http://technet.microsoft.com/en-us/library/ee382271(WS.10).aspx you would have been led to believe that the answer is 128. However, if you go to your UAG server and run the command netsh interface ipv6 show global, you will see the following:
We then need to ask “is the 256 value specific for UAG DirectAccess”? I can’t tell you for sure as I don’t have any Windows DirectAccess labs up to check the default value. But the question was specific regarding “UAG DirectAccess server” and the default value for a UAG DirectAccess server is 256.
OK – it was a tricky question, but sometimes you have to check these things out on a live server
IP-HTTPS is a IPv6 transition technology that enables a DirectAccess clients to connect to the UAG DirectAccess server even when the clients are located behind web proxy or port restricted firewalls. Which of the following statements are true regarding IP-HTTPS? A. IP-HTTPS has higher protocol overhead than Teredo and 6to4 B. IP-HTTPS has higher processing overhead than Teredo and 6to4 C. IP-HTTPS is required when Force Tunneling is enabled D. IP-HTTPS requires client certificate authentication to establish the SSL session
The answer to question 3 is A, B, C and D.
IP-HTTPS has higher protocol overhead because it puts an HTTP header on top of the IPv4 header that’s used by all three IPv6 transition technology. IP-HTTPS has higher processing overhead because in addition to the IPsec processing required by all DirectAccess connections, it adds SSL processing on top of that. IP-HTTPS is required when you want to do Force Tunneling, which is one of the reasons why you want to avoid Force Tunneling if you can.
The answer that tripped most of you was D. While not obvious, you can find information on this behavior at http://social.technet.microsoft.com/wiki/contents/articles/troubleshooting-the-no-usable-certificate-s-ip-https-client-error.aspx and http://technet.microsoft.com/en-us/library/ee731901(WS.10).aspx
This quiz was pretty tough – and the game is really close because of it!
I’m pretty sure I got all of the entries this time (I missed a couple of you in the last quiz). If you sent in an entry and don’t see your score recorded, please let me know so that I can score your entry and get it into the leaderboard.
Make sure to check late Thursday or Friday this week for the next quiz. I’m hoping to get a “video question” up so that you’ll need to watch a short video to solve the problem.
This time, a short one…some customers are wondering where would an administrator be able to know to which UAG node (in an array) a certain user has connected. For this, the Event Viewer is useful.
1. Open the UAG Web Monitor
2. Click on Session in the Event Viewer (bottom-left)
3. Note the “Session Started” events – each would have the client IP, and the Node Name column will show the array member:
Another option would be to use the Event Query form, which is more useful if you are looking for info from the past, or if your server is very busy and the Event Viewer view is refreshing too fast:
Another option is to use the TMG monitor, which allows you to define a filter in a way that you might like better:
(If you didn’t participate in Quiz 1 – you can read the rules of the game over at http://blogs.technet.com/b/tomshinder/archive/2010/12/02/uag-sp1-directaccess-contest-quiz-one-round-one.aspx)
It’s time for Contest 1-Round 2/Quiz 2 and Contest 2-Round 1/Quiz 2
Send your entries until 11AM Central Standard Time (-0600 UTC) on Monday January 17th.
The scores are really close and at this point, anyone can end up winning this round!
Now for the questions!
Now send your answers to me at (make sure to use this link since it contains the subject line I need):
This week was a big “catch up” week after the holidays so I didn’t get to put as much on the Edge Man blog this week. Next week I should have some nice “goodies” for you – so you’ll have something to look forward to.
Take a look at the figures below and see if you can guess what device is in the request/response path that you don’t typically see a UAG DirectAccess deployment.
First, the ipconfig output on a DirectAccess client located behind a NAT device:
Now let’s ping DC1:
Now let’s do a tracert from CLIENT1 and DC1:
Figure 3
With this information you should be able to figure out what the “novel” device is in the path between CLIENT1 and DC1. If you know, then consider yourself pretty well-versed with IPv6 addressing. If you don’t know, then here’s a great opportunity to learn something new!
Now take a look at figures 4 and 5 and determine what device was removed from the path:
Figure 4
Figure 5
Think about the solutions and put your answer in the comments section. Give your reasoning. I’ll post the answer and a network diagram of the solution tomorrow.
Have fun!
Now for the moment you’ve all been waiting for – the answers to UAG SP1 DirectAccess Contest 1–Round 2/Quiz 1 and Contest 2 Round 1/Quiz 1!
==========================================================
Answer to Question 1:When the DirectAccess client connects to the UAG DirectAccess server, it establishes two IPsec tunnels – the infrastructure tunnel and the intranet tunnel. All traffic destined to the intranet travels through these two IPsec tunnels with the exception of what type of traffic?
A. ICMPv6 B. ICMPv4 C. DCOM D. SIP (Session Initiation Protocol)
The answer to Question 1 is A.
From http://social.technet.microsoft.com/wiki/contents/articles/directaccess-forcing-encryption-for-icmpv6-traffic.aspx (DirectAccess: Forcing Encryption for ICMPv6 Traffic on the TechNet wiki):
“…By default, the DirectAccess Setup Wizard creates Group Policy objects for DirectAccess clients and servers for settings that allow the following behaviors:Internet Control Message Protocol (ICMP) traffic, for both Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6), is exempted from Internet Protocol security (IPsec) protection Teredo discovery traffic does not travel within the IPsec tunnels between DirectAccess clients and servers on the intranet…”
“…By default, the DirectAccess Setup Wizard creates Group Policy objects for DirectAccess clients and servers for settings that allow the following behaviors:
The trick here is in the question: “All traffic destined to the intranet travels….” The DirectAccess client only understands IPv6 and therefore does not send any ICMPv4 traffic to the intranet – only ICMPv6 traffic can be sent from the DirectAccess client to the intranet. Therefore, B cannot be true because ICMPv4 is never destined for the intranet. DCOM and SIP traffic are treated like any other non-ICMP traffic and both protocols are always sent through an IPsec tunnel when destined for the intranet.
Question 2:A DirectAccess client is connecting from behind a home NAT device to a UAG DirectAccess server. The user calls the Help Desk and says that he isn’t able to connect to anything on the intranet. You tell the user to open a command prompt and ping the name of a domain controller and the ping succeeds. Then you tell the user to ping the name of a file server and that ping succeeds. Next, you tell the user to ping the name of a web server and that ping succeeds. Then you tell the user to use the net use command to connect to a share on the file server and that fails. Next you tell the user to connect to a share on the domain controller and that attempt is successful. Finally, you tell the user to connect to the web server and that connection attempt fails.
What is the most likely reason for this user’s failure to connect to the resources he needs?
A. The Internet Service Provider is blocking IP Protocol 41 B. Kerberos authentication is failing C. NTLMv2 authentication is failing D. The DirectAccess client doesn’t trust the UAG server’s computer certificate
The answer to Question 2 is B.
Let’s look at what’s happening here:
When we look at this analysis, it becomes clear that the answer is B – that Kerberos authentication is failing. A is not correct because IP Protocol 41 is used by 6to4 – if the client were using 6to4, then even the pings would fail as the IPv6 transition technology would have failed; in addition, the client is connecting from behind a home NAT device, so 6to4 would not be used – IP-HTTPS or Teredo would be used in a NAT scenario. We know that NTLMv2 is not failing, because the infrastructure tunnel is working. And we know that the DirectAccess client trusts the UAG server’s computer certificate, since the client was able to establish the infrastructure tunnel.
========================================================== Question 3:Which of the following are new features included with UAG DirectAccess Service Pack 1?
A. Wizard based configuration of the DirectAccess Connectivity Assistant (DCA) B. Wizard based configuration of “manage only” DirectAccess client connectivity C. Support for Smart Card Authentication D. Support for One Time Password (OTP) Authentication
The answer to question 3 is A, B and D.
Support for Smart Card authentication was available in pre-SP1 UAG DirectAccess.
For more information on what’s new and improved with DirectAccess in UAG SP1, check out UAG 2010 SP1: The New and Improved DirectAccess Features http://blogs.technet.com/b/edgeaccessblog/archive/2010/10/27/uag-sp1-da-overview.aspx
This quiz was a pretty tough one that required you to have a pretty good understanding of the IPv6 transition technologies and authentication for DirectAccess IPsec tunnels. In the next quiz we’ll go more into IPv6 related questions to test some of your IPv6 chops.
The next quiz will be posted late in the day on Thursday, January 13, 2011.
Visit the TechNet forums to discuss all your UAG DirectAccess issues http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/threads Stay up-to-date with “just in time” UAG DirectAccess information on the TechNet wiki http://social.technet.microsoft.com/wiki/tags/DirectAccess/default.aspx
Funny that you should ask!
Most of our planning and review of the basic networking configuration and virtual machine requirements were complete by the end of the third week of last month. But then the holiday season came upon us and things pretty much stopped for a week and a half. But with the new year come new energy to get this critical piece of documentation done so that you can deploy UAG DirectAccess servers and arrays in different sites using UAG Service Pack 1.
Late last year we provided a high level description of how you would configure a multi-site (multi-GEO) configuration using UAG Service Pack 1. You can find that description in the blog post Supporting Business Continuity, Disaster Recovery and Multi-Site Scenarios with UAG 2010 RTM and UAG 2010 Service Pack 1 at http://blogs.technet.com/b/edgeaccessblog/archive/2010/12/01/supporting-business-continuity-disaster-recovery-and-multi-site-scenarios-with-uag-2010-rtm-and-uag-2010-service-pack-1.aspx
In that overview, we provided two multi-site scenarios: the first (easier) scenario is where you depend solely on the NAT64/DNS64. In that scenario, you don’t worry about using IPv6 at all on the intranet and let the NAT64/DNS64 component take care of converting the IPv4 addresses on the intranet to IPv6 addresses that the DirectAccess clients can “consume”. While this is the “easier” scenario to configure, it does suffer from one important limitation – you won’t be able to initiate a connection to a DirectAccess client from a management station on the intranet. Many organizations don’t care about this because in the majority of cases, client management is carried out via agents on the clients who initiate the connections to the intranet and don’t depend on management servers initiating a connection to the DirectAccess clients.
However, there are more than a few organizations who want the full “manage-out” ball of wax – they want to take advantage of management agents on the clients and and they want to be able to connect to the DirectAccess clients out on the Internet to perform maintenance and troubleshooting.
To support this second scenario, you need to have management stations that support IPv6. They can be either native IPv6 systems, or they can use ISATAP. The challenge in a multi-site scenario is how to support these IPv6 capable management stations. Our solution focuses on using ISATAP and creating a single ISATAP cloud that spans all IPv4 subnets on the intranet. To do this, we need to deploy an ISATAP router at each site that has a UAG DirectAccess server or array. That ISATAP router needs to be on-link with the UAG DirectAccess server or array and needs to be assigned a native IPv6 address that is used to communicate to another IPv6 address that is configured on the UAG DirectAccess server or array.
Figure 1 shows the network diagram for the virtual machine setup that we’ll use in the Test Lab Guide.
Figure 1 (click the diagram to see the details)
Things to note in this figure:
The IPv6 addressing information was derived from the external addresses on the UAG DirectAccess servers, as seen in figure 2.
Another key requirement for the solution is that we keep the RAM requirements on the virtual server as low as possible. I figure that most admins will have access to a virtual server that has at least 16 GB of RAM (most of test virtual servers I’ve seen have between 16-48 GB). Therefore, I set a goal of limiting the total RAM requirements to be less than 16 GB. This TLG does a good job of that, with total RAM requirements of only 7.68 GB of RAM. In fact, if you use a virtualization platform that allows for memory overcommit, you could realistically get away with running this lab on a system with only 8 GB of RAM.
You can see the list of virtual machines and their memory assignments in figure 3.
Let me know what you think. Is there something that I should add? Is there something wrong with the addressing configuration? Something else we might have missed? Thanks!
I typically use this blog to talk about UAG and IAG stuff, but this time, I want to tell you about something a bit more personal.
A lot of people have asked me what is the meaning of my double-name “Ben Ben”, as it appears in my Email. Now, with my and Ran’s UAG book coming out, revealing my “real” name as “Erez Ben-Ari”, more and more people are interested what’s wrong with me, suspecting I’m some kind of spy or a deranged mental patient. I guess now would be a good time to share this with you.
My birth first name is Erez, and my last name is “Ben-Ari”. The names are from Hebrew, as I was born in Israel. Erez means “Cedar” (the tree) and Ben-Ari means “Son of a Lion”. I spent most of my life in Israel, but when I moved to the US in 2008, I figured people will have a hard time understanding, pronouncing and remembering that name, so I decided to just drop it, and be known as “Ben”, with the last-name “Ari”. In fact, when I did register with certain service providers in the US, things never worked out. Even though I have a good accent, I still got listed under crazy names like “Ebez Ben Avip” and “Eric Ben Harry”. I’ve also heard some customers make a nice-sounding salad out of my dear colleagues Bala and Tarun’s names. Tragic, really, believe me!
So, while I never changed my name legally, I did present myself as Ben, but when I tried to modify the record in Microsoft’s HR system, I was able to set my first name to Ben, but I could not remove the Ben from “Ben Ari”, so the result ended up as “Ben Ben Ari”, which earned me the nickname “Ben Ben”. People still come over at noon calling out “Ben Ben! Luncn lunch!”. Hilarious hilarious.
So, now, 2.5 years later, where pretty much every UAG customer knows me personally, I’ve decided to take it down a notch. I’m still going to be Ben for everyone, but I decided to put out the book as “Erez”.
So that’s my story for today. Now go out there and buy the book! The Amazon page says Feb 10th, but the publisher told me they’ll start shipping on JAN 10th…4 days from now. Hope you like the result!
It that time again! The UAG DirectAccess Contest. If you’ve been participating in Contest 1 Round 1, you know the drill.
If you’re new – don’t worry about Contest 1 – you’ll be automatically entered into Contest 2 and you’ll be participating in Round 1. And if you participated in Round 1 of Contest 1 but didn’t do so well, there’s still a chance to improve in Contest 2 – so make sure you send your entries.
You can find the rules of the game over at
http://blogs.technet.com/b/tomshinder/archive/2010/12/02/uag-sp1-directaccess-contest-quiz-one-round-one.aspx
There you go!
Send your entries until 9AM Central Standard Time (-0600 UTC) on Monday January 9th.
Good luck!
Just a quick note about the UAG DirectAccess contest. We didn’t have a quiz last week because of the entire world was on vacation
We’ll continue the contest this week with the next quiz being tomorrow, January 6, 2011.
The first round of the first contest is complete. The second round of the first contest starts with tomorrow’s quiz, which will be Quiz 1, Round 2.
Tomorrow quiz will also represent the first round in Contest 2. So even if you didn’t do well in Round 1 of Contest 1, you can get back in the game for Contest 2!
Quiz Dates for Contest 1/Round 2 and Contest 2/Round1 are:
The standings for Contest 1/Round 1:
For a review of the scoring methods, check out the first quiz at http://blogs.technet.com/b/tomshinder/archive/2010/12/02/uag-sp1-directaccess-contest-quiz-one-round-one.aspx
For Contest 1 Round 2/Contest 2 Round1 – I’m thinking of doing some more interesting things with the questions, like screenshots of something gone wrong and then looking for the answer to the most likely reason for the finding or what should you do next to determine the problem.
I’m looking forward to seeing your entries this week!
The UAG portal is designed to let you publish multiple applications using a single public hostname, but many customers need UAG to publish only a single application, or simply don’t want to have the portal visible to their users, and have the users redirected to a specific application immediately after logon. The UAG User interface offers this option in a way that’s easy to see – you select an Initial Internal Application that is other than “Portal”:
Often times, the purpose of using this option is to present the user with an experience that hides UAG as much as possible, and for that, many users will also check-off the option “Display home page within portal frame”:
With this option set, the UAG interface is pretty-much tucked away and concealed, but this has a side effect that needs to be kept in mind. The UAG toolbar isn’t just for looks – it also runs some important scripts that affect the security of the site. For example, it is in charge of showing a notification that the session is about to time-out for inactivity. With it being hidden, the user may not become aware that his session is about to expire, and will only find out when he clicks a link and gets redirected to the login page.
In some circumstances, the result could be even more awkward. For example, if the published app uses frames, then action done in one frame may not affect the others, and so after a session expiry, one frame may remain with “old” content, while the user clicks a link in another frame and gets the UAG login page.
Before I go on and tell you how to get around that, it’s important to realize that hiding the portal frame is not the only way to get rid of it. UAG also supports “application-specific hostname” applications, sometimes referred to as “AAM-Like” applications. The way this works is by having you, the administrator; select a specific public name for one of the applications, and mapping it in DNS to resolve to the UAG Trunk’s public IP. For example, the portal may be published on “https://uag.contoso.com”, with the application published as “https://mail.contoso.com”. You need to configure your DNS to resolve these two names to the same IP, and if your UAG trunk is an HTTPS Trunk, then it’s certificate has to be a wildcard certificate (*.contoso.com) or a SAN certificate.
The application itself needs to be configured accordingly. If this is a generic web application, you need to use the “Other Web App(Application-specific hostname)” template, which has a special setting for you to let UAG know which public hostname this application will use:
When this is done, this is how it works:
As the user types https://mail.contoso.com in his browser, it resolves to the UAG’s external IP, and the request is received by the UAG. However, the request also includes the host-header, which tells UAG that the request was for that specific URL, and not to the portal hostname.
UAG uses the host-header to search it’s list of configured applications to find which one has that configuration, and will then retrieve data from that server (only after completing the login process, though, of course).
For some of the application template, this mechanism is mandatory. For example, CWA publishing and SharePoint publishing require that to be configured this way. You still can access those applications via the UAG portal, but if you look closely, these links actually point to the public hostname you defined. This is really nice, because you have the two options for the price of one – you can let your users access the application via the portal (by clicking on an app link), or directly, by typing-in the public URL. Naturally, they can also go to it from their Favorites folder or from a link that has been emailed to them etc)
Back to hiding the portal frame
As I said, just setting the portal frame to be off has some downsides, but there is another way to get this done. UAG uses CSS to control the way the portal frame looks, and it’s fairly easy to customize it to hide the frame without actually disabling it. This is discussed in the UAG Customization guide, alongside other ways to affect the appearance of the portal. The file in question is called Office.css, and it’s located at <UAG Folder>\Von\PortalHomePage\App_Themes\Office. As is always the case with UAG, you should not edit the original file. To make changes, copy the file to the <UAG Folder>\Von\PortalHomePage\App_Themes\CustomUpdate\Office folder, and then edit the file in CustomUpdate. Once you make a change to the file and save it, the change is applied immediately, so there’s no need to re-activate the configuration on UAG or to log-off/log-on again on the client.
You can make any changes to the CSS style sheet that suits your taste. For example, the style “display:none;” makes an element hidden from view, and changing the position and size styles (top, bottom, left, width, height etc) affects their position on the page. Note that setting the div#topStrip and div#toolbar (the frame is actually comprised of two separate ribbons) to hidden will just turn the top area of the screen to a clean white, but the app will still show-up in the area below it. To make the app stick to the top, you also need to change the location of the div#content element from Top:85px; to Top:0px;. You could move stuff around and even integrate your own unique elements to get your own company’s look-and-feel.
To make the entire frame invisible, you need to hide the following elements, and then move the content piece up, as noted earlier:
· div#topStrip
· div#toolbar
· div#footer
· .contentLeftSideBarCell
· .topLeftMarginGradient
· .topRightMarginGradient
· .bottomLeftMarginGradient
· .bottomRightMarginGradient
With these changes, the only thing you will see after logging in is the application list, or the application you have set as the initial app:
Thanks to Shay M for helping me come up with this topic and the details!
While I spend most (all) of my time working with the UAG DirectAccess solution, UAG DirectAccess is functionality essentially represents a superset of Windows DirectAccess functionality. Therefore, I thought it might be interesting to share with you all some questions I received from a fellow who is interested in deploying Windows DirectAccess. Maybe the questions and answers contained here will help you with your own planning for deploying DirectAccess in your SMB environment.
==============================
Question/issue 1:I’m in the process of putting together a DirectAccess solution for a small client of mine that needs the features of DirectAccess but can’t lay down the cash for multiple physical servers or UAG. They don’t need the additional complexities of access to IPv4 only resources as this is basically going to be a new network starting from scratch.
I know this may not be ideal from a performance perspective because of the many shared roles and limited scalability, but this is not going to be a network with many users; rather it will be a network of a dozen or so kiosks that will always be remotely connected. I’m starting to experiment some but haven’t found many resources for the absolute simplest implementation of DirectAccess.
I will certainly be going through the test lab documentation and other papers from Microsoft regarding the set up, but I thought I’d ask just in case anyone knows of some resources I haven't found yet (or just has some good tidbits of info themselves).
My concept is this:
What I’d ultimately really love is a "test lab" document similar to the one already out there from Microsoft but designed to interface with the real internet instead of a fake internet. The document makes several references to "problems" trying to adapt that test environment into a real world scenario, but it doesn’t give a whole lot of information about what "problems" they are referring to.
ANSWER: First off, these are great questions and thanks for sending them my way. Examples of planning for real-world deployments help everyone on their trek to DirectAccess goodness.
Since your customer can’t afford UAG at this time (maybe he will in the future as the company grows), the place to start is with the Windows DirectAccess solution. You are right that you will not have support for IPv4-only resources on the intranet, and your high availability options are somewhat limited. But you recognize these conditions and we can work within these parameters.
We generally recommend that you don’t put the Network Location Server on the domain controller, especially in pure IPv6 scenarios for some reasons regarding interface timings. While I don’t have the details in front of me, I have received information from a DirectAccess PM who strongly recommends that the Network Location Server not be placed on a DC – so if you could create a VM for the NLS, that would be a good way to go.
You can put the DirectAccess server in a virtual machine. However, there are performance implications and therefore we generally recommend that you put the DirectAccess servers on physical machines. With that said, you mention that this is going to be a relatively lightly used configuration, and therefore you might be able to get acceptable performance. You’ll need to monitoring your deployment and see if you are running into processor bottlenecks.
It is good that you’re planning on dedicated NICs for the virtual and physical interfaces. DirectAccess will perform better this way.
It’s also good you recognize that the firewall in front of the DirectAccess server will perform only firewall functionality and not NAT, because DirectAccess is not supported from behind a NAT device (although it can be done with the help of a few routing tricks, but that configuration is not supported by the product group).
Windows 7 Enterprise or Ultimate is required – so you’re good with the OS on your clients. Keep in mind that these must be domain members.
Regarding the problems that we suggest with the Test Lab Guides here are a few things that I can think of:
With those things in mind, you can create a “live” pilot deployment. I’d recommend that you obtain a commercial certificate for the IP-HTTPS listener, and not use the CRL checking disablement steps I deployed in the UAG DirectAccess Test Lab Guides.
-----------------------------------------
Question 2: What are the advantages/disadvantages of using a native IPv6 infrastructure (with a tunnel broker like Hurricane Electric) vs just using ISATAP? Are there any compelling reasons to go ahead and go native (especially if the network is going to be new with no legacy devices)?
ANSWER:
ISATAP is useful if your network infrastructure isn’t IPv6 aware, since you can tunnel your IPv6 traffic over IPv4 and use your current IPv4 routing infrastructure. However, if your routing, DNS and DHCP infrastructure is all IPv6 capable, there’s no need to deploy ISATAP and I’d recommend that you go native IPv6. You will need to configure your routers (and maybe the hosts) on your network so that they know the route back to the DirectAccess clients.
In most cases that will require that you make the DirectAccess server the IPv6 route of last resort since this is the only way to get the messages back to the 6to4 DirectAccess clients – or better, you can disable 6to4 on your DirectAccess clients and they will use Teredo instead – then your routing tables will be a bit “cleaner” and you want need to make the DirectAccess server the IPv6 route of last resort.
Question 3: What are the security implications with opening up inbound IPv6 traffic into your network? Since DirectAccess requires Protocol 41 traffic to be let through the firewall directly to the external NIC on the DirectAccess server, doesn't this open up some potential security issues without an IPv6 firewall in place? Maybe I am missing something, but since Protocol 41 is encapsulating ALL IPv6 traffic in IPv4 packets isn't letting Protocol 41 traffic through essentially the same thing as having a computer directly connected to the IPv6 internet with no firewall at all?
IP Protocol 41 is used to indicate that there is direct encapsulation of IPv6 packets within an IPv4 header to support 6to4. So, we’re not really allowing all IPv6 traffic through the firewall, just 6to4 traffic. Also, keep in mind that both of infrastructure tunnel and the intranet tunnel require authentication – for the infrastructure tunnel, both computer certificate and NTLMv2 authentication is required, and for the intranet tunnel, both computer certificate and Kerberos v5 authentication is required.
While all IPv6 traffic is allowed through the IPv4 tunnel – traffic to the DirectAccess server is allowed only after the client authenticates and establishes a valid IPv6 IPsec connection . We also have some Denial of Service Protection technology built into to take care of malicious users who try to take advantage of this situation, though. However, if you don’t think this is enough – you can take my earlier recommendation and disable 6to4 on the DirectAccess clients and let them use only Teredo or IP-HTTPS. Keep in mind that this is the same situation – the Teredo and IP-HTTPS clients are also encapsulating all IPv6 traffic. But the same protections still apply regarding IPsec and DoSP.
I hope you find these answers helpful and would be happy to carry on the conversation in the comments section.
In a previous blog post, I’ve detailed how to create a custom application template to perform a special drive-mapping. Later on, I’ve posted another one, which offers a way to use the “relay” template format to run a VBScript that can do other things.
The “relay” template is one of the most powerful features of UAG and IAG, because it’s so customizable. You can use it to run pretty much any BATCH command on the client, and using the method I suggested back-then, you can use the batch commands to generate a dynamic VBScript file, which is even more powerful. There are some limitations to this, because when using the ECHO batch command to generate the file, you can’t use the & sign (the CMD interpreter uses that to link commands, so it will think the text after the sign is a new command). This means you can’t combine variables like you’re used to if you’re a veteran VBScript writer. Instead, you can use the + sign.
Another challenge this method has is that on Vista and Windows 7 systems, the OS is protected by the UAG system against most of the really interesting modifications you may want to do. The good news is that there IS a way around that by using some tricky code:
If WScript.Arguments.length =0 Then Set objShell = CreateObject("Shell.Application") objShell.ShellExecute "wscript.exe", Chr(34) + WScript.ScriptFullName + Chr(34) + " uac", "", "runas", 1Else ***Your violent code!!!****End If
This little trick cause the VBScript engine to invoke the UAC confirmation dialog, and if the user approves it, it will execute your violent code.
The way to make use of this for your purposes is this:
1. You write the VBScript that does what it is you need, and test it properly on some client. You need to be sure to avoid using the & sign.
2. You convert the code to a dynamic CMD processing format, using the ECHO command to push the VB commands into a file generated in the system’s TEMP folder. For example:
@echo wscript.sleep 500 >>%temp%\DoMyBidding.vbs
Note that I use the @ sign so that the user won’t see what’s happening, because this is being processed in a visible CMD window on the client. Also, I use the >> symbol to APPEND this content to the file I’m generating. I would use just one > in the 1st line of the batch so as to make sure the file is overwritten initially (because the user may run this app multiple times). I’m also putting the file in the %temp% folder, because it’s freely writeable and so I don’t have to worry about permissions.
3. You add a line to actually RUN the file using the silent CSCRIPT interpreter:
@cscript %temp%\SetDns.vbs
4. You put all that into a custom SSL-VPN template based on the relay format. To do so, you create a new text file, and paste this into it, updating the relevant part with your code from steps 1-3:
<config><templates version="3" use-lsp="1"><template name="DoMyBiddingTemplate" userrights="562" repository-type="NT Domain,Active Directory" credvar-prefix="WhlDrvMap" use-with-lsp="yes" win="yes"><!--Windows--><port id="0" remoteport="139" flags="10" use-with-lsp="yes"/><config-file flags="1" path="%Temp%\DrvMain-%InternalAppID%.bat" use-with-lsp="yes"><![CDATA[
***Your Code from step 1-3 comes here***
]]></config-file><exec exe='%Temp%\DrvMain-%InternalAppID%.bat %DrvLetter% "%WhlDrvMapPwd%" %WhlDrvMapDomain%\%WhlDrvMapUser%' flags="4" param=""/></template></templates></config>
You save this file under the name SSLVPNTemplates.xml in the folder <UAG Folder>\von\conf\CustomUpdate
The <UAG Folder> is typically c:\Program Files\Microsoft Forefront Unified Access Gateway
5. You have to CLOSE the UAG console before continuing!!!
6. You create a custom Wizard template to call the new relay template you just created. To do so, you create a new text file, and paste this into it:
[Application_List] NumOfApps=1App1=DoMyBidding
[DoMyBidding] Name=My Custom ApplicationAppType=1WhaleApp=0Types=1,2 SSLVpnTemplate=DoMyBiddingTemplateSSLVPNNumOfElements=3SSLVPNElement0ID=0SSLVPNElement1ID=ShareNameSSLVPNElement2ID=DrvLetter0Name=Server NetBIOS Name:0Type=00GuiType=00Validation=IP/DNS NotEmptyDrvLetterName=Drive Letter:DrvLetterType=2 DrvLetterGuiType=3DrvLetterValue=*DrvLetterListValue=*;D;E;F;G;H;I;J;K;L;M;O;N;P;Q;R;S;T;U;V;W;X;Y;ZDrvLetterGuiWidth=35ShareNameName=Share Name:ShareNameType=2 ShareNameGuiType=0ShareNameValidation=Pattern(Exclude /:*?"<>|) NotEmptyAutoLaunch=0CreateEntryLink=0ActivateSmugglingProtection=0MaxHTTPBodySize=49152 ContentTypeList=application/x-www-form-urlencoded|multipart/form-data
You save this file under the name WizardDefaultParam.ini in the folder <UAG Folder>\von\conf\WizardDefaults\CustomUpdate
7. You re-open the UAG configuration console, and you should now see the new application template appear in the Client/Server and Legacy application list container. When you create a new application based on that template, you are asked to fill in various details, but don’t worry about it – other than the applications’ name, the rest has no bearing on what the application actually does, so you can fill-in bogus data.
8. Don’t forget that you can set this app to launch automatically with the portal login, if it performs something all your users need to do.
To conclude this, here’s a sample of a complete SSL-VPN template that I created recently. It changes the DNS settings on the client to point it to a specific public DNS server, instead of the user’s default one:
<config><templates version="3" use-lsp="1"><template name="configdns" userrights="562" repository-type="NT Domain,Active Directory" credvar-prefix="WhlDrvMap" use-with-lsp="yes" win="yes"><!--Windows--><port id="0" remoteport="139" flags="10" use-with-lsp="yes"/><config-file flags="1" path="%Temp%\DrvMain-%InternalAppID%.bat" use-with-lsp="yes"><![CDATA[ @echo If WScript.Arguments.length =0 Then >%temp%\SetDns.vbs@echo Set objShell = CreateObject("Shell.Application") >>%temp%\SetDns.vbs@echo objShell.ShellExecute "wscript.exe", Chr(34) + WScript.ScriptFullName + Chr(34) + " uac", "", "runas", 1 >>%temp%\SetDns.vbs@echo Else >>%temp%\SetDns.vbs@echo Dim aDNS(1) >>%temp%\SetDns.vbs@echo aDNS(0) = "4.2.2.2" >>%temp%\SetDns.vbs@echo aDNS(1) = "4.2.2.1" >>%temp%\SetDns.vbs@echo set objWMIService = GetObject("winmgmts:\\.\root\cimv2") >>%temp%\SetDns.vbs@echo Set colItems = objWMIService.ExecQuery("Select * From Win32_NetworkAdapterConfiguration Where IPEnabled = 1") >>%temp%\SetDns.vbs@echo For Each objItem in colItems >>%temp%\SetDns.vbs@echo errDNS = objItem.SetDNSServerSearchOrder() >>%temp%\SetDns.vbs@echo wscript.sleep 500 >>%temp%\SetDns.vbs@echo errDNS = objItem.SetDNSServerSearchOrder(aDNS) >>%temp%\SetDns.vbs@echo next >>%temp%\SetDns.vbs@echo End If >>%temp%\SetDns.vbs@cscript %temp%\SetDns.vbs]]></config-file><exec exe='%Temp%\DrvMain-%InternalAppID%.bat %DrvLetter% "%WhlDrvMapPwd%" %WhlDrvMapDomain%\%WhlDrvMapUser%' flags="4" param=""/></template></templates></config>
Trying to implement a two node array in UAG. The first node was succesfully created as array manager, but I just could not join the second node to array. Always the error "The server cannot join the array". Until I removed all the trunks from node1, then joining was successfull. Is it really that you cannot create an array when first UAG has a working trunk ?
So I exported the configuration to a file, deleted all trunks and created the array. And I though that importing the configuration to existing two node array afterwards would be fine. But again nope. Import was successfull, but nothing worked. When you have an array, you cannot import configuration, instead you have to create a new trunk from scratch ? is this so ?
UAG's have updates 1 and 2, and TMG's have SP1 and SP1 update 1.
My UAG's are in separate hyper-v servers, and once I create a new trunk and try to activate it, it says that "you must enable spoofing of mac address..." I have already done this !
without trunks activation and nlb seems to be ok.
UAG's are on separate hyper-v servers, should this work ? hyper-v machines are connected to an old "hub" so traffic at least should be echoed to all ports.
I have only two physical (and virtual) network cards on both servers, internal and external.
Thanks !
We have an IAG 2007 server with Network Connector configured.
IAG 2007 has the pool 172.16.64.1 - 172.16.67.255 with the Pool subnet set as 172.16.64.0/255.255.252.0
All this is working fine. However, I have a user who needs to use Network Connector but his ISP issues the IP Address 172.16.1.20 to his laptop and so Network Connector does not work and gives the following error message.
SSL Network Tunneling session failed. An unresolved network conflict has been detected !
The session's settings included the following conflicting route: 172.16.64.0 / 255.255.252.0 (0x80004005).
Is there workaround for this - except changing his ISP?
Performing a configuration activation on a UAG server is one of those things that we wish we could do without, but understanding how it works and why it is so important can make this a bit more tolerable.
The reason for the activation process is that UAG is but one piece of a big puzzle. You, the administrator, see only the configuration console, but the real work is done by the UAG Filter – a DLL by the name of “WhlFilter.dll”, which you can see for yourself if you open the ISAPI filters Config page of IIS on the UAG Server (be careful there! Don’t make any changes to the Config, as it could destabilize your server!):
When a client interacts with a UAG server, it is actually talking to the IIS web server that’s running on it, and that’s where the filter comes in. Every request that’s received by that IIS is received by the filter, and that’s where the magic happens. The filter parses the request, and invokes additional pieces of code, if such are required. It is the code that contacts the internal server that you are publishing (like your exchange or SharePoint server) and fetches data from it. It performs various actions, like checking the URL for security and performing the HAT process on the content, and then delivers it to the client, which has no idea about all this labor going-on in the background, within a fraction of a second.
Another piece of this puzzle is TMG, which acts as the guard at the gate. It is the component that does the initial screening of traffic that reaches the UAG server. It’s there to get rid of unwanted traffic, and protect against several forms of attacks, like WinNuke, Half-Scan, UDP bomb and others. TMG also configures and protects VPN connectivity, so if you are using the SSTP feature of UAG, it has a major role there too. TMG also contains the infrastructure that’s used for Array management, so if you are using several UAG servers in an array, TMG is your buddy. TMG itself may configure various networking settings within the operating system, like the IP configuration of the NICs when using NLB, or the configuration of the Routing and Remote Access Service (RRAS) when using SSTP.
What all this means is that the configuration you set within the UAG console affects a lot of other components and settings, and that’s the purpose of the configuration activation process. When you run it, it performs these changes within TMG, IIS, and these, in turn, may make changes to other components.
If you want to see what’s going on back-stage while activation is in progress, click on the Messages menu, and select Filter Messages. Then, check the option “Information Messages” on the left and OK:
This will configure UAG to show what’s going on during activation in the bottom of the console window. Here’s a sample of such an output (I photoshopped it a bit, to make it all appear as one screen…):
It may be hard to see in the screenshot, but the process is comprised of the following:
1. The configuration file (EGF) is saved (if you’ve been manually saving it before activation…don’t bother)
2. NLB settings are configured
3. Configuring TMG rules
4. Configuring SSTP VPN settings
5. Configuring the SSL Tunneling component (a.k.a. “network Connector”)
6. Updating and creating local configuration files for the trunks
7. Updating and creating local registry entries on the server
8. Configuring settings for the File Access application
9. Configuring the IIS server with the sites for the trunks
10. Configuring DirectAccess
11. Waiting for TMG to synchronize the storage
Naturally, some of these steps may require no actual configuration (for instance, step 10, if you have not configured DA) and are just listed as check-points in the activation process. Others may take more time, like step 3, which typically takes a while. Depending on your actual configuration, the activation process can be as quick as 2-3 minutes and in some cases, take over an hour to complete. It can take a longer time if it has more to do. For example, UAG has to verify the various servers that are configured as part of your applications, and that takes a certain amount of time. If a server’s name does not resolve for some reason, it can cause the activation process to hang while UAG sweats it out. Additionally, each trunk has a corresponding website in IIS, so the more trunks you have, more work is required for configuring these sites.
Even though an activation is not something you do all the time, it can be annoying to have to wait a long time for it to complete, but before thinking something is wrong, keep in mind that in the real world, even strong servers typically take 5-10 minutes to activate, and a complex Config (one with many trunks, many apps or many services) would easily take 15-20 mins. If your numbers are higher, or make no sense to you, the 1st step would be to observe the steps shown with the “information messages” showing, and seeing where there are big gaps. For example, you might see that there’s a delay after step 5, which could happen if the Network Connector is heavily utilized. In such a situation, it may take the service (the WhlIOS service) a while to stop as it’s shutting down connections. The final step (TMG Storage sync) can also take a while if you have an array with several servers, as TMG is pushing the configuration to the other members sequentially).
Once you have identified a problematic stage, you can try to disable it, to prove it’s causing a problem. For example, if you see a significant slow-down during step 9 (IIS Config), there may be an issue with IIS or with one of the trunk settings. You could, in that case, try disabling some or all of your trunks, and try to home-in on a problematic one. If you have a small number of trunks (or just one), you can try disabling the applications on the trunks, to see if one of them may be slowing down the process because of a non-responsive server. As with any performance-related investigations, a good idea would be to keep track of your time. Start by measuring a baseline of the activation time when the UAG server is new and has little or no configuration, and measuring it regularly too. You may discover that what took 10 minute last month now takes 20, and this way, you can look at the changes that occurred between those two as a starting point.
Publishing Office Communication Server (OCS) and Communicator Web Access (CWA) with UAG has been a source of confusion for some UAG customers, mostly because these products offer a wide range of functionality. Some of this is pretty simple to configure, and some takes more planning.
When planning OCS publishing with UAG, one must take into consideration the fact that OCS has many features, functions and roles. Not all of them were planned with publishing in-mind, and UAG was not designed to publish all the features either. Essentially, UAG includes a special template for Communicator Web Access (CWA) 2007, and for other features, UAG does not include built-in functionality, and something “else” needs to be used.
Virtually any firewall product in the market can be used to publish internal servers to the outside world. Some companies may refer to this as “port forwarding” or “Reverse-proxying”, or even simply as “routing”. At Microsoft, we divide this into sort of functionality into two categories. The 1st is “Web publishing”, in which an edge device gives computers on the internet access to web servers inside the organizational network. The 2nd is “Server publishing”, in which the access is to services that are not necessarily web services (for example, RDP access). The difference is that web services are a narrow type of service, which is very clearly defined. This clear definition allows us to offer additional features that go beyond just moving the packets from one “side” to the other. For example, with Web Publishing, we can do more advanced content inspection, and can block certain file-types from being transferred.
If you purchased UAG to publish certain applications, good chance you’d prefer not to purchase any additional devices to publish the non-web OCS features, and the good news is that UAG does, in fact, include something else…TMG! If you read your documentation carefully or ever spoken to Microsoft Customer Support, you are probably aware that trying to use the UAG server for “other” things is not supported. You’re not supposed to tack-on an additional website on the IIS that’s on UAG to publish your cafeteria’s lunch menu, or use the SQL that’s there to store your inventory database. We do, however, allow for a certain, limited list of things to be done with TMG, as stated here in the support boundaries for uag (http://technet.microsoft.com/en-us/library/ee522953.aspx). This list includes publishing OCS features other than CWA.
When you publish something with TMG, you select whether you want to use Web Publishing or Server publishing by the type of task you select in the task list. There are actually some more variations for types of publishing, but for our purposes, the “Publish Non-Web Server” is the relevant one for OCS’s features. Using this wizard will allow you to specify which ports you need to publish, which depends on the type of service you need to publish. For example, you may need to publish port 5063 for incoming SIP listening requests or port 8057 for direct PSOM connections from Live Meeting clients.
I will not cover this in high detail here, as this blog is about UAG, but you can read more about server publishing in one of many books that are available about TMG, such as this one. For more information about ports used by OCS, refer to this article.
To publish CWA itself using UAG, what you need to know is that CWA needs to be published as a non-HAT application (a.k.a AAM-Like application). If you are not familiar with HAT and what it does, you might want to take a peek at this blog post. Like SharePoint, CWA cannot be published with the HAT mechanism, and requires its own public hostname, which brings the following considerations into play:
1. The public hostname needs to be based on the same public domain you are using for your UAG trunk. For example, if your trunk is published as https://uag.contoso.com, then you need to use something like https://*.contoso.com for CWA.
2. If your UAG trunk is an HTTPS trunk, it has to have a certificate, and that certificate needs to certify both the trunk’s hostname and the CWA’s. Most UAG customers use a wildcard certificate for this, and others prefer a more economic SAN certificate. I should mention that wildcard certs don’t have to cost an arm and a leg. Some websites like http://www.sslcatacombnetworking.com and http://www.rapidssl.com offer them for as low as $199 a year.
3. Both hostnames need to be publicly resolvable to the UAG trunk’s external IP. This is not absolutely mandatory, as you can use static HOSTS file entries on your client computer, but if your intended audience is the general public, setting up the DNS correctly is very important.
4. The authentication settings on the CWA server need to be adjusted to allow UAG to perform Single-Sign-On. With UAG, you need to publish the “External” CWA site, and use custom authentication, as described in the lab guide http://www.microsoft.com/downloads/en/confirmation.aspx?FamilyID=0e21123a-8452-4b25-8cde-57f750cd7803
So, the 1st step is to choose the name that you want to use. The 2nd is changing your certificate, if you are using an HTTPS trunk and your current cert is not a SAN or Wildcard cert. The 3rd step is to add the appropriate host name to your domain’s public DNS server. The 4th step is to adjust the CWA site settings, or re-publish it according to the specifics in the above-mentioned guide. Once this is done, you can start the UAG wizard.
On the UAG application wizard, the key element is setting the public host name in step 5 of the wizard:
Setting the internal website is also important, because that tells UAG with which internal server it talks to. That server has to be resolvable and reachable on the appropriate ports. This part is no different than publishing other applications, but some users are iffy about it still. In case the publishing does not work, one of the first troubleshooting steps would be to try to access the server directly from the UAG server (open a browser on the UAG server, and browse to http://CWA01/quicksignin, in our case). If it does not work from UAG, it cannot work through UAG.
Blog Post written by Ben Ari
SharePoint is probably the most common service that is published by UAG servers out there, and it can be really simple, but sometimes extremely difficult. The situation can be challenging because the external access to the site can be non-trivial, and there are multiple possible scenarios.
The tricky part about SharePoint publishing, as opposed to many other applications, is that UAG is a reverse-proxy, and was designed to publish multiple applications on the same public URL. To that end, UAG has a sophisticated URL-encoding mechanism known as “HAT” (Host Address Translation). We will talk more about HAT in a minute, but it’s important to know that unfortunately, SharePoint is too complicated for HAT to handle properly, and so we need to use a special publishing concept called “Application-specific hostname”, also referred to as “AAM publishing”. When doing this, we select a different public URL for the SharePoint site, and that’s what UAG uses to “know” with which internal server we are talking.
With most other “regular” web applications, UAG delivers to the client HTML pages that have multiple links in them. Some of these are just calls to other resource files, like images, CSS and JS files. Others are actual links or buttons that the user can press, like a form’s submit button, or a link to a document.
If UAG is publishing an internal server that’s running on, for example, http://internal, then the links in the HTML pages would normally point to resources under that URL. If UAG delivered that page as-is, the client browser would be a pickle…it would see a call to some graphic file like http://internal/logo.jpg, but it would not be able to fetch it, because “http://internal” is not reachable from the public internet. Instead, UAG HATs the URL – it replaces is with a URL pointing to itself. For example: https://uag.contoso.com/uniquesig6bde2668a4c1c5537c654fb04c6ba522/uniquesig0/logo.jpg. When the browser tries to fetch that image, it asks for it from the UAG server itself, and UAG uses that unique string to know from which server, inside the network, to get it…from http://internal in our case. If the UAG is also publishing another internal site (http://internal2, for example), the unique string will be different and unique when accessing the other internal site.
For this HAT process to work, UAG goes through every page that it delivers to the client, and changes all the links it finds to have that unique string of numbers. That process is called SRA, and it’s quite clever, as it needs to be able to handle many possible ways for links to be included in HTML and JavaScripts. Sometimes, though, the code is just too complicated, and it misses. When this happens, the application may have broken links, or some functionality won’t work. For example:
SharePoint is one of those cases – its functionality is based on very complicated scripts that are sometimes impossible for UAG to change. If you’re a veteran of the UAG world, you may recall that early versions of IAG had an older template for SharePoint, and if you used it, some stuff didn’t work properly, like certain operations based on drop-down actions in document libraries.
The people who wrote SharePoint were aware of this challenge, which affects other publishing solutions, and not only UAG. To this end, they built a feature called AAM into SharePoint. AAM does something similar to UAG’s HAT – it changes the URLs in the HTML document BEFORE sending them out to UAG. Configuring AAM, then, is the key to successfully publish SharePoint with UAG.
As we said before, there are multiple possible scenarios. The difference between them is how the SharePoint is to be accessed from the outside, as opposed to the access from inside. Here are the common scenarios:
Internal protocol
Internal URL
External Protocol
External URL
1
HTTP
Short name or FQDN
HTTPS
Different FQDN
2
FQDN
Same FQDN
3
4
For most companies, choosing the appropriate scenario can be daunting. Generally, you’d want to make things as simple as possible for your users, and that means letting them use the same URL at home as the one they use at the office. For many, this may not be an option, because the users are used to use a “short name” like http://SharePoint in the office, or an FQDN (a.k.a. “long name”) that’s not based on a public domain name, like http://SharePoint.contoso.local.
Companies like that will probably have some top-level domain, and will just want to pick some prefix and use it to access their UAG trunk, and for them, scenario no 1 above is the perfect choice. They will need to pick a name for the UAG portal (for example, https://uag.contoso.com) but they also need a separate name for the SharePoint site. This could be, typically, any name under that domain. For example, it could be https://sps.contoso.com or https://SharePoint.contoso.com.
For this to work, we need to configure AAM on the SharePoint site itself, and tell it something along the lines of “When you deliver content outside, change all links from http://internal to http://sps.contoso.com. This is rather simple, and most companies get that right easily. Once the AAM is configured on the SharePoint server, you publish the application on the UAG with the appropriate public URL setup, and it’s all good. If you want to learn more about this, visit the following link:
http://technet.microsoft.com/en-us/library/cc261814(office.12).aspx
Scenarios no. 2 and 3 above are also simple – if you use the same internal and external URL exactly, things are simple, and AAM is not needed at all. Scenario no. 4, though, is more challenging. For this to work, the links need to stay the same, but their protocol needs to be changed, and AAM was not really designed for that. To make it work, we need to create a “bogus” URL for it to feed-on. We basically “invent” a fake internal URL, and tell AAM to treat it as-if it was the name of the internal server. One can come up with any name he wants, and this is configured here:
Once this is set this way, we tell AAM to treat that bogus URL as the internal URL, and then UAG takes care of the rest. One thing that’s unique about this situation is that the IIS running the SharePoint server needs to KNOW about this, and this is not always automatic. This is referred to here (http://technet.microsoft.com/en-us/library/cc261814(office.12).aspx) as mistake 4. If you EXTEND the web application in SharePoint and use the bogus hostname, this should be fine, as the extension process configures IIS correctly. Sometimes, though, you don’t need to extend the application, and that may not work. This is also discussed here:
http://technet.microsoft.com/en-us/library/cc298636(office.12).aspx
If the process has not been done correctly, the symptoms would typically be a 400 error – “bad request”, coming from the SharePoint IIS. IIS issues that error because it receives a request for the bogus hostname (fakeinside, in our example above) which it does not recognize, as none of the host-headers on any of its sites has been configured with it. Ideally, the appropriate action would be to extend the SharePoint application using the bogus hostname. Alternatively, you could also add it to IIS manually, using the following steps:
1. On the server running SharePoint Products and Technologies, open the IIS manager
2. Click on Sites
3. Locate and click on the site that corresponds to the SharePoint site that you intend to publish via UAG. For example: “SharePoint – 80”.
4. In the Actions pane, click Bindings.
*Note the binding settings for the port used by the site. For example: 80
5. Click on the site binding, and click Add
6. Set the bindings’ Type, Post and IP Address to be identical to what you noted in step 4. The settings will not conflict, because the new binding will have a host header that the other one does not.
7. In the host name box, type the FQDN host name that you assigned as the Replacement host header in the Farm host name setting. For example: “fakeinside”
8. Click OK
9. Click Close
10. Exit the IIS Manager.
Yay! This is the end of round 1. Remember, each of two rounds in the contest have four quizzes – and this is the fourth quiz of round one.
Let’s first get to the answers for Quiz 4 and then we’ll look at the leaderboard and the assignment of points for the round.
Question 1:When a DirectAccess client is directly connected to the Internet and is assigned a public IP address, the only IPv6 transition technology the DirectAccess client can use to connect to the UAG DirectAccess server is 6to4. A. True B. False
A DirectAccess client can use one of three IPv6 transition technologies to tunnel IPv6 messages over an IPv4 Internet. You have probably read that when the DirectAccess client is on the Internet and assigned a public IP address, it will use 6to4 as its IPv6 transition technology. While that is true, that doesn’t mean that the DirectAccess client is limited to using 6to4 when assigned a public IP address. While the algorithm for determining which IPv6 transition technology will be used at any point in time, when the DirectAccess client is assigned a public IP address it will try to activate its 6to4 adapter. However, if the 6to4 adapter fails to initiate, the DirectAccess client can attempt to enable its Teredo or IP-HTTPS adapters. Several people have noticed that when a DirectAccess client is connected to some wireless carriers, the 6to4 adapter fails to start and Teredo is used in its place. While we’re not sure what the root cause of this situation is in all instances, there is a chance that the wireless carriers are blocking IP Protocol 41 somewhere between the DirectAccess client and DirectAccess server.
You can find more information on how the DirectAccess client choose an IPv6 transition technology to use at http://blogs.technet.com/b/edgeaccessblog/archive/2010/05/09/the-mystery-of-the-ip-https-listener-an-outlook-client-and-an-ipv4-only-network.aspx
Question 2:Which of the following UAG DirectAccess component technologies require certificates and PKI? A. IP-HTTPS Listener B. Infrastructure tunnel C. Intranet tunnel D. Network Location Server E. Client authentication for IP-HTTPS F. All of the above G. None of the above
The answer to question 2 is F.
Certificates and PKI are used in a number of places in the DirectAccess solution architecture. The IP-HTTPS listener requires a certificate bound to it so that an SSL session can be established between the DirectAccess client and server.
The infrastructure tunnel is an IPsec tunnel that allows the DirectAccess client access to management servers on the intranet. The intranet tunnel is an IPsec tunnel that allows the DirectAccess client access to all other resources on the intranet. Both IPsec tunnels require that the DirectAccess client and DirectAccess server have computer certificates to enable both authentication and encryption for both of the IPsec tunnels.
The Network Location Server is used to help the DirectAccess client determine if it is currently on or off the intranet. If the DirectAccess client can establish an HTTPS connection to the Network Location Server, the Name Resolution Policy Table will be disabled and the DirectAccess client will use the DNS server configured on its local NIC for name resolution. A certificate is required on the Network Location Server’s web site so that the SSL session can be established.
When a DirectAccess client uses IP-HTTPS to connect to the DirectAccess server, the DirectAccess client uses client certificate authentication to authenticate itself before successful establishment of the IP-HTTPS tunnel. In the case of IP-HTTPS, certificates are used by the IP-HTTPS listener and by the client to authenticate before the IP-HTTPS tunnel is established.
Question 3:In order to support DirectAccess client access to the intranet tunnel using NAP, you must deploy at least one Windows-based CA. A. True B. False
The answer to question 3 is A.
When the DirectAccess client starts, it automatically negotiates the infrastructure DirectAccess tunnel. The infrastructure tunnel enables the DirectAccess client access to key management servers on the intranet, such as domain controllers, DNS servers, and management servers that are used by IT to command and control DirectAccess clients. The second DirectAccess tunnel, called the intranet tunnel, allows the DirectAccess client to connect to all other resources on the intranet. Normally, the DirectAccess client uses computer certificate authentication and Kerberos (user) authentication to start the intranet tunnel.
However, you can improve the level of security applied to enabling the intranet tunnel by requiring the DirectAccess client to pass NAP inspection. However, in order to deploy NAP-based access control over the intranet tunnel, you must have at least one Windows-based CA on the intranet to support NAP.
For more information on DirectAccess with NAP requirements, check out http://technet.microsoft.com/en-us/library/gg315299.aspx
Here are the results of Round 1:
Winner – christophf (5 points)
2nd – mika (3 points) jasonj (3 points) oblaba (3 points)
3rd - olivier (1 point)
Point assignment is based on the rules described on Quiz 1 Round 1 at http://blogs.technet.com/b/tomshinder/archive/2010/12/02/uag-sp1-directaccess-contest-quiz-one-round-one.aspx
Next week we begin Round 2. There will be 4 quizzes in Round 2.
Now for those of you who think you’re out of the running – don’t give up! Even if you’re mathematically out of the running for this contest (which ends with the end of round 2), there will be another contest where round 2 of this contest (which starts with the next quiz) will be round 1 of contest 2! So – keep playing!
It’s time for Quiz 4 Round 1!
This is the last quiz in Round 1. If you’re in front, make sure you don’t miss this one – and if you’re playing catch up, it’s even more important, as I suspect some of the leaders will miss today’s quiz because of Christmas, which give you a chance to move ahead.
There you go! I know you’re all busy this week and next, so the questions are short and sweet.
Send your entries until 9AM Central Standard Time (-0600 UTC) on Monday December 27th.
Tom Shindertomsh@microsoft.comKnowledge Engineer, Microsoft DAIP iX/Forefront iX UAG Direct Access/Anywhere Access Group (AAG) The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspxFollow me on Twitter: http://twitter.com/tshinderFacebook: http://www.facebook.com/tshinder
Hi everyone. I’m David from the UAG test team. In this post I want to tell you a bit about the test work we did for UAG 2010 SP1.
During this release, our major goal was to bring the product to a new level of quality, and to do this we pretty much rebuilt our tests from scratch.
Here’s a short overview of our key investments:
Immediate results - running all the tests every night
One of the most important lessons from past releases is that if an automatic test doesn’t run every night – it breaks, and once tests start to break, heavy costs are involved to fix them.
Our goal was simple - if the nightly build ends at 11pm, all automatic tests must finish running on that build by 8am the next morning. That provides 9 hours to run all the automatic tests. Sounds simple, huh?
But the challenge is huge. In terms of UAG tests, 9 hours is a very short time. Just deploying the topology (which beside the UAG machines, also contains: clients, ADFS servers, SharePoint and Exchange servers, etc…) takes a minimum of 2 hours, not to mention the fact that UAG has lots of features to test, which means insane amount of tests.
Parallelization is the key here. Although running all the automated tests takes well over 40 hours, running them in 6 labs in parallel gets us to our goal. The trick is to get automation to a state where it’s possible to easily run tests in parallel. Here are some of the steps we took to get there:
- Automate lab deployment
- Focus tests on key topologies
- Decoupling test suites (which partly use virtualization)
Robustness – Configuring the user interface (UI) without UI automation
A classic testability problem – you can only configure UAG using its UI. Pre-SP1 automation solved this problem using a traditional approach of UI automation. As you can guess, that approach isn’t very robust. To improve it we tried a new approach – creating testability hooks to access the UI code directly, thus bypassing the testability problem, without fragile UI dependencies. This method isn’t bullet proof, and does have downsides, but it allows the discovery of most test-breaking changes during compile time, and even provides some coverage of UI code paths.
We used code generation to simplify the process even further. To update the product configuration, hook was written. The hook definitions (structure, parameters to pass) are kept in an XML file. From the XML files we generate code that the product code can include, as well as scripts that the test code can execute. All that is then required is to implement the actual hook logic in the product code, and you have your hook, with almost no test code to implement.
The process of adding a UI hook looks like this:
Agility - Utilizing the power of virtualization
Automatic tests running each night don’t help if the tests break too often. We want tests to find the problems before damage is done. Changing tests from being bug detectors to bug preventers is probably the holy grail of test teams everywhere, but it’s much easier said than done.
Why? One of the reasons is that running tests require labs, and lab resources are usually limited.
Even if you manage to simplify your automation so that anyone can run it, it isn’t effective if a 20-box ultra-complex topology is needed to run the tests. This is especially a problem in a product such as UAG, where the topologies we use to simulate real customer scenarios are complex.
Here virtualization came into play. We designed a single virtual 8-box topology (nicknamed “private lab”), that includes everything required to run most automatic tests.
The next step, believe it or not, was to provide every developer and tester with his or her own private lab. We’re talking about over 1,000 virtual machines, hosted on a few ultra-powerful hosts. This wasn’t easy to maintain, but it was well worth the price. Bugs were found before getting submitted, and developers were able to easily evaluate the effect of their code changes.
Here’s a representation of a private lab (Note that this is the DirectAccess flavor of the private lab. When testing Secure Web Publishing scenarios, we used different lab flavors).
Private lab topology
During virtualization we utilized the power of snapshots, which helped us in 2 ways:
1 – Speeding up new build deployment:
Instead of rebuilding the topology every night before running the tests, each topology came with a snapshot named “Baseline”. The baseline snapshot contained all the static elements of the lab (meaning all the stuff that doesn’t change between builds). To clean up the lab between builds, we simply reverted the lab back to its baseline snapshot.
2 – Solving the “dirty lab” problem:
A major challenge during testing is cleaning up machines between test suites. This is especially a problem when testing technologies like DirectAccess, which spreads GPOs across most of the lab machines, and are difficult to clean up. Our solution was to create a snapshot called “CleanConfiguration” during the automation cycle flow. This snapshot provided a common starting point for all test suites, making cleanup the simple step of reverting the lab back to the CleanConfiguration snapshot. By using this approach, Parallelization became an easy task.
To better explain, here’s a short pseudo-code implementation of our automation cycle flow :
1. Revert the lab to the “Baseline” snapshot.
2. Prepare the lab to run tests (install the product, etc…).
3. Create “CleanConfiguration” snapshot (if one already exists, overwrite it).
4. For each test suite
a. Run the test suite.
b. Revert the lab to the “CleanConfiguration” snapshot.
Note that at the end of our cycle, the lab has the “CleanConfiguration” snapshot of the latest build it ran. This is not accidental – it’s used in case we need to rerun a test on an exact same lab (for example, to confirm the reproducibility of a certain bug). We are able to do this until the next cycle, without needing to redeploy the product.
Reusability - Separate tests from topology
Accessing topology data inside test code isn’t easy. On the one hand, you want to decouple tests from the topology as much as possible. On the other, you want a simple, logical, maintainable object model that allows you to write simple clean code. For example:
foreach (Machine machine in lab.Topology.Machines)
{
Console.WriteLine("I'm machine {0}, from domain {1}",
machine.FQDN,
machine.Domain);
}
To do this we created a special topology API, which includes both the code that creates the topology, and the tests can access.
By separating the tests from the topology data, we were able to do cool stuff like run all our automatic tests using different topologies (that better simulate real customer scenarios), without writing a single extra line of code.
We used the .Net WCF ServiceModel Metadata Utility tool (svcutil.exe) to auto-generate the object model from a schema XSD file, and kept the XSD (which is somewhat easier to maintain then the actual code). We were able to easily serialize and deserialize all the topology data from an easy and intuitive XML format (that already has a schema) for no cost. Naturally, the generated code you get from SVCUtil isn’t enough, since the topology objects sometimes require some more complex actions. To support them, we added extension classes to the generated code.
In the end, it looked something like the following example –
· We have our schema XSD file, which contained topology objects, such as this:
<xs:complexType name="Credentials">
<xs:complexContent>
<xs:extension base="om:ReferenceObject">
<xs:sequence>
<xs:element type="xs:string" name="Username" minOccurs="0" maxOccurs="1"/>
<xs:element type="xs:string" name="Password" minOccurs="0" maxOccurs="1"/>
<xs:element type="xs:string" name="Domain" minOccurs="0" maxOccurs="1" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
· After running SVCUtil, we get this auto-generated code that matches the Credentials object:
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Runtime.Serialization", "3.0.0.0")]
[System.Runtime.Serialization.DataContractAttribute(Name="Credentials", Namespace="http://AAG.Test.Infrastructure.Configuration.ObjectModel/", IsReference=true)]
public partial class Credentials : aag.test.infrastructure.configuration.objectmodel.ReferenceObject
private string UsernameField;
private string PasswordField;
private string DomainField;
[System.Runtime.Serialization.DataMemberAttribute(EmitDefaultValue=false)]
public string Username
get {return this.UsernameField;}
set {this.UsernameField = value;}
[System.Runtime.Serialization.DataMemberAttribute(EmitDefaultValue=false, Order=1)]
public string Password
get{return this.PasswordField;}
set{this.PasswordField = value;}
· And that object can be easily serialized and de-serialized from an XML file looking like this –
<Admin z:Id="DomainAdmin">
<ID>DomainAdmin</ID>
<Username>admin</Username>
<Password>admin</Password>
<Domain>contoso.com</Domain>
</Admin>
If you have any questions, or would like to see more such posts in the future, comment this post and let us know.
David
David BahatAnywhere Access Group (AAG)
You’ve deployed DirectAccess on your network as a pilot project for your IT group over the holidays and everything is working great. When the users are behind a wide open NAT device, they use Teredo to connect to the UAG DirectAccess server. When they’re behind a port-restricted firewall or web proxy only, then they fall back to IP-HTTPS. Of course, you’d prefer that they use Teredo because it’s better performance. But IP-HTTPS connectivity is better than no connectivity at all.
Then it happens – the unthinkable!
Performance seems to slow down. You do an ipconfig and find that the Teredo interface isn’t starting up and only IP-HTTPS is being used. You move the client around, first behind a wide open NAT device and nothing changes. Then you disable the 6to4 interface and connect the client directly to the Internet. Still, only the IP-HTTPS interface comes up.
What’s up with that?
Here are some hints:
First, check out http://blogs.technet.com/b/edgeaccessblog/archive/2010/05/09/the-mystery-of-the-ip-https-listener-an-outlook-client-and-an-ipv4-only-network.aspx
Next, check out the graphic below:
Finally, check Ben Lee’s blog where he puts all the pieces together to come up with a solution over at http://www.bibble-it.com/2010/12/19/uag-directaccess-only-connects-via-ip-https
Happy Holidays guys! We got a great response to this weeks quiz and added some new contestants. That’s great! Even with the busy holiday it’s cool to see you all interested in playing and learning more about UAG DirectAccess.
Now for the answers:
Question 1:You must be running IPv6 on your corporate network in order to deploy a UAG DirectAccess server that enables DirectAccess clients to connect to intranet resources from virtually anywhere. A. True B. False
The answer to Question 1 is B. When you use the UAG DirectAccess server solution, there are no IPv6 dependencies for resources on the intranet. Because the UAG DirectAccess server includes the NAT64/DNS64 service, all the machines behind the UAG DirectAccess server can be IPv4-only operating systems. When you use the UAG DirectAccess server, the only machine that needs to be Windows Server 2008 R2 on the network is the UAG DirectAccess server. Note that when you use an IPv4-only network behind the UAG DirectAccess server, you will not be able to take advantage of a full “manage-out” deployment. In a full “manage-out” deployment, hosts on the intranet can initiate connections to DirectAccess clients. IPv4-only hosts cannot initiate connections from DirectAccess clients, but DirectAccess clients can initiate connections to IPv4-only hosts on the intranet.
Question 2:You have installed UAG RTM and you want to begin the configuration of the DirectAccess feature. The UAG Management console opens and you are able to see the information on all nodes except for the DirectAccess node in the left pane of the console. When you click on the DirectAccess node in the left pane of the console, you see the following error dialog box:
(Cannot Load the DirectAccess view (0).)
What is a possible cause of this problem? A. The NetBIOS name of the UAG server contains more than 15 characters B. In order to configure DirectAccess, you must first install UAG Update 1 C. The DirectAccess server is a member of a Windows Server 2003 domain D. A firewall behind the UAG server is blocking the SNA (TCP/UDP 108) protocol
The answer to Question 2 is A. This is an interesting problem that was discovered by Shannon Fritz, which he shared on the TechNet forums and discusses in his blog post over at http://blog.concurrency.com/infrastructure/uag-cannot-load-the-directaccess-view-0/ The solution was to rename the machine so that the host name portion of the FQDN was 15 characters or less.
=========================================== Question 3:A UAG DirectAccess server must be a domain member. However, the UAG DirectAccess server does not need to be a member of the same forest or domain as the resources that DirectAccess users will connect to. What Active Directory domain functional level is required for the domain that the UAG DirectAccess server belongs to for DirectAccess to work correctly? A. Windows Server 2008 R2 B. Windows Server 2008 C. Windows Server 2003 D. None of the above
The answer to Question 3 is D. This is a tricky question. Many of you answered C because you might have read that Windows Server 2003 domain functional level is the minimum domain functional level. I can’t confirm or deny that is true, since it’s not documented anywhere and I suspect that no testing was done with Windows 2000 Server domain functional level. However, regardless of what the minimal domain functional level might be, the question asked which was required. Because you can use any of these domain functional levels in answers A, B and C, none of them are required – you can use any one of them. This makes answer D the correct answer.
The race remains pretty close as we enter into the last quiz of the first round. Six contestants are within two points for the lead. Also, note that the zeros you see in the results are due to contestants that didn’t send an entry for that quiz – no one has scored a zero on any of their entries. The blue highlighting on the cell indicates that no entry was received. But you can see that a few of the new entrants have some strong performances and could end up in the top three if any of those near the top decide to take a Christmas vacation for Quiz 4 .
I want to thank everyone who participated in Quiz 3, Round 1. Quiz 4 and the last quiz in Round 1 will be posted on December 23, 2010 – so make sure you put that on your calendar so you don’t miss the quiz because if you do, someone behind you might sneak up and take your position! But even if you don’t end up in the top three, you’ll learn a lot and remember more when you have some “skin in the game”. And then there’s always Round 2. See you then!
Citrix recently released version 5.4 of their Web Interface. Obviously there were major changes in the layout and behaviour therefore it does not work anymore with the UAG template for WI 5.0. Are there any plans to include support for the new version in an update soon or will there be a hotfix/hack which will support it? The problem seems to be with the way the WI does the detection of any installed XenApp plugin as this loops ifinitely (GET /Citrix/XenApp/auth/silentDetection.aspx).
Test Lab Guides provide a method for you to try out a new product or technology and see how it works in your own test lab. When you use Test Lab Guides you see all the working parts, all the front-end and back-end components, and most importantly, see how that all work together to create a working solution.
Test Lab Guides enable you to get your hands on each configuration setting for simple to extremely complex scenarios. In fact, I’m working on a Test Lab Guide now that will require 10 virtual machines – but provides a demonstration of a very complex multi-site deployment of UAG DirectAccess using a single ISATAP cloud to enable multi-point access to the intranet. You’ll see what it looks like in about two weeks.
There are three types of Test Lab Guides:
The following troubleshooting TLGs are available:
The Troubleshooting Test Lab Guides are actually based on a working configuration that you have already created when you did one of the “Demonstrating” Test Lab Guides.
For example, the Test Lab Guide: Troubleshoot UAG DirectAccess is based on the completion of another Test Lab Guide called Test Lab Guide: Demonstrate UAG DirectAccess. In the troubleshooting Test Lab Guide you begin with a working configuration and then break stuff on purpose (we give you instructions on what to break, in what we call “Break-Me’s). After you break the stuff, you use a variety of troubleshooting tools and techniques to troubleshoot the broken configuration.
For an example of how “Break-me’s” work, check out this video.
The goal of the Troubleshooting Test Lab Guides is to show you what tools are available to troubleshoot the product, technology or scenario and what their output looks like when things are working right, and then what the output looks like when things aren’t working (because you’ve broken it on purpose).
We have received various feedback regarding the “Troubleshooting” guides and we would like to get input from the community on whether or not you find this approach valuable and if we should continue investing in the troubleshooting guides. Of course, we think the Troubleshooting Test Lab Guides are a great idea because you get hands-on experience with the troubleshooting tools and some insight into what things should look like and what they might look like when they’re broken. In the guides we try to focus on the most common troubleshooting scenarios so that you get the most “bang for your buck”.
What do you think? Are the troubleshooting Test Lab Guides valuable to you? Would you like to have more troubleshooting Test Lab Guides? Is there something missing from the current approach to Troubleshooting Test Lab Guides that would make them more useful for you?
Let us know! You can write to me at tomsh@microsoft.com and let me know what you think about the Troubleshooting Test Lab Guides or you can write your thoughts and ideas about Troubleshooting Test Lab Guides in the comments section below. I do subscribe to the RSS feed for the comments section, so I’ll know when you’ve posted a comment and I’ll acknowledge your input and address your issues.
Thanks for the help!
It’s time for Quiz 3-Round 1!
Send your entries until 9AM Central Standard Time (-0600 UTC) on Monday December 20th.
The scores are really close and at this point, anyone can end up winning Round 1. So make sure to send your answers in this week and next week.
The questions in Quiz 1 and Quiz 2 were pretty tough – so I hope you find these a bit easier. So far everyone is doing great and learning a lot! If you know any UAG DirectAccess admins, let them know about the contest so that they play too. Even though they might not win the first round (winner of the first four quizzes), remember there is a second round. So it’s possible to win by cleaning up in the second round. And they can join in on the fun of taking the quizzes and learning from the answers.
When the contest is over I’d like to put together a LiveMeeting and talk about the contest and if the winner is willing to be interviewed, take the opportunity to interview the winner and get his or her thoughts on UAG DirectAccess.
Troubleshooting is always a challenging topic. Challenging from the point of view of the person who has to do the troubleshooting, and challenging to the product group who wants to provide valuable troubleshooting information so that you can solve your troubleshooting issues.
Because information on troubleshooting is so dynamic, we need a way to share information on what we learn about troubleshooting as soon as possible. For this reason, we’ve decided to publish UAG DirectAccess troubleshooting information to the TechNet wiki. With the TechNet wiki, we can provide you “just in time” information about how to troubleshoot problems you might encounter with UAG DirectAccess.
And even more important, if you find that you have a valuable troubleshooting information that will help other UAG DirectAccess admins, you can share that information on the TechNet wiki!
As we begin this effort, we’ve created a main UAG DirectAccess troubleshooting page – Forefront UAG DirectAccess Troubleshooting. On this page you will find useful links to UAG DirectAccess troubleshooting content. Right now, you’ll find links to the following wiki docs:
The great utility of the wiki is that if you find other UAG DirectAccess troubleshooting information, you can add to this list – as another logged onto the wiki can edit and enhance the content. Make sure to add the RSS feed for this page so that you receive automatic updates when this troubleshooting page is updated.
Here are the answers to Quiz 2, Round 1:
====================================================
Question 1:You have installed UAG Service Pack 1 and find that you are unable to connect to resources on the intranet using fully qualified domain names. What is the most likely reason for this failure?
A. The ISATAP adapter on the DirectAccess client failed to startB. The Teredo interface on the UAG DirectAccess server failed to startC. The DNS64 service failed to startD. The IP-HTTPS certificate needs to be renewed
The answer to Question 1 is C. The DNS64 service is used by the UAG DirectAccess server to resolve names on behalf of DirectAccess clients. Although we often talk about DNS64 as providing name resolution support for IPv4 only hosts in conjunction with it’s integration with NAT64, the DNS64 service also provides what you can consider to be a “DNS proxy” to support UAG DirectAccess client name resolution. If you perform a netsh name show eff command on a UAG DirectAccess client, you will see something similar to what appears in the figure below. Notice the DirectAccess (DNS Servers) setting for Settings for .corp.contoso.com. This address is the 6to4 address of the UAG DirectAccess server. When the DNS64 service receives the name query request from the DirectAccess client, it forwards the query to the DNS servers configured on the internal interface of the UAG DirectAccess server and then it receives and caches the DNS server responses before returning the results to the DirectAccess client.
It now should make sense that if the DNS64 services does not start, intranet name resolution for DirectAccess clients will fail. However, why did the DNS64 service fail to start? If you check the UAG Service Pack 1 Release Notes (http://technet.microsoft.com/en-us/library/gg315322.aspx) You will see the following:
“After installing SP1 RTM on a Forefront UAG server running SP1 RC and acting as a DirectAccess server, the DNS64 service will be set to Manual. Following the installation, set the DNS64 service to Automatic and start the service.”
This explains why the DNS64 service failed to start. After applying UAG SP1, you will need to manually configure the DNS64 service to start automatically. Jason Jones provides some information on how to do this on his blog at http://blog.msedge.org.uk/2010/12/microsoft-forefront-uag-dns64-service.html
Answer A is incorrect because the ISATAP adapter on the DirectAccess client isn’t used to connect to the intranet through the DirectAccess tunnels. Answer B is incorrect because if the Teredo adapter failed to start, the IP-HTTPS adapter could enable connectivity – recall that only name resolution is affected, which suggests that connectivity through an IP address was still available. Answer D is incorrect because the IP-HTTPS listener’s certificate status would not have selective effects on name resolution.
Question 2:A Help Desk professional is trying to provide assistance to a DirectAccess user who is connected to the intranet from a hotel on another continent. The DirectAccess connection is working for the user and the user is able to connect to all required resources on the intranet. However, the user is having problems with some editing software and would like the Help Desk Professional to take a look at her system. When the Help Desk Professional tries to RDP into the user’s computer, the connection attempt fails. What is the most likely reason for the connection failure?
A. A Windows Firewall rule on the client exists for inbound RDP with Edge Traversal enabledB. The Help Desk Professional is connecting from a Windows 2000 Workstation ComputerC. The hotel where the user is staying blocks outbound RDP connectionsD. The user is connecting to the UAG DirectAccess server using IP-HTTPS
The answer to Question 2 is B. In this scenario the Help Desk professional is trying to establish a connection from the intranet to the DirectAccess client on the Internet. This is what we often refer to as a “manage out” scenario. In order for hosts on the intranet to initiate connections to DirectAccess clients on the Internet, there must be a Windows Firewall with Advanced Security Firewall Rule in place on the DirectAccess client to support that connection.
In addition, if the DirectAccess client is using Teredo or IP-HTTPS, the the Firewall Rule will need to have Edge Traversal enabled (because these protocols will be used when the DirectAccess client is located behind a NAT device). You can find more information about Edge Traversal and DirectAccess clients at http://technet.microsoft.com/en-us/library/gg315320.aspx In addition to a Firewall Rule that allows the desired protocol inbound to the UAG DirectAccess client with Edge Traversal enabled, the system on the intranet that’s initiating the connection must be an IPv6 capable machine that is able to consume the IPv6 AAAA resource record returned in a name query for the DirectAccess client (and the system must be assigned an IPv6 address, either through native IPv6 addressing or via ISATAP). Since the Help Desk Professional is using Windows 2000 Workstation, the system is not IPv6 capable and therefore the Help Desk Professional will not be able to initiate a connection to the DirectAccess client.
Answer A is incorrect because we do need a firewall rule on the client to support inbound RDP with Edge Traversal enabled. Answer C is incorrect because all communications in this scenario are taking place over the IPsec tunnels used by DirectAccess – which means the firewalls are actually only seeing the IPv6 transition technology headers (most likely Teredo or IP-HTTPS). Answer D is incorrect because “manage out” scenarios are supported for all IPv6 transition technologies the DirectAccess client might use when connecting to the UAG Direct Access server.
Question 3:A UAG DirectAccess server benefits from being placed behind a front-end firewall in order to reduce the firewall filtering load on the TMG server that is also installed on the UAG server. Which of the following protocol(s) is/are not required through the front-end firewall to the UAG DirectAccess server when the server is connected to an IPv4 Internet? (Choose all that apply):
A. IP Protocol 50B. UDP Port 3544C. TCP Port 443D. IP Protocol 41
The answer to Question 3 is A. The question asks which protocol(s) are NOT required access through the front-end firewall to the UAG DirectAccess server when the server is connected to the IPv4 Internet. UDP Port 3544 inbound and outbound to and from the UAG DirectAccess server is required to support Teredo. TCP port 443 is required to and from the UAG DirectAccess server to support IP-HTTPS, and IP Protocol 41 is required to and from the UAG DirectAccess server to support 6to4. Teredo, IP-HTTPS and 6to4 are IPv6 transition technologies that allow the DirectAccess client to tunnel IPv6 messages over the IPv4 Internet.
In contrast, when the UAG DirectAccess server is connected to the IPv6 Internet. there is no need to support the IPv6 transition technologies and the DirectAccess client won’t be tunneling their IPv6 messages inside of these protocols. Instead, the DirectAccess clients will establish IPsec connections to the UAG DirectAccess server directly – these IPsec connections won’t be encapsulated by the IPv6 transition protocol headers because there is no need for them. In this scenario, the front-end firewall needs to allow IP Protocol 50 (ESP) inbound and outbound to and from the UAG DirectAccess server, and UDP port 500 (IKE) inbound and outbound to and from the UAG DirectAccess server. In addition, ICMPv6 inbound and outbound to and from the UAG DirectAccess is also required, because by default, ICMP messages are not encapsulated by IPsec.
Therefore, the answer to the question is A since it is NOT required when the UAG DirectAccess server is connected to an IPv4 Internet.
You an find more information on firewall configuration requirements for the UAG DirectAccess server over at http://technet.microsoft.com/en-us/library/dd857262.aspx
Looks like we have a real horse race going right now! Six contestants are within one point of each other, and eight are within three points of each other. I should note that all the “zero” point results are because the contestant didn’t send an entry for that quiz. No contestant has actually actually submitted an entry where none of the answers were correct. Also, its not too late to come from behind and win! If the leaders fail to submit an entry, or get the questions wrong, you can still circle the field and run in-the-money for round 1.
I want to thank everyone who participated in Quiz 2, Round 1. This was another tough one! Some of the quizzes will be easier, some will be more difficult. But I hope you will continue to play and that you find this a useful and fun learning experience. Quiz 3, Round 1 will be posted on December 16, 2010 – so make sure you put that on your calendar so you don’t miss the quiz because if you do, someone who’s ahead of you now might miss the next quiz and that will be your chance to take the lead! For the same reason, those of you who didn’t participate in Quiz 2 you still have a chance – so make sure to take next week’s quiz and get yourself on the leaderboard! And even if you don’t win, you’ll learn a lot and remember more when you have some “skin in the game”. See you then!
It’s time for Quiz 2-Round 1!
I got started late on this one today and I was also reminded that there are plenty of UAG DirectAccess fans who aren’t in North America
For this reason, I’m going to change one of the rules for the contest which will allow more people to participate. From this point forward, you don’t have to send your answer until 9AM Central Standard Time (-0600 UTC) on Monday December 13th.
All the other rules remain the same.
There you go! Now click the following link (which will populate the subject line on the email message) to email me your answers:
I must receive your entry by December 13, 2010 9:00 AM Central Time
Have fun and good luck!
When a DirectAccess client computer is on the Internet, it connects to the corporate network using DirectAccess. All communications between the DirectAccess client and DirectAccess server are done over IPv6 (encapsulated by an IPv4 tunnel to carry the IPv6 traffic over the IPv4 Internet). In fact, the client application assumes that the connection is IPv6 from end-to-end, even when the destination server on the intranet is an IPv4-only capable resource. UAG DirectAccess can enable IPv4 connectivity to an intranet resource by using its NAT64/DNS64 IPv6/IPv4 protocol translation feature, which allows the UAG DirectAccess server to map an IPv6 address associated with the IPv4 address of the intranet resource. This mapped IPv6 address is used by the DirectAccess client to connect to the IPv4 resource on the intranet. The UAG DirectAccess server will translate this to an IPv4 address and forward the connection to the desired IPv4-only resource on the intranet.
While NAT64/DNS64 solves the problem of IPv4-only capable systems on the intranet, the client side application on the DirectAccess client must be IPv6 capable. If the client-side application is not IPv6 capable, it must use a non-DirectAccess method to reach the application server, such as an Internet accessible application gateway.
In the context of connectivity to SAP resources, you had to use an alternate method outside the DirectAccess tunnels before the release of SAP GUI version 7.1. With the introduction of SAP GUI 7.1, the DirectAccess client can connect to SAP resources on the intranet over the DirectAccess tunnels. However, to get this to work, you need to set a specific environment variable, which we will discuss later in this post. This solves the IPv6 problem on the client side.
If the SAP server is not IPv6 capable (meaning that it isn’t using ISATAP or native IPv6 addressing), then the UAG DirectAccess server’s NAT64/DNS64 feature will be used for IPv6/IPv4 protocol translation. While this will allow access to a SAP server, it will break SAP load balancing. The end result is that if you don’t need SAP load balancing, then all you need is to do is set the environment variable on the SAP GUI client and connectivity will work over DirectAccess because NAT64/DNS64 will take care of the protocol translation for you.
However, if you need load balancing for your SAP servers, NAT64/DNS64 isn’t going to do all the work. In this case you’re going to need to bring in another component, called a SAPRouter.
A SAProuter is a non-transparent gateway that can accept both IPv4 and IPv6 connections and do protocol translation between IPv4 and IPv6. NAT64/DNS64 are not used. Instead, the DirectAccess client connects to the SAPRouter using the SAPRouter’s IPv6 address, and then the SAPRouter can route the connections to the IPv4-only SAP servers behind the SAPRouter. At this point the SAP servers are able to load balance the connections and also return the responses to the SAPRouter, which is then able to return the responses to the DirectAccess clients through the UAG DirectAccess server.
Figure 1 illustrates the request/response path between the DirectAccess client and the SAP resource servers (note that the load balancing component of the SAP servers is called out to make the path easier to understand).
The following are instructions should configure the SAP GUI 7.1 client to work with DirectAccess:
If you are using a saprouter you would have to add an entry in the field "SAProuter String", for example "/H/saprouterxy".
If you have further questions regarding this issue, please write to the address in the sig line below.
Authors:
Noam Ben-Yochanan, Senior Program Manager, DA
We are proud to announce that Forefront Unified Access Gateway (UAG) 2010 was released and is available now for download as an upgrade from UAG 2010 or for a clean install. SP1 includes a leap forward in DirectAccess deployments, ADFS 2.0 support and investments in quality. You can learn more on our TechNet Library and SP1 blog posts.
You can download SP1 here:
A few days ago, Service Pack 1 for UAG has been released, but we have seen some confusion with customers with regards to the type of updates UAG may have and how they relate to each other.
UAG can have the following types of updates:
1. A private fix, which the product-group may issue to resolve a specific issue that has been discovered.
2. A hot-fix, which may be released to resolve an issue, but is suitable for multiple customers.
3. A Roll-up, which is a hot-fix that includes several fixes in one package.
4. An Update, which is a more major collection of changes and fixes, often containing some functionality change.
5. A Service Pack, which is a major change to the product, including fixes and usually major functionality changes too.
Many Microsoft products have hot-fixes released, and these are often not publicly available, but require a customer to contact Microsoft within a support-case to receive. The reason for this is that the fix may require personal attention and guidance by a support engineer because it has a specific installation procedure, or changes the way the product behaves in a way that is not suitable for the general public.
Until now, the UAG product-group has released Update 1, which was followed by Roll-up 1. A little later Update 2 has been released, and most recently, Service Pack 1 was released. Service-packs are cumulative, so SP1 includes all updates prior to it. This means that if your server is at Update-1 level, there will be no need to install Update 2 before installing Service Pack 1. Similarly, if your server has never been updated, you can go directly to Service Pack 1, with no need to install Update 1, Rollup 1 or Update 2. However, later on, If post-SP1 updates are released, they will not include the Service Pack itself, so you will be required to install SP1, and then the post-SP1 updates.
If you have installed a certain update, you may be wondering how to know at what level you are at. To know this, you can click on the Help menu, within the UAG management console, and select About.
The version number can tell you what version you are running, according to the following table:
Version
Release Date
Version Number
Gold (no updates)
25 January 2010
4.0.1101.0
Sec Update MS10-089
9 Nov 2010
4.0.1101.052
Update 1
12 April 2010
4.0.1152.100
U1 Rollup 1
18 May 2010
4.0.1152.110
U1+Sec Update MS10-089
4.0.1152.150
Update 2
21 September 2010
4.0.1269.200
U2+Sec Update MS10-089
4.0.1269.250
Service Pack 1 RC
21 October 2010
4.0.1575.10000
Service Pack 1
3 December 2010
4.0.1752.10000
Post written by Ben Ari
Both the Windows DirectAccess and the UAG DirectAccess solutions are heavily dependent on the Windows Firewall with Advanced Security. DirectAccess clients take advantage of both firewall rules and Connection Security Rules. Connection Security Rules are IPsec rules that control the IPsec tunnel mode connections between the DirectAccess clients and the DirectAccess server. In addition to the IPsec tunnel mode connections, Connection Security Rules are used to enable IPsec transport mode connections for servers for which you want the DirectAccess clients to connect using end-to-end security.
In order to get the most out of DirectAccess and how DirectAccess works, it helps to have a better understanding of the different components of the Windows Firewall with Advanced Security and how some of the important settings work and how they interact with DirectAccess
Windows Firewall offers three firewall profiles: domain, private and public. The domain profile applies to networks where the host system can authenticate to a domain controller. The private profile is a user-assigned profile and is used to designate private or home networks. Lastly, the default profile is the public profile, which is used to designate public networks such as Wi-Fi hotspots at coffee shops, airports, and other locations.
Different firewall and connection security rules can be configured for each profile. There are default settings that are applied to each profile, but the administrator can customize their default settings.
The different profiles are important because a computer only works as a DirectAccess client when it is not on the corporate network. In order words, if the DirectAccess client detects that it can connect to its domain controller and is on the corporate network, it will use the domain profile. The DirectAccess client will only act as a DirectAccess client when the Private or Public Profiles are enabled. The reason for this is that the Connection Security Rules that enable the IPsec tunnel mode connections to the DirectAccess server are included only in the Public or Private Profiles. There are no Connection Security Rules that enable IPsec tunnel mode connections to the DirectAccess server in the Domain Profile.
The UAG DirectAccess server (as well as the Windows DirectAccess server) will create the Connection Security Rules that allow for the creation of the DirectAccess IPsec tunnels (and the end-to-end IPsec transport mode connections for servers configured for end-to-end security). However, the UAG DirectAccess wizard does not import any firewall rules that you might have configured to work on the corporate network. Those rules that you created for the intranet hosts were created for the Domain Profile. If you want your Domain Profile firewall rules to apply to DirectAccess clients, you will need to enable those rules on the Public Profile and Private Profile too.
In order for intranet computers to connect to DirectAccess clients, there need to be firewall rules in place on the DirectAccess clients that allow the incoming connections from the intranet servers. In addition, if you are blocking outbound connections, you may need to create rules that enable required protocols outbound. There are several things you need to know about these firewall rules:
While it’s possible for you to create your firewall rules in the DirectAccess Clients GPO, that’s not a good idea because your rules will be overwritten the next time you use the UAG DirectAccess wizard and deploy updated GPO settings. Instead, create a new GPO with the firewall settings and apply it to your DirectAccess clients security group or OU.
For a very good tutorial on configuring firewall rules for DirectAccess client, check out How to enable Remote Desktop Sharing (RDS/RDP) from corporate machines to DirectAccess connected machine at http://blogs.technet.com/b/edgeaccessblog/archive/2010/09/14/how-to-enable-remote-desktop-sharing-rds-rdp-from-corporate-machines-to-directaccess-connected-machines.aspx
And if you want to try it out for yourself in your UAG DirectAccess Test Lab, check out Test Lab Guide: Demonstrate UAG DirectAccess Remote Management over at http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=385a3144-8e84-4335-896b-a2927e4d46cd
I’m glad you asked! Yes, there are a few more things you should think about when configuring firewall rules for DirectAccess clients. These are:
Yaniv Naor, SDETom Shinder, Knowledge Engineer/Principal Technical Writer, Anywhere Access Group (AAG)
With the upcoming release of Unified Access Gateway 2010 (UAG) Service Pack 1, we decided it was important to discuss some important scenarios that many of our customers have asked us about. These scenarios are:
We believe that support for each of these scenarios is important for an enterprise ready solution. Business continuity and disaster recovery needs to be part of any solution designed to provide your users seamless and transparent connectivity to resources that give your firm a competitive advantage. In addition, support for multiple, geographically dispersed sites is also considered important in an era of international business can travel and we consider support for this scenario to be central in our near term goals for UAG.
While UAG Service Pack 1 (UAG SP1) can provide you basic support for business continuity, disaster recovery and multi-geo scenarios, we want you to know that we plan to address each of these scenarios with a post-UAG SP1 update and that work is already underway.
However, until we are able to deliver this update to you, we want to provide you some guidance for supported workarounds for these scenarios.
In the area of business continuity and disaster recovery we recommend that you create a “mirrored” installation of your UAG DirectAccess server or array. This can be a hot or cold standby that is configured with the same IP addresses as the production server or array. If the production array should fail, you can bring up the standby server or array and take advantage of ISP subnet redundancy so that traffic is routed to the backup deployment. When the primary UAG DirectAccess server or array comes back up, you take down the backup and route the traffic back through the original route.
There are two primary scenarios to consider when deploying UAG SP1 DirectAccess servers or arrays in multiple locations:
If all your intranet resources are accessible only through IPv4 addresses (IPv4-only network), then you will take advantage of the UAG SP1 NAT64/DNS64 IPv6 to IPv4 protocol translator. In this scenario the source IP address of the incoming connections from DirectAccess clients is always an internal IP address on the UAG DirectAccess server or array. Your existing IPv4 routing infrastructure will be able to route these connections from the UAG DirectAccess server or array to the destination resource and responses back to the UAG DirectAccess server or array that the DirectAccess client is connected to. In this scenario you do not need to worry about IPv6 routing on the intranet.
You would install multiple UAG DirectAccess servers or arrays and apply the DirectAccess client and server settings by using different GPOs (which are specific to the particular UAG DirectAccess server or array)and assigning those GPOs to different OUs or security groups. If you are using a pre-SP1 deployment of UAG, you can use the methods discussed in the blog post http://blogs.technet.com/b/edgeaccessblog/archive/2010/02/18/deep-dive-into-uag-directaccess-tweaking-the-gpos.aspx to deploy the settings to different OUs. If you plan to deploy this scenario with UAG SP1, you can take advantage of the new GPO deployment features included in UAG SP1 which make custom deployment of GPOs to OUs or security groups available in the UAG DirectAccess wizard.
This method enables you to assign a fixed number of clients (based on the fixed number of computer accounts that belong to an OU or security group that you configure) to each UAG DirectAccess server or array. While this method allows for a static level of load balancing (DirectAccess clients can be split relatively evenly between servers or arrays), this approach does not allow users to change which array they connect to. This change requires that an administrator move the computer account to a different security group or OU.
In this scenario, you would take advantage of the same distribution of DirectAccess clients are you would with an IPv4-only intranet – by assigning clients to a specific UAG DirectAccess server or array through the use of different GPOs or security groups. What changes in this scenario is how you handle the IPv6 routing requirements in a geographically distributed environment.
In this scenario you can configure a single ISATAP cloud and deploy multiple ISATAP routers that are on-link with the UAG DirectAccess server or array at each location. To make this work, you need to do the following:
One other thing worth highlighting is the fact that the ISATAP Router needs to be configured with two IPv6 addresses:
Figure 1 provides a high level overview of what this configuration looks like.
Figure 1 Workaround for an intranet with IPv6 ISATAP resources
Figure 1 shows that the ISATAP router in Asia is configured with routes for the Asia UAG Teredo and IP-HTTPS address space to the Asia UAG DirectAccess server. It also shows that the ISATAP router in the USA is configured with routes for the USA UAG Teredo and IP-HTTPS address space to the USA UAG DirectAccess server.
If you have some experience with IPv6 and ISATAP, the configuration should not be too difficult to accomplish. However, if you would like to see how this configuration works in a Test Lab, we plan to publish a Test Lab Guide – Test Lab Guide: Demonstrate UAG SP1 DirectAccess in a Multi-Site Configuration soon after the release of UAG SP1, which should help speed you understanding of the overall solution. For a list of current UAG Test Lab Guides, be sure to check out UAG DirectAccess Test Lab Guide Portal page at http://social.technet.microsoft.com/wiki/contents/articles/uag-directaccess-test-lab-guide-portal-page.aspx
Authors:Ben Bernstein, Senior Program Manager, DirectAccessTom Shinder (tomsh@microsoft.com), Knowledge Engineer/Principal Technical Writer, Anywhere Access Group (AAG)
We are publishing SharePoint 2010 with UAG. This works fine except for 'explorer view'. Explorer View works great inside the network. It works fine either with or without SSL. SharePoint is accessed by the same fqdn both internally and externally.
Additionally, Office 2007 can use webdav fine through UAG (uses the 'bypass trunk authentication..') option. Setting up a webdav connection manually externally through UAG works fine.
Anyone have any ideas why Explorer View might not work? The only difference I can see is that it probably does not use the office clients bypass trunk authentication option. I don't see any block notices in the web monitor.
Can anyone confirm that Explorer View with Sharepoint 2010 works through UAG?
Forefront UAG 2010 makes extensive use of group policy objects for client provisioning, corporate servers, and the gateway itself. Customers familiar with this capability asked for more. More flexibility defining objects, and more control over their naming, placement and creation. Here are a couple of enhancements we’ve made in SP1 to meet these requests.
Organizational Units
Prior to SP1, you could define security groups that contained applicable end-users for DirectAccess. With the service pack are able to choose organizational units (OUs) instead.
Support Multiple Domains
In some scenarios the end-user’s machine is joined to a different domain than the one that user is authenticating against. For example, Bob is authenticating against CORPUSER domain while his machine belongs to domain CONTOSO. This scenario is now possible with UAG SP1, because you can define separate domains for clients’ computers and authentication.
Control Policy Names & Creation
Some customers use their own naming conventions for objects, so with SP1 you can not only change the name of the GPO, but also pre-create it, and let UAG fill in the designated containers. This can be useful when edge and GPO management responsibilities are handled by different administrators.
We’ve recently updated our Forefront UAG TechCenter with content for Forefront UAG SP1 RC. Here’s what we’ve added:
As we move towards RTM we’ll be making the deployment and solution guides available in downloadable format.
As always, we’d love to get your feedback on our SP1 content, and to receive for requests and suggestions for specific documents. Documentation feedback can be posted here, or sent to our team at uagdocs@microsoft.com.
Cheers!
Rayne Wiselman
Forefront iX team
Today I figured I would address an issue that has been encountered by some UAG administrators – the “haunted” UAG server.
Why haunted, you ask? I’ll tell you why. Because settings you configure in CustomUpdate files or registry keys, rather than in the UAG Management console, mysteriously disappear after you have applied them (and sometimes even after you’ve seen them affect your UAG configuration as expected). An additional symptom is the opposite behavior – a file or registry key that you deleted, suddenly reappears uninvited.
Before you run and call the nearest exorcist, let me try and explain why this happens, and you will see that it actually has nothing to do with tales from the darkside.
As you are probably aware, UAG stores its entire configuration in the TMG storage, an Active Directory Lightweight Directory Services (AD LDS) instance. The storage includes all the configuration settings from the UAG Management console, as well as configuration files, both default and CustomUpdate, and UAG-related registry keys. Each activation performed from the UAG Management console collects all of these settings into a “package”, which is then pushed into the TMG storage. These configuration settings are then extracted from the TMG storage, unpacked, and applied to either a standalone UAG server, or to UAG servers in a UAG array.
However, not all configuration changes in UAG seem to require activation. Some configuration settings are read by UAG components at runtime. For example, a custom .INC file that you just placed in the correct CustomUpdate folder will immediately be used by the relevant UAG .ASP script. The opposite is also true – if you delete or rename a CustomUpdate file from the relevant directory that too immediately changes the behavior of your UAG server. This behavior might lead you to believe that you do not need to activate the UAG configuration.
Another example is changing UAG functionality by means of a registry key. Let’s assume you read here that in order to configure UAG to perform Kerberos constrained delegation to a backend web server using UPN, you need to modify the KCDUseUPN key. Since making this registry modification will not take effect without you taking some further action, you would probably restart “the UAG services”. If you have some experience with UAG, you might correctly decide to restart the Microsoft Forefront UAG User Manager service, since this is the service responsible for both front-end and back-end authentication. So you do this, and a few dependent services are restarted too. All is well, and UAG seems to behave as expected.
So when does the mystery begin? Usually, it begins after your UAG server is rebooted. We hear UAG admins claiming “It used to work! I didn’t change anything. I only rebooted the server!” And they are, of course, right. So what’s to blame for removing files that were there before the reboot, for placing deleted files back on the hard drive, or for reverting changes to registry keys?
The culprit is the Microsoft Forefront UAG Configuration Manager service. Every time this service starts (and it starts after a reboot), it fetches the last stored configuration from the TMG storage, and applies it to the UAG server on which the service is running. This ensures that a server that has been powered off starts with an updated configuration that matches the configuration currently saved in TMG storage. This is particularly important in an array, where array changes controlled by the array manager might have occurred while an array member is switched off.
This, therefore, is the reason that you need to remember to activate the configuration after you make any changes to UAG files and registry settings, in order for these changes to be stored in the TMG storage. You do not necessarily need to activate immediately. You can first test the changes. But once you decide to keep the settings, remember to activate, or else the next time you reboot your server (and by that time may have forgotten you ever made changes), your UAG server will revert to a configuration that does not contain the changes, and you’ll be left wondering who or what possessed it.
Author:
Ran Dolev, Senior CSS Engineer, Microsoft Forefront UAG
Reviewer:
Rayne Wiselman, Senior Writer
Always managed
One of the reasons I really like DirectAccess is that client computers can always be managed, regardless of location. This means that whenever a user turns the laptop on and connects to the Internet, management agents on the client laptop can synchronize with corporate management servers, report on their health status, and download updates.
The user doesn’t have to be in the office in order for the laptop to have the latest patches, the most updated software, and the current policy settings. Desktop managers always know what the state of the laptop is, and don’t have to wait until the user explicitly connects to the corporate network with her credentials.
In addition to these things happening in the background, the user can also perform self-help actions remotely, such as changing an expired password.
Manage Only
For some customers, having the clients always managed is the trigger for installing DirectAccess, and they aren’t initially interested in the availability of a seamless connection to internal application servers on the internal network. In fact, they want a way of blocking users from connecting to the application servers over the second (intranet) tunnel, allowing only the first (infrastructure) tunnel to connect.
In SP1 we’ve created a simple step in the DirectAccess wizard which enables the admin to select “manage only”. Furthermore, the admin can select to only accept connections from agents or services running under the machine account, while dropping connections from the logged on user. This is configured by selecting a single checkbox.
Note that some functionality is affected by not having the second tunnel. For example, while NAP monitoring will work, NAP enforcement will not. Force tunneling of client Internet traffic also will not work in the “manage only” mode, because there is no second tunnel to send the user traffic through. Similarly, user authentication with username/password; one time password (OTP), and smartcard authentication is not supported. This is because user authentication takes place when creating the second tunnel, which is not created in this mode.
Auto-detecting management servers
Managing the list of servers on the infrastructure tunnel becomes all the more important in the “always managed” scenario. In SP1 we added auto-detection of NAP Health Registration Authority (HRA) servers and of System Server Configuration Manager (SCCM) servers, so that you can refresh the list and any change in the servers is detected.
We have already received some positive feedback from our early adopter customers around these features, and we hope you find them useful as well.
Noam Ben-Yochanan
After deploying your UAG DirectAccess environment, you need to ascertain that it’s up and running, and is providing the remote access as planned. There are a few things you’ll want to check:
Fortunately, the new DirectAccess logging and monitoring functionality provides answers to these questions. Starting from SP1, UAG supports out-of-the-box logging and monitoring functionality for DirectAccess user activity, based on the TMG SQL logging infrastructure.
What’s new in UAG DirectAccess logging & monitoring?
In SP1, we augmented the existing UAG monitoring tool (Web Monitor), with real-time DirectAccess monitoring information. Two new screens were added: DirectAccess Monitor – Current Status, and DirectAccess Monitor – Active Sessions.
DirectAccess Current Status screen displays a “SCOM-like” health indication of UAG DirectAccess servers and relevant DirectAccess sub-components. On this screen, you can see whether the UAG DirectAccess servers in your deployment are configured for DirectAccess, and that all relevant sub-components (DNS64, IP-HTTPS, etc.) are up and running. Everything is presented at the array level so that the admin can access all the information from the console of any array node.
Figure 1: DirectAccess server health status screen
DirectAccess Active sessions screen presents the list of DirectAccess sessions currently connected via all UAG DirectAccess array nodes. You can see a list of currently logged on users, access level (infrastructure or intranet), NAP health status, machine account, user account, and other fields.
Figure 2: DirectAccess active sessions
Web Monitor is useful for monitoring the current state of your DirectAccess deployment. In order to search across DirectAccess sessions that occurred in the past, you can use either the user monitoring PowerShell snap-in or the TMG SQL log viewer. The user monitoring PowerShell snap-in now presents the user and server monitoring information at the array-level, without enabling the Security Auditing event logs.
Figure 3: TMG log viewer displaying DirectAccess events
How does it work?
At the beginning of a DirectAccess session, the DirectAccess client and UAG DirectAccess server establish security associations (SAs). This is a security agreement with which both computers agree on how to exchange and protect information transferred during the DirectAccess session. You can see the configured and currently opened SAs on the “Windows Firewall with Advanced Security” screen.
The UAG DirectAccess logging mechanism monitors the currently opened SAs, and uses the SA info to log and monitor DirectAccess user activity. Changes in session state are written to the SQL log for persistency. Errors encountered during the session (e.g., “a smartcard wasn’t provided”) are also monitored and written to the SQL log. In this way the logging mechanism collects and stores information about DirectAccess sessions that can be subsequently viewed on the Web Monitor DirectAccess Active Sessions screen, or via the PowerShell snap-in or TMG log viewer.
What else?
What happened to DirectAccess user monitoring mechanism supported in earlier UAG releases? What is the difference between the new mechanism and the old one?
The DirectAccess user monitoring mechanism supported in Forefront UAG 2010 RTM (TechNet article here) was based on IPSec logging messages printed to the Security event log. The new SP1 implementation doesn’t require IPSec logging to be enabled, but rather collects the required SA information programmatically. The PowerShell snap-in was re-designed to work over the new infrastructure for both current and historic sessions. The snap-in was also augmented to include server health info.
How do I enable the new DirectAccess logging and monitoring feature?
DirectAccess logging and monitoring functionality is on by default. It collects DirectAccess events from the moment DirectAccess is configured and running on a UAG SP1 machine. Note that SQL logging is mandatory for DirectAccess monitoring functionality, so make sure it’s not disabled on your system.
Where can I find more info on this feature?
See http://technet.microsoft.com/en-us/library/gg313780.aspx for more info on UAG DirectAccess logging and monitoring, including information on the different PowerShell snap-in parameters.
We appreciate your feedback: please post comments for any questions you have, or for issues you might encounter with the new DirectAccess monitoring mechanism.
A nice feature of the endpoint policy mechanism in UAG is the ability to create a Corporate-Machine policy, and then use it to grant more granular access to machines which meet the policy. Some customer have found this to be confusing, thinking that you can simply specify that as an expression, and UAG will be able to detect corporate machines on its own.
The truth of the matter is that there’s no generic corporate-machine definition, and it’s up to you to help UAG detect one. By default the built-in expression for Corporate Machine is simply “false”, which means that if you attempt to use that within a policy, the policy will evaluate to “false” as well. To make use of this expression, you need to edit it, and define a condition that meets your needs. For example, you might decide that a computer that is a member of a specific domain would be recognized as a corporate machine. You may want a specific registry setting or the existence of a certain file on the computer’s hard drive to be the condition, or any combination of the above and other policy expressions and elements. Here’s how to do this.
First, you need to decide what conditions are to be met, for a computer to be recognized as a corporate machine. If, for example, you want a computer to be a member of a certain domain, then you would need to replace the default content of the Corporate Machine expression with something along the lines of:
NetBIOS Domain = “contoso”
To do so, follow these steps:
1. In the UAG configuration console, click on the trunk you want to apply the policy to.
2. Click on "advanced Trunk Configuration"
3. Switch to the "Endpoint Access Policies" page and click "Manage Policies" on the bottom-left.
4. Double-Click on one of the policies – doesn’t matter which.
5. Click on "Manage Windows Policies"
6. Expand “Windows Expressions”
7. Double-click on “Corporate Machine(Windows)”
8. The bottom-right of the screen contains the policy, and you can see that the default is “false”.
9. Either Type in the policy expression that you want to use, or use the components or expression tree on the lft to build the policy to your liking. Here’s an example of a policy:
After clicking OK through the screens, the new expression will be populated with a “false” or “true”, based on how the client computer meets those conditions. You can test this by logging in to the UAG portal with a client computer, and observing the user’s parameters table. You can see the table using the Web Monitor on your UAG server, by clicking on an active sessions, and switching to “Parameters”:
If the corporate machine evaluation did not go as planned, you can observe other parameters that were detected, to try and find out which one you missed. For example, you may have mistyped the domain name.
Once you verified that the parameter is populated correctly, you can go ahead and integrate it into a policy. Simply edit the policy, and specify the expression Corporate_Machine as a condition. Be sure to use the correct case , because policies are case-sensitive, and keep the Boolean logic straight – only if the entire policy evaluates to “true” will the client be allowed access to the resource assigned the policy. You may have to carefully employ parenthesis as part of your syntax.
We received some great feedback from customers about deploying DirectAccess in their organizations. One notable quote was “it works like magic!” Our customers also told us how we can make the product better by adding features and making existing features easier to manage.
After discussions and prioritization we are now proud to present the DirectAccess enhancements in service pack 1:
We’ve been hearing this request a lot from customers and potential customers – so we’ve gone ahead and did it.
Server side
On the server side UAG now provides a choice between smartcards and OTP. We did this by adding support for OTP in the UAG UI as part of the UAG DA Wizard’s optional settings. UAG comes out-of-the-box with an RSA SecureID agent so you can be up and running in no time if you have SecurID tokens.
Figure 1: UAG DA UI with OTP
You can use OTP solutions from other 3rd party vendors as long as they are RADIUS based (OATH compliant).
Client side
On the client side the users are given the same experience and look & feel as the smartcard authentication “pop-up”. Our implementation is not based on credential provider so that requiring OTP for authentication in the UAG DA server UI does not enable the user to login to Windows on the client using an OTP token.
Figure 2: OTP authentication balloon
Figure 3: OTP authentication popup
Deployment
When deploying OTP you need to set up a dedicated Certificate Authority server (CA) and cannot use an existing CA. UAG makes life easier by generating a script which you can apply on the dedicated CA for use with OTP instead of performing CA configuration manually. Another bonus is that you do not need to make changes to the existing RSA ACE servers.
NAP setup
NAP integration in UAG 2010 seemed easy enough. All you had to do was select a checkbox and NAP was enforced. In reality, there is more to it than that. Someone needs to install and configure an NPS, HRAs and CAs. This is not a simple task. In SP1 we decided to ask a few more questions, but have UAG do the bulk of the work for you. We did this by installing and configuring NAP roles on the UAG server, and by adding the NAP settings to the client GPO. You still need to set up a dedicated CA server and health template, and point to them in the UAG UI.
In the wizard you can choose between enforcing and monitoring health. If you select to enforce, client machines cannot create the second (intranet) tunnel until they can obtain a health certificate. Monitor only, on the other hand, will make sure that client health is checked and reported, but unhealthy clients will not be blocked.
NAP client health troubleshooting
Another non-trivial task that administrators face when using NAP is trying to understand why a particular client machine is considered unhealthy. Although the data exists, it is buried in the Windows EventLog and the actual events are not very clear. We’ve decided to add NAP troubleshooting to the UAG DA UI, specifically to the Web Monitor. You can query the last event for a specific machine, the last five events, or all of the events in a range of dates.
Existing NAP infrastructure
If you already have a NAP infrastructure or just want to have separate NAP and UAG servers, you can select not to use the internal NAP server, no questions asked. You then have to:
Integrated Multi Domain Support
Many of our customers have more than one domain. We have added support for managing DirectAccess in a multi domain deployment.
Using the UAG DirectAccess UI you can specify which domains the DirectAccess GPOs will be applied to. You can also specify which GPO the UAG will use, allowing for better role separation between the DirectAccess admin and the UAG admin. In addition, the GPOs can now be linked to OUs, not only to whole domains.
Figure 4: Selecting client computer domains
Figure 5: Selecting OUs/Security groups
Figure 6: Selecting Preconfigured/New GPO
Domain controller auto-discovery has also been extended to discover DCs across all selected domains.
Some customers wanted to deploy DirectAccess for the purpose of managing remote client machines, but do not wish to have users connect to application servers on the intranet. Using a new setting located on the first page of the client wizard, the admin can now choose to enable only the first (infrastructure) tunnel, without enabling the second (intranet) tunnel.
Some customers want to enable client machines to connect via DirectAccess, but while connected they do not want the clients to connect to anywhere else (i.e. creating a split tunnel). The UAG DirectAccess UI enables you to specify force tunneling in one of two flavors:
If you are thinking of utilizing this feature, please read Tom Shinder’s blog post (http://blogs.technet.com/b/tomshinder/archive/2010/03/30/more-on-directaccess-split-tunneling-and-force-tunneling.aspx) in full prior to deployment.
Since UAG has a built in monitoring tool called Web Monitor, we’ve integrated DirectAccess information into it, providing a unified monitoring experience. The information is stored in an internal SQL database. You can display a list of currently logged on users, access level (infrastructure/intranet), NAP health status, machine account, user account and other fields.
At the array level, there is a “SCOM-like” health indication for each UAG array member. Everything is presented at the array level so that the admin can access all the information from the console of any node of the array.
The user monitoring PowerShell snap-in can now present the user and server monitoring information at the array-level, without enabling the Security auditing event logs.
DirectAccess Connectivity Assistant (DCA) is an application that runs on the DirectAccess clients. DCA enables the user to easily check the status of the DirectAccess connection to the corporate network and resources. It also provides troubleshooting features that will help in solving connectivity issues.
In SP1 you can centrally configure the DCA using the UAG DirectAccess UI. Configuration is propagated to clients via GPO. The DCA binary distribution is not done by UAG – you need to do it manually or automate it via GPOs, SCCM or other means.
We’ve added 7 new diagnostics to DCA, E.g. “IPv6 is disabled on the client” and now provide an HTML based troubleshooting summary.
Figure 7: HTML Summary with Hyperlinks
We are excited about this new release and we encourage you to share with us any feedback you have.
Noam
The following is a guest-post by Alexandre Giraud, a highly valued MVP I’ve worked with a lot. Thanks a lot, Alexandre, for sharing your work with me and allowing me to share it with our customers!
I recently had a customer with Exchange 2003 Front-End, who needed to publish Exchange Web Services (EWS). Of course, I suggested the best solution…Microsoft Forefront UAG!How surprised was I when I discovered that this doesn’t work natively and needs a couple of customizations to work fully.
The first issue you might experience with publishing Exchange 2003 Outlook Web Access with UAG is getting an access-denied error. The reason for this is that the default path in the application template is incorrect, and needs a little tweak.
As you can see, the last path is: |/Microsoft-Server-ActiveSync|/rpc/rpcproxy.dll\?(?!localhost).*
The workaround: Replace the single path noted above with two separate paths:
- /Microsoft-Server-ActiveSync/
- /rpc/rpcproxy.dll\?(?!localhost).*
That’s not all…if your users use ActiveSync with iPhones, you also have to change “/Microsoft-Server-ActiveSync/” to “/Microsoft-Server-ActiveSync.*”. This is required because an iPhone appends information to the URL. We can easily see this in the UAG’s web monitor:
A request on trunk ***; Secure=1 failed because of an unknown application. The URL is /Microsoft-Server-ActiveSync?User=***&DeviceId=***&DeviceType=iPhone&Cmd=FolderSync. The source IP address is a.b.c.d.
Apparently, Apple simply forgot to add a slash (/) in its ActiveSync request
So, the path should be :
OWA is not accessible, access is denied!
After publishing an exchange portal trunk, users get an access denied error when trying to access Outlook Web Access. The reason for this error is that the OWA form provided by UAG 2010 is not compatible with Exchange 2003. The native OWA form is like the one in Exchange 2010.
Workaround: You have to uncheck the “Owa look and feel” option in the advanced trunk configuration to avoid the use of UAG’s OWA form’s and use the default UAG forms instead.
Outlook Anywhere can’t synchronize the mailbox!
You will not to be able to configure Outlook Anywhere, and the mailbox will not be resolvable. When this happens, you can see that RPC_IN_DATA and RPC_OUT_DATA methods are blocked (in the web monitor):
A request from source IP address a.b.c.d on trunk xxx; Secure=1 for application xxx of type ExchangePub2003SP1 failed. The URL /rpc/rpcproxy.dll?exchange.fqdn.local:6001 contains an illegal path. The rule applied is Default rule. The method is RPC_IN_DATA.
A request from source IP address a.b.c.d on trunk xxx; Secure=1 for application xxx of type ExchangePub2003SP1 failed. The URL /rpc/rpcproxy.dll? exchange.fqdn.local:6001 contains an illegal path. The rule applied is Default rule. The method is RPC_OUT_DATA.
To work around this, you have to perform the following actions:
First, you have to add the HTTP methods RPC_OUT_DATA and RPC_IN_DATA in the advanced configuration
Then, you have create a new access rule to allow UAG to accept the RPC_IN_DATA and RPC_OUT_DATA methods for the /rpc/rpcproxy\.dll.* URL:
And lastly … many mails in “Plain Text” are not viewable using OWA.
When reading some mail items, users will encounter an error “Internet Explorer cannot display the webpage”. This is specific to message that have been sent as “plain text”. If you refresh the browser several times, you may be able to see the message.
The error would look something like this:
If we record the session with a tool such as httpwatch, we can see that InitParams.aspx and InstallAndDetect.asp are used after a get request for blank.htm ….
Why? Because when an email is opened or previewed, the code uses an iframe with restricted security to show blank.htm. When this is done, the cookie is lost. The code that does this is:
<IFRAME security="restricted" id="idHtmlBody" src="/uniquesigxxx/uniquesig1/exchweb/6.5.7651.60/controls/blank.htm" frameborder="0" width="100%" height="100%"></IFRAME>
To work-around this problem, I use an AppWrap to remove the restricted security tag from the iframe. Below is the AppWrap that does this. The left column is not encoded in Base 64, so you can see the changes it makes clearly. When putting this on your own server, you have to use the right column, with the data encoded.
Not encoded in Base 64
Encoded
<APP_WRAP ver="3.0" id="RemoteAccess_HTTPS.xml">
<MANIPULATION>
<MANIPULATION_PER_APPLICATION>
<APPLICATION_TYPE>ExchangePub2003SP1</APPLICATION_TYPE>
<DATA_CHANGE>
<URL case_sensitive="false">/exchange/.*\.EML(\?cmd=open|\?cmd=preview)</URL>
<SAR>
<SEARCH encoding="base64"><IFRAME security=”restricted” </SEARCH>
<REPLACE encoding="base64"><IFRAME </REPLACE>
</SAR>
</DATA_CHANGE>
</MANIPULATION_PER_APPLICATION>
</MANIPULATION>
</APP_WRAP>
<SEARCH encoding="base64">PElGUkFNRSBzZWN1cml0eT0icmVzdHJpY3RlZCIg</SEARCH>
<REPLACE encoding="base64">PElGUkFNRSA=</REPLACE>
At this point, you can now use ActiveSync, Outlook Anywhere and Outlook Web Access for Exchange 2003 Services through UAG ! All these issue will be fixed in the next Service Pack for UAG, planned for Q4 2010.
Enjoy !
The French version of this article on Alexandre Giraud’s blog : http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=165
We are happy to announce Forefront UAG 2010 Service Pack 1 (SP1) and the availability of its final release candidate. This service pack includes many enhancements to the product, designed to ease DirectAccess deployments and to enable secure collaboration scenarios using Active Directory Federation Services (AD FS) 2.0.
Among the new features for DirectAccess:
The new AD FS 2.0 secure collaboration scenarios in SP1 enable the following:
SP1 is not only about features – it’s also about the user experience and the quality of the product. We addressed many customer requests and improved the stability and robustness of the system – not only for the new functionality but also for the existing scenarios. We also invested in completing the localization of the end-user experience. We are confident that you and your users will notice the improvement.
You can start experimenting with UAG 2010 SP1 RC right now by downloading the Release Candidate (RC). It includes all of the new features and is available both as an upgrade from a previous UAG 2010 releases, or as a clean install. You can find updated documentation that reflects all SP1 changes in our TechNet Library. We recommend you begin with the new installation guide.
We are eager to get your feedback and to assist with your deployments via our TechNet forum. Our team as well as our MVPs and partners monitor the forum. Please post any issues you might encounter. Compliments are also welcome ;-)
Over the next few weeks we will publish a series of blog posts to introduce SP1. Stay tuned!
I’m very happy to announce that on September 21st we released Forefront UAG 2010 – Update 2.
In this update we deliver enhancements to existing UAG functionality, and solutions for major deployment blockers for a broad set of customers, addressing 18 customer requests.
Some of the major functionality added in this update:
· Client Components Enhancement—The Forefront UAG SSL Application Tunneling component is now supported on Windows 7 64-bit operating systems for 32-bit applications.
· Virtual Desktop Infrastructure (VDI)—Forefront UAG fully supports publishing remote desktops using VDI.
· Citrix publishing support—Forefront UAG fully supports Citrix Presentation Server 4.5 and its replacement Citrix XenApp 5.0.
· Citrix client computer support—Forefront UAG supports client computers with 64-bit operating systems accessing Citrix XenApp applications.
· SSTP user and group access control—Forefront UAG now provides a finer authorization mechanism allowing administrators to authorize individual users or groups for SSTP access.
· SSL handshake—Forefront UAG now provides better handling of the SSL handshake including the case when the application server requires client certificate credentials for the negotiation.
· MAC addresses support—Forefront UAG Network Connector supports a wider range of network adapters with a larger valid MAC address range.
We know that there are a significant number of customers and partners who are eager to get Update 2. Download it at Forefront Unified Access Gateway (UAG) Update 2.
Apologies for posting this notification late, and we will ensure more timely notification in the future.
Eyal Peri
Senior Program Manager
Many customers have been eagerly waiting for this update…even if they didn’t even know it was coming. Why? Because it finally introduces 64 bit support for all of the SSL-VPN components of UAG for Windows 7. This is a great milestone!
Additionally, you can now publish VDI with UAG, which has also been requested by many users. Additional things that have been addressed by this update include SSTP user and group access control, and a limitation of the SSL-VPN tunneling (Network Connector) to work with certain MAC address.
Soon, the release notes will be available, providing more detail about the new features and fixes. Until then, you can download it here:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=9dcccebc-accb-4229-901a-792cc66791de
If you configured your server for automatic updates, you should be getting a notification about this any second now!
My dear colleagues Yuri and Thomas, who have written extensively everywhere about our various security products have just informed me that they are also releasing a book! It is going to be available pretty soon, and I’m sure will be fantastic. When conquering new technology, it is always a good idea to have more than one resource and I’m sure their perspective can shed some more light on the product and help you, the customers, make the best of it. For more info
Yuri Diogenes and Tom Shinder will soon release their book Deploying Microsoft Forefront Unified Access Gateway*. The book focuses on deployment scenarios and best practices for implementation, and can be preordered here.
Nathan Bigman, Content Publishing Manager
* They are also releasing books on Forefront TMG and Forefront Protection for Exchange Server
Summary:
I had a customer ask how the helpdesk / support staff can connect to DirectAccess (Windows7) connected machines. He asked because if they enabled “Remote Desktop Sharing” in the Firewall in the Public or Private Profile, it enabled it for all hosts – not just the corporate host via DirectAccess. Another way of looking at this is: “Where is the DirectAccess Firewall Profile?”
Windows Firewall and DirectAccess:
DirectAccess requires the Microsoft Windows Firewall to work. This is because the IPsec Polices are defined in the Windows Firewall. If you turn off the firewall, neither IPsec nor DirectAccess will work. Technically, you only need the Firewall Profile for the location you are connecting from. This means you do not need the Domain Profile to be enabled, as this is only active when you are connected to the domain and then you do not need DirectAccess. For some of my deployments, corporate customers do not want the Firewall on when inside the corporate network (Domain Profile) but they do want it on when outside, either in public locations (Public Profile) or at home office locations (usually Private Profile).
Because DirectAccess does not show up as a physical or virtual network card, there is no Profile associated with DirectAccess. This means you can’t associate a specific rule with a “DirectAccess Profile” – it does not exist. To work around this, we can use the use Public and Private Profiles and set the scope of the rule to match incoming DirectAccess communications, which will be IPv6. Because we use IPv6 in Direct Access, any corporate client that wants to communicate to the DirectAccess clients must have an IPv6 address. We can set up either a real IPv6 addressing scheme or set up ISATAP, which does not require IPv6 aware routers, switches or hubs. For more information about ISATAP, see: http://www.microsoft.com/downloads/details.aspx?FamilyId=B8F50E07-17BF-4B5C-A1F9-5A09E2AF698B&displaylang=en.
From a security perspective the process below shows how to enable only RDP connections from the ISATAP Network. With the IPsec policy that is already in place on a client computer when you configure DirectAccess, all traffic arriving from a computer on your intranet will travel inside of an IPsec-protected tunnel. The IPsec rule is configured to “require inbound and outbound” authentication, and this requires an SSL certificate. With this configuration there is no need to create further IPsec rules to enforce protection of this traffic.
Security Recommendation:
From a security perspective, it is my strong recommendation that you always enable the firewall on both servers and clients. This functionality gives you an added layer of protection and can help mitigate risk of network based security concerns. This one factor alone can make the difference on a “high impact” patch / update.
The Setup:
For this particular setup, we need to set a client firewall setting. To really scale, we will use Group Policy Objects (GPO). Note we do not want to use the existing DirectAccess Client GPO, as this GPO is changed and could be deleted when we make changes to the Unified Access Gateway Server or the DirectAccess Server.
Step 1. From any machine with the Group Policy Management console, create a GPO, in my case it was named “DirectAccess Clients – RDS Override”.
Step 2. Edit this GPO so we can set the Firewall Settings.
Step 3. In the Windows Firewall with Advanced Settings create a new rule.
Step 4. Set the rule type to Port. Note we do not want to override the existing “Remote Desktop” predefined rule.
Step 5. Set the Port value to TCP and port 3389.
Step 6. Set the action to allow. We do not require security, as DirectAccess is already a secure tunnel.
Step 7. Set the Profile to Public and Private. Domain is not required for this.
Step 8. Name the Rule, in my case I named it “Remote Desktop Services via DirectAccess”
Step 9. Next, we need to set the scope, so we will edit the properties of the rule.
Step 10. Go to the scope tab. Here we will determine and add a value.
Step 11. Next we need to determine our ISATAP scheme. On any corporate connected ISATAP enabled host, type IPCONFIG.EXE. The screen below shows my ISATAP address as: 2002:c800:2:8000:0:5efe:10.214.1.38. The ISATAP Router creates this network, in my case the router is my Unified Access Gateway (UAG) server. Because I want more than one host to communicate to DirectAccess machines, I will take my entire ISATAP network and enable it. Note: If you want just a subnet of machines, then you can adjust the mask from /96 to a finer scope, like /120 (which is a 94 bit mask + a 24 bit mask). To enable the entire network, I calculate the network, so in my case I use: 2002:c800:2:8000:0:5efe:0.0.0.0/96, which is all ISATAP host. If you are using load balancers, you will need to include that address (or range or addresses) as well.
Step 12. Take the network calculated in the step above and add it to the “Remote IP Address” list.
Step 13. Next click “apply” to apply the settings.
Step 14. Next based on Teredo needs, we need to select “Advanced” and set the “Edge traversal” to “Allow Edge Traversal”. Then click OK to complete the settings.
Step 15. Close the GPO to save it and set the permissions on the GPO to only apply to the DirectAccess machines. In my case, I used the same domain group that was used in the first setup of the DirectAccess wizard.
Step 16. Last, force the GPO to the client computers, either by rebooting the machine or running “GPUPDATE.EXE /FORCE” from an administrator’s command prompt.
Testing it out:
Once everything is set up, you can test it out. From any corporate connected computer, first ping the name of the DirectAccess connected computer. You should see it respond with an IPv6 address. If this does not work, verify DNS setup, ISATAP setup or that the DirectAccess connected computer is on and functioning.
Next attempt a “Remote Desktop Connection” from the corporate connected computer to the name of the DirectAccess connected computer. Assuming that Remote Desktop Services is enabled on the DirectAccess connected computer, it should work and perhaps prompt you for your credentials.
Additional Items:
What about pinging a Direct Access connected machine from a corporate machine? Follow the same rules above, but at Step 4, select “Custom” and use the Protocols “ICMPv6”. The following settings will be required:
Enabled: allow
All programs
Protocol: ICMPv6 ; ICMP type: Echo request
Remote IP Addresses: <ISATAP subnet>
Profiles: Private, Public
Allow Edge traversal
What about “Remote Assistance” and not “Remote Desktop Services”? Include the following settings:
First Entry:
Name: Remote Assistance (DCOM-In) – DirectAccess
Program: %SystemRoot%\system32\svchost.exe
TCP local port: 135
Allow Edge Traversal
Second Entry:
Name: Remote Assistance (RA Server TCP-In) – DirectAccess
Program: %SystemRoot%\system32\raserver.exe
TCP all ports
Author(s):
Kevin Saye, Security Technical Specialist – Microsoft
Eddie Huibers, Infrastructure Consultant - Microsoft
Contributor:
Pat Telford, Principal Consultant – Microsoft
I’ve gotten some great response about the first 3 chapters of the UAG book, and many customers are surprised to discover that the author is me – the same person who have been helping them resolve their cases over the past few years. One of the reasons for the confusion is that Microsoft’s CSS customers know me as “Ben Ari” (which is also the name on this blog), but the book is published under my full name “Erez Ben-Ari”. If you’ve been wondering about that, then you might be interested to know that I’m originally from Israel (where UAG was developed) and so Erez is my first name (means Cedar in Hebrew) and Ben-Ari is my last name (means Son of a Lion in Hebrew). When I moved to the United States, I chose to drop my first name from most places, as it’s hard for American’s to pronounce.
Anyway, enough about me – the good news is that as of today (Sep 13th, which is also my birthday!), chapters 4-7 of the UAG book are available on the RAW site:
These are the most useful chapters, as they talk about actually publishing applications, as well as authentication. Another good news is that a few days ago, I finished writing the final chapter and the book is moving on into the editing/rewriting phase. We are on schedule for a final release early next year!
One of the common errors seen by many UAG users, usually following a new installation, is the error message “The configuration cannot be loaded from Forefront TMG storage. An unrecoverable error has occurred. The application will close”.
This is particularly frustrating on a freshly installed server, when there’s seemingly nothing to do.
The reason for this error is, at it indicates, that the UAG configuration console is unable to communicate with TMG, which is the firewall that protects it. There is more than one reason for this, but the most common one is that TMG itself cannot communicate with the computer’s domain controller. This might happen if the networking configuration of the computer is such that once TMG comes up, it blocks communication to the network in which the DC is. There’s no single solution for this, because that depends on the network configuration. For example, if the UAG server is on the DMZ, and the DC is inside the corporate network, it could be the cause.
When UAG is installed on a computer, it automatically installs TMG, and it then configures TMG with the entire IPv4 address range, except 127.x.x.x, as the “internal” network:
This should allow it full communication to the internal network until you get a chance to run the UAG getting Started Wizard, which reconfigures that based on your selection of which Network Card is the “real” internal network. However, if the networking is configured incorrectly, it could still cause a problem. For example, if the default gateway or subnet masks are misconfigured, it could disrupt configurations. We’ve also seen cases where the administrator has been successful in launching the UAG management console, and ran the getting-started wizard with the wrong settings, causing the “internal” network to be configured incorrectly, thus blocking access to some or all resources on the internal network.
Another scenario where a similar issue can occur is if TMG itself is off – if its services are not operational for some reason. One common reason for this is an organizational group policy that prevents them from running. For example, a group policy may block the RRAS service, on which TMG relies. In such a case, the TMG services won’t come up, and launching UAG will give out the same error. The solution is to make sure the UAG server is excluded from such group policies. Ideally, it should be excluded from ANY policies (even if to simply save you the time-waste of trial-and-error). One thing that’s important to keep in mind is that excluding the computer from group policy does not necessarily “clean” it up. Policies are applied as registry settings, and just disabling them after they have been applied to a computer may not reverse the settings.
Another situation where this could happen is if there’s some hardware problem that prevents TMG from working properly. For example, certain virtualization technologies do not emulate Network Cards properly, causing TMG to fail. TMG should work fine on all hardware platforms, but if you are running it as a virtual machine, you can check if the VM software is compatible. The 1st step would be to check if all TMG services have started successfully. This is done using the Event Viewer – look for TMG services that are set to “automatic” but are stopped:
If this is the situation, you can check your version of the VM software using this URL:
http://www.windowsservercatalog.com/svvp.aspx?svvppage=svvpwizard.htm
If you suspect your server’s hardware may be unusual, you can check the Windows Server Catalog for compatibility:
http://www.windowsservercatalog.com/
If the TMG services are all up then inspect the computer’s routing table, IP configuration and the IP range that’s set as the “internal” network (see screenshot above). Think of the configuration, and try to trace (in your mind or with a network map) the network route from your UAG to its DC. A common for administrators to configure both NICs with the same network Config (IPs on the same network segment), disable one of the NICs, set a default-gateway on the internal NIC instead of the external, or on both NICs. Keep in mind that UAG is a router…and it’s network configuration has to make sense, and allow it to route traffic from the users on the external side, to servers on the internal side, and back. UAG can often “survive” and even work with a wrong configuration, but even so, it’s a good idea to only use the server in a supported configuration.
In case you’ve miss it, MS pushed an antivirus signature to detect malicious PDFs attempting to exploit CVE-2010-2883(0-day in Adobe PDF Reader/Acrobat) on 08.10.2010, so you can attempt to block potentially such malicious files at the gateway level with TMG.The signature is detailed on the MPC Encyclopedia.
Additionally, you can have TMG to block HTTP responses containing PDF files(assuming they are not zipped or so), and you can combine this with the URL filtering if you want to be able to whitelist/blacklist some destinations.
Two terms that often confuse UAG and IAG customers are Privileged Session and Privileged Endpoint. What those actually mean, and how do they differ? And what’s the difference between a default session and a privileged one? Well, here I am, with answers.
To put it simply, a privileged session is a session that was initiated by an endpoint that has met the Privileged Endpoint policy, and therefore receives special treatment. This is useful in a situation where an organization considers users to be at a certain level of risk (or to BE a certain level of threat), but under certain circumstances to be at a lower level of risk/threat. For example, an organization’s users may be using public computers, such as internet kiosks, but some of them are using laptops provided by the workplace. A public computer can be very risky for an organization, if it is used for remote access. It has a high chance of containing viruses or spyware (compared to a private computer), and can be accessed by virtually anyone – the next user, the kiosk owner etc. An organization can reduce its security exposure by detecting that their users are using a public computer, and treating it with higher prejudice than a private computer (or, from a different perspective, treat a private computer as a lesser security exposure, and giving it a break).
The way this works is by the administrator assigning a certain policy for the trunk (on the Endpoint Access Settings tab), and then configuring different settings for endpoints that meet it (on the Session tab):
The tricky parts are deciding which endpoints would be considered “privileged”, and how to detect them reliably. You might decide, for example, that only company computers should be treated as privileged, and everything else as regular endpoints. Another popular differentiator is the security software in use – computers that have a certain Anti Virus product would be considered OK, and all the rest as higher-risk. As you know, the endpoint policy mechanism in IAG and UAG is extremely clever and flexible, and you can check many things for this determination. You can even write a custom detection script to look for a registry key on the client computer, or a certain file.
One thing that concerns some administrator is how reliable are these checks. Would an attacker that is familiar with your organizations policy be able to fake it? Unfortunately, most of the things detected by the UAG/IAG client components are possible to fake, and so this indeed needs to be carefully considered. One thing that is virtually impossible to forge is a computer certificate, and so I strongly recommend employing that (“Use certified endpoints”), but I won’t get into that now. One important thing to keep in mind is that the default privileged endpoint policy that comes with UAG and IAG is just set to “false”, and does not check anything. This means that it cannot be used as-is, because no computer will ever be able to “meet” it and be considered a privileged endpoint.
Once you have defined what you consider to be the differentiators, configured your endpoint policy and selected it in the Endpoint Access Settings tab, it’s time to configure the specific settings for the privileged sessions in the Session tab. Most of these are pretty straight-forward. The inactive session timeout and the trigger logoff scheme are obvious things that make life easier. Setting the server not to delete cookies at log off can benefit users of applications that rely on cookies a lot. For example, an app that stores your last visited page in a cookie will save you some time by being able to go to that page automatically. The “not to cache” setting, if set to be unchecked, allows the user’s browser to cache the application’s files, making the application perform faster. The endpoint session cleanup component (known as the Attachment Wiper in IAG) cleans up files downloaded during the session, so having it disabled for privileged endpoints can make them perform faster when re-visiting the application later-on.
Unlike many software products, where most errors are presented by the application’s user interface, many of the issues you might encounter have little or no visual indication of what’s going on. In those cases, you might have no choice but to go under the hood, and ask UAG to perform a “trace”. A Trace sets the software to write a very detailed log of what it is doing. It logs functions, values and errors, which often helps you see what’s really going on. For example, if there’s a problem with a server’s certificate, UAG may not be able to create a secure communication channel and show a very generic error like “An unknown error occurred while processing the certificate”. In this type of situation, a trace would be essential for understanding what the problem is.
Keep in mind, though, that a trace is far from easy to read. In fact, the sheer volume of data in a trace can be overwhelming. A busy server may generate 600,000 of lines of trace data in a single minute of activity! Add to that the fact that it contains application-developer level data, and you can see how this can be scary. Often, Microsoft CSS support will ask you to generate such a trace, as the only means to investigate a problem, so knowing this could be useful. If you are feeling adventurous, you might even want to try reading a trace on your own.
For those of you who are veterans of IAG or EGAP, you probably remember some procedure involving editing some XML files or editing a registry key. With UAG, these days are over, as the server includes a friendly and visual tool that’s a lot easier to use. To launch the tool, navigate to the folder c:\Program Files\Microsoft Forefront Unified Access Gateway\common\bin\tracing. In that folder, launch the file trace.hta. Note that this is not an executable, but an HTML application file. These types of files are run within MSHTA.EXE (Microsoft HTML Application host), and it looks like this:
All these items on the long list on the left are names of various UAG components that you can trace. As you can see, by default, tracing is done, but only at a basic level, so we’ll need to set it to get more details.
When you launch this utility, tracing will be ON, so we first need to turn it all off by scrolling all the way down and clicking “stop”:
The next step is to check the appropriate boxes next to the components we want to trace. It may be tempting to check everything, but be careful – if you do so, the server will generate a huge amount of data that even well-trained Microsoft support engineers have a hard time reading. In fact, the end result could be a file that’s so large, that it will be almost impossible to read. Here are some common troubleshooting scenarios, with the appropriate items to check:
Scenario
Components
General
INTERNALSITE, PORTALHOMEPAGE
Remote Desktop Gateway
UAGRDPSVC, WHLTSGAUTH, WHLTSGCONF, WHLFILT_CORE, WHLFILTSECUREREMOTE_BASE, WHL WHLGENLIB, WHLGENLIB_GENERAL
Network Load Balancing (NLB)
CONFIGMGR_SERVICE, CONFIGURATION_GENERAL
SSTP
SSTP_ADMIN, WHLFILTSSLVPN_BASE, SESSIONMGR_SERVICE, WHLFILT_CORE
Authentication and Single Sign On (SSO)
WHLFILTAUTHORIZATION_BASE, SSLBOX_Base, WHLFILT_CORE
RPC-over-HTTP exchange publishing
WHL_LOCAL_IP_MNGR, WHL_ASYNCCOMM_BASE, WHLFILT_CORE
For each item, check all columns except “noise”. After selecting the appropriate items, make sure you uncheck “Auto enable tracing on startup”. If you forget this, the server will restart the tracing when rebooted, and it will run and consume server resources without need. If you expect to need to gather a very long log, you might want to uncheck the option “Circular log file of ___ Mbytes”, but keep in mind that even logging everything, it would take a while to generate such a large log file. Also, a 400 MB log would actually contain millions of lines, making it almost impossible to view without special tools.
After reproducing the issue you want to investigate, click “stop” to stop logging, and retrieve the log file, which would be located by default in c:\windows\debug, and named Forefront-UAG.bin. Be sure to at least move it, because it will get overwritten if you turn on logging again – better safe than sorry.
The trace file that you just generated, you might soon discover, is unreadable! It’s actually binary, and to read it, you have to perform a decryption using specially created TMF files that Microsoft distributes. These can be downloaded here. Get the file UAG_TMF_files.zip, and expand it to some folder on your hard drive. You will also need the TRACEFMT tool, which does the decoding. This tool can be downloaded as part of the XP SP2 tool pack. You don’t need to actually install it, or to have an XP machine to use it – just extract the EXE using WinZip, and then extract support.cab, and get the files tracefmt.exe and traceprt.dll from it. Put these two files in the same folder where you put the content of the TMF file ZIP.
Now, open a CMD prompt, and run the tracefmt tool using the following parameters:
tracefmt.exe <trace bin file> -p <path to extracted TMF files> -o <Target TXT file>.
For example:
The resulting file (UAGLog_09_02_10.txt in the above example) would be a simple text file that you can open with Notepad, or your favorite text editor (mine is MetaPad). Keep in mind that the file grows significantly in the decoding process. The above file was 1.5 MB in binary form, but 4 MB as text – expect the text file to be about X2.5 the size of the binary, and make sure your text editor can handle it. Here’s an example of what you can expect to find in a log:
Don’t expect me to teach you in a single blog entry how to read a full log, but here is some info. The above piece depicts the start of a request from a UAG client to the UAG server. Each line has a time-stamp, down to the millisecond, followed by the component name (whlfilter in this example), and by the function name. Then comes the name of the source file and the line number of where the function is…you don’t have access to the source so you can’t read the full function, of course. Then, after “info:” comes what the data that this function recorded. At the top, you can see the details of this request – the protocol (HTTPS), HTTP method (get), the URL and then more info, including the cookies, hostname of the server, user agent etc.
Below all this, you see the UAG filter start processing the session info, so it can match the request to an existing user session (or fail to do so). On some lines you see a PFC code, which is a unique number assigned to this request, and allows you to track it along the trace. Later on, you can see the header encoding being handled and finally, at the bottom, the application that was identified for this request (Internal Site). Naturally, this is not the end, and this request goes on much longer – several dozen pages, and this is very normal.
Trying to understand all these functions and jargon can be frustrating, no doubt, but with time, you’ll learn to recognize repeating patterns. You can also search the text for keywords like “Error” or “fail”, if you are looking to troubleshoot a specific error. You can do a search for the expression “request from client to filter” to find the URL you are looking to troubleshoot. Each request to UAG has 4 stages:
1. request from client to filter
2. Request sent from filter to web server
3. Response from RWS to filter
4. Response from filter to client
This means that depending on where you see an error, it can indicate if the problem is with UAG itself, or perhaps with what the backend server is sending.
Issues you might run into when running a trace would typically be about the trace.hta file not having the permissions to start the trace. This could happen if you are not logged into the UAG server as a local administrator. Unfortunately, you cannot run the HTA using the runas command, and you’ll have to actually login as an administrator to use it. The symptom for this is that you click “go”, and nothing happens (stays off). Another common issue is that the trace file has many or all of the lines saying “No Format Information Found”:
This typically happens because the decoder couldn’t find the appropriate TMF files, or some of them. This could happen if the file you download is corrupted, did not open fully, or is for a version that’s different than yours. The link I suggested earlier is for UAG Update 1, but if you have installed a later update (as of writing, U1 is the latest, but that won’t be like that for long…), you would need updated TMF files. It’s also possible that when specifying the path to the TMFs, you misspelled it or something.
Last thing to know is that a similar procedure can be done on the client – the same utility is there, and the TMF files package includes data for client-side tracing. The trace utility would be at c:\Program Files\Microsoft Forefront UAG\Endpoint Components\3.1.0\trace.hta , and works the same as on the server.
Happy tracing!
With IAG, creating custom form login was well documented (http://technet.microsoft.com/en-us/library/dd282925.aspx), but UAG does not. The process is actually almost identical, but to make it more available, I’ve decided to write this up and give some examples. The IAG-related entry is here, if you’re interested: http://blogs.technet.com/b/ben/archive/2010/01/23/custom-form-login-sso-how-to.aspx
First, collect the same information as in the IAG post:
1. The application TYPE
2. The Primary Host URL
3. The Form Name
4. The name of the Username and Password input fields.
Then, use this template. To make things clear, this time, it’s actually filled with examples:
<WHLFILTFORMLOGIN ver="1.0">
<APPLICATION>
<APPLICATION_TYPE>HelpDeskApp</APPLICATION_TYPE>
<USAGE description="form_login">
<PRIMARY_HOST_URL>/helpdesk/login\.aspx</PRIMARY_HOST_URL>
<SCRIPT_NAME source="data_definition">FormLoginSubmitStandard</SCRIPT_NAME>
<USER_AGENT>
<AGENT_TYPE search="group">all_supported</AGENT_TYPE>
<POLICY>multiplatform</POLICY>
<SCRIPT_NAME source="data_definition">FormLoginHandler</SCRIPT_NAME>
</USER_AGENT>
<LOGIN_FORM>
<NAME>Login</NAME>
<METHOD>POST</METHOD>
<CONTROL handling="dummy_value">
<TYPE>USER_NAME</TYPE>
<NAME>helpdeskusername</NAME>
<DEF_VALUE>usr</DEF_VALUE>
</CONTROL>
<TYPE>PASSWORD</TYPE>
<NAME> helpdeskpassword</NAME>
<DEF_VALUE>whlpass</DEF_VALUE>
</LOGIN_FORM>
</USAGE>
</APPLICATION>
</WHLFILTFORMLOGIN>
The original version of this template, which includes some variations and notes, can be found on your server at:
C:\Program Files\Microsoft Forefront Unified Access Gateway\von\Conf\WizardDefaults\FormLogin\FormLoginCustom.xml
Whether you use “my” sample, or modify the original template, make sure you save it in this location, and under this name*:
C:\Program Files\Microsoft Forefront Unified Access Gateway\von\Conf\WizardDefaults\FormLogin\CustomUpdate\FormLogin.xml
*Remove the word “custom” from the name, and put it in CustomUpdate.
Note that when putting in the host URL (line 7 above), I used Regular Expression (RegEx), which is required for UAG to be able to identify it. I won’t get deep into RegEx here, but basically, you need to “slash” characters which are non-literals, like dots. You can also use various commands to define a wide pattern. For example, form.*\.htm will catch every file that starts with form, and ends with a “.htm”. More about RegEx here: http://msdn.microsoft.com/en-us/library/6wzad2b2(VS.85).aspx. There’s also a lot of info in the IAG’s original Advanced User Guide: http://download.microsoft.com/download/2/F/9/2F9D9113-B84B-4838-98A0-A3AEFA6608E2/IAG_AdvancedUserGuide.pdf
Naturally, the custom form-login will not always work for you on the first attempt. There are a lot of variations in forms used by applications, and the auto-submit script that UAG uses can only accommodate for some of them. That script is:
function FormLoginSubmit()
formsCol = document.forms;
if (formsCol.length == 1)
document.forms[0].submit();
else
alert("more than one form");
return false;
When troubleshooting, I recommend using HTTPWatch by SimTel software from the UK, downloadable from http://www.httpwatch.com. It costs a little money, but not unreasonable. To troubleshoot the form-login, launch the browser on the client, and login to the UAG portal. Then, open the HTTPWatch plug-in from the tools menu on your browser and hit Record. Now, launch the applications you are attempting to customize. When you reach the form that was supposed to be automatically submitted, stop the HTTPWatch recording, and find the URL on the list of captured URLs.
On that URL, you should expect to see the above script injected into the page, at the top. You should also see a second function called “FormLoginOnLoad”, injected into the page at the very bottom:
<SCRIPT language="JavaScript">
var gSafeOnload = new Array();
function FormLoginOnload()
for (var i=0; i < gSafeOnload.length; i ++)
gSafeOnload[i]();
}// for i
}// FormLoginOnload
if (window.onload)
gSafeOnload[0] = window.onload;
gSafeOnload[gSafeOnload.length] = FormLoginSubmit;
window.onload = FormLoginOnload;
window.onload = FormLoginSubmit;
} // if window.onload
</SCRIPT>
If one or both aren’t there, then you may have misconfigured the XML, and it was unable to locate the form. In that case, check your App-type, primary host URL and form name settings.
As we mentioned in a previous blog entry the KB980346 update published by Microsoft upgrades the underlying Windows SChannel used by Forefront TMG 2010 to support the secure TLS renegotiation extension.
What must be noted that after applying KB980346 on the TMG machine, both the secure and insecure forms of renegotiation may be supported, TMG being in (server) Compatible mode, thus clients not supporting the secure TLS renegotiation extension may use the old insecure form of renegotiation for example in the case of the scenario of a secure web server publishing.
You can adjust this by setting the AllowInsecureRenegoClients registry entry to 0, path: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL
This will put TMG as a “TLS server” in server Strict mode, thus TMG will allow only clients supporting the TLS renegotiation extension to connect for example for the scenario of a secure web server publishing(when TMG acts as a “TLS server”), if the clients’ TLS Client Hello does not “flag” support for the TLS renegotiation extension, TMG will terminate such requests from the clients.
Other possible interesting “issue”: there was a report in respect with RFC 5746 on the McAfee forums that the McAfee Web Gateway “is reintroducing this vulnerability into connections where both the client and server have been updated”(when doing outbound HTTPS Inspection). More exactly some version of Google Chrome 6 has some sort of a static list of web sites supporting the TLS renegotiation extension, and since the McAfee Web Gateway was acting as a MITM for the SSL/TLS traffic between the client and server and was not supporting RFC 5746, as a result this prompted Google Chrome to throw an error.
More about this error here(not sure if again MWG was on the path or other web gateways doing outbound HTTPS Inspection): http://www.google.ro/support/forum/p/Chrome/thread?tid=4af55758316034e2&hl=en
On Chrome 6.0.472.51 beta(currently the latest from the beta channel for Chrome, http://googlechromereleases.blogspot.com/) if TMG was not updated with KB980346, seems that Chrome is “silently” notice(similar with what Opera does) the user about this, if the user clicks the SSL padlock(as suggested by a (disappointed I would add) user on the McAfee forums).
On Chrome 6.0.472.51 beta, if TMG was updated with KB980346, again Chrome similar with what Opera does, will not display the message about the TLS reneg extension to the user, if the user clicks the SSL padlock.
I’ve tried myself the “culprit” Chrome 6.0.472.0 behind TMG doing outbound HTTPS inspection and I did not have any troubles when KB980346 was applied on TMG(if it was not applied Chrome did throw that error).
Opera also has an option to display a warning about a secure web site not supporting the secure TLS reneg extension but this is not currently enabled by default.
Do note that while TMG(with KB980346 applied on TMG) is on the path doing outbound HTTPS Inspection(thus for the client appearing as the SSL/TLS server) the client will not know if the targeted end server really supports the secure TLS reneg extension. You can put TMG in client Strict mode, but this will make TMG to not be able to set up TLS sessions at all with servers which do not support the secure TLS reneg extension, which will likely currently break a lot of connections(for the outbound HTTPS inspection scenario when TMG acts as a client and not only).
I recently had a customer ask about how to do SSO with an email address and not the samAccountName. Knowing that Forefront Unified Access Gateway (UAG) is VERY flexible, the answer is of course yes, and this blog outlines how.
My customer has a need to hold non-employee accounts in their directory. Specifically, they use Active Directory (AD) for SharePoint. They have both employees and non-employees in the directory. Their challenge was to get the non-employees to remember their AD user id. The answer was to have the non-employee use their company email address, something they can remember.
While AD understands Universal Principal Name (UPN), it is not a free text field allowing you to type anything you choose. In addition, you cannot include a “@” in your samAccountName, as AD does not allow this.
UAG can be configured to do a lookup of the email address and return the samAccountName. This is no different than many LDAP login mechanisms, but the important thing is that UAG does know the real samAccountName, which is required to perform SSO login to most applications.
To enable UAG to do this “switch email for samAccountName” function we add a prevalidate.inc file, as discussed on page 99 of IAG_AdvancedUserGuide.pdf. (Note: IAG was the prior name for UAG).
For this demonstration, we will assume you already have SharePoint setup and protected by UAG. We assume that the user can log in successfully with their userid (samAccountName), we just want to add e-mail address support.
Step 1. Create the file <TrunkName><0 or 1>PreValidate.inc, where the TrunkName is the name you created in UAG, and 0 stand for HTTP and 1 stands for HTTPS. In my case, my trunk was named “UAG” and it was HTTPS, so my filename is UAG1PreValidate.inc. This file is placed in the \von\InternalSite\inc\CustomUpdate directory.
Step 2. Add code similar to the following in the file. Note you will need to change the userid and password (on the Ads Provider line) and LDAP string (on the oConn.Execute line) to match your settings. See security note below*.
<%
If instr(Session("user_name"&num),"@") > 0 then
Dim oConn
Dim rs
Set oConn = Server.CreateObject("ADODB.Connection")
oConn.Provider = "ADSDSOObject"
oConn.Open "Ads Provider", "scd-labs\serviceaccount", "servicepassword"
Set rs = oConn.Execute("<LDAP://dc=SCD-LABS,dc=net>;(&(objectClass=user)(mail=" & Session("user_name"&num) & "));sAMAccountName")
if not rs.eof then
if rs.recordcount = 1 then ' we found our user!
Session("user_name"&num) = trim(rs("sAMAccountName").value) ' Required for SSO and change password
user_name = trim(rs("sAMAccountName").value) ' Required to pass CheckCredentials()
response.write "<font color=""red""><b><center>More than one user was found with the e-mail address " & Session("user_name"&num) & "<br></center></font></b>"
end if
response.write "<font color=""red""><b><center>No user was found with the e-mail address " & Session("user_name"&num) & "<br></center></font></b>"
set oConn = nothing
set rs = nothing
End if
%>
Step 3. Activate the configuration.
Step 4. Create an account in Active Directory with a known email address.
Step 5. Log in using the email address as the account name and the real password.
If you have an error, and the UAG portal gives you an “Error 500”, then verify the code above, looking for any special characters that can be common in Unicode files.
*Security Note: Neither Microsoft or I are recommending having clear text passwords in text files on product servers. The goal of this blog was to show how it could be done in the simplest form. There are many ways to encrypt the password, but that is beyond the scope of this blog.
The details of the scenario are as follows:
Published Exchange Applications
Authentication Details
Ratio (of overall usage)
Outlook Web Access
Outlook Web Access Look and Feel with Basic authentication against the Client Access Server
50%
Outlook Anywhere and Web Services
Clients authenticating with UAG with NTLM, and using KCD between UAG and the Client Access Server
40%
ActiveSync
Basic authentication
10%
Results for a single test server running Forefront UAG (RTM build 1101):
Hardware:
Processor
2 Quad-Core Intel Xeon 5500 Series
Memory
24 GB RAM
Network Interface
Gigabit Ethernet
Results:
Number of concurrent users
16,000
CPU utilization
85%
Memory usage
44%
I came across today upon an interesting case where a user was trying to configure Forefront TMG 2010(on Windows Server 2008 R2) as an L2TP/IPsec VPN remote access server.
The configuration seemed OK and it was pretty standard(for address assignment for VPN clients DHCP was used).
The Vista SP2 L2TP/IPsec VPN client showed error 736:
I took a quick look within the RRAS mmc on TMG(RRAS provides the VPN functionality for TMG), the Internal interface of the RRAS obtained an IP address from the DHCP server:
And then looked at the Event Viewer on TMG. I noticed a warning and an error thrown by the Remote Access service:
Warning: No IP address is available to hand out to the dial-in client.
Error: CoId={BCE3AB30-44F8-4466-967E-25E13C94BE15}: The user x connected to port VPN2-9 has been disconnected because no network protocols were successfully negotiated.
Noticing the above warning I decided to look at the local DHCP server.
Within the Event Viewer on the DHCP server(Windows Server 2008 R2), two warnings were present, indicating that the scope was simply left without any IP addresses to lease (TMG obtained the last IP address available(which was used on the RRAS Internal interface) and could not obtain other IP address for the VPN clients(IPCP is used with L2TP/IPsec to provide the VPN clients with IP addressing information, the VPN clients do not talk with the DHCP server directly)
Warning: There are no IP addresses available for lease in the scope or superscope "LAN Use Scope".
Warning : Scope, 192.168.x.x, is 100 percent full with only 0 IP addresses remaining.
The DHCP server admin configured a small scope which was insufficient as the network expanded and more clients were provisioned.
So what appeared a TMG issue simply turned into a DHCP scope one due to network growth.
We got reports from folks who published Outlook Anywhere through UAG and noticed their (apparently large) Offline Address Book (OAB) is not being updated.
David Bahat from our test team came up with the following procedure that solves the problem.
After you have published Exchange, open Advanced Trunk configuration -> Click the Portal Tab –> Click the Edit button of the Do not parse the response bodies option:
Select the relevant Exchange Client Access Server (e.g. EX01BE10) –> Click the Add button in the URLs group box
Add the /OAB.* expression
Save and activate the configuration.
I recently had a customer ask about setting the timeout in Unified Access Gateway (UAG) on a per-user basis. By default, UAG allows you to determine this at the portal on an application basis, but not on a per-user basis. Knowing that UAG is VERY customizable, this blog outlines how to accomplish this.
UAG defines an “Inactivity Timeout” setting as a time period with no activity before a forced log off happens. There are several of these including: login page inactivity (default is 30 seconds), portal home page inactivity (default is 300 seconds for non-privileged endpoints) and application inactivity (default is 30 minutes).
UAG also defines a “Scheduled Timeout” for both privileged (default 60 minutes) and non-privileged (default 1440 minutes) endpoints. A scheduled timeout occurs whether or not there is any activity.
To meet some security policies, customers have a need to set the inactivity and scheduled logoff time on a per-user or per-group basis. Setting this can be accomplished by a single line of code, but UAG leave it up to the customer to determine the logic of when to apply the setting.
One example can be to pull the setting from the user repository. In this example, we can modify an attribute to hold the UAG timeout setting. To illustrate this example, consider the following code:
on error resume next ' we need error handling so we can ignore users without a timeout setting
oConn.Open "Ads Provider", Session("repository"&num) & "\" & Session("user_name"&num), Session("password"&num)
Set rs = oConn.Execute("<LDAP://dc=SCD-LABS,dc=net>;(&(objectClass=user)(sAMAccountName=" & Session("user_name"&num) & "));physicalDeliveryOfficeName")
SetSessionParam g_cookie, "SchedTimeout", trim(rs("physicalDeliveryOfficeName").value) ' setting the value
on error goto 0 ' reset error handeling
This code finds the user in Active Directory and returns the physicalDeliveryOfficeName attribute (which is the office attribute). It then sets the global cookie “SchedTimeout” to the value of that attribute. If the value of 120 was returned, the user would be experience a forced logoff after 2 minutes (120 seconds). We could also have set the “SessionTimeout”, cookie value, which would have set the inactivity for the user.
We used the “on error resume next” command to deal with any user who does not have the value set, though we could have added more complete logic.
You can add the code sample above to any of the validate.inc files. In my example, I added it to the file <TrunkName><0 or 1>PreValidate.inc, where the TrunkName is the name you created in UAG, and 0 or 1 stands for HTTPS. In my case, my trunk was named “UAG” and it was HTTPS, so my filename is UAG1PreValidate.inc. This file is placed in the \von\InternalSite\inc\CustomUpdate directory.
During the time I’ve been working with IAG and UAG, many customers and visitors to this blog asked me about the availability of public material about the products. Other than the various blogs and official documentation, as well as occasional public course, there was nothing to be found. I’m glad to tell you that finally, there’s a book out there for UAG…written by me, of course.
The book itself is not really finished – I still have a few more chapters to write, but the publisher has released the first three chapters as something they call RAW (short for Read As we Write). It’s like a Beta version – readers can get it right now, way before the book is officially out, and also make comments or suggestions to it. This is a great honor for me, of course, as the publisher only releases into RAW books that are very well written, and can stand their ground without significant edits.
Even though the book is about UAG, a lot of it also applies to IAG, and even eGap. It’s written specifically for the UAG beginner, and starts with basic concepts and design. It goes through advanced configurations and troubleshooting and includes Direct Access scenarios. It does not, however, cover advanced scenarios like ADFS or customizations.
Interested? I hope so…go ahead and look at:
Well, this is not a police state, but if you don’t meet the policy, you’re in a bit of a pickle. Several users have reported issues when publishing Remote Desktop applications with UAG. This can happen when using one of the new Remote Desktop application templates:
For some customers, trying to launch these applications on the UAG portals shows the following message:
“Your computer does not meet the security policy requirements of this application” sounds a lot like you have configured the access policy on the UAG application incorrectly, but the truth of the matter is that this error is being displayed by the remote desktop client (MSTSC) and has nothing to do with the application or trunk policy in UAG. In fact, this error is a very generic one, and can indicate several things, completely unrelated to the policy or each other.
The primary cause for this error is that the Certificate on the Remote Desktop Gateway on UAG has not been configured. To perform this type of publishing, UAG installed and configures the RDG service on Windows 2008 R2, but this does not include assigning a certificate to it. Without a certificate, the RDG cannot be trusted, and without being trusted, the Remote Desktop client cannot connect to it, giving this error, which actually means “could not connect to RDG server”.
Assuming you have already installed a certificate on your server, in order to publish your trunk, all you have to do is this:
1. From the Administrative tools on the UAG server, open Remote Desktop Gateway Manager
2. Right-click on your servers name, and click Properties
3. Switch to the SSL Certificate tab.
4. Import certificate, and select the appropriate one.
5. You will be asked to restart the service – go ahead and do so.
For the most part, this would take care of the problem. If you are running an array of server, keep in mind that this needs to be done on all of them. Also, check the certificate chain and CRL carefully, to make sure that both the UAG and the connecting client are able to trust it. This is especially tricky if the certificate has been issued by an internal Certificate Authority. You may have to import the issuing CA’s root certificate into the UAG server’s trusted root authority’s store, and perhaps the same on the client.
The same identical error, however, may pop-up if the UAG is unable to contact the back-end server. Here are some scenarios that can cause this:
1. You configured the “pre-defined” template with a server name that doesn’t really exist
2. There’s some problem with DNS that prevents UAG from resolving it’s name
3. You forgot to open the appropriate port (3389) on a router or firewall that’s between UAG and the servers that it is supposed to publish.
4. If publishing the “user defined” template, you may have configured it with an incorrect IP address or subnet.
To check the above, try to connect to your back-end server manually from the UAG server, by running MSTSC. If it cannot connect, then UAG will not be able to publish it, so proceed with standard Network configuration analysis. If UAG is able to connect, check the server settings. For example, if you are publishing a subnet, it should be in this format:
I am trying to customise the layout of the portal pages - I know of the changes in Technet etc to hide the left bar, top har, toolbar etc, but I want to rearrange the look of the whole page. However, I am having an almighty battle with changing the DIVs' positioning in CSS (no help from IE & Firefox layout differences!).
I have spent a couple of hours on this, playing with DIV positioning etc, but not really in huge depth as every change I made caused odd effects. DIVs within tables within DIVs etc...I spent about an hour trying to stop the main content window overflowing off the bottom of the page acheiving only some loss of sanity
Has anyone made wholesale changes to the layout of the Portal? Does it work well or are there gotchas?
And is this beyond the support boundary for UAG (the technet article is unclear on how far you can go)
Thanks, --Chris
In recent months, we have seen several instances of tunneled applications failures, which seems to affect a limited number of an organization’s clients. In all cases, these are IAG Servers that have been working well, but suddenly, some customers are unable to use the tunneled apps (applications that are client/server based, and require the use of the SSL VPN component to function). Investigation of this issue has revealed an interesting fact. As it turns out, some Internet Service Providers (ISPs) have started employing a technique known as “NXDomain Manipulation”, which leads to this, as well as other problems. This is still not done by all of them, but some countries are more affected by others.
NXDomain manipulation is a process in which the ISP changes the normal behavior of DNS servers. One of the primary principles of the DNS system is the RCODE, or Response-code. As specified in section 4.1.1 of RFC 1035 (http://tools.ietf.org/html/rfc1035), DNS servers respond with an RCODE of 3 (“Name Error”, a.k.a. NXDOMAIN) when a client submits a query for a name that does not exist. Some ISPs are configuring their DNS to respond differently, so when the servers receive a request for a non-existent domain, instead of replying with an RCODE of 3, they respond with an RCODE of 0 (“No error”) and direct the browser to an internal webpage hosted by the ISP. That page would typically be either a search page or a custom error page such as the one shown below:
Typical error page when NXDomain manipulation is employed
ICANN is not happy about this practice, and published a draft-memo about it (http://www.icann.org/en/topics/new-gtlds/nxdomain-substitution-harms-24nov09-en.pdf). In the memo, the organization attempts to ban NXDomain manipulation, saying “ICANN strongly discourages the use of DNS redirection, wildcards, synthesized responses and any other form of NXDOMAIN substitution in new and existing gTLDs and ccTLDs and any other level in the DNS tree for registry-class domain names”. ICANN’s plan is to include this in the agreement that owners of the new gTLDs would have to sign.
For regular users, NXDomain manipulation is not a problem, and might even be helpful, as the result is easier to digest than a bleak numerical error message, but for IAG customers, this can lead to some unpleasantness. The root cause of the issue is the way the IAG Tunneling components perform name resolution as part of their design. This design is based on that when a tunneled application tries to contact its server, the main DNS server would not be able to resolve that servers name, but when NXDomain manipulation is involved, DNS is able to resolve it…or at least, it looks that way. In reality, though, the communication process is interrupted by this false-positive, and the application tries to contact the IP resolved by the ISPs DNS servers, which fails, of course.
Unfortunately, the way this occurs, from the IAG’s perspective, is exactly as it should, and so there’s no way to fix it. An ISP that performs NXDomain manipulation will prevent its users from using tunneled applications, and the user can only work around it, and not solve it (assuming, of course, that they are not willing to switch to another ISP).
Typical error 3 response by a DNS server to a non-existent page.
Success replied by manipulated DNS server. Note that the server gives an IP array of its internal search pages.
The available workarounds are the following:
1. Some ISPs allow their customers to ask to be excluded from the process of NXDomain manipulation. The exclusion is sometimes based on a cookie implanted on the user’s computer, and in other cases, based on the computers MAC address. Technically, a cookie-based exclusion would not solve the problem, as the tunneled app that performs the DNS query would typically not be able to send the cookies to the DNS server to get excluded.
2. Since this manipulation is done by the ISPs server, using a different DNS server that does not do NXDomain manipulation is also a workaround. Verizon hosts publicly usable DNS Server at the IP address 4.2.2.1 and 4.2.2.2, and these can be used in this scenario. To use these servers, the user needs to change his networking configuration to these DNS servers, and that solves the problem well. However, when the affected computer is a mobile computer, this can complicate things, because if the computer is manually set to a specific DNS (as opposed to a DHCP-assigned one), it won’t be able to resolve names when the user connects to his workplace’s corporate network, which has its own DNS servers. A solution we have come up with for this is a small application that allows the user to change the DNS settings on his computer from automatic to static with one mouse-click (contact Microsoft Support to obtain this tool).
DNS Switcher app
It’s also possible to create a custom VBScript that changes these settings, and implement it as a custom application on the IAG portal, though we do not have a prepared guide for this.
3. A variation of the above workaround is to set the router at the user’s residence to assign connecting users a static DNS server address (like the 4.2.2.1/4.2.2.2 we just mentioned), instead of the one that is assigned by the ISP. This, naturally, may be challenging, as routers have very diverse and often unique user-interface. This could be too complicated for home users to perform by themselves.
Typical DNS settings on a home router
4. Another workaround is to connect to the corporate network using Network Connector instead of a tunneled application. When using the Network Connector, the user’s computer has a full VPN access to the network, including a change to the DNS settings, so it bypasses the NXDomain manipulation completely. Not all organizations are OK with using the Network Connector, because it opens connectivity to internal network that may not meet the organizations security policy, but technically, this is a good solution.
What else can one do? Well, hopefully, ISPs will start stepping back from this technique, following the action taken by ICANN. You might be able to help by applying pressure to your ISP to stop this as well, by showing them that this practice may be more upsetting than helpful.
I have configured AD authentication repository in UAG and allowed password change in trunk configuration. Also the Base DN in AD configuration is the domain root. Also sub folders are allowed. Connection to Domain controller is non-secure (no SSL certificate)
When user logs in and tries to find password, he is able to insert old password and new password twice. After submitting the question he / she receives following error: The password change cannot be applied
In UAG log there are following entryThe user XXXXX failed to change a password on trunk ovi (secure=1) using authentication server AD. The source IP address is xx.xx.xx.xx. The session ID is %[SessionId%]. The error code is There is no such object on the server. -- Extended Error --- LDAP Provider : 0000208D: NameErr: DSID-031001CD, problem 2001 (NO_OBJECT), data 0, best match of: 'DC=domain,DC=local'.
The actual best match varies depending of the user that is trying to change their password. In DC event logs I have following errors
Successful Network Logon:
User Name: uag_ad_repository
Domain: DOMAIN
Logon ID: (0x0,0xFCB73B2)
Logon Type: 3
Logon Process: Advapi
Authentication Package: Negotiate
Workstation Name: DC1
Logon GUID: -
Caller User Name: DC1$
Caller Domain: DOMAIN
Caller Logon ID: (0x0,0x3E7)
Caller Process ID: 428
Transited Services: -
Source Network Address: xx.xx.xx.xx (UAG server internal IP address)
Source Port: 43747
For more information, see Help and Support Center at
Pre-authentication failed:
User Name: username
User ID: DOMAIN\username
Service Name: krbtgt/domain.local
Pre-Authentication Type: 0x0
Failure Code: 0x19
Client Address: xx.xx.xx.xx (UAG server internal IP address)
Authentication Ticket Request:
Supplied Realm Name: domain.local
User ID: -
Service ID: -
Ticket Options: 0x40810010
Result Code: 0x17
Ticket Encryption Type: -
Pre-Authentication Type: -
Client Address: xx.xx.xx.xx (UAG server internal address)
Certificate Issuer Name:
Certificate Serial Number:
Certificate Thumbprint:
User ID: domain\uag_ad_repository
Service Name: krbtgt/DOMAIN
Client Address: xx,xx,xx,xx (UAG Internal address)
Any tips or tricks would be highly appreciated!
One of the strong points of IAG over the years has been the fact that it supported multiple platforms. Recently, cellular phone users, and especially iPhone users have discovered that they can’t browser IAG portals anymore. If this happened to you, don’t jump to the conclusion that you and your device have been ostracized. What’s really happening here is that support for additional platforms has actually been EXPANDED.
Before IAG 3.7 SP2 Update 2, the server had one Endpoint Policy setup for all connecting devices, and that made things a bit of a problem, because different platforms have different endpoint security products. With Update 2, the policy editor has been expanded to include 4 distinct sub-policies in each policy. Now, each policy includes a separate policy for Windows computers, Macintosh computers, Linux computers and “other”. This is how it looks:
The problem some mobile phone users are facing is a result of this expansion. As you can see from the screenshot above, the default policy that’s used with most portals and applications is the “Default Web Application Access”, and as you can see, the policy for “other” is set to “Never”. IAG detects the type of device that is connecting based on the user-agent string, which is pre-set into the web browser used by the device or computer. Mobile phones are classified as “other”, and so are treated with accordance with the “Other” policy…and get banned.
The solution to this is really simple – just edit the default policies, and assign whatever sub-policy you want to the “Other” category. Just keep in mind that the IAG client components cannot run on mobile phones, so endpoint security is something that is difficult to enforce.
With the release of UAG, our customers are finally able to install the product on any computer, as opposed to the previous releases that were available as an appliance or a pre-configured Virtual Machine. This is good news, but also carries a risk. A lot of customers think that if this is just some piece of software that you can install, then why not use the same server to do some other stuff, and conserve some resources.
Indeed, this is tempting, but from a supportability perspective, this is a big problem. A unique trait of UAG is that it doesn’t work on its own. UAG integrates tightly with several other components, and that makes the whole thing much more sensitive. When you configure a UAG server, it automatically configures other components, like the TMG firewall server that comes along with it, as well as IIS. TMG itself may need to configure the RRAS service, and so on. Because of this “chain of command” within the server, even a minor change to one of the components could cause a lot of damage to the system. For example, if the user is tempted to add some policy rule to TMG, it may conflict with a UAG-created rule, leading to some feature or application being unusable. An even worse case could be that the configuration becomes less secure and expose the server to attack.
Microsoft’s support policy dictates very clearly that the administrator should never attempt to configure any component on the server, except the UAG management console, or if directly instructed to by a Microsoft support engineer or official documentation. This also means that installing additional software on the server is also not supported, so if you planned on hosting a TeamSpeak server on it, better think again. This is somewhat similar to the old “warranty sticker” on appliances – if you decide to open up a TV and stick an espresso machine in it, it might invalidate the warranty. Again, this is not because we want you to have a hard time or spend more money – it’s because the introduction of additional software into the picture could make it hard or even impossible for support engineers to figure out what’s wrong with the server if it blows up. For example – installing certain applications can replace some of the system’s networking components, which are a critical part of UAG. A different component might process data differently, and cause communication problems that make no sense. If this happens, Microsoft Technical Support may not be able to tell exactly which files have been replaced, and be unable to help.
Despite all this, sometimes it is necessary to install some things on servers, and we recognize that. For example, installing an Anti Virus is definitely a good idea. For that end, Microsoft does approve of installing of Anti Virus and Anti Malware tools. These applications may require that certain folders and files be excluded from the scan, and the list is covered (and updated) here: http://technet.microsoft.com/en-us/library/cc707727.aspx
A more problematic question surrounds installation of other management software. For example, what about system or drivers support, like Virtual Machine extensions, hardware drivers that are an installable or system management utilities? Unfortunately, this, although sometimes necessary, still falls under the same category as any other software, and is not supported. Microsoft is certainly not in a position to forbid you from doing anything, but if you do choose to install additional software on a UAG server, you might end up with an unsupported or unsupportable system. In such a case, Microsoft support may have to ask you to uninstall these additions before being able to receive support for your server.
Active Connections Proto Local Address Foreign Address State PID TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 700 TCP 0.0.0.0:443 0.0.0.0:0 LISTENING 4 TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4 TCP 0.0.0.0:1433 0.0.0.0:0 LISTENING 2880 TCP 0.0.0.0:2103 0.0.0.0:0 LISTENING 1704 TCP 0.0.0.0:2105 0.0.0.0:0 LISTENING 1704 TCP 0.0.0.0:2107 0.0.0.0:0 LISTENING 1704 TCP 0.0.0.0:2171 0.0.0.0:0 LISTENING 1296 TCP 0.0.0.0:2172 0.0.0.0:0 LISTENING 1296 TCP 0.0.0.0:2173 0.0.0.0:0 LISTENING 1296 TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING 1892 TCP 0.0.0.0:3847 0.0.0.0:0 LISTENING 1660 TCP 0.0.0.0:4443 0.0.0.0:0 LISTENING 4 TCP 0.0.0.0:5985 0.0.0.0:0 LISTENING 4 TCP 0.0.0.0:6001 0.0.0.0:0 LISTENING 4 TCP 0.0.0.0:6002 0.0.0.0:0 LISTENING 4 TCP 0.0.0.0:9389 0.0.0.0:0 LISTENING 1316 TCP 0.0.0.0:10000 0.0.0.0:0 LISTENING 428 TCP 0.0.0.0:10001 0.0.0.0:0 LISTENING 884 TCP 0.0.0.0:10002 0.0.0.0:0 LISTENING 924 TCP 0.0.0.0:10003 0.0.0.0:0 LISTENING 528 TCP 0.0.0.0:10004 0.0.0.0:0 LISTENING 1704 TCP 0.0.0.0:10010 0.0.0.0:0 LISTENING 2896 TCP 0.0.0.0:10012 0.0.0.0:0 LISTENING 2612 TCP 0.0.0.0:10013 0.0.0.0:0 LISTENING 1244 TCP 0.0.0.0:10025 0.0.0.0:0 LISTENING 804 TCP 0.0.0.0:10059 0.0.0.0:0 LISTENING 520 TCP 0.0.0.0:10064 0.0.0.0:0 LISTENING 2380 TCP 0.0.0.0:10218 0.0.0.0:0 LISTENING 2336 TCP 0.0.0.0:47001 0.0.0.0:0 LISTENING 4 TCP 0.0.0.0:50002 0.0.0.0:0 LISTENING 4 TCP 10.0.0.1:80 0.0.0.0:0 LISTENING 804 TCP 10.0.0.1:139 0.0.0.0:0 LISTENING 4 TCP 10.0.0.1:1745 0.0.0.0:0 LISTENING 804 TCP 10.0.0.1:1801 0.0.0.0:0 LISTENING 1704 TCP 10.0.0.1:8080 0.0.0.0:0 LISTENING 804 TCP 10.0.0.1:10099 0.0.0.0:0 LISTENING 804 TCP 10.0.0.1:10173 10.0.0.10:445 ESTABLISHED 4 TCP 127.0.0.1:8008 0.0.0.0:0 LISTENING 4 TCP 127.0.0.1:8080 0.0.0.0:0 LISTENING 804 TCP 192.168.150.18:1801 0.0.0.0:0 LISTENING 1704 TCP 192.168.150.18:10824 92.122.207.171:80 TIME_WAIT 0 TCP [::]:135 [::]:0 LISTENING 700 TCP [::]:443 [::]:0 LISTENING 4 TCP [::]:445 [::]:0 LISTENING 4 TCP [::]:1433 [::]:0 LISTENING 2880 TCP [::]:2103 [::]:0 LISTENING 1704 TCP [::]:2105 [::]:0 LISTENING 1704 TCP [::]:2107 [::]:0 LISTENING 1704 TCP [::]:2171 [::]:0 LISTENING 1296 TCP [::]:2172 [::]:0 LISTENING 1296 TCP [::]:2173 [::]:0 LISTENING 1296 TCP [::]:3389 [::]:0 LISTENING 1892 TCP [::]:3847 [::]:0 LISTENING 1660 TCP [::]:4443 [::]:0 LISTENING 4 TCP [::]:5985 [::]:0 LISTENING 4 TCP [::]:6001 [::]:0 LISTENING 4 TCP [::]:6002 [::]:0 LISTENING 4 TCP [::]:9389 [::]:0 LISTENING 1316 TCP [::]:10000 [::]:0 LISTENING 428 TCP [::]:10001 [::]:0 LISTENING 884 TCP [::]:10002 [::]:0 LISTENING 924 TCP [::]:10003 [::]:0 LISTENING 528 TCP [::]:10004 [::]:0 LISTENING 1704 TCP [::]:10010 [::]:0 LISTENING 2896 TCP [::]:10012 [::]:0 LISTENING 2612 TCP [::]:10013 [::]:0 LISTENING 1244 TCP [::]:10025 [::]:0 LISTENING 804 TCP [::]:10059 [::]:0 LISTENING 520 TCP [::]:10064 [::]:0 LISTENING 2380 TCP [::]:10218 [::]:0 LISTENING 2336 TCP [::]:47001 [::]:0 LISTENING 4 TCP [::]:50002 [::]:0 LISTENING 4 TCP [fe80::b9c7:3dc6:95e1:d0b3%14]:1801 [::]:0 LISTENING 1704 TCP [fe80::b9c7:3dc6:95e1:d0b3%14]:2171 [fe80::b9c7:3dc6:95e1:d0b3%14]:10194 ESTABL TCP [fe80::b9c7:3dc6:95e1:d0b3%14]:2171 [fe80::b9c7:3dc6:95e1:d0b3%14]:10195 ESTABL TCP [fe80::b9c7:3dc6:95e1:d0b3%14]:2171 [fe80::b9c7:3dc6:95e1:d0b3%14]:10720 ESTABL TCP [fe80::b9c7:3dc6:95e1:d0b3%14]:2171 [fe80::b9c7:3dc6:95e1:d0b3%14]:10721 ESTABL TCP [fe80::b9c7:3dc6:95e1:d0b3%14]:2171 [fe80::b9c7:3dc6:95e1:d0b3%14]:10868 ESTABL TCP [fe80::b9c7:3dc6:95e1:d0b3%14]:2171 [fe80::b9c7:3dc6:95e1:d0b3%14]:10869 ESTABL TCP [fe80::b9c7:3dc6:95e1:d0b3%14]:10194 [fe80::b9c7:3dc6:95e1:d0b3%14]:2171 ESTABL TCP [fe80::b9c7:3dc6:95e1:d0b3%14]:10195 [fe80::b9c7:3dc6:95e1:d0b3%14]:2171 ESTABL TCP [fe80::b9c7:3dc6:95e1:d0b3%14]:10720 [fe80::b9c7:3dc6:95e1:d0b3%14]:2171 ESTABL TCP [fe80::b9c7:3dc6:95e1:d0b3%14]:10721 [fe80::b9c7:3dc6:95e1:d0b3%14]:2171 ESTABL TCP [fe80::b9c7:3dc6:95e1:d0b3%14]:10868 [fe80::b9c7:3dc6:95e1:d0b3%14]:2171 ESTABL TCP [fe80::b9c7:3dc6:95e1:d0b3%14]:10869 [fe80::b9c7:3dc6:95e1:d0b3%14]:2171 ESTABL TCP [fe80::f902:f89f:e8b1:551c%13]:1801 [::]:0 LISTENING 1704 UDP 0.0.0.0:123 *:* 972 UDP 0.0.0.0:500 *:* 924 UDP 0.0.0.0:1645 *:* 924 UDP 0.0.0.0:1645 *:* 924 UDP 0.0.0.0:1645 *:* 924 UDP 0.0.0.0:1645 *:* 924 UDP 0.0.0.0:1646 *:* 924 UDP 0.0.0.0:1646 *:* 924 UDP 0.0.0.0:1646 *:* 924 UDP 0.0.0.0:1646 *:* 924 UDP 0.0.0.0:1812 *:* 924 UDP 0.0.0.0:1812 *:* 924 UDP 0.0.0.0:1812 *:* 924 UDP 0.0.0.0:1812 *:* 924 UDP 0.0.0.0:1813 *:* 924 UDP 0.0.0.0:1813 *:* 924 UDP 0.0.0.0:1813 *:* 924 UDP 0.0.0.0:1813 *:* 924 UDP 0.0.0.0:4500 *:* 924 UDP 0.0.0.0:5355 *:* 376 UDP 10.0.0.1:137 *:* 4 UDP 10.0.0.1:138 *:* 4 UDP 10.0.0.1:2171 *:* 1296 UDP 127.0.0.1:11510 *:* 2880 UDP 127.0.0.1:11511 *:* 4836 UDP 127.0.0.1:24364 *:* 3924 UDP 127.0.0.1:25815 *:* 1296 UDP 127.0.0.1:28266 *:* 2800 UDP 127.0.0.1:28875 *:* 2896 UDP 127.0.0.1:35676 *:* 1316 UDP 127.0.0.1:36670 *:* 528 UDP 127.0.0.1:63212 *:* 1660 UDP 127.0.0.1:64625 *:* 924 UDP 192.168.150.18:2171 *:* 1296 UDP [::]:123 *:* 972 UDP [::]:500 *:* 924 UDP [::]:4500 *:* 924 UDP [::]:5355 *:* 376 UDP [::1]:24362 *:* 924 UDP [::1]:24363 *:* 924 UDP [::ffff:10.0.0.1]:1645 *:* 924 UDP [::ffff:10.0.0.1]:1646 *:* 924 UDP [::ffff:10.0.0.1]:1812 *:* 924 UDP [::ffff:10.0.0.1]:1813 *:* 924 UDP [::ffff:192.168.150.18]:1645 *:* 924 UDP [::ffff:192.168.150.18]:1646 *:* 924 UDP [::ffff:192.168.150.18]:1812 *:* 924 UDP [::ffff:192.168.150.18]:1813 *:* 924 UDP [fe80::b9c7:3dc6:95e1:d0b3%14]:1645 *:* 924 UDP [fe80::b9c7:3dc6:95e1:d0b3%14]:1646 *:* 924 UDP [fe80::b9c7:3dc6:95e1:d0b3%14]:1812 *:* 924 UDP [fe80::b9c7:3dc6:95e1:d0b3%14]:1813 *:* 924 UDP [fe80::b9c7:3dc6:95e1:d0b3%14]:2171 *:* 1296 UDP [fe80::f902:f89f:e8b1:551c%13]:1645 *:* 924 UDP [fe80::f902:f89f:e8b1:551c%13]:1646 *:* 924 UDP [fe80::f902:f89f:e8b1:551c%13]:1812 *:* 924 UDP [fe80::f902:f89f:e8b1:551c%13]:1813 *:* 924 UDP [fe80::f902:f89f:e8b1:551c%13]:2171 *:* 1296
Once you have your "site" created check the box Request Compressed HTTP Content from Servers.
You'll be able to speak to the iTunes servers now.