I got some strange issues / problems while testing a Sophos UTM appliance with 9.004-34 software. The Web Security feature is filtering requests and using client authentication. The proxy is using Standard Mode with Active Directory SSO authentication. I testing the proxy by changing the proxy settings on a Citrix server. Everything was working without any problems. Next I tried some standalone workstations and laptops, including my own.
I wasn’t able to authenticate. I got an Authentication Failed in my browser and noticed the following entry in the Web Filter logging.
adir_auth_process_negotiate (auth_adir.c:311) gss_accept_sec_context: An unsupported mechanism was requestedNo error
I didn’t know where to look. I tried different things, like rejoining the Sophos UTM in Active Directory, rebooting the appliance and changing the proxy settings. When using the IP address of the Sophos UTM in the proxy settings the authentication mechanism NTLM is being used. When using the hostname or an DNS alias the authentication mechanism Kerberos is being used.
After some more testing I noticed that authentication failures only occurred when using Kerberos authentication. I did some more research on the internet and I found a lot of people complaining about this issues and blaming the “Windows Live ID Sign-In” component. My browser included this add-on. I disabled it in Internet Explorer, but that didn’t help. I stopped the service via msconfig, but that didn’t help either. Eventually I uninstalled the complete Windows Live Essentials suite from my laptop. This solved the problem!!!
Uninstalling the Windows Live Essentials component from the other laptops and workstations also resolved their problems. Till now I still don’t know why Windows Live Essentials “breaks” the Kerberos authentication process.
Creating a web server certificate request is very easy when using a Windows CA server. There is one disadvantage. The requested certificate is directly stored in the user store (by default) or the local computer store, if specified during the request. The disadvantage is that you cannot export the requested certificate including the private keys. During the request the option to Mark keys as exportable is grayed out.
There is a way to mark the keys as exportable when using a Windows CA server. You need to create a new Web Server Certificate template. You can use the existing Web Server Certificate Template as default and copy the current settings. To do so, you just:
That is all you need to do. You can now request a new certificate with the newly create certificate template. After the certificate is issued and installed on the user or local computer store, you can export the certificate including the private key.
A lot of appliances and/or security solutions use LDAP to synchronize users from an Active Directory or an eDirectory environment. Active Directory is LDAP enabled by default. If you would like to harden your network, you would like to use LDAPS.
LDAPS is a term to refer to LDAP communication over SSL. Intercepted LDAPS traffic cannot be read easily by hackers. In an Active Directory environment you need to have at least one Certificate Authority (CA) to enable LDAPS. Windows uses Server Authentication certificates for the LDAPS operations.
Last week I had a customer complaining that people weren’t able to access their webmail via a Microsoft ISA reverse proxy. The cause of the problem was an expired Server Certificate on the specific domain controller. The reverse proxy server uses LDAPS to authenticate the user against an Active Directory. The following event log was found on the reverse proxy server.
To resolve the problem I had to renew the Server Authentication certificate on the domain controller. I decided to use the “Windows method” by using the Windows CA to renew the certificate. From the domain controller with the expired certificate I opened IE and enter the URL:
http://<IP address CA>/certsrv
This opens the Microsoft Certificate Services webpage of the CA. The following screenshots show the request and installation procedure for the certificate renewal.
Normally I use OpenSSL to generate the certificate signing request, which is submitted to the CA. In that scenario I had to choose option 2. This time I decide to generate the csr via the webpage and choose the first option: Create and submit a request to this CA.
The csr is generated with the information from the screenshot above. Because I had to renew a Server Authentication certificate, I choose the Web Server certificate template. The Name field is very important and should match the FQDN of the LDAPS server. It is also important to select the Store certificate in local computer certificate store option. This ensures that the certificate isn’t installed in the user’s certificate store, because the certificate cannot be exported with private key.
When you submit the certificate request, you have to wait until the request is approved. The approval has to be done by someone who manages the CA environment. If you open the CA MMC snap-in you will see one or more pending request. The pending request needs to be approved. After the request was approved, I browsed to the Microsoft Certificate Services webpage, like shown below.
I choose the option View the status of a pending certificate request. Remember that I did the whole procedure on the LDAPS server to be sure that the certificate is stored in the servers local computer certificate store. The last step involves installing the certificate in the local computers certificate store. After the installation I always check the store to see if the private key is present for the certificate.
The renewal of the certificate is almost done. The LDAPS services depends on the process LSASS.exe. To “associate” the SSL certificate with the LDAPS server I needed to reboot the server. During the reboot the first valid Server Authentication SSL certificate within the local computer certificate store is used by the LDAPS server.
The reverse proxy server was able to use LDAPS again after the reboot of the specific domain controller.
Security is getting more and more important for people. I notice that especially IT manager would like to implement some kind of security measurements to improve the safety of their network and data. Lately I have been busy with configuring a Juniper SA solution. The customer wants to publish different kind of services through the Juniper SA to his employees or suppliers. Example of these services are file sharing and full IPSec tunnels. When using file sharing and full IPSec tunnels, the use of a virus scanner is arbitrary for all workstations connecting to the customers network through the Juniper. Juniper provides an option to configure a Host Checker to check if the client has a (specific) virus scanner. This kind of predefined check only works with Windows clients.
I wanted to configure a predefined Host Checker for all the Windows clients connecting to the Juniper SA box. The configured policy checks all Windows clients on a, by Juniper supported, virus scanner. This works perfectly, but I noticed at all Linux and Mac OS X users weren’t able to connect anymore. When configuring a Host Checker policy for Windows, you also have to configure a policy for other OS-users, like Linux and Mac OS X.
I didn’t know which policy to configure for these users, because the outcome of the policy check should be positive at all times. I have the option to check the presence of a specific file. This gave me the idea to configure a dummy file check for Linux and Mac OS X clients. The dummy file check has the following properties:
The policy checks the presence of the file mac_dummy_file. To pass the host checker test, the file should NOT be present of the client. I configured a similar rule for Linux clients. By configuring the policy like this, all Windows clients are checked on the presence of a virus scanner and the Linux and Mac OS X hosts are checked on the dummy file. Normally, the dummy file doesn’t exist on the specific Linux / Mac OS X clients, so they are always allowed access to the Juniper.
I guess it’s a nice workaround….
Microsoft IAS server is often used as RADIUS server to authenticate VPN users or in conjunction with ISA reverse proxy to authenticate OWA users or PDA synchronization.
Today I had to install an ISA reverse proxy server with ISA 2006 Standard and Exchange 2007. I wanted to install Microsoft IAS as RADIUS server to authenticate the OWA users. Normally I install IAS on one, but preferably, on two domain controllers. I logged in on a domain controller through RDP. I noticed that the OS of the domain controller was Windows Server 2008.
Cool, finally working with a Windows Server 2008. After getting familiarized with the new view and layout, I started to search for a way to add the needed Windows component IAS. After searching for a while I found how to add Windows component. Looking at the complete list, I couldn’t find the Internet Authentication Service.
Oops, did Microsoft remove the IAS functionality from its server platform??? After googling for a second, I found that IAS has been replaced by Network Policy and Access Server service in Windows 2008.
Microsoft TechNet told me the following:
Network Policy Server (NPS) is the Microsoft implementation of a Remote Authentication Dial-in User Service (RADIUS) server and proxy in Windows Server 2008. NPS is the replacement for Internet Authentication Service (IAS) in Windows Server 2003.
As a RADIUS server, NPS performs centralized connection authentication, authorization, and accounting for many types of network access, including wireless and virtual private network (VPN) connections. As a RADIUS proxy, NPS forwards authentication and accounting messages to other RADIUS servers. NPS also acts as a health evaluation server for Network Access Protection (NAP). Source
After installing NPS, I started the configuration. You really have to get familiar with the way Windows Server 2008 works. There are a lot of different wizard and multiple configuration options to choose from. Everything looks a bit more fancy. NPS is not only a replacement for IAS, but has also many enhancements.
More information about installing and configuration Network Policy Server can be found in the article Understanding the new Windows Server 2008 Network Policy Server on WindowsNetworking.com. Here you can read that NPS has a lot of functions related to Network Access Protocol (NAP). A very detailed example of using NPS to perform NAP can be found in Brian Posey’s series An Introduction to Network Access Protoction.