Last week I have installed a Microsoft UAG array. I installed Microsoft ForeFront Unified Access Gateway 2010 including Service Pack 1. When using an array configuration you have to deploy Microsoft’s Network Load Balancing (NLB) for redundancy and load balancing purposes. I configured NLB with multicast and IGMP support. I had configured some HTTPS trunks and some HTTP trunks for http-to-https redirection.
Everything was working perfectly and I decided to install the update KB2585140 (ForeFront UAG SP1 Update 1). The main reason for installation was the introduction of SharePoint 2010 with Office Web Apps and Lync web services publishing.
The installation process was easy and completed without any errors. I noticed that after installing the update I couldn’t activate any configuration changes. Everything I hit Activate I receive the following error message:
The Activation works again by deleting all HTTP trunks and only use HTTPS trunks. The customer started a support call with Microsoft and Microsoft acknowledges this behavior when installing the update on an array configuration. At first Microsoft advised to “break” the array and use a stand-alone server deployment. If that isn’t an option we should uninstall the update. We are told that the current configuration will get to the configuration state prior to the installation.
This morning the customer received another e-mail from Microsoft stating at more and more calls were logged with the same issues. The issues now has the highest priority for the Microsoft UAG developers. Microsoft couldn’t tell when the issue will be fixed, but I guess very soon.
So when using a Microsoft UAG array configuration DON’T install Microsoft UAG SP1 Update-1.
Using a Microsoft CA is very common in network to issue self-signed certificates. Last week I had to configure a Windows IIS server with client certificate authorization. Remote people (non Active Directory users) need a client certificate to browse to a specific website. The communication between the remote user and the website is secure by a default SSL web certificate.
The website is configured to require SSL and client certificate authentication. Within IIS I configured Client Certificate Mappings to authenticate the remote users. To create Client Certificate Mappings I had to generate client certificates. Client certificates can be generated by installing a Microsoft Certificate Authority. You can also use OpenSSL to generate client certificate, but this customers has a complete Microsoft Windows environment, so I decided to install a Microsoft CA.
You can install two kinds of CA’s:
A standalone CA does not issue certificates independent of administrator intervention. The reasoning for this is based upon the fact that a standalone CA doesn’t tap into a local or domain user account. Instead, it relies upon human intervention as a ‘last check’ method prior to issuing a certificate. Standalone CA certificates are also not distributed automatically, but further require a delivery method, such as group policy (for local domain users), or via further human intervention. For Web and Internet access, this is the type of CA to use.
The enterprise CA adds a new level of flexibility and ability to the certificate picture, but also added complexity. The Enterprise CA is integrated with Active Directory, and only provides certificates to members within that Active Directory. This pretty much kills the idea of having both an extranet or secure Internet communications along with secure local domain communications. Enterprise Certificates can, however, be used in a manner that falls within the ‘not often, but still really nifty’ category. Enterprise Certificates can be used to bypass repeated and redundant domain authentication, and when properly configured, can be used to further enhance the standard Kerberos authentication methods. Enterprise Certificates are automatically issued for every user account when it is created. The certificate itself, since it is a file, can be stored on any storage location and can still be valid. In keeping along this train of thought, it is possible to place a certificate on a card or plug-in device that can be used to authenticate a user during the normal Kerberos authentication process. These specialized devices are called Smart Cards, and while Smart Card implementation is somewhat expensive, several large corporations have implemented this technology as an added safety factor. […] Source
I decided to install a Standalone CA server, so client certificates can be generated with credentials from the remote users. When using an Enterprise CA, the client certificate contains the credentials from the Windows users who generates the request. The Enterprise CA requires Windows Integrated Authentication to perform a request.
Everything is working perfectly, the only caveat was the validity period of the client certificates. By default, the lifetime of a certificate that is issued by a Stand-alone Certificate Authority CA is one year. The validity period that is defined in the registry affects all certificates that are issued by Stand-alone and Enterprise CAs. For Enterprise CAs, the default registry setting is two years. I used the following procedure to change the default validity period from one year to two years.
I found this procedure in the Microsoft Knowledge Base and used it on Microsoft Windows 2003 and Microsoft Windows 2008.
It has been a while since my last post, but time is short these days.
Today I had to troubleshoot a Microsoft IAG appliance. Microsoft IAG stands for Microsoft Intelligent Application Gateway. And indeed, intelligent it is. NOT. I have seen and configured multiple SSL VPN solutions like Juniper SA, Citrix Access Gateway, Citrix Secure Gateway and Cisco WebVPN. But to be honest, Microsoft IAG is the worst of all.
Microsoft IAG is installed on an appliance and is closely related to Microsoft ISA 2006, which is also installed on the server. Whenever you make some configuration changes to IAG, you have to active the new configuration inside IAG. After activating the configuration, I looked at the new ISA firewall policies and I really couldn’t believe my eyes. IAG configured ISA automatically, when activating the configuration.
A simple portal, where 2 websites and OWA are published and a network connect (SSL IP VPN), results in approximately 10 firewall policy rules in ISA. Okay, I could live with that, but I shivered while taking a closer look at the rules. It is not easy to discover what purpose a specific rule has, without looking to the different tabs while editing the rule.
Besides the crazy management of the appliance, me and a colleague had a lot of problems when testing the appliance. Currently the network connector is not supported on Windows Vista and you receive a lot of (useless) errors when using Internet Explorer 8. The logging functionality is also very basic and hard to find. I had problems with configuring and testing the network connector with the non-split tunneling and disable local area network access option, I couldn’t find any useful logging about the problem. For some reason only specific traffic is routed into the VPN tunnel. I ended up configuring split-tunneling and only route specific network segments into the SSL VPN tunnel.
My opinion till now, Microsoft IAG cannot be compared with other SSL VPN appliances I have seen. I guess Microsoft IAG could test positive when using the appliance in a solely Windows environment, where only Windows services, like OWA and SharePoint, are published to the internet.
Maybe the solution is a lot cheaper compared with the Juniper and Citrix solution, but for know I would rather buy a Cisco ASA 5505 or Cisco ASA 5510. I would definitely not configure the Microsoft IAG as a cooperate firewall terminating the Internet connection.
One of our customers wants you use their locally installed Microsoft Outlook through a Citrix Access Gateway (CAG). Sales people from that customer travel through the country and use the Outlook offline to read or prepare e-mail to send later. These people use UMTS technology to connect their laptops to the Internet. The customers wants these sales people to have the ability to use their Outlook offline and actually send/receive mail when connected to a network with Internet access.
The customer is using CAG’s to publish multiple services to the Internet, so together with my colleague Edwin Houben from DigiPulse, we started to look at a suitable solution. The CAG is located behind a CheckPoint firewall and traffic to the internal network needs to go through an ISA server firewall.
First we started to look at the ports Microsoft Outlook uses to connect to the Exchange server. Looking at the settings from a laptop, the connection is made by FQDN of the Exchange server. While performing a netstat -na we noticed that Outlook uses two ports to connect to the Exchange server.
The Outlook clients connects to the Exchange server on FQDN. So the laptop needs to have an IP connection to the Exchange server. So we decided to use the Citrix Secure Access Client to give the user the ability to establish an secure IP connection to the network.
Looking at the customers network, we had to configure access-lists on two locations to make the solution more secure. The first location is a Network Resource in the CAG. The Network Resource enables only the above ports to the Exchange server IP address. The second location is allowing the IP address of the CAG to connect to the Exchange server on the above port numbers through the ISA server.
After configuring both access-list, we did some testing and the solution works perfectly. You can now use the laptop on the internal network and externally with the Citrix Secure Access Client without making any changes in the Outlook configuration.
Later, the customer noticed that he couldn’t use Microsoft Outlook anymore in conjunction with the Citrix Secure Access Client. After digging a bit deeper in the traffic flow between Microsoft Outlook and the Exchange server, I noticed that, beside TCP/135, random ports above 1024 are used. So I changed the Network Resource and the ISA servers to allow TCP/135 and the range TCP/1024-2000. I haven’t used the complete range of registered port numbers, so I hope Exchange doesn’t use a port above TCP/2000.
I didn’t some Googleing (or Googling or whatever) on TCP port 135 and I found some “funny” things:
Some well known Root kits also use this port to transmit data back to home base and download more malware. I also suspect may be an entry point for some root kit /malware for un patched systems or systems that did not patch correctly. Source
Currently inbound scans are likely the Nachi or MSBlast worms. Source
The problem with port TCP 135 is that it is used for multiple services, which are listed below. So blocking port TCP 135 could affect communication between devices or the usage of services.
|Client/Server Communication||DCOM||DHCP Manager|
|Exchange Administrator||Microsoft Message Queue Server||RPC User Manager|
|RPC Service Manager||RPC Port Mapper||SCM used by DCOM|
|SQL Session Mapper||WINS Manager|
Today I have be working on publishing Microsoft Exchange Outlook WebAccess and Active Sync to the Internet. We had some discussions with some Microsoft Consultants about a secure way to publish Outlook Web Access to the Internet, especially the authentication part of such a solution.
Some people are talking about publishing OWA directly to the Internet. In my opinion, this results in a major security thread, because you directly publish a TCP/80 and TCP/443 connection from the Exchange server to the Internet. An vulnerability or exploit in these services could end up in an hacker who takes over the Exchange server.
A second solution is placing a front-end server in a DMZ segment, but making the server a domain member for authentication. In my opinion still a security leak, because somebody who hacks the DMZ server has maybe the ability to hack or corrupt the Active Directory.
The third solution, and the solution we advise, is using a Microsoft ISA 2006 server as a front-end server in the DMZ. We configure a RADIUS or LDAPS (if you would like the option to change the password) connection to a RADIUS server or a domain member on the internal LAN segment. This ensures a secure way of authenticating users and even if somebody hacks the ISA server, he still hasn’t hacked a domain member server or a vulnerability in TCP/80 or TCP/443 of the Exchange server.
I have had a lot of help of an article on isaserver.org from Thomas Shinder while configuring the solution. I had some problems with publishing Active Sync. Ended up with enabling Basic Authentication on the Active Sync virtual directory (Microsoft-Server-ActiveSync).