Re: OWA 2003 w/ Smart Card Authentication.

Karim,

Thanks for the guidance. I'll look through it very carefully. I've already
spent many hours online and on the system attempting to make it work, but no
luck.

I'll let you know what happens.

Miguel


"Karim Batthish [MS]" <karimbonline@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:%23YYlcmRWGHA.1228@xxxxxxxxxxxxxxxxxxxxxxx
Miguel, I know the way to make it work - it isn't easy and you will need
to do a lot of reading.

As well, Microsoft PSS may not officially support or endorse this, so you
should attempt it at your own risk. (I have tested this and seen it
function in a number of different topologies. Most people who try are
daunted by the number and complexity of steps, and give up when they
realize that smartcards seldom work most of the places users want to
access OWA. If you can get past these, then let me know how it goes.)

The minimum requirements for this are as follows:

1. Whether or not authentication will succeed is completely dictated by
IIS and Windows.
See
http://www.microsoft.com/windows2000/techinfo/planning/security/mappingcerts.asp
on how to create certificates that'll map to user accounts. The
requirements are generally the same as those for using a client
certificate to sign-in to Windows, plus the IIS server's machine account
must trust the root CA that issued the client cert.
See
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/iis/reskit/iis50rg/iischp9.asp
on IIS authentication models.
See http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B257586 on
how SSL certificate auth handshake happens.

2. The Forest where Exchange is running must be in Windows 2003 'native'
mode, i.e. all DCs are W2K3 servers and domain functional levels are
raised to maximum. (While the functionality may only require a Windows
2003 Domain, cross-domain will likely require a Windows 2003 Forest, or
both domains must be and there are too many permutations to test and
support.) Cross-forest - i.e. user forest and Exchange resource forest -
certificate auth could work if there is a two-way trust between forests
and the NTAuth certificate store is correctly populated. (More reading to
do here.)

3. FE servers must be Windows Server 2003.

4. Each FE server must have constrained delegation configured for "any
authentication protocol" for "HOST" and "http" to all BE servers.
(Negotiate != Kerberos.) This generally requires a reboot of the FE box
to kick in.

5. HTTP authentication (basic, anon, etc.) must be disabled in ESM for all
v-roots for the v-server on the FE.

6. HTTP authentication must be disabled for /exchweb/bin on the FE server
via the IIS Manager snap-in. For the non-ESM change to settings on
/exchweb/bin to stick, you'll need to:
a. Turn off the System Attendant on the FE,
b. or set a bit in the AD on the Exchange HTTP Virtual Server object
that maps to the FE. (To do this, you need to OR 128 to the value of the
msExchDS2MBOptions bitmask on the FE virtual server object in the AD.)
c. Either choice will, of course, interfere with other changes and the
OR'ed 128 should be removed or the System Attendant must be restarted to
configure other IIS-related setting on the FE.

7. Server's SSL certificate must be configured on root of v-server via the
IIS Manager snap-in.

8. Active Directory mapper must be enabled on root of Web Sites via the
IIS Manager snap-in. IIS Admin will need to be restarted.

9. Force SSL, enable mapping on root of v-server. Ensure changes are
cascaded to all sub-v-roots. This means that "Enable client certificate
mapping" must be enabled on the /exchange, /exchweb/bin and /public
virtual directories.

10. Authenticating users must be in the same forest as the FE server.

11. Users must have a valid client certificate with private key on the
machine that is used to connect to the front-end server (it can be
software-based or on a hardware token) key and have the corresponding cert
with Public Key published to their user object in the AD. Cross-forest is
more complicated.

12. Client machines - and the FE - must have access to one of the CRL
Distribution Points (CDP) on the client certificate and the CDP must be
running.

If you want to do FE/BE, with SSL cert signon on FEs, those are the
requirements. I've been asked this several times, so I'll note: you
cannot use SSL client cert auth and "regular" HTTP auth, or even cookie
auth on the same virtual server and get single-signon.

Other notes:
. X.509 certificates that can be read by Windows and stored in the user's
personal certificate store that have an associated private key, can
generally be used by Internet Explorer for authentication. If the cert
and key are stored on a smartcard connected to a reader that is compatible
with Windows, it'll work too. See link above for Windows requirements of
certs and authentication. We've also tested this successfully with
properly configured non-Microsoft clients, through configuration steps may
vary from application to application.
. Note that removing a smartcard doesn't mean that IE will stop being able
to connect to the server. For performance reasons, IE will often continue
an SSL client-certifacte authenticated session after a smartcard has been
removed for some time, until the browser has been closed or until the
"Clear SSL State" button has been clicked in IE's Internet Options. To
solve this with Exchange Server 2003, if the OWA S/MIME control is
downloaded, logging out of OWA will automatically "clear SSL state".
. Because SSL client certificate authentication requires IIS running on
the Exchange server to terminate SSL, it is not possible to offload SSL
processing to another server (such as ISA Server or any other reverse
proxy,) nor is it possible to use ISA Server's SSL Bridging functionality.

Cheers and good luck,
- Karim

"Miguel" <me@xxxxxxxx> wrote in message
news:elIPUh$VGHA.5076@xxxxxxxxxxxxxxxxxxxxxxx
Karim,

Thanks for the reply. I'm actually trying to make this work via a
front-end. Would you happen to know what I need to do?

Miguel


"Karim Batthish [MS]" <karimbonline@xxxxxxxxxxxxxxxxxxxx> wrote in
message news:ODLSu12VGHA.4360@xxxxxxxxxxxxxxxxxxxxxxx
To get smartcard auth working against a backend server (i.e. not on a
front-end) you need to disable all the auth methods - Basic, Windows
Integrated, forms based - otherwise users will get prompted.

If you're trying to make this work via a front-end, there's a lot more
to
configure.

- Karim

"Miguel" <none@xxxxxxxx> wrote in message
news:ejGTHlJVGHA.5808@xxxxxxxxxxxxxxxxxxxxxxx
I've configured OWA 2003 to use smart card authentication, which works,
but
I also still receive the prompt to enter a userid and password, which I
don't want. I would like to configure the system to only use smart card
authentication.

I've completed all the prerequisites for enabling the capability (e.g.,
directory service mapper, name-mapping of useraccount and certificate,
enabled SSL, selected require client certificate to access the site,
installed the CA certificate into the Trusted Root Authority of both
the
client and the server, and also loaded the CRL), but no luck.

Just to ensure that the capability is working on the server, I created
a
virtual directory and configured it to use smart card authentication,
which
does work. I use this capability on other non-OWA web servers without
a
problem.

After many unsuccessful searches for the answer, I've started to
dissect
the
OWA logon.asp file for code that might be preventing this. I did notice
that
the file doesn't check for certificates when authenticating the user.
Not
sure if that even matters. I'm starting to think that the server is
requiring multi-factor authentication.











.