[isapros] Re: SSL Client Certificate Authentication with non-web clients
- From: "Jim Harrison" <Jim@xxxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Thu, 23 Aug 2007 18:24:48 -0700
Me & Tim bees playin'...
We'll respond when we've sorted it all out.
JimmyJoeBobAlooba
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Jim Harrison
Sent: Thursday, August 23, 2007 4:41 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: SSL Client Certificate Authentication with non-web
clients
CIL...
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Thor (Hammer of God)
Sent: Thursday, August 23, 2007 3:48 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: SSL Client Certificate Authentication with non-web
clients
You mean "force authentication" at the rule, not the listener, right?
[Jim] - sorta, but there is no such setting at the rule. You accomplish this
by include only "Authenticated Users in the "Users" tab.
Doesn't matter anyway- same thing. I go to the site, present my "client
certificate" which it accepts apparently, then I get:
Error Code: 401 Unauthorized. The server requires authorization to fulfill the
request. Access to the Web server is denied. Contact the server administrator.
(12209)
[Jim] - 12209 is an authentication failure (yeh; I know - "DUH!"). Oddly
enough, this is also seen when you would actually expect a 403/12202. What is:
- the "public name" allowed for the rule?
- the path(s) specified in the rule?
- the *exact* URL you're using in the test browser?
Nothing in the logs at all, either on the ISA box or the back end web server.
Nor is there anything in the web logs of the back end server.
As I said before, if I change the CA to something other than my domain CA, when
I present my domain client cert, it fails saying I need a different cert.
t
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> Sent: Thursday, August 23, 2007 3:43 PM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: SSL Client Certificate Authentication with non-
> web clients
>
> That's why you need "force authentication" at the listener.
> Change it to "all authenticated" and you should see different behavior.
> If you still get failures, check the security event log for SChannel
> errors.
> ISA and IIS both use SChannel to validate user certs by requesting a
> Kerberos ticket for that user account. Errors in this process will be
> reflected in the Security event log.
>
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> bounce@xxxxxxxxxxxxx] On Behalf Of Thor (Hammer of God)
> Sent: Thursday, August 23, 2007 3:40 PM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: SSL Client Certificate Authentication with non-
> web clients
>
> All users...
>
> > -----Original Message-----
> > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> > Sent: Thursday, August 23, 2007 3:36 PM
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: SSL Client Certificate Authentication with
> non-
> > web clients
> >
> > Is your rule set for "all users" or "all authenticated users".
> > Might be simpler to just send me your ISAInfo or BPA repro...
> >
> > -----Original Message-----
> > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > bounce@xxxxxxxxxxxxx] On Behalf Of Thor (Hammer of God)
> > Sent: Thursday, August 23, 2007 3:09 PM
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: SSL Client Certificate Authentication with
> non-
> > web clients
> >
> > I hoping you'd help out with this....
> >
> > I'm not combining it with any other method.
> >
> > Under "Client Authentication Method" I select "SSL Client Certificate
> > Authentication" and specify the CA that must have signed the client
> > certs.
> > It doesn't work.
> >
> > What else am i supposed to do?
> >
> > t
> >
> > > -----Original Message-----
> > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> > > Sent: Thursday, August 23, 2007 2:54 PM
> > > To: isapros@xxxxxxxxxxxxx
> > > Subject: [isapros] Re: SSL Client Certificate Authentication with
> > non-
> > > web clients
> > >
> > > You can combine FBA & client cert, but only if you select client
> cert
> > > from the FBA configuration.
> > > You cannot combine "primary" user cert auth (selected from the
> > listener
> > > auth schemes UI) and any other auth method.
> > >
> > > -----Original Message-----
> > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > bounce@xxxxxxxxxxxxx] On Behalf Of Thor (Hammer of God)
> > > Sent: Thursday, August 23, 2007 2:12 PM
> > > To: isapros@xxxxxxxxxxxxx
> > > Subject: [isapros] Re: SSL Client Certificate Authentication with
> > non-
> > > web clients
> > >
> > > If I leave "require client cert" but remove "require
> authentication"
> > > then any client can connect from anywhere without regard to
> > > certificates.
> > >
> > > I absolutely agree that the expected behavior would be that without
> a
> > > client cert, that you could not connect. But you can.
> > >
> > >
> > >
> > > In fact, from a client with or without a client cert, when "require
> > > authentication" is removed, the listener does not even ask for a
> > client
> > > certificate-- it just goes right to the web site.
> > >
> > >
> > >
> > > It is "poo poo"
> > >
> > >
> > >
> > > t
> > >
> > >
> > >
> > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > bounce@xxxxxxxxxxxxx] On Behalf Of Gerald G. Young
> > > Sent: Thursday, August 23, 2007 2:07 PM
> > > To: isapros@xxxxxxxxxxxxx
> > > Subject: [isapros] Re: SSL Client Certificate Authentication with
> > non-
> > > web clients
> > >
> > >
> > >
> > > No, I meant what if you leave " require client cert", remove
> "require
> > > authentication", and then...
> > >
> > > Test 1
> > > From a client without a client cert installed try to connect. Can
> > you?
> > > Expected result is no, you can't.
> > >
> > > Test 2
> > > From a client with a client cert installed try to connect. Can
> you?
> > > Expected result is yes, you can.
> > >
> > > Cordially yours,
> > > Jerry G. Young II ++ Sent from BlackBerry ++
> > > Application Engineer
> > > Platform Engineering and Architecture
> > > NTT America, an NTT Communications Company
> > >
> > > 22451 Shaw Rd.
> > > Sterling, VA 20166
> > >
> > > Office: 571-434-1319
> > > Fax: 703-333-6749
> > > Email: g.young@xxxxxxxx
> > >
> > >
> > > -----Original Message-----
> > > From: isapros-bounce@xxxxxxxxxxxxx <isapros-bounce@xxxxxxxxxxxxx>
> > > To: isapros@xxxxxxxxxxxxx <isapros@xxxxxxxxxxxxx>
> > > Sent: Thu Aug 23 16:52:46 2007
> > > Subject: [isapros] Re: SSL Client Certificate Authentication with
> > non-
> > > web clients
> > >
> > > If I select "require authentication," but don't have a client cert,
> I
> > > cannot present the cert (have an empty "select cert" window) and
> > can't
> > > access the site.
> > > If I load the cert properly, it is available to present, but after
> I
> > > present it, I get the 401 authentication error.
> > > If I tell ISA to use a *different* CA (one that I don't have), but
> > > present my domain cert, it comes back and tells me to select a
> > > different certificate.
> > >
> > > The client I'm testing from is not on the domain, and I'm not
> logged
> > on
> > > as a domain user for ISA-- but I shouldn't be. I'm testing what
> > would
> > > be a "standard"' internet user accessing an SSL site that is
> > configured
> > > to require a client-side cert for access.
> > >
> > > The goal is to limit who can connect up to the site in the first
> > place
> > > via user cert, just like what you can do in IIS directly with
> client
> > > cert mapping. I'm hoping that I don't also have to go to the IIS
> > site
> > > and configure some sort of client cert mapping voodoo-- if you have
> > to
> > > do that, there is no use in having the listener require a client
> > cert.
> > >
> > > Still macking at it ;)
> > >
> > > t
> > >
> > > > -----Original Message-----
> > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > > bounce@xxxxxxxxxxxxx] On Behalf Of Gerald G. Young
> > > > Sent: Thursday, August 23, 2007 1:46 PM
> > > > To: isapros@xxxxxxxxxxxxx
> > > > Subject: [isapros] Re: SSL Client Certificate Authentication with
> > > non-
> > > > web clients
> > > >
> > > > Can you connect from a client that doesn't have a client cert
> > > > installed?
> > > >
> > > > For the "Require SLL Certificate" checkbox being grayed out, can
> > you
> > > > have both a SLL Cert for the server AND require a client cert?
> > Isn't
> > > > that a one-or-the-other kind of thing?
> > > >
> > > > Yeah, I'm sorry I'm not able to help more. :(
> > > >
> > > > Are you on your client as an AD user from the domain in which the
> > ISA
> > > > server exists?
> > > >
> > > > Have you taken a network trace to see what kind of communication
> is
> > > > occurring between the ISA server and the client?
> > > >
> > > > I'm grasping here but... :)
> > > >
> > > > Cordially yours,
> > > > Jerry G. Young II
> > > >
> > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > Application Engineer
> > > > Platform Engineering & Architecture
> > > > NTT America, an NTT Communications Company
> > > > =====================================
> > > > 22451 Shaw Rd.
> > > > Sterling, VA 20166
> > > > Office: 571-434-1319
> > > > Fax: 703-333-6749
> > > > Email: g.young@xxxxxxxx
> > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > >
> > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > > > "The truth is that there is nothing noble in being superior to
> > > somebody
> > > > else.
> > > > The only real nobility is in being superior to your former self."
> > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > > bounce@xxxxxxxxxxxxx] On Behalf Of Thor (Hammer of God)
> > > > Sent: Thursday, August 23, 2007 4:39 PM
> > > > To: isapros@xxxxxxxxxxxxx
> > > > Subject: [isapros] Re: SSL Client Certificate Authentication with
> > > non-
> > > > web clients
> > > >
> > > > I agree completely- "require authentication" seems like, in
> > addition
> > > to
> > > > the client cert, that the client must be authenticated via "one
> of
> > > the
> > > > selected methods," in this case AD (the only radial button
> > selected-
> > > > and it is grayed out).
> > > >
> > > > What is curious the that the "Require SSL Certificate" is grayed
> > out
> > > > and unchecked. But why would that option be there in the first
> > place
> > > > if I've explicitly said I'm requiring a client cert? The help is
> > > > useless in this regard, and I'm not finding much other info on
> > it...
> > > >
> > > > But thanks for your input ;)
> > > > t
> > > >
> > > > > -----Original Message-----
> > > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > > > bounce@xxxxxxxxxxxxx] On Behalf Of Gerald G. Young
> > > > > Sent: Thursday, August 23, 2007 1:34 PM
> > > > > To: isapros@xxxxxxxxxxxxx
> > > > > Subject: [isapros] Re: SSL Client Certificate Authentication
> with
> > > > non-
> > > > > web clients
> > > > >
> > > > > No other thoughts than I always assumed a 401 error was for
> > failure
> > > > of
> > > > > user authentication, not client cert authentication. I would
> > have
> > > > > assumed that by configuring a listener to use client certs, a
> > > browser
> > > > > wouldn't even be able to connect without one (don't remember
> > > > selecting
> > > > > a cert to present). I thought requiring a client cert and
> > > requiring
> > > > > authentication were two different things. If the issue really
> is
> > > > > something simple and not a... ahem... bug, my money would be on
> > the
> > > > > understanding of the difference of those two settings.
> > > > >
> > > > > Cordially yours,
> > > > > Jerry G. Young II
> > > > >
> > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > Application Engineer
> > > > > Platform Engineering & Architecture
> > > > > NTT America, an NTT Communications Company
> > > > > =====================================
> > > > > 22451 Shaw Rd.
> > > > > Sterling, VA 20166
> > > > > Office: 571-434-1319
> > > > > Fax: 703-333-6749
> > > > > Email: g.young@xxxxxxxx
> > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > >
> > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > > > > "The truth is that there is nothing noble in being superior to
> > > > somebody
> > > > > else.
> > > > > The only real nobility is in being superior to your former
> self."
> > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > > > bounce@xxxxxxxxxxxxx] On Behalf Of Thor (Hammer of God)
> > > > > Sent: Thursday, August 23, 2007 4:23 PM
> > > > > To: isapros@xxxxxxxxxxxxx
> > > > > Subject: [isapros] Re: SSL Client Certificate Authentication
> with
> > > > non-
> > > > > web clients
> > > > >
> > > > > I'm hitting the listener as an anonymous user, yes. But, I'm
> > > > providing
> > > > > the cert as authentication. If I don't "require
> authentication"
> > in
> > > > the
> > > > > "SSL Client Certificate Authentication" properties, it never
> asks
> > > the
> > > > > client to provide a cert. And just to ensure that the browser
> > > isn't
> > > > > "automatically" sending anything, I've deleted the client cert
> > and
> > > > > removed the domain CA cert from root certs on the client box --
> > > with
> > > > > "require authentication" cleared, but requiring SSL Client Cert
> > > Auth,
> > > > > the client, the client can still connect to the server without
> > > > > presenting a certificate (which doesn't make any since to me)
> and
> > > > there
> > > > > is no fallback auth specified.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > t
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > > > > bounce@xxxxxxxxxxxxx] On Behalf Of Gerald G. Young
> > > > > > Sent: Thursday, August 23, 2007 1:15 PM
> > > > > > To: isapros@xxxxxxxxxxxxx
> > > > > > Subject: [isapros] Re: SSL Client Certificate Authentication
> > with
> > > > > non-
> > > > > > web clients
> > > > > >
> > > > > > Are you still logging on as an anonymous user? Since you're
> > > > > > configuring the listener to use a client cert and require
> > > > > > authentication, shouldn't you be authenticating against the
> ISA
> > > > > server?
> > > > > >
> > > > > > Cordially yours,
> > > > > > Jerry G. Young II
> > > > > >
> > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > > Application Engineer
> > > > > > Platform Engineering & Architecture
> > > > > > NTT America, an NTT Communications Company
> > > > > > =====================================
> > > > > > 22451 Shaw Rd.
> > > > > > Sterling, VA 20166
> > > > > > Office: 571-434-1319
> > > > > > Fax: 703-333-6749
> > > > > > Email: g.young@xxxxxxxx
> > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > >
> > > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > > > > > "The truth is that there is nothing noble in being superior
> to
> > > > > somebody
> > > > > > else.
> > > > > > The only real nobility is in being superior to your former
> > self."
> > > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > > > > bounce@xxxxxxxxxxxxx] On Behalf Of Thor (Hammer of God)
> > > > > > Sent: Thursday, August 23, 2007 4:10 PM
> > > > > > To: isapros@xxxxxxxxxxxxx
> > > > > > Subject: [isapros] Re: SSL Client Certificate Authentication
> > with
> > > > > non-
> > > > > > web clients
> > > > > >
> > > > > > OK... Help me out with this one-- forget about RDP, etc. I'm
> > > just
> > > > > > trying to get an SLL Listener to require an SSL Client
> > > Certificate
> > > > > for
> > > > > > authentication, and am having some issues- i'm sure it's
> > > something
> > > > > > easy,
> > > > > > but I'm missing it.
> > > > > >
> > > > > > Start from the basics without requiring auth on the listener:
> > > > > > 1) Create SSL listener with proper cert
> > > > > > 2) publish to internal site
> > > > > > 3) got to https://www.domain.com and it works fine (either
> > > bridged
> > > > to
> > > > > > 443 or redirected to 80) as anonymous user.
> > > > > > 4) at this point, everything works just fine...
> > > > > >
> > > > > > Now, I tell the listener to require a client-side cert for
> > > > > > authentication- in this case, it is a cert that must be
> signed
> > by
> > > > my
> > > > > > own
> > > > > > domain CA. The ISA box is NOT on that domain.
> > > > > > 1) install CA cert in trusted root certificates on ISA box.
> It
> > > > > works,
> > > > > > and is valid.
> > > > > > 2) install User cert created by the CA on client box with
> path
> > to
> > > > > root
> > > > > > cert. Move CA cert to trusted root certs. User cert is
> valid,
> > > > cert
> > > > > > path is valid.
> > > > > > 3) Configure listener to use client cert, and to require
> > > > > > authentication.
> > > > > > If I don't require, the client does not have to present a
> cert.
> > > I
> > > > > > further tell ISA to only accept certs trusted by the domain
> CA
> > > (it
> > > > > > shows
> > > > > > up in the list, of course). Note that behavior does not
> change
> > > if
> > > > I
> > > > > > select "all CA's"
> > > > > > 4) Configure the system policy on ISA for CRL lookups
> > > > > > 5) Verify the ISA box can get to the CRL path specified in
> the
> > > cert
> > > > > > 6) from the client, go to https://www.domain.com and it asks
> > for
> > > a
> > > > > > cert.
> > > > > > The cert is available, and i present it: but I always get:
> > > > > >
> > > > > > Error Code: 401 Unauthorized. The server requires
> authorization
> > > to
> > > > > > fulfill the request. Access to the Web server is denied.
> > Contact
> > > > the
> > > > > > server administrator. (12209)
> > > > > >
> > > > > > Removing the SCCA returns things to normal. I've even tried
> > > > > publishing
> > > > > > to different back end servers... same thing.
> > > > > >
> > > > > > What could be the problem?
> > > > > > t
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > > > > > bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> > > > > > > Sent: Thursday, August 23, 2007 11:26 AM
> > > > > > > To: isapros@xxxxxxxxxxxxx
> > > > > > > Subject: [isapros] Re: SSL Client Certificate
> Authentication
> > > with
> > > > > > non-
> > > > > > > web clients
> > > > > > >
> > > > > > > The point of using a browser on not is not relevant.
> > > > > > > It's the client application's responsibility to handle the
> > > return
> > > > > > from
> > > > > > > SCHannel that says "pick a cert of type 'X'". Supposedly,
> > the
> > > v6
> > > > > RDP
> > > > > > > client knows how to prompt for smartcard certs, but I
> haven't
> > > > > > > personally
> > > > > > > tested this. Word on the streets is that "soft-certs"
> should
> > > > also
> > > > > > > work,
> > > > > > > but again; I haven't personally tested this.
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> > > > > > > bounce@xxxxxxxxxxxxx]
> > > > > > > On Behalf Of Thor (Hammer of God)
> > > > > > > Sent: Thursday, August 23, 2007 7:26 AM
> > > > > > > To: isapros@xxxxxxxxxxxxx
> > > > > > > Subject: [isapros] SSL Client Certificate Authentication
> with
> > > > non-
> > > > > web
> > > > > > > clients
> > > > > > >
> > > > > > > So, in an earlier thread, we discussed using certificates
> to
> > > > > control
> > > > > > > what clients could connect to a published RDP server. As
> we
> > > saw,
> > > > > > this
> > > > > > > is not possible in Vista/2003 implementations. However, we
> > see
> > > > > that
> > > > > > in
> > > > > > > TSGateway, one uses an SSL listener (with public names to
> > /rpc)
> > > > to
> > > > > > > publish access to TSGateway functionality via RDP over
> > > RPC/HTTP.
> > > > > The
> > > > > > > TSGateway configuration allows you to specify smart-card
> > logon,
> > > > but
> > > > > > in
> > > > > > > the absence of that, the recommendation was made to use
> "SSL
> > > > Client
> > > > > > > Certificate Authentication" restrictions at the SSL
> listener
> > > > > itself.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > However, I don't see how this will work. As I see it, the
> > only
> > > > way
> > > > > > to
> > > > > > > use SCCA on a web listener is for the client to be a
> browser
> > -
> > > > > that's
> > > > > > > how the user is given the option of choosing which cert to
> > > > present
> > > > > to
> > > > > > > the server. In the case of an RDP client (MSTSC.exe)
> > > connecting
> > > > to
> > > > > a
> > > > > > > TSGateway published via an SCCA web listener, it won't work
> > as
> > > > > there
> > > > > > is
> > > > > > > no way to present a cert.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > So, we really can't use SCCA as it relates to RDP, correct?
> > Or
> > > > is
> > > > > > > there
> > > > > > > some secret squirrel configuration I don't know about?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > t
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -----------------------------
> > > > > > >
> > > > > > > vinni, viddi, vinni denuo
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > All mail to and from this domain is GFI-scanned.
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > =================================
> > > > > >
> > > > > > This email message is intended for the use of the person to
> > whom
> > > it
> > > > > has
> > > > > > been sent, and may contain information that is confidential
> or
> > > > > legally
> > > > > > protected. If you are not the intended recipient or have
> > received
> > > > > this
> > > > > > message in error, you are not authorized to copy, distribute,
> > or
> > > > > > otherwise use this message or its attachments. Please notify
> > the
> > > > > sender
> > > > > > immediately by return e-mail and permanently delete this
> > message
> > > > and
> > > > > > any attachments. NTT America makes no warranty that this
> email
> > is
> > > > > error
> > > > > > or virus free. Thank you.
> > > > >
> > > > >
> > > > >
> > > > > =================================
> > > > >
> > > > > This email message is intended for the use of the person to
> whom
> > it
> > > > has
> > > > > been sent, and may contain information that is confidential or
> > > > legally
> > > > > protected. If you are not the intended recipient or have
> received
> > > > this
> > > > > message in error, you are not authorized to copy, distribute,
> or
> > > > > otherwise use this message or its attachments. Please notify
> the
> > > > sender
> > > > > immediately by return e-mail and permanently delete this
> message
> > > and
> > > > > any attachments. NTT America makes no warranty that this email
> is
> > > > error
> > > > > or virus free. Thank you.
> > > >
> > > >
> > > >
> > > > =================================
> > > >
> > > > This email message is intended for the use of the person to whom
> it
> > > has
> > > > been sent, and may contain information that is confidential or
> > > legally
> > > > protected. If you are not the intended recipient or have received
> > > this
> > > > message in error, you are not authorized to copy, distribute, or
> > > > otherwise use this message or its attachments. Please notify the
> > > sender
> > > > immediately by return e-mail and permanently delete this message
> > and
> > > > any attachments. NTT America makes no warranty that this email is
> > > error
> > > > or virus free. Thank you.
> > >
> > >
> > >
> > > =================================
> > >
> > > This email message is intended for the use of the person to whom it
> > has
> > > been sent, and may contain information that is confidential or
> > legally
> > > protected. If you are not the intended recipient or have received
> > this
> > > message in error, you are not authorized to copy, distribute, or
> > > otherwise use this message or its attachments. Please notify the
> > sender
> > > immediately by return e-mail and permanently delete this message
> and
> > > any attachments. NTT America makes no warranty that this email is
> > error
> > > or virus free. Thank you.
> > >
> > >
> > >
> > >
> > > All mail to and from this domain is GFI-scanned.
> > >
> >
> >
> > All mail to and from this domain is GFI-scanned.
> >
>
>
> All mail to and from this domain is GFI-scanned.
>
All mail to and from this domain is GFI-scanned.
All mail to and from this domain is GFI-scanned.
Other related posts:
