I am assuming you're using Exchange 2003, from one of the articles you linked.

Are you using a Frontend and Backend, or is everything on a single Exchange 
server?  

In IIS under the Secure Communications settings, are you set to "Require client 
certificates"?  If so, change this to ignore (unless you require them for RSA 
authentication).

It sounds like you are using the same ISA publishing rule for ActiveSync that 
you are for OWA, is that correct?  Are you doing Forms-based authentication on 
OWA through the ISA?  You will probably have some issues getting this to work 
while Forms-based authentication is enabled on that publishing rule, especially 
if you're running ISA 2004.  You will need to create a separate publishing rule 
for ActiveSync.  Otherwise, make sure your ISA publishing rule is set with the 
correct "verbs" and set so you can access the Microsoft-server-activesync 
virtual directory.  Also, make sure you're set to require SSL (only on a 
frontend server or single server) and set Authentication to just "Basic 
Authentication" on the Exchange side in IIS.

If you do require client certs, take a look at Apple's config doc:  
http://images.apple.com/iphone/enterprise/docs/iPhone_MS_Exchange.pdf

Check out this website as well for ISA publishing of Exchange 2003, it may give 
you some pointers:
http://www.isaserver.org/tutorials/2004pubowamobile.html

We had to create separate publishing rules for OWA with forms-based 
authentication and our site for RPC/HTTP, ActiveSync connections.  At least 
with ISA 2004, which you may not need to do with ISA 2006.

Without knowing more about your topology, I'm just guessing at what your issues 
might be.  I may not know all the ISA details, as I was only indirectly 
involved with configuring the correct publishing rule.

-----Original Message-----
From: Maglinger, Paul [mailto:pmaglin...@scvl.com] 
Sent: Wednesday, August 19, 2009 2:01 PM
To: MS-Exchange Admin Issues
Subject: RE: Microsoft Exchange ActiveSync Mobile Administration Web Tool 
install

Still having fits with this.  
We can get to my owa using https://servername.domain.com/exchange
When we try to go to https://servername.domain.com/microsoft-server-activesync 
it tells me the page needs a client certificate, but I installed the 
certificate on the workstation.
If we try to hit https://servername.domain.com/oma, I get "You do not have 
permissions to access this Web site".

This is what was done...
On our Exchange server I went to the IIS Manager and created a new certificate. 
 That was sent to Startcom and got back the file ssl.crt.  We used this file to 
complete the pending certificate on the Exchange and imported it on the ISA 
server.  We exported the certificate from the Exchange server and imported it 
on the ISA.  I know we're missing a key step here, but it eludes me.

-----Original Message-----
From: Knoch, James W [mailto:james.kn...@intergraph.com]
Sent: Tuesday, August 18, 2009 5:50 PM
To: MS-Exchange Admin Issues
Subject: RE: Microsoft Exchange ActiveSync Mobile Administration Web Tool 
install

You should use the same external FQDN SSL certificate on both the ISA server 
and Exchange server.  Otherwise the SSL connection "breaks".


-----Original Message-----
From: Maglinger, Paul [mailto:pmaglin...@scvl.com]
Sent: Tuesday, August 18, 2009 5:41 PM
To: MS-Exchange Admin Issues
Subject: RE: Microsoft Exchange ActiveSync Mobile Administration Web Tool 
install

I appreciate the input and will pass it on, but more than likely it will be 
ignored.  

Bottom line is that I still need to set this up.  Can anyone give me their 
thoughts on the original post. 

-----Original Message-----
From: Steven Peck [mailto:sep...@gmail.com]
Sent: Tuesday, August 18, 2009 4:49 PM
To: MS-Exchange Admin Issues
Subject: Re: Microsoft Exchange ActiveSync Mobile Administration Web Tool 
install

We tested them because we 'had to'.  The chief proponent of this was bragging 
about how he was going to get it approved.  Because his iPhone was part of the 
test, our security guy had his iPhone hacked when it connected to the wireless 
LAN.  They added this example/demo as part of their commentary on iPhone 
suitability and security in our environment.

End result:  We do not allow iPhones

Caveat:  We have to answer to HIPAA.  As there is limited/no real case law on 
violations, no one wants to be the case that is quoted as a foundation decision 
for the next 25 years.

Steven Peck

On Tue, Aug 18, 2009 at 2:44 PM, Maglinger, Paul<pmaglin...@scvl.com> wrote:
> Yeah, like that's going to work.
>
> -----Original Message-----
> From: Kurt Buff [mailto:kurt.b...@gmail.com]
> Sent: Tuesday, August 18, 2009 4:32 PM
> To: MS-Exchange Admin Issues
> Subject: Re: Microsoft Exchange ActiveSync Mobile Administration Web 
> Tool install
>
> The following is not terribly helpful, but I just can't help myself.
>
> I'm working on banning iPhones in my environment:
>
> http://www.wired.com/gadgetlab/2009/07/iphone-encryption/
>
> http://arstechnica.com/apple/news/2009/07/new-iphone-hardware-encrypti
> on-not-even-close-to-hack-proof.ars
>
> http://wikee.iphwn.org/howto:iphones_at_defcon
>
> http://www.youtube.com/watch?v=5wS3AMbXRLs
>
> http://www.youtube.com/watch?v=kHdNoKIZUCw
>
>
> If you value your org's data, don't allow iPhones to connect.They 
> might be great personal tools, but given the current state of their 
> security, I would not put any data on them that I wanted to keep 
> private.
>
>
> On Tue, Aug 18, 2009 at 14:09, Maglinger, Paul<pmaglin...@scvl.com> wrote:
>> We're struggling with implementing iPhones into our environment.  We 
>> have set up an ISA server and when we try testing from 
>> https://www.testexchangeconnectivity.com/ for ActiveSync using SSL 
>> authentication, we get this:
>>
>>  Testing Exchange Activesync for host 
>> https://telstar.scvl.com/Microsoft-Server-Activesync/
>>  Exchange Activesync test Failed
>>  Test Steps
>>   Attempting to Resolve the host name telstar.scvl.com in DNS.
>>  Host successfully Resolved
>>  Additional Details
>>  IP(s) returned: 12.156.139.141
>>
>>  Testing TCP Port 443 on host telstar.scvl.com to ensure it is 
>> listening/open.
>>  The port was opened successfully.
>>
>>  Testing SSL Certificate for validity.
>>  The SSL Certificate failed one or more certificate validation checks.
>>  Test Steps
>>   Validating certificate name
>>  Successfully validated the certificate name
>>  Additional Details
>>  Found hostname telstar.scvl.com in Certificate Subject Common name
>>
>>  Validating certificate trust for Windows Mobile Devices
>>  Certificate trust validation failed
>>   Tell me more about this issue and how to resolve it
>>
>>  Additional Details
>>  The certificate chain did not end in a trusted root. Root = 
>> CN=StartCom Certification Authority, OU=Secure Digital Certificate 
>> Signing, O=StartCom Ltd., C=IL
>>
>>
>>  Okay, so I understand the SSL portion of this is failing.  This free 
>> certificate was obtained from Startcom Ltd., which was mentioned in 
>> this article
>> http://www.msexchange.org/tutorials/SSL-Enabling-OWA-2003-Using-Free-
>> 3rd
>> Party-Certificate.html .
>>
>> Okay now...  Let me write this out and see if I've gotten this right.
>>
>> We have our Exchange server on the inside of our firewall.  We have 
>> our ISA server between the Exchange server and the iPhone.  We need 
>> two certificates.  One certificate will be generated by our internal 
>> CA and will used between the Exchange server and the ISA server.  The 
>> other certificate is public and goes between the ISA server and the iPhone.
>>
>> Now...
>> Is it necessary for the ISA server to mimic the FQDN of our internal 
>> mail server?  If so, then we generate a certificate from our mail 
>> server and use it to obtain the SSL certificate from the provider, 
>> then import that certificate on the ISA server.  If it is not 
>> necessary and we generate the certificate from the ISA server itself 
>> and use it, as long as the the name of the ISA server and the name 
>> the client points to is the same as what's in DNS, that's all that 
>> matters, right?  And ActiveSync should be part of the ISA server 
>> because that is what the client is going to hit rather than be 
>> installed on the internal Exchange server.
>>
>> - Paul
>>
>>
>>
>
>
>
>
>










Reply via email to