Re: OWA 2003 w/ Smart Card Authentication.
- From: "Miguel" <me@xxxxxxxx>
- Date: Thu, 13 Apr 2006 20:20:01 +0900
Karim,
Interesting that you should mention this as I am working on another project
involving a WM5 (i-mate JasJar) and Exchange 2003. Below is a copy of a
posting that I've listed in another group discussion. Hopefully, you can
shed some light on the root cause.
---My posting within other newsgroups---
I'm currently having some issues synching a Windows Mobile 5 device to an
Exchange 2003 server via ActivSync. It reports error 0x80070300. The
device was working at one time. The only difference between then and now is
the IIS certificate. Initially, the certificate was issued by VeriSign, but
now it's from a third-party Intermediate Certificate Authority. Because
it's a third-party certificate, I installed the Root and Intermediate
certificates in the root store of the mobile device.
I've tried multiple tests in an attempt to identify the root cause. Please
keep in mind that the server is currently serving successful requests (HTTP,
HTTPS, and RPC over HTTPS), just not to WM5. I've loaded all the required
certificates and CRLs on the server. To rule-out ActivSync specific issues,
I tried accessing the IIS root website via WM5 Internet Explorer, but also
receive the same error, 0x80070300.
---My posting within other newsgroups---
Thanks,
Miguel
"Karim Batthish [MS]" <karimbonline@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:%23SxBddQXGHA.4144@xxxxxxxxxxxxxxxxxxxxxxx
You can also look at what's necessary to configure the same thing for
mobile devices at
http://www.microsoft.com/technet/itsolutions/mobile/deploy/msfp_a.mspx.
"Miguel" <me@xxxxxxxx> wrote in message
news:eob78RVWGHA.3848@xxxxxxxxxxxxxxxxxxxxxxx
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.
.
- References:
- Re: OWA 2003 w/ Smart Card Authentication.
- From: Karim Batthish [MS]
- Re: OWA 2003 w/ Smart Card Authentication.
- From: Miguel
- Re: OWA 2003 w/ Smart Card Authentication.
- From: Karim Batthish [MS]
- Re: OWA 2003 w/ Smart Card Authentication.
- From: Miguel
- Re: OWA 2003 w/ Smart Card Authentication.
- From: Karim Batthish [MS]
- Re: OWA 2003 w/ Smart Card Authentication.
- Prev by Date: Re: Can Exchange Server Sync be broken?
- Next by Date: HTTP 500 - Internal server error with some OWA Users
- Previous by thread: Re: OWA 2003 w/ Smart Card Authentication.
- Next by thread: Special User Failed To Send Email To Outside
- Index(es):
Relevant Pages
|
