• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1438
  • Last Modified:

ISA best practice report - secure channel to the domain controller cannot be verified

Hi all,

i just ran the ISA best practice report tool and came back with a few errors, just wondering if anyone can help me out with them

as in the title secure channel to the domain controller cannot be verified - i looked in the system policy (see below)
and it all looks up and allowed

the version is ISA 2004 and is installed on sbs server

the no connectivity error, doesnt matter about that one thats about a connection to an external company

Thanks
system-policy.png
BPR.png
0
awilderbeast
Asked:
awilderbeast
  • 3
  • 2
1 Solution
 
pwindellCommented:
I suspect the BPA you ran does not work correctly on SBS.  SBS lives in its own little world. What is true in the real world in not true in the SBS world,...and what is true in the SBS world is not true in the real of the world.

If the ISA was not communicating with Active Directlry services,...it would become obvious without having to have the BPA tell you about it.

But you Certificate error is definiately a problem.

0
 
awilderbeastAuthor Commented:
i darent play around with the certificates anymore after it took me so long to get owa and activesync working
0
 
pwindellCommented:
The "Certificate not matching the Public Name" is a serious Cert problem,...it is not going to "go away".   So however you have it working,...it isn't working correctly.  If the Cert does not match the Public Name then it is as if the Cert does not exist.

You can do what you want with it,..it rests on you.  But I feel responsible to make sure you are properly warned.


0
 
awilderbeastAuthor Commented:
how would i go about assessing the problem before i make any changes?

can you guide me through and help me sort it?

cheers
0
 
pwindellCommented:
It is a simple thing.  Think of these terms,...common name,....public name,....FQDN,....Hosts Headers,.....well guess what,...they all mean the same thing with just a little different focus.  So if your OWA site is recognized from the Internet as:

webmail.mycompany.org

Then the Certificate has to be specifically purchased for exactly "webmail.mycompany.org"
And then the names above are like this:

common name = webmail.mycompany.org
public name = webmail.mycompany.org
FQDN = webmail.mycompany.org
Hosts Header = webmail.mycompany.org

So in the Publishing Rule for OWA,...anytime any of these names are asked for,...you answer it with "webmail.mycompany.org",...no matter what.   Never ever ever use an IP# at all in the Rule anywhere.  The Listener might have an External IP# only if there is more that one external IP on the SBS box,...but if there is only one IP# then it only needs to be specificed as External.

Now the other half of the picture is your DNS.  It has to be correctly done,...no compromises!
People out in Internet Land don't use your DNS,...so they are irrelevant.   But your users and the ISA use your DNS (and only your DNS),..so they are completely and totally relevant. Every single host on the LAN needs to use your AD/DNS and never anything else.  Even the SBS Box only uses itself,...and it does that only on the Internal facing Nic,...the external facing Nic must have the DNS left blank.  In the config of the DNS Service you can add an external DNS IP# as a Forwarder and make sure the SBS is allowed to make outbound DNS queries.

You have to create a Split DNS Setup so that as far as your Users and your ISA are concerned the name "webmail.mycompany.org" will always resolve the private internal IP# that the OWA site runs at.   So the Publishing Rule for ISA will send the incomming OWA traffic to the Private IP# of the OWA by correctly resolving "webmail.mycompany.org".

Your LAN users is even more simple,...they go directly to the OWA site at the private IP#.  Since this is SBS with Exchange, IIS, OWA and ISA on the same box this may require an Access Rule for HTTP/HTTPS that runs between Internal to Localhost or it could be Internal to <OWA IP#>.

One last thing,....I am not an SBS guy.  It would be a smart thing to do to run what I am saying past someone more experienced with SBS incase what I said needs tweeked a little bit.
0

Featured Post

[Webinar] Cloud and Mobile-First Strategy

Maybe you’ve fully adopted the cloud since the beginning. Or maybe you started with on-prem resources but are pursuing a “cloud and mobile first” strategy. Getting to that end state has its challenges. Discover how to build out a 100% cloud and mobile IT strategy in this webinar.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now