Exchange 2k7, Touchdown

Claymoore

The problem isn't so much the self-signed part, because Active Directory acts as a trusted third party so the clients will trust the CAS server cert because they are both members of the same domain. The problem is the name of the certficate - owa.company.com - will not match the name of the server - cas.company.com. This will generate errors in the autodiscover service, and thus the availability service, as well as internal OWA problems if anyone uses that.

Exchange also relies on certificates for internal TLS encryption of SMTP traffic, but you can use different certs for different services to avoid problems there.

If you just want to test things, create a different external A DNS record that matches the name of the internal CAS server - cas.company.com instead of owa.company.com - and a different firewall rule. You will be telling the ActiveSync client to ignore certificate errors either way. Just be sure to manually set the server names rather than relying on autodiscover since you won't have that name on the cert.

Once you have it working, buy a real cert and fix your A records and firewall rules. As a bonus, a trusted third party UCC cert will allow your hub transport servers to start using TLS to encrypt external SMTP traffic.

Bl8ckr0uter

Here is another issue, we don't have a server with the CAS role on it. We only have one exchange server and I don't know if it has the role installed or not.

Claymoore

It does. If you only have one server, it will host the Client Access Server, Hub Transport and Mailbox server roles.

I don't know how large your company is, but you might consider splitting up those roles to additional servers to provide some high availability and redundancy options. But that's another project for another day.

Bl8ckr0uter

Claymoore wrote: »

It does. If you only have one server, it will host the Client Access Server, Hub Transport and Mailbox server roles.

I don't know how large your company is, but you might consider splitting up those roles to additional servers to provide some high availability and redundancy options. But that's another project for another day.

Smallish. No more than 70 users. Would you previous statement still apply since owa.company.com is cas.company.com?

Claymoore

Yes, just replace CAS with the actual name of your exchange server.

The issue you will face is the certificate name and server name will not match. By using a UCC cert you can include multiple subject alternate names to avoid the issue, but for testing it would be easier to create a new A record and change the firewall than to order a 3rd party cert.

Bl8ckr0uter

Ok so here is my plan now:

Change my created A record from A record in public DNS to OWA.Company.Com to (Mail Server Name).Company.Com

Go to firewall and create a rule to point connections to (Mail Server Name).Company.Com to the internal ip address of the exchange server

Go to exchange and back up certificates

While on exchange, create a self assigned cert with the cn name of (mail server name) .company.com

lockdown virtual directories in IIS

Test outlook autodiscovry tool

Test sync with Droid 2

God this is really risky isn't it? Probably not to an exchange expert like you huh lol. I am just concerned about taking down our mail server. I am not going to touch the mx record nor any other parts of the configuration. I just wish I had a server to test this on but the CEO wants this running so I have no choice.

Bl8ckr0uter

Well the boss approved getting a UCC cert so now I need to explore that.

subl1m1nal

The signed certificate is the way to go. Even if you only have 2 smartphones setup now.

Smartphones seem to spread like wildfire. Similar to dual monitors. One person in the office gets it, the rest of the office will want it, and complain about it till they get it.

Bl8ckr0uter

This issue is neither me nor my senior have any experience in doing this. I am going to get an Admin guide this week.

subl1m1nal

No way to get experience besides going for it!

You should do fine. Just do it after hours. You have plenty of support here on TE and google.

Just make sure your certificates match up, the firewalls setup, and IIS is configured and you're good to go.

Bl8ckr0uter

And setting up owa isn't that difficult?

subl1m1nal

It's not too bad. It'd be simpler if you had an SBS server. You could knock all of this out in an afternoon.

Bl8ckr0uter

subl1m1nal wrote: »

It's not too bad. It'd be simpler if you had an SBS server. You could knock all of this out in an afternoon.

So I've been calling around and it seems that godaddy is the best value as far as this is concerned. What I didn't understand was why they were asking how many names I require. I thought I needed four (owa.public.com autodiscovery.public.com, owa.private.com, autodiscovery.private.com). Are there other names I need?

Claymoore

knwminus wrote: »

So I've been calling around and it seems that godaddy is the best value as far as this is concerned. What I didn't understand was why they were asking how many names I require. I thought I needed four (owa.public.com autodiscovery.public.com, owa.private.com, autodiscovery.private.com). Are there other names I need?

You will need to include the netbios name as well as the FQDN of each server (or service). Since you only have the one server, the names should be something like:

owa.public.com
owa.private.com
owa
autodiscover.public.com
autodiscover.private.com
autodiscover
server.private.com
server

Digicert has a web tool that will generate the powershell command for you, all you have to do is list the names:
https://www.digicert.com/easy-csr/exchange2007.htm

GoDaddy is the cheapest, but I have had problems with some browsers or devices not trusting their root certificate or the entire cert chain in the past. I didn't have a problem the last time I used a GoDaddy cert, but you may need to export the cert or add it to the trusted root through group policy.
Certificates for Windows Mobile 5.0 and Windows Mobile 6
Add a trusted root certification authority to a Group Policy object: Security Configuration Editor

Bl8ckr0uter

Awesome. I think I will check out digicert, even though the name reminds me of this wargreymon - Google Search


So the order of events is:

Purchase cert
Set up OWA
Apply cert
Completed ActiveSync Profiles
Sync w/ Droid 2
Make my CEO happy!

Bl8ckr0uter

So now I have until the 18th to configure OWA, activesync, make it work with the droids and test it for the CEO. :Shock:. Can anyone recommend this book for getting me up and running on OWA/Activesync/certificates quickly: Amazon.com: Microsoft Exchange Server 2007 Administrator's Pocket Consultant Second Edition (9780735625860): William R. Stanek: Books

Bl8ckr0uter

Well the book has been ordered. Hope it is good enough to get a noob like me going.

Forsaken_GA

Totally off topic, but the subject of this post made me think that EA had acquired Microsoft and was starting a new franchise!

Bl8ckr0uter

Claymoore wrote: »

You will need to include the netbios name as well as the FQDN of each server (or service). Since you only have the one server, the names should be something like:

owa.public.com
owa.private.com
owa
autodiscover.public.com
autodiscover.private.com
autodiscover
server.private.com
server

Here is the issue I am having. I called Digicert (since I have been approved for the cert) and they said I would only need owa.public, owa.private, autodiscover.public and server.private. Is that not the case? This would cause a major price difference of the cert (328 vs XXX).

Claymoore

knwminus wrote: »

Here is the issue I am having. I called Digicert (since I have been approved for the cert) and they said I would only need owa.public, owa.private, autodiscover.public and server.private. Is that not the case? This would cause a major price difference of the cert (328 vs XXX).

While working with Microsoft on a crazy cross-forest availability impementation last year, they recommended always including the NetBios name along with the FQDN when creating the certificate requests because some of the services may use the netbios name instead of the FQDN. Autodiscover.private will probably never be used because internal clients should use the service connection point defined in AD, but I would hate to spend weeks troubleshooting a weird issue only to find out the cause was a certificate missing a specific name. I just put every permutation of the name in there to be safe.

The GoDaddy certs are cheaper and I think they are tiered at 5 subject alternate names.

Bl8ckr0uter

So worse case I would need to add 3 more SANs. Awesome. I figured you had a good reason for saying what you did as I know you know way more than some 1st level rep about exchange and certs. Alright now here is the million dollar question: How long does this take? I am a noob at this but I am willing to buckle down and get er done. I really need to get it done by Wednesday of next week but I probably won't start til Saturday (when my exchange manual comes here). I could stay at work all day Sat, Sun but I need to get owa and activesync (and then sync with the droids) working by Wednesday. Do you think it can be done?

Hyper-Me

Yeah we pay like 50$ for godaddy certs.

Bl8ckr0uter

Great! New issues. So godaddy is having issues with the fact that our domain is a top level domain and we don't own that domain*. So our internal domain name is abc.com and we don't own abc.com but we do own abccompany.com. I asked if I can make an A record that says mail (or owa) .abcompany.com and make a firewall change to forward those request to mail.abc.com would that be ok. They said, in short, no. So now I am kind of lost. I don't think it should make a big difference anyway.

Thoughts?

Bl8ckr0uter

Well it is official. This is not going to work. I'll just have to use make exchange trust the self assigned certificate until we can do something about this. I am thinking PKI. Anyone else want to chime in?

Claymoore

Ouch.

I had a client whose internal domain extension was actually a top-level country domain. Unfortunately, they didn't own the domain and couldn't buy it because they weren't located in that country. They had to use a combination of SSL offloading and an internal CA to solve the issue.

They had an internal CA that they could use for their internal servers and they had to use an SSL offload device as a reverse proxy to handle their official external domain name. If you connected to an internal server you got the certificate issued by the internal CA that used the internal domain extension. If you connected externally, the edge device (a Linux server in this case, but ISA or ForeFront server will do the same thing) had a real third-party cert and would handle the SSL connection between the external client and the internal server.

I think the only way around this is to offload the external SSL and use an internal CA for the internal server requests. You might be able to set the Android devices to ignore certificate errors, but the external OWA connections will throw errors.

Bl8ckr0uter

Claymoore wrote: »

Ouch.

I had a client whose internal domain extension was actually a top-level country domain. Unfortunately, they didn't own the domain and couldn't buy it because they weren't located in that country. They had to use a combination of SSL offloading and an internal CA to solve the issue.

They had an internal CA that they could use for their internal servers and they had to use an SSL offload device as a reverse proxy to handle their official external domain name. If you connected to an internal server you got the certificate issued by the internal CA that used the internal domain extension. If you connected externally, the edge device (a Linux server in this case, but ISA or ForeFront server will do the same thing) had a real third-party cert and would handle the SSL connection between the external client and the internal server.

Lol this is so much bullshit. I mean I wish the last guy had just bought the domain when it was available (like 7 years ago). Man there is no way I am going to be able to do that in 1 day. That's it man, I quit on this project lol. You know what pisses me off the most? I had a bad feeling about this from the get go (because of our domain name). Because the self assigned certificate isn't in the root certificate authorities I cannot even browse to owa internally without getting 501/505 errors. So lame

The issue is I really don't want to admit defeat and look like a noob in front of the other admin

About the internal CA, they basically just implemented PKI and gave out their own certificates right? How well did that work for them?

Claymoore wrote: »

I think the only way around this is to offload the external SSL and use an internal CA for the internal server requests. You might be able to set the Android devices to ignore certificate errors, but the external OWA connections will throw errors.

I might try this later on tonight. I need to take a break as I am getting a royal headache. I do think that exchange is pretty cool though I also like this exchange manual. Seems to be very well written. But I knew we were going to have problems when I called Godaddy for help and they had to put me on hold. The CSR actually failed when I pasted it in. Oh well. SSL offloading is a bit over my head (so is PKI for that matter) so that will be good reading for another day.

subl1m1nal

That sucks man. Self signed cert or do the whole CA thing. Might be a little extra work getting the phones to trust the cert, but it works.