The dilemma is: work life balance and I can tell you that this is hard equation…
I’m 11 days away from my blog and people might think that I gave up, but I didn’t. Actually yesterday I published an article on our team blog called Troubleshooting OWA 2007 Publishing Rules on ISA Server 2006. This post took me a lot of time to setup the lab, repro the most common issues that we have on this area and review it after all.
I’m currently working on other docs for our team and soon more articles will be published on ISA Server Team Blog. What about your own blog Yuri? I will also update, but probably just next week. I’m working on a trick ISA escalation and as soon as I find out the root cause I will blog that. Stay tune!!
For the Portuguese readers the news is that I just finish recording 3 videos for Microsoft TechNet Brazil about IAG 2007. Those videos will be available soon at Microsoft TechNet VideoCast.
The interesting thing that came up this week was an old question with a new shape on it:
Does ISA Server 2006 support FTP Secure? Because now IIS7 can do it, right?
No, ISA Server still not supporting Publishing FTP Secure and the official answer still on the article below:
Yes, IIS7 now can do this and here are a couple of good links on that:
Installing and Troubleshooting FTP7
Using FTP Over SSL
Well, that’s all for today. I hope next time I have a real technical post to publish it here.
The years working on Platforms and Networking were essential for me to build the foundation prior to migrate to the Security area. Regardless of the technology that I worked, most of the time I was dealing with situations where the customer wants to be secure while allowing access to the core network resources.
The scenario that I’m going to describe on this post was related to a really trick situation where only six users were having authentication problem on the 802.1x Wireless Network. Here the topology that was used on that case:
Figure 1 – Wireless Network.
As you can see, we have an unsupported operating system (Windows NT) on the environment which shows how heterogeneous the scenario was. On the infrastructure side, customer was using a Cisco and the servers were using Cisco Secure ACS for Windows. Those six users belong to the Windows Server 2003 Domain and all of them were located on the same OU. On that same OU we also had users that were not having problem at all.
To enhance the security on the network customer was using the 802.1x technology for wireless network. This technology comes originally from the 802.1x for wired network. The IEEE 802.1x is used to guarantee authentication on the link level (layer 2). This way the switch port where the computer is connected will stay in blocking state until the authentication is successfully completed.
For more information on 802.1x network review the article Understanding 802.1X authentication for wireless networks.
2. Collecting Data
Since we just have six users that were having problem, the first step was to use the LDIFDE command to dump the user’s properties. The idea behind this is to dump the properties of a user that works and the one that doesn’t work. Then compare the attributes and values. To do that the following command was used:
ldifde -f C:\User.ldf -d "DN" -p base
The DN (Distinguished Name) is the location of the user on the Active Directory. To find out this attribute you can use the ADSIEdit Tool.
After compare both accounts I couldn’t find any problem on the attributes and values that could lead to an authentication issue. The next step was to start a netmon capture and see what was going in the wire. The following steps were done:
· Installed Netmon on the Windows XP (Client), on the Windows Server 2003 DC and on the Windows 2000 Member Server.
· Enabled the RRAS Logging using the command netsh ras set tracing * enable. The logs will be added to the %systemroot%\tracing folder.
· Configured the switch that was connected to the access point to do a port mirror for one workstation.
· The CTEST\Bob user performed the logon on the Windows XP workstation.
Note: The same steps were done for a user that could successfully authenticate.
Here the traffic for a user that could successfully logon:
1. CiscoAP WindowsXPMAC EAP Request, Identity
2. WindowsXPMAC CiscoAP EAP Response, Identity
3. CiscoAP WindowsXPMAC EAP Request, PEAP
4. WindowsXPMAC CiscoAP TLS Client Hello
5. CiscoAP WindowsXPMAC TLS Server Hello
6. WindowsXPMAC CiscoAP TLS Change Cipher Spec
7. CiscoAP WindowsXPMAC EAP Success
8. CiscoAP WindowsXPMAC TLS Application Data
Opening the EAP header (frame 2) it is possible to verify that the user sends the credential:
Type: EAP Packet (0)
Extensible Authentication Protocol
Code: Response (2)
Type: Identity [RFC3748] (1)
Identity (17 bytes): CTEST\Will
On the EAP header (frame 7) we have the successfully negotiation message:
Code: Success (3)
Now, let’s see the traffic for a user that was not working:
1. CiscoAP WindowsXPMAC EAP Request, Identity
7. CiscoAP WindowsXPMAC EAP Request, Identity
8. WindowsXPMAC CiscoAP EAP Response, Identity
9. CiscoAP WindowsXPMAC EAP Request, PEAP
10. WindowsXPMAC CiscoAP TLS Client Hello
11. CiscoAP WindowsXPMAC TLS Server Hello
Clearly we can see that on this process we have multiple logon attempts without success. The interesting part of that was the customer’s revelation when he told me: if I don’t cancel this process the user account gets block on AD due the multiple bad logon attempts.
That was key information, this pretty much means that our package was going all the way up to the DC and trying to authenticate. However, for some reason that we didn’t know yet, it was failing.
4. Going further
Without a doubt netmon trace is something that helps a lot to understand the traffic. But, on this case we need something else to help us understand why was failing. Since we enabled the debug logs on the Windows XP we had the data that we need to figure that out. Looking to the files Wzctrace.log, Eapol.log, Netman.log and RASTLS.LOG located on the folder %systemroot%\tracing it was possible to determine that.
Let’s see the difference for a user that could logon for the one that could not logon in the file RASTLS.LOG:
- Successful logon:
 17:04:57:801: EapTlsBegin(CTEST\Will)
 17:04:57:801: State change to Initial
 17:04:57:801: EapTlsBegin: Detected 8021X authentication
 17:04:57:801: EapTlsBegin: Detected PEAP authentication
 17:04:57:801: MaxTLSMessageLength is now 16384
 17:04:57:801: EapPeapBegin done
 17:04:57:801: EapPeapMakeMessage
 17:04:57:801: EapPeapCMakeMessage
 17:04:57:801: PEAP:PEAP_STATE_INITIAL
 17:04:57:801: EapTlsCMakeMessage
 17:04:57:801: EapTlsReset
 17:04:57:801: GetCredentials
 17:04:57:801: Flag is Client and Store is Current User
 17:04:57:801: GetCachedCredentials
 17:04:57:801: PEAP GetCachedCredentials: Using cached credentials.
 17:04:57:801: MakeReplyMessage
 17:04:57:801: SecurityContextFunction
 17:04:57:801: InitializeSecurityContext returned 0x90312
 17:04:57:801: State change to SentHello
- Unsuccessful logon:
 16:58:02:568: EapTlsBegin(CTEST\Bob)
 16:58:02:568: State change to Initial
 16:58:02:568: EapTlsBegin: Detected 8021X authentication
 16:58:02:568: EapTlsBegin: Detected PEAP authentication
 16:58:02:568: MaxTLSMessageLength is now 16384
 16:58:02:568: EapPeapBegin done
 16:58:02:568: EapPeapMakeMessage
 16:58:02:568: EapPeapCMakeMessage
 16:58:02:568: PEAP:PEAP_STATE_INITIAL
 16:58:02:568: EapTlsCMakeMessage
 16:58:02:568: EapTlsReset
 16:58:02:568: GetCredentials
 16:58:02:568: Flag is Client and Store is Current User
 16:58:02:568: GetCachedCredentials
 16:58:02:568: FreeCachedCredentials
 16:58:02:568: No Cert Store. Guest Access requested
 16:58:02:568: No Cert Name. Guest access requested
 16:58:02:568: Will NOT validate server cert
 16:58:02:568: MakeReplyMessage
 16:58:02:568: SecurityContextFunction
 16:58:02:568: InitializeSecurityContext returned 0x90312
 16:58:02:568: State change to SentHello
 16:58:02:568: BuildPacket
Notice that the user is authenticating as Guest since there was no certificate available.
Since customer was not using user certificate to gain access to the system and using computer certificate only we could change the original behavior via registry change. What we did was to force each laptop that those users were using to use computer authentication only. The following registry key was changed:
The number 2 means: Computer authentication is performed when the wireless client computer is started. User authentication is never performed. For more information on that registry key review the article Wireless LAN Support in Windows: Frequently Asked Questions.
On those laptops this key was configured to 1, therefore the user authentication was happening and the user’s certificate on those laptops was corrupted.
Without a doubt one of the most powerful features that IAG 2007 has is the capability to allow full VPN access using a pure SSL connection. This feature is not available on ISA Server and the only other product that Microsoft has to enable this technology is the SSL VPN that comes with Windows Server 2008. If you want to learn more about the implementation of SSL VPN on Windows Server 2008, read the following article that my friend Tom Shinder recently published on ISAServer.org. The article is called Publishing a Windows Server 2008 SSL VPN Server Using ISA 2006 Firewalls.
The part 1 of my post will show how to configure IAG Network Connector on the server side. The part 2 will show how to establish the connection from outside and some troubleshooting tips.
2. Configuring Network Connector Server
The follow steps assume that you already have a trunk created to be used as your Portal entry point. The whole idea is to create a link on the Portal so the client can use to fully access the internal network.
1. Open the IAG Console, highlight the Portal , click in Admin and then click in Network Connector Server.
Figure 1 – Network Connector Server
Note: for the purpose of this demonstration, the external IP address of the IAG Server is a non-valid Internet IP Address (192.168.0.70).
2. After select this checkbox, the options on this window will be available. Click in the option Use the Following Connection and select the internal network adapter. If you leave the option Only if Network Configuration is Missing then the client that connects from outside will use the same DNS configuration as used on the internal NIC of the IAG Server. If you want to use a different DNS, WINS or Default Gateway, make sure to select the option Always, Overriding Existing Network Configuration of this Server.
3. Click in the IP Provisioning and select the pool type. Here is the definition for each one of the available options:
Corporate IP Address
Select this option to use the same IP range is the internal network of the IAG Server. Make sure to exclude the range from your internal DHCP Server. If the question is: Can I use my current DHCP Server to assign IP address to the remote clients, like RRAS and ISA Server do? The answer is: you can’t. This version of the IAG doesn’t support that.
Private IP Address
Use this option if you want to use another range (such as 10.20.20.0/24) for the remote clients.
4. For the purpose of this demo, we will use the option Corporate IP Address. Click in the Add button and add the range below:
Figure 2 – Adding the Corporate IP address.
Note: IAG will use the first IP address from this pool to the Whale Network Connector adapter.
5. Click OK and click in the IP Provisioning Tab. Here is the definition for each one of the available options:
Use this option if you want to allow the VPN user to access the Internet and the corporate LAN at the same time. The corporate access goes through the IAG and the Internet access goes through the user’s Internet access (user’s ISP). This is a good option on the performance standpoint, because the user will not use the company’s link to access the internet.
Use this if you want to control the Internet access on the remote client workstation. This option will allow you to restrict the remote user to access Internet, but will add an extra load on the company’s Internet link since all Internet traffic will pass through it. Optionally you can select the checkbox Disable Local Area Network Access to disallow the client to access the local company’s LAN.
No Internet Access
This option will disallow the remote client to access Internet.
IP Spoofing Policy
When enabled, this option will analyze the IP address to verify if this is a spoofed IP.
Allow an extra control on the TCP, UDP and ICMP packages. Be careful because this option is not granular, which means that if you select TCP then you will be blocking all TCP traffic through the VPN connection.
6. For the purpose of this demo, we will use the default options.
7. Click in Additional Networks tab and you will have the option to add other networks that the remote client can use it. Usually this option will be used when the company’s network has more the one IP subnet and you want to grant access to some or all subnets located within your internal network. In this case we will not enable this option.
8. Click in Advanced and the following options will be available:
Figure 3 – Network Connector advanced options.
9. By default the Network Connector’s Listener uses the TCP port 6003, but here you can change it. You also can change the log level from 1 to 5 (where 5 is the most detailed one). You also can change the log location and tune the server’s performance using the Server Resource options. Click in OK to finish the configuration.
10. Press CTRL + G to activate the configuration.
3. Adding the Network Connector to the Portal
Now that we have the feature already enabled, the last step on the server side is to add the Network Connector link into the IAG Portal. Follow the steps below to add that:
1. On the Application option click in Add.
2. Select the Network Connector option as show below:
Figure 4 – Adding the Network Connector link.
3. Click in Next.
4. Type the application’s name and leave the other default options selected. Click in Next to continue.
5. Leave the Server and Port options with the default option selected. Click in Next to continue.
6. Add a name for the application; this name is the one that will appear on the Portal’s web site. Click in Finish.
Now that the full network connector configuration is done, the window will show that IAG is trying to start the service:
Figure 5 –Network Connector service.
If you type ipconfig on the command prompt you will notice that the Whale Network Connector is now using the first IP from the pool that we configured earlier:
Figure 6 –Automatic IP.
On this post we saw how to configure the Network Connector Server and how to add the Network Connector entry on the IAG Portal. Next session will cover what needs to be done on the client side and also some troubleshooting tips.
There are many people that still having doubts about IAG and why IAG 2007 has the ISA Server 2006 on the same box. To understand that let’s see the diagram below:
Figure 1 – Software layer that involved on the way that IAG 2007 Server handles the traffic.
This figure shows the main components that are used on an IAG 2007 box and the processing order. Let’s see what it happens:
1. When the client workstation sends the HTTP GET Request while accessing the IAG portal the first thing that will happen is traffic hitting the NIC and the OS processing that.
2. Then ISA Server filter engine will intercept that traffic and see if that traffic is allowed or not.
3. Assuming that the traffic is allowed, the destination HTTP Server that will process the GET Request is the IIS Server. The IIS will see that who is supposed to handle this traffic is an ISAPI Filter/extension that is loaded on the site.
4. The ISAPI filter/extension loaded on the site is from IAG 2007 application. At this point, IAG will process the request according to the configuration policy that it has.
Note: By definition ISAPI extensions are DLLs that handle specific requests and ISAPI filters are DLLs that you can register with IIS to modify the behavior of the server. For IAG both functions are performed by WhlFilter.dll.
This is the basic flow that we are going to have when we are processing a request on an IAG 2007 Server. Based on that there are some common questions about those components working together:
Question: I know that there are problems when you have IIS and ISA Server on the same computer. How this work with IAG?
Answer: That’s true, but the IAG uses the ISA Server only as a firewall, the publishing rules are not created on ISA Server. Since ISA Server will not publish the pages (IAG will) you don’t need to worry about resource allocation problems.
Question: Since we have this dependency, this means that IAG will stop if IIS stops?
Answer: Yes, it will. IAG relies on IIS, in another word: if the inetinfo.exe process hangs, leak or crash the IAG will suffer the pain too.
Question: Can I create rules on ISA, publish other stuff on it?
Answer: Well, you can but it is not recommended to touch on the ISA Server that is installed on the IAG box. This ISA Server should not be used as another point of publishing, web proxy or caching. You should have another ISA Server in a separate box to do that.
Question: Can I create my web sites on the IIS that is located on the IAG box?
Answer: Yes, you can, but there are some caveats:
· You have to add the IIS web site on the IAG Application Server Configuration to make sure that IAG will not delete the web site from the IIS when it saves the configuration.
· On the performance standpoint you should be careful to not start to use your IAG box as a web server. If you think that you will then it is strongly recommended to use another IIS Server to do that.
Question: With the integration between those products, what happens when I create new trunk, publish the application and activate the changes?
Answer: What happen (broadly speaking) is:
· IAG Configuration is saved
· IAG Creates the site on IIS (for new trunk)
· IAG deletes IIS sites (if it the trunk was deleted or disabled)
· Rules are created on ISA Server
Figure 2 – The integration between the components.