Designing a web publishing

infrastructure with Microsoft ISA

Server and Gemalto SA Server

Based on One Time Password (OTP)

technology
By Frédéric ESNOUF, ISA MVP

www.gemalto.com
 Executive summary

In the last 10 years, IT infrastructures have changed a lot especially with the expansion of the World Wide
Web. These changes touch several aspects of the enterprise infrastructure. Here is a quick list of the
most important ones:

• The way we create applications: more and more applications are accessible via a basic
Internet browser. Technologies such as HTML, XML and of course HTTP are now widely
used to publish enterprise “key” applications.
• The way users’ access to these applications: while telecommunication costs are
decreasing, the Internet infrastructure is expending day after day. From home, airport, or
train, our users can now reach the Internet from almost everywhere in the world. Mobility
is now a reality.
• Security: because of all these changes, securing the data and private network is more
and more complex. More precisely, the “cures” of the past (firewalls, antivirus software
etc.) are not sufficient anymore and we need to understand each stack of the design to
secure the entire service. Authentication (and more important strong authentication) is
one of the most important “security” aspects.

In order to provide a “secured” and powerful infrastructure, we need to work on many different subjects
from the most technical to the most organizational. The ISO 17799 standard can help you to divide this
big and complex “security” term in smaller “sub security subjects” and so, simplify your vision of security
in the project. One of these ISO chapters concerns authentication and our ability to make sure that
nobody will be able to fake the system and steal valuable data.

One of the aspects to secure an application is the way we can identify the user requesting this access. As
soon as this user is authenticated, we can give him/her access to what he/she is entitled to see, and not
more, which could compromise the security of the entire application. For many years, robustness of an
authentication system was based on its ability to resist to attacks such as dictionary or brute force.
Nowadays, there are a lot of new techniques to “steal” users’ credentials without being a security agency
with super-computers. Login and password are not anymore sufficient to “authenticate”, and
authentication needs to move from “what I know” (a login and password) to “what I know AND what I
have” (a login, a password, and a strong authentication system such as a smartcard or a token).

Figure 1 – Our challenge: Authenticating Everyone, Everything and Everywhere

2 Version 1.1
© Gemalto, Inc. 2007
 In this white paper, you will see how to implement Gemalto Strong Authentication (SA) Server, the strong
authentication system designed by Gemalto based on One Time Password (OTP) technology. In our
scenario, we will demonstrate the use of Gemalto SA Server with Internet Security and Acceleration
Server 2006 (ISA Server 2006), the Microsoft product used to publish enterprise application.

Whereas SA Server will provide some strong authentication with a One Time Password (OTP) Token, ISA
Server will publish the web application and inspect the data to see if any malicious code could
compromise the security and integrity of the company.

Figure 2 - Gemalto SA Server Smart Card Device portfolio

About the author

Frédéric ESNOUF is the manager of a security team at PI Services, a Microsoft Gold Partner based in
Paris.

As a Microsoft Most Valuable Professional (MVPs) on Microsoft ISA Server, he is the author of several
books and has extensive experience on “mobility” architecture. He also worked closely with the Gemalto
engineering team, especially on SA Server.

Implementing the Strong Authentication Solution

In this document, we will describe how to install the Gemalto products on Microsoft-based infrastructure.
To do so we will use the Microsoft Virtual environment available for download online at Microsoft.com.

Some of the components require an evaluation key to be activated. To get your activation key or if you
have any questions regarding this white paper, please contact us at: SASolutions@gemalto.com

3 Version 1.1
© Gemalto, Inc. 2007
 Table of contents

DESIGNING A WEB PUBLISHING INFRASTRUCTURE WITH MICROSOFT ISA

SERVER AND GEMALTO SA SERVER .................................................................... 1
Executive summary.................................................................................................................................2

About the Author .....................................................................................................................................3

Implementing the Strong Authentication solution ..................................................................................3

Table of contents.....................................................................................................................................4

How to read this document .....................................................................................................................6

Connecting a “Web-Based” application in the enterprise .......................................................................6

Publishing the enterprise applications: basics ........................................................................................7

Publishing Web applications: The HTTP protocol ..................................................................................8

What are the risks in a mobility architecture ...........................................................................................9

Introduction to strong Authentication with OTP Token .........................................................................11

How OTP works in detail?.....................................................................................................................12

User, ISA, Protiva: How the credentials are transported? ....................................................................14

Evaluating and testing SA Server: The Microsoft Virtual environment .................................................15

Gemalto SA Server architecture: overview ...........................................................................................16

Implementing Gemalto SA Server on Microsoft Virtual Environment ...................................................18

Istanbul Parameters ..............................................................................................................................18

Introduction to ISA Server, and his “Reverse Proxy” capabilities .........................................................18

ISA: Creating a Web Listener................................................................................................................19

Modifying the Web Radius authentication page....................................................................................20

Implementing IAS service on “Denver/IAS” ..........................................................................................23

Implementing Gemalto SA Server (application and IAS driver) on “Denver/IAS”.................................24

4 Version 1.1
© Gemalto, Inc. 2007
 Table of contents (continued)

Authenticating Gemalto SA Admin portal for the first time....................................................................27

Registering an OTP Device/Association with an AD user ....................................................................28

SA Server and the end-users................................................................................................................30

Why Gemalto ? .....................................................................................................................................30

Table of Figures ....................................................................................................................................32

Glossary (SA Server/Gemalto) .............................................................................................................33

Glossary (ISA).......................................................................................................................................33

5 Version 1.1
© Gemalto, Inc. 2007
 How to read this document
Understanding and implementing a solution are never easy. This white paper will explain what the threats
in a Web Publishing scenario are and why strong authentication is mandatory to secure the entire
infrastructure.

Then, we will discover what strong authentication is, what is One-Time Password Technology (OTP) and
what are the components to implement.

Finally, we will see the parameters we have to implement on ISA server to put this solution in production.
As you will see, it will be very user-friendly.

Connecting a “Web-Based” application in the enterprise

Most of the Enterprise applications (Messaging, Sales, Accounting …) are now “web-based”, which
means that the only component you need on your client machine to access these applications is a Web
browser, such as Microsoft Internet Explorer.

These applications can be accessed on the private network, but also from anywhere in the world, using
the Internet network.

To do so, companies need to implement an architecture to interconnect their private network to the
Internet, and to provide some security services such as authentication, data inspection,.. .etc.

In Microsoft architecture, Internet Security and Acceleration Server 2006 (ISA Server is designed to
provide all the services to the enterprise. In the acronym ISA you have the notion of “S”ecurity but also
the vision of “A”cceleration which means that the machine will provide some features to speed-up the
connection, and provide a better service to the end-user.

A “standard” architecture to publish internal web application to the Internet is generally a sum of 3
important components:

• The remote user: he is using a web browser from a company’s machine, a private
machine (home) or a public one such as airports or web-café.
• The web application itself: installed on the private network, it provides some access
using the HTTP protocol.
• A gateway (usually an “application layer firewall”): used to interconnect the
Internet to the private network, authenticate the user, secure the traffic and publish
application.

Now let’s see what “securing a web application” means.

6 Version 1.1
© Gemalto, Inc. 2007
 Publishing enterprise applications: basics
Enterprise applications are primarily located on the private network of the company. It could be a financial
application, a messaging system, … etc. Because most of these applications provide some Web
interface, the IT team will have to implement mobility gateways to publish these applications.

A mobility gateway is a product such as Microsoft ISA server that has the ability to publish a Web
Application (also called Reverse Proxy) based on security rules such as user authentication and URL
inspection.

The most common scenario (or these if you need high availability) is to implement a mobility gateway on
the “Edge” of the company (directly to the Internet, or in a Demilitarized Zone – DMZ). The following
diagram illustrates this infrastructure:

Enterprise
applications
App A App B

HTTPS Internal Network

Remote The Internet
users

Authentication
Gateway

Figure 3 - A basic web publishing architecture

The Authentication server will be used by the Gateway to authenticate the users, which means validate
their credentials.

7 Version 1.1
© Gemalto, Inc. 2007
 Publishing Web applications: The HTTP protocol
The data exchanged between the remote machine and the Gateway is transported using an HTTP
connection.

On the diagram below you can see an example of a network frame. This frame represents a good
example of an HTTP conversation.

Physical, IP and TCP part of frame

HTTP part of the frame

Figure 4 - A basic HTTP network frame

The IP and TCP protocols will transport frames from the remote machine to the mobility server (Gateway).
The HTTP portion of the frame will be handled by the web application. In this example, I have visited the
Gemalto’s web site, and “clicked” a link to download a brochure about one of the OTP tokens called SA
570. My “click” generated a flow of data from my machine to the remote server. My machine sent an
“HTTP GET” (which means “give me this document”) request to the remote server, requesting “SA
570.pdf” file. In return, the server will send this document back to me, and the web browser will display
the content.

In this example, the published information (the brochure) can be downloaded by “anyone”, so is not linked
to any kind of credentials. If you set the appropriate permissions on the server (either on the document
itself or directory where a list of file is stored), you can force the user to provide credentials prior to
sending back the requested document.

The web browser would get in return an HTTP error (authentication requested) and I will be asked to
provide some sort of credentials. Once this answer is received by this browser, a popup message
appears on my screen, requesting these credentials to the user. Usually, the user provides their login
name and password.

8 Version 1.1
© Gemalto, Inc. 2007
 *
Figure 5 - A basic login popup window

In this example, accessing the data (which could have a great value for hackers) is linked to two text
information fields: the login user name and password.

What are the risks in a mobility architecture

In order to provide this service, the IT team must design the infrastructure to publish the enterprise
applications. Because these applications are business-critical most of the time, the team will need first to
identify the risks involved by these new and crucial services.

In order to identify these risks and the solutions), we usually use a methodology called risk “analysis”.
This is in fact a 3 steps approach:

• Step 1: identify the risks.

o Example, steal the user’s credentials.
• Step 2: the “probability” to have this attack.
o Example, if 100% of the users are using corporate computers we could imagine
that this particular risk is low. On the other hand, if most of the people connect
the internal network via Web Cafés, this risk is extremely high, because they are
potentially running hacking components such as key loggers.
• Step 3: The impact.
o If this risk happens, what is the “Impact” for my company? Is it just a little
problem or it may drive the company to bankrupt?

The ratio between “probability” and “impact” will guide you in your project.

Using thins “risk analysis” method helps to understand the risk and prioritize them. It is usually a good
moment to brainstorm within the team, which helps to have everybody involved in security, in the same
direction.

If we look at web publishing scenarios, here is a quick list of the most common risks we have to face.

Risk 1:
This is not the purpose of this white paper, but the HTTP traffic can transport some good data, but
also some very bad ones (attacks). For example, a bogus Web application could receive some sort of

9 Version 1.1
© Gemalto, Inc. 2007
 data generating a failure in the application, and exposing some major security problem. A good example
of that is the use of “the value of characters” rather than the characters themselves. Here is an example
of the same URL:

• http://myserver/My Dir/My File.htm : A normal way to code this URL.

• http://myserver/My%20Dir/My%20File.htm : a “character value” way to do it.

As you can see, the URL contains some “spaces” in the name (My<space> Dir). The first example shows
you a normal way to write the URL. The second one uses another technique authorized by the web
technologies (HTTP, HTML …). Rather than providing a real “space” for this character, the URL contains
the ASCII (value of this character) code of space which is 20 hexadecimal (32 decimal). Why do that?
Well, in the past some web applications were bogus. Presenting a “coded” version of the URL could
compromise the security and expose some security holes. For example if the administrators said “only
people who are members of ‘accountancy’ group can reach ‘http://myserver/My Dir/My
File.htm’”, some web engine could be faked using ‘http://myserver/My%20Dir/My%20File.htm’. This
bug is fixed now but it shows that inspecting the flow of data is mandatory.

Solution 1: provided by ISA, via an HTTP application filter

ISA server is an “application-layer” firewall which means that it embarks in the core of the system
some specific software components. Each of these components knows a protocol in details. In the HTTP
attack scenario, ISA can inspect each part of the HTTP payload and authorize/refuse/modify some
characters. When ISA will receive ‘http://myserver/My%20Dir/My%20File.htm’ it will do a “normalization”
which means it will modify this URL to get http://myserver/My Dir/My File.htm. This way, if a server is
under attack from a rogue client application it will always receive consistent and attack free urls.

Here is another example. If a web application is supposed to deliver some documents (Read) but not
receive any information, only the HTTP GET method will be authorized, and not the HTTP POST one.

Risk 2:
The credentials supplied by the remote users are one of the most important keys for network
“security”. If for any reason someone can get this information, they can easily access the data. More
important, these “Web” credentials could be used for other systems in the company, for example
connecting by VPN which could provide full access to the internal network. Also, a lot of people think that
the only way to get these credentials is the ability for the hacker to “break” the system used to cipher the
data, but it is not true anymore. For example, “key loggers” capture all the data sent by the user to the
computer by intercepting the dialog from the keyboard (keystrokes). They could be software or hardware
components (a tiny token connected at the rear of a web-café computer for example), and they send
these keystrokes to a hacker in real-time. This bad person could be located on the other side of the
planet.

Solution 2: Provided by Gemalto, SAS One Time Password solution

Because there are so many techniques to “steal” a login and a password, you must add to the
authentication process some sort of “hardware” component such as a One-Time Password key or a
smartcard using certificates. With this approach the user must know a login, a password, but also have a
smartcard device that will generate the last part of the authentication process. Even if a hacker can get
the two first ones, he will never be able to copy the content of this smartcard token, and so will never be
able to “fake the system”. In this scenario, the only way to hack the system is to also steal the token itself,
and this is why training the user is also very important (what to do if you lose your token: call the hotline
that will deactivate it ! ).

The Gemalto SA server offers a real-time option for lost/stolen smartcard devices. Its User-care portal
enables users or administrators to deactivate the device immediately through the web portal.

10 Version 1.1
© Gemalto, Inc. 2007
 In our scenario we said that we use an HTTP connection. In fact, we use an HTTP “s” one which stands
for “HTTP Secured”. This little “S” means that we have asked the remote server to cipher all the data sent
and received during the transaction. This encryption is done by other protocols such as SSL or TLS. It is
important to know that this encryption protects the data from the “workstation network card” to the
“Gateway network card”. This is not a solution to prevent key loggers or other kind of malicious software
that could be used to steal important data. These malwares can intercept this data before it is passed to
the ssl/tls stack because they are running hidden on the computer.

Introduction to strong Authentication with an OTP Token

As we said, login and password are not sufficient anymore. There are many techniques we could use to
steal or break that protection. The easiest way would be to install a “Key Logger” on a public machine and
wait for a user. When this user reaches an important web site (a bank portal for example) and provide the
credentials, this “key logger” will intercept all the keystrokes, store them on the hard disk and regularly
send them to a hacker located somewhere on the World Wide Web. A few minutes later, this bad guy
could use the credentials. There is absolutely no way for a user to detect this kind of malicious application
on a public machine, event at home !

“What you know” (login/password) is not sufficient anymore, so we need to introduce another factor to
reach strong authentication: what you have (A physical device)!

In this documentation we would like to focus on one “strong authentication” system called OTP which
means One Time Password. As you will see, it is easy to use and easy to implement in most of the
scenarios. This means that with a small effort, we can reduce the risk of credential theft.

An OTP is a 6-digit number generated for you by a hardware device such as a token. When users wants
to authenticate, they press a button on this device and a “random” number is generated. This is not a
magic number but the result of a cryptographic calculation done by the smart card module inside the
device, linked to a “secret” stored in it, and that cannot be reproduced by any other device.

Once the number is displayed on the device, the user will be able to provide the 3 pieces of the strong
authentication scenario: the login name, the password, and this OTP.

But how this OTP is generated? When the user presses the button, the token makes a complex
calculation using the OATH Algorithm (Open Authentication), where one of the variables is a “secret”
stored in the smartcard device. The result of this calculation is the OTP, and it is sent to the server-side
component of the Gemalto SA server, the Gemalto implementation of One Time Password Technology.
SA Server computes the same calculation (it knows the secret too), and compares the 2 OTPs. If they are
the same, it means that the user used the appropriate device to authenticate to the server.

Without the token, even if you know the login name and password of a user you will not be able to
authenticate. This means, that if you can hack a system, and “capture” the login, the password and the
OTP during an authentication, you will not be able to replay the authentication: As a matter of fact, a few
seconds later the OTP is 100% different, and there is no way to calculate the next or the previous one.

11 Version 1.1
© Gemalto, Inc. 2007
 Here is list of devices that you can find on the Gemalto’s portfolio. As you can see, the same technology
is used in different types of devices, which covers most of the enterprise’s use cases:

Easy OTP Token Token+USB+ SA USB OTP Token SA .NET IM Card &
Secure Storage Easy OTP Reader

Figure 6 Figure 7 Figure 8

Figure 9

Usually, users have this token with their key and so make sure that no matter where they go, they will
have this strong authentication key with them. It is important to notice this OTP approach is very efficient,
but also very easy to use for a user. It means that this strong authentication architecture does not require
any training at all: a basic memo or a 5 minutes webcast will be sufficient, reducing the cost of the
implementation.

How OTP works in detail?

The OTP mechanism used by Gemalto is pretty simple. A cryptographic algorithm is used to generate a 6
Digits number called “One Time Password”. This is one time because one of the variables (the counter)
used to make this calculation changes every time you press the button.

The two variables used by this algorithm are:

• The “secret”, stored in the token but also stored in the SA Server application located on the
server-side,
• A “counter”, which changes every time the user presses the button of the token.

12 Version 1.1
© Gemalto, Inc. 2007
 Here is a more detailed diagram:

Figure 9 - OTP and Math

What is SHA 1? SHA1 is a hash function created by the National Security Agency (NSA). SHA stands for
Secure Hash Algorithm. Hash algorithms compute a fixed-length digital representation (known as a
message digest) of an input data sequence (the message) of any length. Hash algorithms are very useful
because:
• If you know the digest (result of the hash function) it is impossible to know the original message,
• If you change a tiny part of the original message, you will get a totally different digest.

Here is an example:
Message Sha1 result
thisistest1 bd877ed733c0b7b8664cbd29304010644790556f
thisistest2 2a2b413eb407ea0d6b9dad33538347b39af277ad

HMAC-SHA1 used by the Gemalto tokens is in fact an algorithm (keyed-Hash Message Authentication
Code) using SHA1 as the hash algorithm.

It is important to notice that this calculation will take place in the token and also on the server-side. The 2
components will do the same calculations. The server side will compare the OTP received from the token,
and will compare it with the one it has generated. If they match, it means that authentication is positive.

The result of this calculation can be a 6- or 8-digit number, depending on your architecture. You can see
here that the “counter” is a key component in this scenario, which means that if you press the token
several times without authenticating, your token “counter” could be desynchronized with the “server-side”
counter.

13 Version 1.1
© Gemalto, Inc. 2007
 There are 2 solutions to face this problem:

• First, you can define a “tolerance” on the server side which means that if the token counter is “in a
range of server-side counters” the authentication is accepted. In this scenario, the Server
application will calculate your OTP but also your OTP+1, OTP+2, …OTP+<tolerance>.
• Second, in case of de-synchronization, the user can reach the Gemalto web interface published by
ISA Server. On this page, there is a user friendly form where the user can “re-synchronize” the
token himself, providing an effective service to the user and reducing the administration cost (not
hotline needed).

This feature provided by SA Server is very important because it makes sure that the user can reach the
application pretty quick, but also, that your support team will not get some extra work for this kind of basic
problem. With this approach, security and flexibility can be combined.

Information: If you want to go a little bit deeper in the OTP technology (and related protocols), we
recommend these readings:

• http://www.openauthentication.org/pdfs/HMAC_OTP_DRAFT_4.pdf
• http://www.ietf.org/rfc/rfc2104.txt
User, ISA, SA Server: How the credentials are transported?
The authentication mechanism requires the transportation of the credentials from the remote machine to
the authenticating application through the gateway. In our scenario, there are in fact 2 steps:

• The user sends the credential to the application (ISA Server) requesting them. In our scenario,
ISA Server will ask the user to authenticate prior publishing any application.
• The Application (ISA Server) asks to an authentication server Gemalto SA Server) if the
credentials are valid, and who is this user.

The communication between the remote user and ISA will be transported and secured by HTTPs. When
the user will click the “connect button”, an HTTP command called “POST” will send the data through this
HTTPs connections. Parameters (login/password/OTP) will be part of the URL sent by this POST
command to the server.

http://portal.company.com/login.asp?UName=theloginname&UPass=thepassword&UOtp=123456

Once the credentials have arrived on the ISA server which acts as a Mobility Gateway, ISA will send
these credentials for verification to an authentication server. It will use the Radius protocol to transport
them to the Authentication Server.

Here is a diagram that shows this dialog:

HTTPs Radius

Login+Password+OTP Login+Password+OTP
The Internet Mobility Gateway
Remote users Authentication

Figure 10 - How authentication is transported

14 Version 1.1
© Gemalto, Inc. 2007
 As you can see, the authentication data are not changed at all, only the protocol use to transport them will
be different.

For your information, Radius is a AAA (said ”triple A”) protocol used to transport the credentials from a
Radius Client (ISA Server) to a Network Access Server or NAS (our Radius Server). Radius
authentication is supplied by Microsoft via the Windows IAS service.

It is important to notice that because Gemalto SA Server is based on standard protocols, the
infrastructure is very easy to implement, and can cope with all enterprise scenarios, Microsoft and non-
Microsoft ones.

Let’s see now how we implement this infrastructure. To simplify the evaluation, we will use the Microsoft Virtual
environment available online. This environment contains all the components we usually encounter in the company,
and we will implement Gemalto SA Server components on the same machines.

Evaluating and testing SA Server: The Microsoft Virtual environment

By reading this white paper you will be able to see how to implement Gemalto SA Server OTP solution on
Microsoft ISA server.

In order to show you how to implement this solution, we used the Microsoft “Virtual” environment
available online. This environment contains all the Microsoft components (Active Directory, ISA,
Exchange, SharePoint, …) based on Microsoft virtual technology.

You can download it (it comes as a big Zip file) on your hard disk, and start each Virtual Machine (VM)
you need, depending on your scenario. This big file is available on Microsoft’s web site at
http://www.microsoft.com/forefront/edgesecurity/iag/trial.mspx and then select “Check out the Forefront
Edge Security and Access Demonstration Toolkit”.

Here is a diagram of the entire infrastructure supplied by this virtual environment. This infrastructure
represents the “ISA” scenario, and it is important to notice that there is the same one for IAG (Intelligent
Application Gateway), the new VPN/SSL solution of Microsoft.

Figure 11 - The Microsoft Virtual Machine environment, ISA Server scenario

15 Version 1.1
© Gemalto, Inc. 2007
 For our lab, we will only use 3 of these machines of this global infrastructure:

Figure 12 - VPCs supplied by Microsoft in the ISA scenario

• Paris will be our ISA Server 2006: This server is connected to the private network and also to the
Internet. This machine will be used to authenticate the users “on the edge” using the Gemalto
OTP token. Then, ISA will publish this application and will act as an application firewall by
inspecting the Http traffic.
• Denver will be our Domain Controller: This machine contains all the users and group objects of
the Active Directory. This machine will also be used by the ISA Server to authenticate the users.
We will install the Windows Radius service (IAS – Internet Authentication Service) but also the SA
Server application.
• Istanbul will act as the client machine: This machine is supposed to be connected anywhere on
the Internet, representing the remote user.

This Virtual Lab is extremely efficient to evaluate the product and validate an infrastructure. It also saves
a lot of time. We estimate the time to implement this white paper at 30 minutes.

Gemalto SA Server architecture: overview

Gemalto SA Server is the software used to manage the OTP devices and to add strong authentication.
Gemalto Engineers have created SA Server to work in many scenarios that can cope with most of
constraints. In this white paper we will only describe one in order to present the design approach and the
components involved.

In case you have any questions about other kind of scenario, please contact sasolutions@gemalto.com.

A “strong authentication” architecture in a Microsoft environment contains these three elements:

• The remote machine: The user will be prompted to provide a login, a password and a Onetime
Password.
• The ISA Server connected to the edge of the company, acting as the mobility Gateway: ISA
will be the component requesting the remote user to authenticate and the one that will ask SA
Server and Active Directory if the credentials are ok.
• An authentication server, running Windows 2003 and the Windows IAS Service (the Radius
service) will be the authentication server. On this same machine we will install 2 other
components supplied by Gemalto/SA Server 1) the “Gemalto Radius Agent” which will interact
with the IAS component and 2) the SA Server application itself, used to manage the token and
authenticate.

Important: We have implemented all these services on a single machine for the purpose of this white
paper. In a real infrastructure, we would probably split the services to provide performance and high
availability.

16 Version 1.1
© Gemalto, Inc. 2007
 Here is a high level diagram that describes the different phases that take place during the authentication
phase. As you can see, each service will have its own role in this process:

Active Directory Protiva ISA Server Remote User

IAS Radius . HTTPs
Server Server
Server

DENVER PARIS ISTANBUL

Login, Pwd & OTP
HTTPs POST

Login, Pwd & OTP

Radius

Check Login/Pwd

Check OTP

User is authenticated on ISA. He can reach the application or the enterprise « portal »

Figure 13 - What is an authentication process with OTP

• Phase 1: the user provides to the web authentication interface (displayed by ISA Server) a login
name, a password, and the OTP number displayed on his token. By clicking the “connect button”
on this web page, this information is sent to ISA via an “HTTP POST” command, encrypted by
HTTPs.
• Phase 2: ISA Server receives these 3 pieces of information. ISA knows that it has to send these
credentials to a Radius Server. Radius authentication mechanisms are provided by the Windows
Internet Authentication Service (IAS) component.
• Phase 3: the Radius Server (IAS) receives this data and sends it to the Gemalto SA Server for a
two factors authentication. The SA Server will first ask the Active Directory (First Factor) if the
login and password are ok, using the LDAP protocol. If the Active Directory responds positively, it
will then test the OTP part of the authentication in the next phase.
• Phase 4: The SA Server will then check the OTP. It means that the server will process the same
calculation as the token did on the user’s side. If the two OTPs are the same, it means that the
remote user has this token so the authentication phase (second factor) is validated.
• Application access: now that all the authentication components are validated, the user can
access the enterprise applications. Keep in mind at this level, the published application could
require some other sort of credentials, or take advantage of the ISA 2006 SSO (Single Sign On)
features.

Important: In Figure 14, we have decided to represent each role by a tiny computer in grouped in the
Virtual Environment machine name. This is why you can see on this diagram a dedicated machine for
IAS, another one for Gemalto SA, etc. In the real life, you can have more than one service per machine.
For example, we can have one machine which acts as the IAS Radius Server and install the SA Server
application. In terms of “change management” constraints, having a dedicated machine for IAS/SA Server
could be interesting because it makes the implementation process easier and the team is autonomous
when they want to change parameters or install updates. It is also important to notice that having one
Radius is not sufficient to provide high availability. Depending on your “Services Level Agreements”(SLA),
you may require a second Radius machine to provide Fail Over.

17 Version 1.1
© Gemalto, Inc. 2007
 At this level, we understand why strong authentication is crucial for the
security of the company. We also understand what OTP Technology is
and how it works on Microsoft infrastructure.
Where Are We ?

Implementing Gemalto SA Server on Microsoft Virtual Environment

Rather than re-installing an entire Windows environment to implement this system, we have decided to
use the Virtual Machines supplied by Microsoft. We will need to do some specific configurations on the
existing machines, plus install the Gemalto components.

Important: In our scenario we use ISA server 2006, but Gemalto SA is also compatible with ISA 2004.

We will only need a subset of the Virtual Machines supplied by Microsoft. The architecture contains these
Servers/Services:

• DC (Denver): On this Domain Controller, we will implement SA Server.

• DC (Denver): On this machine, we will install the IAS (Radius) Windows component and the SA
Server IAS agent.
• ISA (Paris): We will put the appropriate parameters to ask ISA to authenticate through Radius.
• ISA (Paris): We will also modify the “Authentication Banner” to inform the users to provide a One
Time Password.
• DC (Denver): Once the infrastructure is on production, we will “declare” all the hardware tokens
in the SA Server database, and link them to a user in the Active Directory.

Istanbul Parameters
The Istanbul Machine will be used as the remote user’s computer in our Virtual Lab. We have decided to
publish an application called “portal” to the users. The URL to reach this application is
https://portal.contoso.com.

In order to make it work, we have modified the Istanbul HOSTS file with this extra line to simulate a DNS
Server. Here is the line you have to set on this machine:

39.1.1.3 portal.contoso.com # to Portal Web site on Sydney - ISA

For debug purposes, you can use this command line: Ping portal.contoso.com. This ping will fail
because the ICMP protocol is not authorized by ISA, but you will see if the name resolution part works
fine. You need to see the external IP address of this ISA machine (39.1.1.3).

At this level, the remote machine can reach ISA Server with an HTTPs
connection using the portal.contoso.com.

Where Are We? Next Step: Install ISA, the Radius Server and SA Server.

Introduction to ISA Server, and its “Reverse Proxy” capabilities

Microsoft ISA Server is an application firewall which could deliver a lot of services. The core of ISA is in
fact the firewall-engine, but thanks to “application filters” it can provide many features, including server
publishing also called “Reverse Proxy”.

We will use this feature to publish our enterprise web application.

18 Version 1.1
© Gemalto, Inc. 2007
 First of all, you need to create firewall rules to publish your applications. To do so, you will be guided by
the Wizards supplied by ISA. Each Publishing rule will be based on a key parameter (the trigger) which is
the URL you want to publish. For example, ERP.company.com will be routed by ISA to a Web Server
based in Paris whereas OWA-HKG.company.com will be routed to the Outlook Web Access Server
located in Hong Kong. In our scenario, prior to any routing services, we want ISA to pre-authenticate
users with Strong Authentication.

ISA: Creating a Web Listener

ISA will listen for HTTP requests via a component called a “Web Listener”. This object is part of the ISA
objects and provide some parameters such as a Name, a listener port (80, 443), a Web Certificates (for
an HTTPs connection, a web certificate is mandatory and is used to cipher the connection). Once the
Listener has received some data, it will pass this data (GET, POST, URL, payload …) to the ISA firewall
engines that will inspect and route the traffic based on the web publishing rules. The HTTP application
filter will inspect the HTTP dialog, and if need, will modify part of the transaction.

For our scenario, we can use one of the pre-declared Web Listener. It is called “Contoso SSO listener”.
We can use it because it is supposed to listen to any HTTPs connection arriving to 39.1.1.3, which
represents the external IP of our Virtual ISA. Here is the list of the parameters set to this Listener:

• Name : contoso sso listener

• Network : External, IP 39.1.1.3
• Connections : HTTPs, port 443
• Certificates : portal.contoso.com
• Authentication : “HTML Form Authentication”, Radius, “Denver” as the Radius Server
• Forms and SSO : no change

One of these parameters is called the “authentication validation method”. ISA Server provides a list of
authentication methods such as Windows (AD), LDAP and important for us RADIUS and RADIUS OTP.

As you can see there are two methods that are quite similar: Radius and Radius OTP. If fact, Radius OTP
will provide a web authentication page with only a login and OTP (but no password). Here is an example
of what you get if you select this method:

Figure 14 - The default Radius OTP authentication page

19 Version 1.1
© Gemalto, Inc. 2007
 For our scenario, we will rather use the Radius Authentication validation method. As you can see below,
the web interface asks for a “domain/username” and a “password” which makes the authentication
process stronger:

Figure 15 - The default Radius authentication page

But, with the default page, there is no field for an OTP! We will need to modify this web page to ask the
user to provide his OTP, and the easiest way is to ask the user to add this OTP in the password field.

Information: If you want to go deeper in the different authentication validation method available on ISA
2006, please refer to this article: http://www.microsoft.com/technet/isa/2006/authentication.mspx

Modifying the Web Radius authentication page

By default, the RADIUS authentication page displayed by ISA will not request any OTP at all. If we leave
it this way, we could have some very bad feedback from the user, even if they received a procedure by
mail.

20 Version 1.1
© Gemalto, Inc. 2007
 In order to guide the remote-user, we will change the “look and feel” of the default page. In our scenario,
we will provide this web page which is more efficient:

Figure 16 - The 'Modified' Radius authentication page

As you can see, this screenshot is in French. In fact, it is important to have in mind that the remote-user
has to be part of the security policy. This means that the service we provide must be understood without a
problem, no matter where the user comes from. ISA is designed to cope with language constraints. In this
example, a French user will receive a French interface, a Spanish user in Spanish …

Important: in this white paper, we have decided to provide a web page with only two fields? The second
one is supposed to ask for an OTP and password. It is also possible to display 3 fields, the first one for
login, the second for password and the third one for the OTP. This is just a checkbox in the ISA
configuration console.

What we want to do here is to modify – per language – the text displayed on this login banner. This way,
we can provide some more details or any kind of information that a relevant at this level.

To do so, we just need to edit the files located in ISA Directory, in the CookieAuthTemplates/isa sub
directory. Here is a screenshot:

Figure 17 - Files to modify

As you can see there are 3 sub directories called “CHTML”, “HTML” and “XHTML”. These acronyms are
in fact different technologies used by different type of “Web Client” such as a browser, a PDA, …:

• HTML will be used by all normal browser,

• CHTML (C for compact) will be used by embedded browser such as I-mode telephones,
• XHTML (X for extensible) supporting this new technology such as Windows mobile.

21 Version 1.1
© Gemalto, Inc. 2007
 How does it work? When the remote machine sends and HTTP request, one part of this request contains
information called the “User-Agent”. This variable contains the type of browser used to send this request.
Based on the value, ISA will determine which page will be displayed.

If we focus on HTML, we will find some sub-directories corresponding to the language used by the remote
user. In fact, most of the web browser sends this information by default in the Header of the HTTP
request, exactly the same way as the user-agent. ISA can then display the login banner based on the
remote web browser capabilities and in the remote user’s language. Here is an example with Windows
Mobile 6:

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows CE; IEMobile 6.9)

X-ICAP-Version: 1.0
UA-OS: Windows CE (Pocket PC) - Version 5.2
UA-color: color16
UA-Voice: TRUE
UA-pixels: 320x240
UA-CPU: ARM

For each language, a specific “Strings.txt” file is supplied by ISA. Each zone of this Web authentication
page is in fact the results of this variables, stored in this string.txt file. For our demo, we just changed a
few of them to get this result:

Figure 18 - The String.txt parameter file

Figure 19 - Modified web page

By changing the values of each variable, you can easily explain the remote user way he can authenticate,
in his language.

At this level, the remote machine can reach ISA Server with a n
HTTPs connection using the portal.contoso.com

ISA has the appropriate parameters, and is listening for HTTPs

connections through its Web Listener. ISA will display a login banner
Where Are We? which is modified, and we have declared a Radius Server (Denver).
Next Step: Install IAS Service on Denver to act as the Radius Server,
install SA Server Radius agent, Install SA Server Application.

22 Version 1.1
© Gemalto, Inc. 2007
 Implementing IAS service on “Denver/IAS”
On windows 2003, the Radius authentication is supplied by the IAS (Internet Authentication Service), part
of the Windows Operating System. This component is not installed by default, so you have to install it
manually on your own infrastructure.

On the Microsoft VPC environment, this service is already installed and the appropriate parameters are
set. On this screenshot, you can see the path to install this service, but also see the Windows MMC
(Microsoft Management Console) your get after this installation:

Figure 20 - Installing Microsoft IAS (Radius) Service

At this level, you have implemented the IAS Service that will provide Radius authentication. Again, in the
real world we recommend having 2 Radius Servers in order to provide a Fail Over infrastructure.

At this level, we have a Radius server available for authentication. It

will be used by ISA to validate the users credentials
Next step: implement SA Server application.
Where Are We?

23 Version 1.1
© Gemalto, Inc. 2007
 Implementing Gemalto SA Server (application and IAS agent) on “Denver/IAS”
Now that our IAS server is up and running, we will use the same machine to implement the SA Server
components.

In fact, SA Server product will use 2 components:

• The application itself: The Gemalto SA application is in fact a database where all the security
policies, the tokens, and the “user/token” association are declared. The entire administration is
done via a Web page.
• The IAS agent: this component is based on the IAS APIs (Application Program Interface). Once
installed, it is plugged to the IAS Service itself. When the IAS server will receive the credentials
(in our scenario the “Password” will be in fact equal to “OTP + Password”), the agent will separate
OTP and Password and send the credentials to SA Server. SA Server will delegate to AD the
password validation and then will validate the OTP.

The entire process to install SA Server Application is described in this documentation: sa-adminref-
config.pdf. We advise you to download it to get more details.

In order to make this White Paper easy to understand, we have extracted a few screenshots, the most
interesting one:

• Activation Key: In order to install the product, you will need to get Activation key. To do so,
please send an email to Sasolutions@gemalto.com, we will then redirect your request to the local
Gemalto team.

Figure 21 - Activation key Window in installation process

24 Version 1.1
© Gemalto, Inc. 2007
 Figure 22 - IAS Agent/SA Server

During the installation, the SA Server Setup will propose a URL. This URL is used by the agent to “talk” to
the backend-application. Depending on your infrastructure you may have to adapt it. The URL you can
see is the one used if SA Server is installed on the Radius Server, which is the scenario of this White
Paper.

• Authentication: SA Server will use the Active Directory to link a user with a token. You provide
here the LDAP parameters used by the application to check the users. To discover “your”
parameters, you can use the ADSI edit MMC Snap-it supplied by Microsoft. This component will
give you information for parameters such as BASE DN … You can notice here that we use the
Administrator account to make these LDAP search. In real world, we advise you to create a
dedicated user with only “Read” access in the Active Directory.

Figure 23 - LDAP parameters for SA Server/ADSI Edit

Once the application is installed, you can do some manual debug.

25 Version 1.1
© Gemalto, Inc. 2007
 Figure 24 - Basic test and registry
The URL you have provided during the setup is located in the registry. Other keys are important such as
Log Level which provides more debug information. In order to test if the provided URL is correct, you can
copy and paste it on your browser. You should get the same result as the screenshot.

Once Gemalto SA Server and the IAS agent are installed, I advise you to reboot the machine. During the
reboot phase, you will get this event log in the application Hive :

Figure 25 - SA Server event

This means that the IAS agent is now plugged in the IAS Service.

26 Version 1.1
© Gemalto, Inc. 2007
 At this level, Gemalto SA Server (back-end application and IAS agent)
is installed on the Denver Machine.

Where Are We? Next step: access to the admin console for the first time, and put the
appropriate parameters (register token, association with AD users).

Authenticating Gemalto SA Admin portal for the first time

Once the SAS application is installed, you will need to authenticate it in order to make the administration.
The first logon is a bit special, since there are not real devices declared so far. To authenticate the Admin
Portal you will need 3 things:

• User ID: the one you have typed during the installation of SA Server,
• Password: the corresponding password,
• OTP: the first time, you will use a “fake” OTP which is always 301389.

Here is the screenshot of this first authentication:

Figure 26 - Your first authentication in SA Server

Once connected, you can make the administration of the SA Server application.

27 Version 1.1
© Gemalto, Inc. 2007
 Figure 27 - SA Server administration portal

Registering an OTP Device/Association with an AD user

In the real world, this process will be automated. Gemalto will send you a file which contains all the
information about your tokens, and you will import it in SA Server.
For this white paper, we wanted to do it manually in order to demonstrate the hidden part of the process.

At the rear of each device, you can see information called “smart card ID”. You need to provide it, and
also provide 2 other things:

• the type of Key,

• the OATH Policy you would like to use.

Figure 28 - Registering an OTP device / Parameters

At this level, the device is registered in the database. We will now link it to a user in the Active Directory.

28 Version 1.1
© Gemalto, Inc. 2007
 Figure 29 - Device registered

Once selected the device, type the name of the user you want to associate. In this screenshot, we have
selected the administrator of the Active Directory (notice that provisioning can also be automated, or
dedicated to the user himself. Please refer to the SA Server Administration Guide).

Figure 30 – User/device association

At this level, SA Server is installed on the infrastructure. We have registered the OTP device of our test
user (Administrator) in the database. Let’s see now how to modify ISA Server to request for this token.

At this level, SA Server is installed on the infrastructure. We have

registered the OTP device of our test user (Administrator) in the
database. Let’s see now how to modify ISA Server to request for this
Where Are We? token.

29 Version 1.1
© Gemalto, Inc. 2007
 SA Server and the end-users
As we said previously, there is a situation where the remote user could experience some difficulties to
authenticate due to a desynchronization.

Gemalto SA Server is designed to fix this problem quickly by providing a web interface to the remote
user.

Figure 31 - Resynchronization

Also, some of the Gemalto tokens can be used via a USB connector. You just need to install an extra
component called the “Gemalto Plug-in” on your PC. A link is proposed on the bottom-left part of the
resynchronization web page.

A new icon will appear in your browser. If you click it, this plug-in will ask this token via the USB connector
and type the number for you.

Why Gemalto?
As you can see in this white paper, strong authentication is one of the keys of security, probably the most
important one. The truth is that even the most complex password can be broken or stolen very easily. A
good example is the use of Key Loggers that can intercept all the keystrokes and send this information on
the other side of the planer in a few seconds.

A companies are now moving to the notion of strong authentication. This Strong Authentication approach
reduces this problem dramatically.

Gemalto has extensive experience on technologies such as smartcards and One Time Password. They
provide a wide range of devices to address a wide range of end-user scenarios.

With Gemalto SA Server, the OTP solution designed by Gemalto, it is very simple to install strong
authentication on IT infrastructure. This application is very easy to implement (reducing the cost of the
implementation) and very easy to be used by the remote users (reducing the cost of support).

30 Version 1.1
© Gemalto, Inc. 2007
 We have seen here how to implement it on a Microsoft infrastructure which contains ISA Server as a Web
Publishing Gateway. Because SA Server is based on market standards such as Radius and because ISA
is very flexible, implementing strong authentication that will fix this “password” risk is easy, and cost
effective.

With a limited investment, you can provide you your company a robust Strong Authentication architecture.
Once in place, you can publish hundreds of company’s application that will take advantage of it.

It is important to notice that SA Server is compatible also with Intelligent Application Gateway, the
VPN/SSL solution provided by Microsoft which is another way to publish applications to the remote users.

31 Version 1.1
© Gemalto, Inc. 2007
 Table of Figures

Figure 1 – Our challenge: Authenticating Everyone, Everything and Everywhere.................. 2

Figure 2 - Gemalto SA Server Smart Card Device portfolio ................................................... 3
Figure 3 - A basic web publishing architecture ....................................................................... 7
Figure 4 - A basic HTTP network frame.................................................................................. 8
Figure 5 - A basic login popup window ................................................................................... 9
Figure 6 – Easy OTP Token ................................................................................................. 12
Figure 7 - SDC ...................................................................................................................... 12
Figure 8 - USB OTP Token................................................................................................... 12
Figure 9 - .NET Card and Easy OTP Reader ....................................................................... 12
Figure 10 - OTP and Math .................................................................................................... 13
Figure 11 - How authentication is transported ...................................................................... 14
Figure 12 - The Microsoft Virtual Machine environment, ISA Server scenario ..................... 14
Figure 13 - VPCs supplied by Microsoft in the ISA scenario ................................................ 15
Figure 14 - What is an authentication process with OTP ...................................................... 16
Figure 15 - The default Radius OTP authentication page..................................................... 17
Figure 16 - The default Radius authentication page ............................................................. 20
Figure 17 - The 'Modified' Radius authentication page ......................................................... 21
Figure 18 - Files to modify .................................................................................................... 21
Figure 19 - The String.txt parameter file ............................................................................... 22
Figure 20 - Modified web page ............................................................................................. 22
Figure 21 - Installing Microsoft IAS (Radius) Service ........................................................... 23
Figure 22 - Activation key Window in installation process .................................................... 24
Figure 23 - IAS Agent/SA Server .......................................................................................... 25
Figure 24 - LDAP parameters for SA Server/ADSI Edit ........................................................ 25
Figure 25 - Basic test and registry ........................................................................................ 26
Figure 26 - SA Server event ................................................................................................. 26
Figure 27 - Your first authentication in SA Server................................................................. 27
Figure 28 - SA Server administration portal.......................................................................... 28
Figure 29 - Registering an OTP device / Parameters ........................................................... 28
Figure 30 - Device registered................................................................................................ 29
Figure 31 – User/device association..................................................................................... 29
Figure 32 - Resynchronization .............................................................................................. 30

32 Version 1.1
© Gemalto, Inc. 2007
 Glossary (SA Server/Gemalto)

Authentication - The process whereby a card, terminal or person proves who they are. A fundamental
part of many cryptography systems.
IP/PC – Internet Protocol / Personal Computer.
OATH – Open AuTHentication. OTP implementation promoted by Liberty Alliance and pushed to
IETF for being a standard.
Smart Card - Also called IC card, chip card or memory card (for certain types). A card formed of a plastic
body with a chip (or module) embedded in a special cavity.
SA Server – Strong Authentication Server. This is the name of the Gemalto solution for two factor
authentication . It rely on OATH for OTP calculations.

Glossary (ISA)
Application filters: Application filters can access the data stream or datagrams associated with a session
within the Firewall service and work with some or all application level protocols.
Authentication is "A positive identification, with a degree of certainty sufficient for permitting certain rights or
privileges to the person or thing positively identified." In simpler terms, it is "The act of verifying the claimed
identity of an individual, station or originator" [Schou, Corey (1996).
Basic authentication: Basic authentication is the standard authentication method for Hypertext Transfer
Protocol (HTTP). Though user information is encoded, no encryption is used with basic authentication.
ISA Server: Microsoft Internet Security and Acceleration Server 2006
IAG Server (Intelligent Application Gateway): IAG is the Microsoft’s SSL/VPN. It is supplied as an
Appliance, which contains Windows 2003 and ISA server 2006.
MMC Microsoft Management Console – A configuration management tool supplied with Windows that can be
extended with plugins.
NTLM NTLM is an authentication scheme used by Microsoft browsers, proxies, and servers (Microsoft Internet
Explorer, Internet Information Server and others). This scheme is also sometimes referred to as the NT
challenge/response (NTCR) scheme or Integrated Windows authentication.
Publishing rules publish virtually any computer on an internal network to the Internet.
Secure Sockets Layer (SSL): A protocol that supplies secure data communication through data
encryption and decryption. SSL enables communications privacy over
networks.
Server publishing: Server publishing allows virtually any computer on an internal network to publish to the
Internet.
Static filters: A static filter is created during configuration of ISA by using the user interface. If IP packet
filtering is enabled, the static filter is always on.
TLS Transport Layer Security: TLS is based on the SSL 3.0 Protocol Specification
W3C World Wide Web Consortium (W3C) develops interoperable technologies (specifications, guidelines,
software, and tools) concerning Web technology (http://www.w3c.org)
Web proxy service log stores one line per HTTP request

33 Version 1.1
© Gemalto, Inc. 2007