Exchange 2007 Sercurity Alert

Hello,

You need an internal record for mail.publicdomain.co.uk and autodiscover.publicdomain.co.uk that both point to the internal IP of your CAS server/CAS array. You also need to set the internal URLs on your web services to point to the these URLs.

I'm assuming that you have both hostnames on your certificate as well.

-JJ

The cert only has mail.publicdomain.co.uk.  Would I still receive the security alert since the hostname "autodiscover.publicdomain.co.uk" isn't included on the cert?

You need to either have autodiscover.publicdomain.co.uk on the cert or you need to setup SRV DNS records for your autodiscover service and change the internalURi of the autodiscover service to point to mail.publicdomain.co.uk

-JJ

Unfortunately at this time, I cannot change the cert so are you suggesting I make these dns changes?

autodiscover.publicdomain.co.uk  -  >  mail.publicdomain.co.uk

mail.publicdomain.co.uk   -  >  "internal mail server ip"


Thanks,

Ok so just to be clear.  By following this post:

http://www.petenetlive.com/KB/Article/0000036.htm

I've already set the internalUri for on my CAS server.  BTW, I only have 1 exchange server hosting all the roles.  So the only thing I am missing is the external DNS record pointing autodiscover.publicdomain.co.uk -> mail.publicdomain.co.uk

Yes . If you already set the internal URL you just need to create the SRV record.

-JJ

OK, I can do that.  My only question now is most of the documents refer to adding this record as a solution for non-domain clients.  We don't allow non-domain clients.  I'm getting this security alert on domain clients that are in the same LAN as the CAS server.

You need to add the SRV record when you can't use autodiscover.domain.com.

-JJ

I just came across this solution.  Would this work rather than changing the external DNS?

http://acbrownit.wordpress.com/2012/12/20/internal-dns-and-exchange-autodiscover/

No, that doesn't really apply. One thing I want to verify is that you are using split-dns. Meaning, you have both an internal and external zone (completely separate) for your publicdomain.co.uk zone. This allow you to set your internal A record for mail.publicdomain.co.uk to the internal IP of your Exchange server and the external A record of mail.publicdomain.co.uk to the external IP.

The reason you need to create the SRV record is for external clients. Outlook will attempt to connect to autodiscover.publicdomain.co.uk. Failing to connect to that, it will look for the SRV record. The SRV record will point to mail.publicdomain.co.uk. You need to use the SRV recond when your cert only has mail.publicdomain.co.uk. For internal clients, they will query AD for the autodiscover service. The value returned is what you set on the internaluri attribute on the Set-ClientAccessServer cmdlet. This value should be mail.publicdomain.co.uk since that is the only name on your cert.

Now you should see why you need split-dns. You could use a different zone internally. For example, you could have privatedomain.co.uk. You would then set all your internal urls on the web services to point to mail.privatedomain.co.uk. There are to caveats with this setup. First, you would need mail.privatedomain.co.uk added your SSL cert. Second, privatedomain.co.uk needs to be a domain that is registered to you and can't be a private domain like yourdomain.local. This is because you can no longer get SSL certs with private domain names.

If you don't have split-dns setup, you could also just have the one A record, which would point the internal clients to the public IP. This would work as long as your firewall and routers will allow your internal clients to use the external IPs.

-JJ

Yes we do have split DNS for example:

publicdomain.co.uk
privatedomain.co.uk

Now our MX record points to a email firewall that has a different IP than our external users use.

webmail.publicdomain.co.uk is what we use for phone/OWA access.

Since the cert is for "webmail.publicdomain.co.uk" i've pointed everything in this article:

http://www.petenetlive.com/KB/Article/0000036.htm

To "webmail.publicdomain.co.uk"


So just creating the srv record that states _autodiscover -> "webmail.publicdomain.co.uk" would work?

sorry for the confusion.  this is a bit overwhelming for me.  Thanks for all of your assistance.

Yes, creating the SRV record should resolve your issues.

-JJ

OK, i hate to make changes on a Friday so if you don't mind, I will test it on Monday and award you your points then.  Hope that's OK.

Sure, that's fine.

-JJ

Sorry that I am just getting back to you.  That didn't work.  I still get the same popup.  One thing I did notice though is that if I click view certificate, the certificate is not the one I purchased and installed in exchange.  It is for some other website/company altogether.  Does this mean that the dns record is still propagating or something else is incorrectly configured?

What is the FQDN that pops up on the security alert? Is it webmail.publicdomain.co.uk? Your users' default email domain is @publicdomain.co.uk?

-JJ

When the alert pops up, it says:

autodiscover.publicdomain.co.uk

Users email domain is:

user@publicdomain.co.uk

The certificate however is *.someotherdomain.com

This alert only pops up when our exchange server is offline.  Other than that, we never see it.  Not sure if that matters.

When you ping autodiscover.publicdomain.co.uk, does it point of your Exchange server?

Run Set-ClientAccessServer -identity <servername> | fl

Make sure the autodiscover URLs are set to webmail.publicdomain.co.uk

-JJ

No, pinging autodiscover.publicdomain.co.uk does not point to our external CAS IP address.

The record I added though was _autodiscover and it was a SRV record, do I need an A record for autodiscover?

No, you do not need an A record for autodiscover. If you have an A record for autodiscover.publicdomain.co.uk, you should delete it. Did you run Get-ClientAccessServer and check the autodiscover URLs?

-JJ

I ran:

get-clientaccessserver | fl


The internalURI is:

https://mail.publicdomain.co.uk/autodiscover/autodiscover.xml

Is there anything else I can try or info you would need to help troubleshoot this?  I know speaking with fictitious domain names make troubleshooting a little more difficult.  I do appreciate all the time and support you have given.  Thanks,

What is *.someotherdomain.com on the certificate, exactly? Is it one of your domains. You say the security alert only ever pops up when your Exchange server is offline?

-JJ

Yes, we only get the certificate alert when our exchange server is offline.  So when I do maintenance or just reboot, internal LAN users get that popup and begin calling help desk.  Only some users get it.  I was attempting to fix that so when I do maintenance, their outlook clients just show disconnected but they wouldn't normally notice that.  The popup alerts them that there is something wrong and the begin hammering the help desk phones.

When I use nslookup, set type=srv, _autodiscover.publicdomain.co.uk, that points to my cas server.  When I do an A record lookup, autodiscover.publicdomain.co.uk, that points to an unknown IP.  

The certificate is issued to: *.webserversystems.com

You need to delete the A record for autodiscover.publicdomain.co.uk. That should solve your issue.

-JJ

Ok, I think I figured it out.  There is no A record for "autodiscover.publicdomain.co.uk"  But there is one for "*.publicdomain.co.uk"  So is that why it is forwarding the "autodiscover" request there?  

If I were to remove the A record of "*.publicdomain.co.uk" how would that impact dns for our website?  There is an A record of "www.publicdomain.co.uk".  What if someone types just "publicdomain.co.uk" in a browser, would it still route them to our website?

Thanks,

I recommend against using a wildcard DNS record. You can create a DNS record for publicdomain.co.uk that points to your www server.

-JJ

What would that look like?  I can delete the "*." but what would the one I create look like to point "publicdomain.co.uk" to our www server?

When you create the new A record, leave the name blank. This will use the name of the parent domain. You would then just enter the IP address of your www server.

-JJ

Let me give that a try. Thanks,

Ok it won't let me change the "*." record because it says there is a conflict with another record.  I'm guessing one or more of the records are not necessary.  Here is what is listed:

www. A
@. A
*. A
mail. A
webmail. A
@. MX
_autodiscover. SRV
www. TXT

I don't think the @. A record is needed but wanted to double check.  Any others you see that are incorrect or redundant?  Thanks,

Scratch that...

I just need an A record for "publicdomain.co.uk".  Then a CNAME record for "www" that points to the A record "publicdomain.co.uk"?  

Is the "@." A record necessary?

Should the "@." MX record be "publicdomain.co.uk" and have an A record of "mail.publicdomain.co.uk" that points to the mail server?

The @ record is actually the one you want. Will it let you delete the * record?

-JJ

I was able to delete the * but I still can't create the blank record "publicdomain.co.uk"

The @ record is the blank one, so it already exists.

-JJ

Ok here is what I have now...

mail. A 2.2.2.2
webmail. A 3.3.3.3
@. A 1.1.1.1
www. A 1.1.1.1
@. MX 10 mail.publicdomain.co.uk
_autodiscover. SRV 10 10 443 webmail.publicdomain.co.uk
www. TXT "v=spf1 mx


The only record I could delete was the "*." when I tried to add jan A record with a blank host name, it added "@." back.

Ok it will take a few hours to propagate before I can test.


How is the @ record different from the * record?  

Thanks

The @ record just reference the part domain. So if you type in domain.com it direct to the IP you specify. The * record is a wildcard catch all. So, if someone types a host that doesn't exist in DNS is goes to the IP on this record. That is why you had trouble. You don't have an autodiscover record but this wildcard record was responding with an IP.

-JJ

Thank you for the explanation!  You rock!  I'll report back soon with the results.

I appreciate all of your help with this.  I do have one more question even though I already closed this.  When I run the Microsoft Remote Connectivity Analyzer it fails the first three tests but succeeds on the fourth(SRV).  The second test fails because we don't have a cert with a SAN.  The third fails because we block incoming 80 traffic.  The first fails and i know why but don't understand how to fix it.  I am asking because it relates to the dns changes.

Attempting to test potential Autodiscover URL https://publicdomain.co.uk/AutoDiscover/AutoDiscover.xml

When it resolves that, it points at our website, not our mail server because the @. record points publicdomain.co.uk to the website.  Is there a way to fix that without effecting the website or is that just the way it is?  Thanks again for all your help and time.  Greatly appreciated.

It is OK that it fails on those tests as long as it succeeds on one. In your case the SRV record. The test is replicating what Outlook does. Outlook has a list of autodiscover URLs it will try. When it fails on one, it moves to the next one until it either succeeds on one or fails on all of them.

-JJ

OK, thanks again!