Identity Management and Information Security from Kent Nordström's point of view!
Just upgraded my client to Windows 10 and discovered that UAG does not really like my client anymore.
The new Edge browser isn’t supported at all if client components are required.
If I start my IE11 on my Windows 10 client UAG fails to detect the FireWall causing all access requiring a compliant FW to fail.
If your clients start using Windows 10 you might need to remove any requirements for FW in your UAG policies.
When you start to use ADFS with your UAG and also start to use Azure or Office 365 you might come up with the idea of “publishing” your Office 365 SharePoint site in the UAG portal. This can be done using what is called a Smart Link.
But when you add your smart link as an application in your UAG you can easily end-up with breaking the UAG Portal and getting a URL is to long error message.
This happens because you have associated your application with the federation URL by adding your ADFS server as the Web Server in your application.
This is an easy misstake to make since the Smart Link starts with something like “https://sts.company.com/adfs/ls…”.
What you need to do is put a “dummy” value in the Web Server setting of the application. This value however needs to be resolvable to an IP address by UAG. One way of solving that is to put the “dummy” value in the hosts file of the UAG and put a “dummy” IP-address on it.
Now you can put the Smart Link URL as the Portal Link in your application and the UAG Portal now contains an application that in fact is hosted in Office 365 but still gives SSO due to ADFS authentication.
Many customers that used UAG 2010 for DirectAccess is in the process of replacing it with DirectAccess in Windows Server 2012 (or 2012 R2). One issue with this is that once UAG has been your DA server it has a hard time forgetting it.
Today I stumbled upon such a case. UAG had not been used for DA for 6 months and DirectAccess had been disabled following the official TechNet article on how to disable and enable DA in UAG.
Now however they started to clean-up some more. Removing the IP-HTTPS certificate and the IP addresses used by DA in UAG. When they did UAG failed to activate the DirectAccess configuration!
The solution to this problem is to remove a small file on the UAG server that holds information about the DA IP addresses and certificates. The file you need to remove is the uagda.config file located in the common\conf folder of your UAG installation.
After deleting the file your UAG should activate just fine again.
In my tweets or searching the Internet you might have learned that UAG 2010 SP3 will detect Windows 8.1 clients as mobile devices.
The not supported solution presented by Risual forgets to notify you that you need to make the change in both the InternalSite web.config as well as in the PortalHomePage web.config. This is documented in the official TechNet article on how to modify the DetectionExpression.
However, they both fail to tell you that the modifications you make in the web.config files might cause your UAG 2010 to start showing IIS Error 500.
The reason is obvious if your a programmer but maybe not if your a typical IT-pro.
When following the guide from Risual for example and adding the line <DetectionExpression Name="IE11" Expression='UserAgent Contains "mozilla" AND UserAgent Contains "rv:11"' DefaultValue="false" /> you have to remember to add that line BEFORE you refer to it in a line like <DetectionExpression Name="Mobile" Expression='!IE11 AND (MobileDevice OR WindowsCE)' DefaultValue="false" />
Are you planning to allow mobile devices in your company and realize you need a secure way of publishing the resources that the clients will access?
Well then I suggest you take a look at the Microsoft Forefront Mobile Configuration Starter book written by Fabrizio Volpe. In this book Fabrizio gives you an easy to follow guideline to get you started with using UAG as your mobile access solution. He also gives you many pointers to resources where you can dig deeper into the mystery of allowing mobile devices access to your internal resources.
I also recommend you take a look at my earlier post on how to use KCD to secure your infrastructure where i discuss how KCD can be used to secure mobile device access.
Erez Ben Ari and Bala Natarajan have written a new book about Unified Remote Access in Windows Server 2012. This explains how Direct Access in Server 2008 R2, combined with Forefront UAG, might be replaced by Unified Remote Access in Windows Server 2012.
Windows Server 2012 Unified Remote Access Planning and Deployment Book
You can get the book from Packt Publishing.
Microsoft have just announced that UAG 2010 SP3 will come in Q1 2013.
The SP3 will add support for:
A common question for all UAG administrators is if activating the configuration will affect users currently using the UAG.
Erez Ben-Ari (co-author of the books Microsoft Forefront UAG 2010 Administrator’s Handbook and Mastering Microsoft Forefront UAG 2010 Customization) have given a very clear answer to that question.
Normally, it does not. The exceptions are:
- SSL-VPN tunnels do get severed during an activation, so anyone using those will be disconnected and need to re-launch the tunnel.
- Occasionally, UAG might detect that IIS is not responding, and issue an IISRESET. That would effectively terminate all sessions. It’s pretty rare to happen, though.
- The labor involved with the process can make the servers less responsive to some degree. Usually, it’s barely noticeable, though.
Bottom line is that activating a new configuration should in normal case not affect the users running applications published in UAG.
If you enable Smart Card authentication in UAG you might run into a problem where UAG allows users access even though the Active Directory account is disabled. In this post I will show you how I solved that problem at a customer.
If you follow the TechNet guide to Configuring SSL client certificate authentication you will find that UAG will allow access to a user even if the account is disabled or locked in Active Driectory. As long as the certificate is ok and mappes to a user in AD it will allow access. At a customer of mine this was not the wanted scenario and they did not want to revoce the certificates either since certificates (Smart Cards) where distributed to vendors and other non-employees. They wanted to be able to disable the AD account and thereby denying access to the UAG portal.
The Solution
In the guide (step 7) you will find that you will make a copy of the repository_for_cert.inc template and rename it to the Authentication_Server_Name.inc. In that file the first function is called CheckCredentials looking like this.
function CheckCredentials(user_name,password)
if user_name = "" then
CheckCredentials = false
SendFailToAuthenticateMsg "Did not get user name"
else
CheckCredentials = true
end if
end function
What I did was to add a new function call to this function getting something like this.
function CheckCredentials(user_name,password)
if user_name = "" then
CheckCredentials = false
SendFailToAuthenticateMsg "Did not get user name"
else
Accountlock = CheckAccountlock(user_name)
if Accountlock = true then
CheckCredentials = false
SendFailToAuthenticateMsg "Account disabled in AD"
else
CheckCredentials = true
end if
end if
end function
The SendFailToAuthenticateMsg “Account disabled in AD” will show in the logs of UAG and will tell you why the authentication failed.
The new function CheckAccountLock gave me a problem. UAG does not run this as an account with access to AD. So I ended up creating a read-only service account I could tell my function to use to check the user account in AD. The final function looked something like this.
function CheckAccountlock(user_name)
Const ADS_UF_ACCOUNTDISABLE = &H0002
'create connection
set connAD = CreateObject("ADODB.Connection")
connAD.Provider = "ADsDSOObject"
connAD.Properties("User ID") = "AD\UAG_ReadAD"
connAD.Properties("Password") = "SomePassword"
connAD.Properties("Encrypt Password") = true
connAD.Open
'Search user
strBase = "<LDAP://DC=ad,DC=company,DC=com>"
strFilter = "(sAMAccountName=" & user_name & ")"
strAttributes = "sAMAccountName,userAccountControl"
strScope = "subtree"
strFullCommand = strBase & ";" & strFilter & ";" & strAttributes & ";" & strScope
set rsADUserInfo = CreateObject("ADODB.Recordset")
set rsADUserInfo = connAD.Execute(strFullCommand)
if not rsADUserInfo.EOF then
uac = rsADUserInfo("userAccountControl")
end if
if uac AND ADS_UF_ACCOUNTDISABLE Then
CheckAccountlock = true
Else
CheckAccountlock = false
end if
'Close
set rsADUserInfo = Nothing
connAD.Close
set connAD = Nothing
end function
I do think that there are more elegant ways of solving this problem. But time in this case was short and I was happy to have solved the customers problem. Feel free to comment if you have some ideas on how to improve this solution.
Today Microsoft released a Security Bulletin for UAG, this Bulletin is rated Important. As with all other UAG updates, these packages are not pushed out via Windows Update/Microsoft Update or any of the other automated patching mechanisms, this is because of the special order that needs to be followed for array deployments (array manager first and then rest of the nodes). Following are the relevant links: