One Post to Sum It All Up

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

One Post to Sum it All Up

I am going to consolidate my problems into this post to try and see if
anyone can help me with my problems, maybe they are related?

1) DNS
I am not suure I have my DNS configured conrrectly. I have a DNS server in
the Permieter Network that is my authoratative DNS for conseptsolutions.com
Currently it's IP is set to 192.168.0.2. I have 2 public IP's from my
provider, both are assigned to the external interface of the ISA Firewall. I
aslo have a DNS server in the Internal Segment which is my Active Directory
Controller/Exchange 2003 server. Currently my DNS records are set up as
follows:

CONSOLNS01-External Auth. DNS (consolns01.conseptsolutions.com)
Same As Parent NS ns1.conseptsolutions.com
Same As Patent NS ns2.conseptsolutions.com
Same As Parent A 70.182.188.196
Same As Parent MX consolsrv01.conseptsolutions.com
ns1 A 70.182.188.196
ns2 A 70.182.188.196
www A 70.182.188.197
consolsrv01 A 70.182.188.196

CONSOLSRV01-Internal AD DNS (consolsrv01.conseptsolutions.com
Same As Parent NS consolsrv01.conseptsolutions.com
Same As Parent A 10.0.0.2
consolsrv01 A 10.0.0.2
webserver A 192.168.0.2
www CNAME webserver.conseptsolutions.com
wpad CNAME consolisa01.conseptsolutions.com
consollap01 A 192.168.1.100 (internal lan client laptop)

I would really appreciate any help in getting my DNS settings correct.

2) Remote Desktop / Terminal Services
I have followed the guide on isaserver.org entitled "Publishing Terminal
Servers with ISA Firewalls (2004) v1.1" to enable access to my servers from
an external source. I have assigned three ports to the publishing rules,
9999, 9998, & 9997. I can remote my ISA Firewall via the external IP:port
however, when I am at a remote location and try to remote either of the
internal/permieter servers via external IP:port, I receive an error message
stating the remote machines cannot be contacted, network problems may be
preventing you from accessing these recources, ensure remote administration
is enabled, etc. I can remote to the ISA Firewall and then bring up a remote
desktop connection to either 192.168.0.2 or 10.0.0.2 and gain access to the
servers. I do not even see anything on the logs when I try and remote to the
internal/perimeter servers? I also noticed that I cannot log into the domain
on the Perimeter server while I am remoted into it. I can log into the domain
without problems if I was sitting at the server locally. Any suggestions?

3)OWA / Email -- Biggest Problem, want to try and get it working!!!
As the network is configured right now, I can send and receive email from
Outlook 2003 on my laptop. I am trying to

get Outlook Web Access (OWA) configured correctly, and believe that my DNS
settings may be causing problems, but am

not 100% sure on that. I can access OWA from my AD server using the web
address https://consolsrv01.conseptsolutions.com/exchange I am prompted with
the certificate warning and a credentials box is displayed. I type in my
credentials for the domain and I am brought right into OWA. I am not sure if
this is how it is suposed to work from inside the domain, or if that is the
correct address (a simple CNAME or A record might fix that for internal
requests).
What I am having mucho troubles with is the external access to OWA. I have
issued certificates to the Exchange 2003 server and also imported the
certificate/public key to the ISA Firewall as described in an articl from
msexchange.org. I would really like to get OWA configured properly.
Main questions being, the certificate is issued with a comon name:
owa.conseptsoltuions.com How/what type of DNS entry is required for this to
work and what type of publishing rule (can I use the publishing wizard with
OWA option) for this to work. The guide says to use FBA, which I have chosen.

These are my remaining problems and would be greatful to anyone who could
help me resolve them. Really summing it up, OWA is my biggest concern. I want
that to be up and running. I can manage with the Remote Desktop for now and
play around with some settings. Thanks in advance, and please don't hesitate
to ask any questions. I appologize for the lengthly post.

Bryan
 
Bryan said:
One Post to Sum it All Up

I am going to consolidate my problems into this post to try and see if
anyone can help me with my problems, maybe they are related?

It generally works best if you post the actual problems up
front (with a meaningful subject line) so that those who
feel they can help can decide whether to read all the gory
details....

You will get more (useful) responses that way most of the time.
I would really appreciate any help in getting my DNS settings correct.

Do you have any PROBLEMS with name resolution?

....or even authentication and replication which are
frequently DNS problems?
1) DNS
I am not suure I have my DNS configured conrrectly. I have a DNS server in
the Permieter Network that is my authoratative DNS for
conseptsolutions.com

Generally better to let your REGISTRAR hold you
public DNS.
Currently it's IP is set to 192.168.0.2. I have 2 public IP's from my
provider, both are assigned to the external interface of the ISA Firewall. I
aslo have a DNS server in the Internal Segment which is my Active Directory
Controller/Exchange 2003 server. Currently my DNS records are set up as
follows:

More important would be to know if you have
all your INTERNAL DNS clients pointing SOLELY
to your internal DNS server set -- this includes DCs
and the internal DNS server which are DNS clients
too.

DNS for AD
1) Dynamic for the zone supporting AD
2) All internal DNS clients NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2

Restart NetLogon on any DC if you change any of the above that
affects a DC and/or use:

nltest /dsregdns /server:DC-ServerNameGoesHere

Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.
I would really appreciate any help in getting my DNS settings correct.

Also run DCDiag on all DCs and send the output (DCDiad /?)
to a text file -- don't bother with any other switches -- search
the text file for FAIL, WARN, IGNORE.

Fix those or report specific errors and problems.
2) Remote Desktop / Terminal Services
I have followed the guide on isaserver.org entitled "Publishing Terminal
Servers with ISA Firewalls (2004) v1.1" to enable access to my servers from
an external source. I have assigned three ports to the publishing rules,
9999, 9998, & 9997. I can remote my ISA Firewall via the external IP:port
however, when I am at a remote location and try to remote either of the

You will do better on the ISA newsgroups with this stuff.

And again, give the problems you are experiencing.

3)OWA / Email -- Biggest Problem, want to try and get it working!!!
As the network is configured right now, I can send and receive email from
Outlook 2003 on my laptop. I am trying to

get Outlook Web Access (OWA) configured correctly, and believe that my DNS
settings may be causing problems, but am

not 100% sure on that. I can access OWA from my AD server using the web
address https://consolsrv01.conseptsolutions.com/exchange I am prompted with
the certificate warning and a credentials box is displayed. I type in my
credentials for the domain and I am brought right into OWA. I am not sure if
this is how it is suposed to work from inside the domain, or if that is the
correct address (a simple CNAME or A record might fix that for internal
requests).

Generally you would prefer to reach OWA by a simple name
or from a link on another web page, e.g., www.conceptsolutions.com
with link, or mail.conceptsolutions.com, or webmail.....

CNAMEs can help. Or A records.
What I am having mucho troubles with is the external access to OWA. I have
issued certificates to the Exchange 2003 server and also imported the
certificate/public key to the ISA Firewall as described in an articl from
msexchange.org. I would really like to get OWA configured properly.
Main questions being, the certificate is issued with a comon name:
owa.conseptsoltuions.com How/what type of DNS entry is required for this to
work and what type of publishing rule (can I use the publishing wizard with
OWA option) for this to work. The guide says to use FBA, which I have
chosen.

The above is pretty much a ramble but you again
will do better with the OWA or Exchange newsgroups.

More experts per message read.
These are my remaining problems and would be greatful to anyone who could
help me resolve them. Really summing it up, OWA is my biggest concern. I want
that to be up and running. I can manage with the Remote Desktop for now and
play around with some settings. Thanks in advance, and please don't hesitate
to ask any questions. I appologize for the lengthly post.

Clarify your problems. State them clearly. Then provide
the details.

Many times the people here have heard the problems so
many times they can give you the answer or the two most
likely answers from almost no detail but they need a clear
problem or clearly reported symptoms.
 
In
Bryan said:
One Post to Sum it All Up

I am going to consolidate my problems into this post to
try and see if anyone can help me with my problems, maybe
they are related?

1) DNS
I am not suure I have my DNS configured conrrectly. I
have a DNS server in the Permieter Network that is my
authoratative DNS for conseptsolutions.com Currently it's
IP is set to 192.168.0.2. I have 2 public IP's from my
provider, both are assigned to the external interface of
the ISA Firewall. I aslo have a DNS server in the
Internal Segment which is my Active Directory
Controller/Exchange 2003 server. Currently my DNS records
are set up as follows:

CONSOLNS01-External Auth. DNS
(consolns01.conseptsolutions.com)
Same As Parent NS ns1.conseptsolutions.com
Same As Patent NS ns2.conseptsolutions.com
Same As Parent A 70.182.188.196
Same As Parent MX consolsrv01.conseptsolutions.com
ns1 A 70.182.188.196
ns2 A 70.182.188.196
www A 70.182.188.197
consolsrv01 A 70.182.188.196

CONSOLSRV01-Internal AD DNS
(consolsrv01.conseptsolutions.com
Same As Parent NS consolsrv01.conseptsolutions.com
Same As Parent A 10.0.0.2
consolsrv01 A 10.0.0.2
webserver A 192.168.0.2
www CNAME webserver.conseptsolutions.com
wpad CNAME consolisa01.conseptsolutions.com
consollap01 A 192.168.1.100 (internal lan client laptop)

I would really appreciate any help in getting my DNS
settings correct.

2) Remote Desktop / Terminal Services
I have followed the guide on isaserver.org entitled
"Publishing Terminal Servers with ISA Firewalls (2004)
v1.1" to enable access to my servers from an external
source. I have assigned three ports to the publishing
rules, 9999, 9998, & 9997. I can remote my ISA Firewall
via the external IP:port however, when I am at a remote
location and try to remote either of the
internal/permieter servers via external IP:port, I
receive an error message stating the remote machines
cannot be contacted, network problems may be preventing
you from accessing these recources, ensure remote
administration is enabled, etc. I can remote to the ISA
Firewall and then bring up a remote desktop connection to
either 192.168.0.2 or 10.0.0.2 and gain access to the
servers. I do not even see anything on the logs when I
try and remote to the internal/perimeter servers? I also
noticed that I cannot log into the domain on the
Perimeter server while I am remoted into it. I can log
into the domain without problems if I was sitting at the
server locally. Any suggestions?

3)OWA / Email -- Biggest Problem, want to try and get it
working!!!
As the network is configured right now, I can send and
receive email from Outlook 2003 on my laptop. I am trying
to

get Outlook Web Access (OWA) configured correctly, and
believe that my DNS settings may be causing problems, but
am

not 100% sure on that. I can access OWA from my AD server
using the web address
https://consolsrv01.conseptsolutions.com/exchange I am
prompted with the certificate warning and a credentials
box is displayed. I type in my credentials for the domain
and I am brought right into OWA. I am not sure if this is
how it is suposed to work from inside the domain, or if
that is the correct address (a simple CNAME or A record
might fix that for internal requests).
What I am having mucho troubles with is the external
access to OWA. I have issued certificates to the Exchange
2003 server and also imported the certificate/public key
to the ISA Firewall as described in an articl from
msexchange.org. I would really like to get OWA configured
properly.
Main questions being, the certificate is issued with a
comon name: owa.conseptsoltuions.com How/what type of DNS
entry is required for this to work and what type of
publishing rule (can I use the publishing wizard with OWA
option) for this to work. The guide says to use FBA,
which I have chosen.

These are my remaining problems and would be greatful to
anyone who could help me resolve them. Really summing it
up, OWA is my biggest concern. I want that to be up and
running. I can manage with the Remote Desktop for now and
play around with some settings. Thanks in advance, and
please don't hesitate to ask any questions. I appologize
for the lengthly post.

This is not a DNS issue, the problem is your certificate. It works but it is
only going to be a trusted certificate for users who have installed your
certificate services as a trusted root certificate. You can purchase a
certificate for your server from a published CA or publish your own CA
certificate services, in which case to alleviate the warning your users will
need to install your CA server certificate as a trusted root.
You can also set your CA up a subordinate CA for an already published CA
that has root certificates already installed with most browsers. you might
contact your registrar for these certificates.
 
Herb Martin said:
More important would be to know if you have
all your INTERNAL DNS clients pointing SOLELY
to your internal DNS server set -- this includes DCs
and the internal DNS server which are DNS clients
too.

DNS for AD
1) Dynamic for the zone supporting AD
2) All internal DNS clients NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2

Restart NetLogon on any DC if you change any of the above that
affects a DC and/or use:

nltest /dsregdns /server:DC-ServerNameGoesHere

Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.


Also run DCDiag on all DCs and send the output (DCDiad /?)
to a text file -- don't bother with any other switches -- search
the text file for FAIL, WARN, IGNORE.

Fix those or report specific errors and problems.
My clients/servers and AD Controller (which is the internal DNS) is pointing
to the internal DNS server. I do not have any references to the DNS server
from my provider on any of my servers. All clients and servers are looking
at my DNS servers for name resolution. I have no problems with name
resolution for external sources such as www.yahoo.com, but really I guess
what I am looking for is clarification on how to configure my authoratative
DNS and internal DNS correctly. I know I should not have any internal IP
references in my external DNS and I have removed those. I just want to know
that I have a good working and correct setup.
Generally you would prefer to reach OWA by a simple name
or from a link on another web page, e.g., www.conceptsolutions.com
with link, or mail.conceptsolutions.com, or webmail.....

CNAMEs can help. Or A records.
What I was saying above is that I can access the OWA from internal by typing
in that address, but I'm not sure if that is exactly how it should work. I
could make a CNAME or A record for owa to make it easier, that way the
address would be https://owa.conseptsolutions.com Is the way I have
described it above the correct way it should be working, at least for clients
accessing it from the internal network? I will post a question regarding
this in the Exchange section. Thanks for the reply and information.

Bryan
 
Also run DCDiag on all DCs and send the output (DCDiad /?)
My clients/servers and AD Controller (which is the internal DNS) is pointing
to the internal DNS server. I do not have any references to the DNS server
from my provider on any of my servers. All clients and servers are looking
at my DNS servers for name resolution.

Then all is well with DNS?

Some people try to put both internal and external DNS
server entries on the internal clients. (That's wrong of course.)
I have no problems with name
resolution for external sources such as www.yahoo.com,

Then you are likely using FORWARDING (tab in the DNS
MMC) to forward from the Internal DNS servers to your own
or the ISP DNS server on the net -- that's the best way.
but really I guess
what I am looking for is clarification on how to configure my authoratative
DNS and internal DNS correctly.

If they are exposed on the Internet you delegate to them
from the parent -- by merely registrering them when/where
you bought the public DNS name.

You will be better served [intended] if you move the public
DNS back to the registrar however (or find one that does this.)

GoDaddy and Register.com do this, and you still maintain your
own records (through a web interface.)
I know I should not have any internal IP
references in my external DNS and I have removed those. I just want to know
that I have a good working and correct setup.

Just MANUALLY duplicate (almost) all external records
on the internal DNS servers if you use the same internal and
external DNS name -- this is split DNS -- so that internal
machines can resolve external names.

The reason for the two Primary/Master DNS servers is so
that INTERNAL names will NOT replicate to the outside,
since as you say we don't want those exposed.
What I was saying above is that I can access the OWA from internal by typing
in that address, but I'm not sure if that is exactly how it should work. I
could make a CNAME or A record for owa to make it easier, that way the
address would be https://owa.conseptsolutions.com

Sure, or anything else you and your users can easily remember
and understand.
Is the way I have
described it above the correct way it should be working, at least for clients
accessing it from the internal network? I will post a question regarding
this in the Exchange section. Thanks for the reply and information.

Sounds like it all works.
 
In Kevin D. Goodknecht Sr. [MVP] <[email protected]> made a post then I
commented below
:: This is not a DNS issue, the problem is your certificate. It works
:: but it is only going to be a trusted certificate for users who have
:: installed your certificate services as a trusted root certificate.
:: You can purchase a certificate for your server from a published CA
:: or publish your own CA certificate services, in which case to
:: alleviate the warning your users will need to install your CA server
:: certificate as a trusted root.
:: You can also set your CA up a subordinate CA for an already
:: published CA that has root certificates already installed with most
:: browsers. you might contact your registrar for these certificates.


Just an FYI, here's how much they cost from Verisign, depending whether
choosing a 40bit or 128bit cert. If 128bit is chosen, and a user doesn't
have the high encryption pack installed, then it won't work. I've chosen a
40bit cert for most of my clients. It's easier to deal with in case someone
has an operating system that doesn't support 128bit.

http://www.verisign.com/products-services/security-services/ssl/ssl-certificate/index.html


--
Regards,
Ace

G O E A G L E S !!!
Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.

This posting is provided "AS-IS" with no warranties or guarantees
and confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft Windows MVP - Windows Server - Directory Services

Security Is Like An Onion, It Has Layers
HAM AND EGGS: A day's work for a chicken;
A lifetime commitment for a pig.
 
Just an FYI, here's how much they cost from Verisign, depending whether
choosing a 40bit or 128bit cert. If 128bit is chosen, and a user doesn't
have the high encryption pack installed, then it won't work. I've chosen a
40bit cert for most of my clients. It's easier to deal with in case someone
has an operating system that doesn't support 128bit.
http://www.verisign.com/products-services/security-services/ssl/ssl-certificate/index.html

Doesn't that pretty much guarantee that the
encryption can be busted by most 12-year
olds with a 386?

If they could have intercepted the plain text,
it pretty much negates the value of the certificate
except to scam people into thinking it will
work.
 
In Herb Martin <[email protected]> made a post then I commented below
:: Doesn't that pretty much guarantee that the
:: encryption can be busted by most 12-year
:: olds with a 386?
::
:: If they could have intercepted the plain text,
:: it pretty much negates the value of the certificate
:: except to scam people into thinking it will
:: work.

The big issue is compatbility. Not everyone is 128bit capable.

Ace
 
In
Herb Martin said:
http://www.verisign.com/products-services/security-services/ssl/ssl-certificate/index.html

Doesn't that pretty much guarantee that the
encryption can be busted by most 12-year
olds with a 386?

If they could have intercepted the plain text,
it pretty much negates the value of the certificate
except to scam people into thinking it will
work.

Ace is correct Herb, the problem is certificate compatibility in the
browser. All certificates follow a hierarchy, if the root is trusted all
below it will be trusted. If the has a limited user base he can distribute
his CA Root only to those users. If he plans on having an extensive user
base, like some one browsing in and purchasing something off his site, he'd
have to go with a commercial site certificate from a Root CA that is already
installed in most browsers. Verisign is the most well known and also
probably the most expensive. You can also purchase SSL certificates from
most registrars that already have its Root Certificate installed and
trusted, then he won't get the warning.

The problem is not the encryption level, he is using a SSL certificate
published by the CA included with Win2k. This certificate would support
128bit or 40bit if, you installed the CA Cert as a Trusted Root. You have to
look at the Cert. Details in the security warning to see that the
certificate is OK, it is the CA Root that is not trusted.
 
Kevin D. Goodknecht Sr. said:


I understand well the issues of public-commercial certs,
but he claimed he was using only 40-bit security.

There is little reason to bother with 40-bit security.
It is not even a full step more secure than MIME-encoding.
 
Back
Top