In some ISA implementations authentication can prove to be quite complex.  It makes sense to try to keep authentication strategies simple, easy to configure and well documented, to avoid confusion at a later stage.  Authentication issues can be difficult to resolve if the steps below are not followed.  In this tutorial I will cover basic steps on how to resolve authentication mysteries.

1.       First thing is first install all service packs and hot fixes for ISA and restart your ISA server if it keeps asking for authentication and you have always been able to use the service previously.

This is a table that highlights some of the authentication issues that may occur

2.       Upgrade and update your web browser to the latest stable version. 

a.       To check your web browser version, open your web browser click on help and then click on about internet explorer.  The version will then be displayed.

In a recent article that Tom Shinder wrote The Web Proxy Service and Integrated Authentication he clearly demonstrates that sometimes the version of web browser can cause authentication to succeed or fail.

3.       Insure that your web browser is configured correctly and points to the correct ISA server that the authentication request will be coming from.

a.       At this point if you do not configure your web browser to point to the correct ISA server, you will not get authenticated and the web page or resource you are looking for will not be found.  Ensure that your web browser is configured correctly both for VPN and RAS connections as this is a common cause for authentication and browsing problems.

b.       If passwords are required you can also configure them in the settings screen. In your open Internet explorer 5.5 ad above click on tools, >then click internet options, > then click on connections, select your dial-up connection that you will be using, and then click settings.

You are presented with this screen here you can fill in both your ISA IP address and port number and your username, password and domain name.  If you are using LAN services remember to check Bypass proxy server for local addresses.

4.       Make sure if you have a routing rule to a chaining or downstream/upstream proxy that the authentication is working and that you can get through a basic authentication first.  If you can, you can then change the authentication type after backing up your ISA configuration in case you need to change back and don’t know how to.  It is good practice to backup your ISA server before any change. Contrary to popular belief the backup of the ISA server or array can reside on a network machine or share, and does not need to be on the local machine in order to be restored.

The authentication methods that ISA support are.

For another article that I have written on authentication click here

1.      Basic authentication

The standard HTTP authentication method.  A valid user name account needs to exist on the ISA Server computer or in a trusted domain of the ISA Server for authentication to succeed.  Your browser stores this password.

The diagram above depicts how basic authentication takes place.

2.      Digest authentication

The Digest authentication process is the same as Basic authentication but uses hashing and the original text cannot be deciphered from the hash.  This authentication method is only used in Windows 2000 domains. If you are running NT check that this authentication method is not turned on, a lot of people make this error.

The picture above shows where authentication can be changed. To get here right click your ISA server in the MMC > then click on properties > then click on outgoing requests > highlight your ISA server and its IP address > then click edit

3.      Integrated Windows authentication

This authentication method does not send user information across the network and uses either Kerberos V5 authentication or its own challenge/response authentication protocol.

4.      Please note: Integrated Windows authentication only uses a Microsoft browser

Do not use integrated authentication in a pass-through authentication scenario, ISA does not support Kerberos V5 authentication, because Kerberos V5 requires that the client be able to identify the authenticating server.

5.      Client certificates and server certificates

This authentication method uses SSL security features for authentication. Smart cards can be mapped in active directory to specific certificates.  Certificates are used in both client and server scenarios to prove to either the client or the server that the authenticating computer is in fact who it claims to be.  This authentication process can be very confusing in scenarios with hundreds of machines if it is not managed properly.  Once it is working do not fiddle with the settings further.  Make sure you back-up ISA server with the working config of the certificate scenario and in the description remember to label it such then store it on tape in case you need to revert back to it.

In some organizations Certificate authentication is the only way that that particular organization may authenticate, due to specifications required by a body or ISO standard that the organization may conform to.  In this type of environment you want to make sure that you do not mess this authentication up.  The only way this authentication can stop working is if the ISA server or certificate server is fiddled with.  All I can say here is back-up, back-up, back-up.  I know of many scenarios where the people fixing an authentication problem fully understand this type of authentication, but when fixing it due to its incredibly high priority no down time can be afforded.  Changes are made to try to rectify the problem and it renders the ISA machine not capable of working. This is where reverting to a back-up is so critical.  It saves time money and your neck.

6.      Pass-through authentication

This authentication type works in the following way when a request to be authenticated is sent to the ISA server the ISA server does not do anything but let the request pass through to the destination server and that server then deals with the authentication request as it sees fit.  The diagram below clarifies this.

7.      Chained authentication

This authentication type refers to when a request is sent through to the ISA server and the ISA server is chained to another upstream server the request is the forwarded to the upstream or chained ISA server and the authentication is then handled at that server.  Make sure that you know witch server is doing the authentication as this can pose quite a challenge if you are trying to resolve authentication issues on the wrong server.  Read the event logs to help identify witch server is failing to authenticate you.

Note: only machines running MS proxy 2.0 and ISA will be able to function as chained authenticators.

Make sure that if the client is being chained upstream and if he needs to be authenticated before his request is sent to the chained ISA server that his account exists and has the appropriate permissions to be proxyed through.  If ISA authenticates on his behalf and the ISA communicates directly with the chained server make sure that ISA has a valid account on the chained ISA server or chained domain to allow it to proxy for the clients behind it.

Mixing authentication.

The only authentication you can mix with web servers and ISA is Client/server certificates.  Other then that, do not use any other sort of authentication on the web server as it will not work.

Please note the above as when publishing internal web servers authentication can become a huge headache when authentication is mixed.  There are ways to get around this like using the Microsoft passport service but for now steer clear of any complications. If you are interested in the passport scenario click on this link http://msdn.microsoft.com/msdn-online/start/features/passport.asp

Confusing Authentication problems.

In many instances most people have confused authentication with a service that is explicitly denying them access to the resource.  Please note that if you are denied access to a resource it has nothing to do with authentication but with permissions to the resource.  An authentication issue normally identifies itself with prompt for user credential or with an error message stating that authentication has failed with the server.

A typical error that you will encounter is error 407 Proxy Authentication Required this means that the authentication has been denied because the user has no valid user account in the domain or that the password has been entered incorrectly.  The 401 error however displays an unauthorized error message this mean the user permissions to that resource are denied.  This error message tells you to look at the ISA server rules not at the way the authentication is handled

Below is a typical error message

HTTP 407 Proxy Authentication required – The ISA Server requires authorization to fulfill the request. Access to the Web Proxy service is denied. (12209)
Internet Security and Acceleration Server

Technical Information (for support personnel)

• Background:
  The gateway could not retrieve the requested page.
  
• ISA Server: isa
  Via:
  URL: http://www.google.com/
  Time: 2/9/2001 8:10:44 AM GMT
  
  
  

Summary: In this article I have shown you how the different authentication types function and also have pointed out some pertinent clues to help solve most authentication issues that may occur.  Armed with this information it becomes easy to conquer the technology.