Stand Alone DHCP Servers and Windows 2000

If I need to run a stand alone DHCP Server on a member server rather than on
a domain controller, how do I get the IP assignments seen by the domain
controller so they can be incorporated into Active Directory and DNS? On
the domain controller, I understand that I need to open up the DHCP
application and authorize the member server that will run DHCP. Is that
the only required step?

What protocol will the member server use to communicate back to the domain
controller? The two machines will be separated by a firewall, so I need
to create a firewall rule for any communications between the two machines.

--
Will

Will wrote:
> If I need to run a stand alone DHCP Server on a member server rather
> than on a domain controller, how do I get the IP assignments seen by
> the domain controller so they can be incorporated into Active
> Directory and DNS? On the domain controller, I understand that I
> need to open up the DHCP application and authorize the member server
> that will run DHCP. Is that the only required step?

Yes.

> What protocol will the member server use to communicate back to the
> domain controller? The two machines will be separated by a
> firewall, so I need to create a firewall rule for any communications
> between the two machines.

OK this bit is interesting. I gather that by "protocol", you're actually
asking which TCP/IP ports are likely to be used for all communication
between the two machines?

If the only reason you want this computer to be in the domain is to
"authorise" DHCP, then the best advice I can give you is do NOT make the
computer a member of the domain, and don't worry about authorising DHCP
because on a totally stand-alone server you do not have to.

If you do this, you've made your DHCP deployment easier, you've simplified
your firewall configuration, and you've improved your domain security by not
having a server outside your firewall that is a member of your domain.


--
--
Rob Moir, Microsoft MVP
Blog Site - http://www.robertmoir.com
Virtual PC 2004 FAQ - http://www.robertmoir.co.uk/win/VirtualPC2004FAQ.html
I'm always surprised at "professionals" who STILL have to be asked "Have you
checked (event viewer / syslog)".

For this particular network, both the clients and the domain controller are
protected internal networks behind a firewall. Neither is exposed to the
outside. We generally put a firewall between our internal clients and the
domain controller just to limit the scope of things that a virus can attack
directly on the domain controller. We also get some flexibility in which
machines can access the domain controller. That much has worked out fine.

Somehow the DHCP assignments need to be communicated to the domain
controller so it can update its DNS. I gather that the forward lookups
will appear on the domain controller's DNS simply by the client computers
sending those updates directly to the domain controller? What about the
reverse lookups? I had somehow imagined that the the member DHCP server
might communicate this reverse IP information back to the domain controller
via some proprietary protocol. If not, then I guess we would need to
install DNS on the DHCP server, and then exchange the reverse zone
information back to the domain controller via DNS? Or would we just
create the reverse zone as an AD integrated zone on the domain controller
and let it try to assemble this information on its own from the forward
zone?

--
Will


"Robert Moir" <robspamtrap+(E-Mail Removed)> wrote in message
news:#(E-Mail Removed)...
> Will wrote:
> > If I need to run a stand alone DHCP Server on a member server rather
> > than on a domain controller, how do I get the IP assignments seen by
> > the domain controller so they can be incorporated into Active
> > Directory and DNS? On the domain controller, I understand that I
> > need to open up the DHCP application and authorize the member server
> > that will run DHCP. Is that the only required step?
>
> Yes.
>
> > What protocol will the member server use to communicate back to the
> > domain controller? The two machines will be separated by a
> > firewall, so I need to create a firewall rule for any communications
> > between the two machines.
>
> OK this bit is interesting. I gather that by "protocol", you're actually
> asking which TCP/IP ports are likely to be used for all communication
> between the two machines?
>
> If the only reason you want this computer to be in the domain is to
> "authorise" DHCP, then the best advice I can give you is do NOT make the
> computer a member of the domain, and don't worry about authorising DHCP
> because on a totally stand-alone server you do not have to.
>
> If you do this, you've made your DHCP deployment easier, you've simplified
> your firewall configuration, and you've improved your domain security by
not
> having a server outside your firewall that is a member of your domain.
>
>
> --
> --
> Rob Moir, Microsoft MVP
> Blog Site - http://www.robertmoir.com
> Virtual PC 2004 FAQ -
http://www.robertmoir.co.uk/win/VirtualPC2004FAQ.html
> I'm always surprised at "professionals" who STILL have to be asked "Have
you
> checked (event viewer / syslog)".
>
>

"Will" <westes-(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ...
> For this particular network, both the clients and the domain controller
are
> protected internal networks behind a firewall. Neither is exposed to the
> outside. We generally put a firewall between our internal clients and
the
> domain controller just to limit the scope of things that a virus can
attack
> directly on the domain controller.

Firewalls don't stop viruses.

> Somehow the DHCP assignments need to be communicated to the domain
> controller so it can update its DNS. I gather that the forward lookups
> will appear on the domain controller's DNS simply by the client computers
> sending those updates directly to the domain controller? What about the
> reverse lookups? I had somehow imagined that the the member DHCP

Get rid of the firewall in the middle of the LAN.

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

I did not say firewalls stop viruses. I said a firewall *limits the scope
of things a virus can attack*. All the firewall does is narrow an attack
profile.

--
Will

"Phillip Windell" <@.> wrote in message
news:#(E-Mail Removed)...
> "Will" <westes-(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) ...
> > For this particular network, both the clients and the domain controller
> are
> > protected internal networks behind a firewall. Neither is exposed to
the
> > outside. We generally put a firewall between our internal clients and
> the
> > domain controller just to limit the scope of things that a virus can
> attack
> > directly on the domain controller.
>
> Firewalls don't stop viruses.
>
> --
> Phillip Windell [MCP, MVP, CCNA]
> www.wandtv.com
>
>

"Will" <westes-(E-Mail Removed)> wrote in message
news:zeydnQ90g73YH_fZRVn-(E-Mail Removed)...
> I did not say firewalls stop viruses. I said a firewall *limits the
scope
> of things a virus can attack*. All the firewall does is narrow an
attack
> profile.

Every virus I have ever been hit with would not have even been slowed down
by a firewall. The same thing the virus needs to communicate,..is the same
thing the LAN needs to function,...in fact the LAN usually needs more. So
you end up with the virus usually not even being slowed down while at the
same time the LAN doesn't function properly because the firewall it in its
way.

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

You make fair points, but I stand by the statement that a firewall limits
the scope of things a virus can attack. For the case where you separate a
client network from domain controllers by an ISA Server 2004 firewall, here
are some examples:

1) If someone accidentally left a web server running on a domain controller,
that is a major security disaster waiting to happen. With a firewall
separating the clients from the domain controllers, the clients cannot
exploit an administrator's sloppiness in leaving the service running there.

2) If you want to restrict a test lab from having any access to your
production domain controllers at all, the firewall gives you the flexibility
to carve out whole networks that cannot reach the domain controller on any
port. It's much harder to do that robustly on a purely routed network.
Since those low security environments like labs are precisely the place that
viruses can most easily grab hold of machines, it's nice to be able to carve
out exceptions.

3) You can restrict the flow of information out from the domain controller
network. So if a trojan does get planted there, it cannot do anything
useful to connect back out of the network.

4) You can enforce restrictions against the old style NetBIOS calls (137) by
forbidding access on those ports at all. That basically wipes out all of
the kiddy hackers, who rely widely on the complete insecurity of those
protocols.

Microsoft has published documents on which ports to expose between clients
and domain controllers. The only port that ever has caused us grief is
RPC, and that is solved by ISA Server 2004. Where it gets very very
challenging is if you want to dig down within RPC and restrict access to
only specific RPC services. We have done even that in a test environment
(even though everyone assured us it was impossible to do), but Microsoft's
organization and documentation of their own software's RPC usage is just
awful. You don't get a 100% reliable result when you restrict access
within RPC. But if you are willing to live with all RPC requests getting
through to your domain controller, it's possible to make a firewall work
extremely robustly and in a way that is transparent to the end user.

--
Will

"Phillip Windell" <@.> wrote in message
news:(E-Mail Removed)...
> "Will" <westes-(E-Mail Removed)> wrote in message
> news:zeydnQ90g73YH_fZRVn-(E-Mail Removed)...
> > I did not say firewalls stop viruses. I said a firewall *limits the
> scope
> > of things a virus can attack*. All the firewall does is narrow an
> attack
> > profile.
>
> Every virus I have ever been hit with would not have even been slowed down
> by a firewall. The same thing the virus needs to communicate,..is the
same
> thing the LAN needs to function,...in fact the LAN usually needs more. So
> you end up with the virus usually not even being slowed down while at the
> same time the LAN doesn't function properly because the firewall it in its
> way.
>
> --
> Phillip Windell [MCP, MVP, CCNA]
> www.wandtv.com
>
>

"Will" <westes-(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ...
> You make fair points, but I stand by the statement that a firewall limits
> the scope of things a virus can attack. For the case where you separate
a
> client network from domain controllers by an ISA Server 2004 firewall,
here
> are some examples:
>
> 1) If someone accidentally left a web server running on a domain
controller,
> that is a major security disaster waiting to happen. With a firewall
> separating the clients from the domain controllers, the clients cannot
> exploit an administrator's sloppiness in leaving the service running
there.

There is no "danger" that I see of having a web service running on the DC in
the context of a "virus". SBS for example is even meant to run with IIS on
it.

> 2) If you want to restrict a test lab from having any access to your
> production domain controllers at all, the firewall gives you the
flexibility
> to carve out whole networks that cannot reach the domain controller on any
> port.

That is a legitiment scenario. I use that here,..with ISA between them. But
the Lab has its own DC and does not depend nor need the other segments to
begin with,...so it isn't the same situation as having a firewall in the
middle of a LAN where the DCs and other resources on the opposite side of
the firewall are "needed" for normal funtionality.

> 3) You can restrict the flow of information out from the domain controller
> network. So if a trojan does get planted there, it cannot do anything
> useful to connect back out of the network.

That is done at the "edge" firewall not at one done in the middle of the
LAN. The solution is to properly maintain, configure and protect the DCs
themslves and not make a mess of the LAN by sticking a firewall in the
middle of it between the DC and the Clients the require it.

> 4) You can enforce restrictions against the old style NetBIOS calls (137)
by
> forbidding access on those ports at all.

Only in a "perfect world". The are still too many applications that require
NetBios to function. In my experiments with software on our LAN that must
have uptime of 100%, these are the protocols that are required. I have
verified them by not allowing them and having things fail. I spent several
days verifying these using ISA2004 as the "firewall" with a "routing"
relationship between the segments. Using a "nat" relationship would have
been nearly impossible because many of the protocols required bi-directional
travel.

These were needed across all users:................
HTTP, HTTPS
FTP
NNTP
DNS
Kerberos Sec (TCP)
Kerberos-Sec (UDP)
LDAP
LDAP (UDP)
Microsoft CIFS (TCP)
NetBios Datagram
Netbios Name Service
Netbios Session
NTP (UDP)
Ping
RPC (all Interfaces)

These were needed for certain users:.................
6341 TCP (proprietary)
2638 TCP (proprietary)
8000-8003 TCP (proprientary)
RDP (Terminal Services)


As a comparison, these are the only protocols allowed Outbound at the
network "edge".
HTTP/HTTPS
FTP
NNTP
(SMTP, POP3 are not used or allowed)

So.
By the time you account for all these protocols and "allow" them at a
firewall in the middle of the LAN, there really isn't any point in having
the firewall there to begin with.

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/IS...cessRules.html

Troubleshooting Client Authentication on Access Rules in ISA Server 2004
http://download.microsoft.com/downlo...7/ts_rules.doc

Microsoft Internet Security & Acceleration Server: Guidance
http://www.microsoft.com/isaserver/t...dance/2004.asp
http://www.microsoft.com/isaserver/t...dance/2000.asp

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.asp

Deployment Guidelines for ISA Server 2004 Enterprise Edition
http://www.microsoft.com/technet/pro...isaserver.mspx
-----------------------------------------------------

On our network the clients are allowed to talk to the domain controller
using just these:

DNS
Kerberos Sec (TCP)
Kerberos-Sec (UDP)
LDAP
LDAP (UDP)
Microsoft CIFS (TCP)
NTP (UDP)
RPC (all Interfaces)
[ maybe one more variant on the above, not sure right now.... ]

No NetBIOS here thank you very much. And yes you are right it is hellishly
hard to get rid of NetBIOS but we forced ourselves to live without it and to
fix whatever breaks without it to not use it. We used the firewall to have
the existing NetBIOS network continue to work as always, then we created new
client segments that use the far more restrictive ruleset. We migrate
each computer one at a time from the insecure segment to the secure one.

While I understand the huge pain that a firewall in the middle of the LAN
would cause most admins, once you go through the huge initial learning curve
and figure out how to make Windows work with just the above protocols, what
you end up with is a far more secure network. And the firewall is there to
*force* you to play by certain restricted protocol rules. Once we got
through the learning curve, I am here to tell you it works extremely
reliably, and I feel really empowered both by a better understanding of how
the different pieces are interacting, and by the ability to finely control
which segments and which computers use specific protocols.

I will say in defense of your point that it took us *months* to figure out
the internals of RPC well enough to be able to restrict inside the protocol
which RPCs can execute through the firewall, and I came away from that
pretty scared at how disorganized and random Microsoft's use of different
RPC services seems to be. If you can live with all RPC (what ISA Server
2004 calls "RPC (All Interfaces)" ) then inserting a firewall between the
client and domain controller is very doable as long as it is done in a way
that lets you slowly migrate each machine from an insecure existing network
to a new segment that is more secure.

I also will say in your defense that most admins spend so much time just
keeping the mess which is computing today working at all, that there is not
a lot of time to think about ideals like building a secure internal
infrastructure. Probably not a lot of managers would support the activity
either.

--
Will



"Phillip Windell" <@.> wrote in message
news:ur$(E-Mail Removed)...
> > 4) You can enforce restrictions against the old style NetBIOS calls
(137)
> by
> > forbidding access on those ports at all.
>
> Only in a "perfect world". The are still too many applications that
require
> NetBios to function. In my experiments with software on our LAN that must
> have uptime of 100%, these are the protocols that are required. I have
> verified them by not allowing them and having things fail. I spent several
> days verifying these using ISA2004 as the "firewall" with a "routing"
> relationship between the segments. Using a "nat" relationship would have
> been nearly impossible because many of the protocols required
bi-directional
> travel.
>
> These were needed across all users:................
> HTTP, HTTPS
> FTP
> NNTP
> DNS
> Kerberos Sec (TCP)
> Kerberos-Sec (UDP)
> LDAP
> LDAP (UDP)
> Microsoft CIFS (TCP)
> NetBios Datagram
> Netbios Name Service
> Netbios Session
> NTP (UDP)
> Ping
> RPC (all Interfaces)
>
> These were needed for certain users:.................
> 6341 TCP (proprietary)
> 2638 TCP (proprietary)
> 8000-8003 TCP (proprientary)
> RDP (Terminal Services)
>
>
> As a comparison, these are the only protocols allowed Outbound at the
> network "edge".
> HTTP/HTTPS
> FTP
> NNTP
> (SMTP, POP3 are not used or allowed)
>
> So.
> By the time you account for all these protocols and "allow" them at a
> firewall in the middle of the LAN, there really isn't any point in having
> the firewall there to begin with.
>
> --
> Phillip Windell [MCP, MVP, CCNA]
> www.wandtv.com
> -----------------------------------------------------
> Understanding the ISA 2004 Access Rule Processing
> http://www.isaserver.org/articles/IS...cessRules.html
>
> Troubleshooting Client Authentication on Access Rules in ISA Server 2004
>
http://download.microsoft.com/downlo...7/ts_rules.doc
>
> Microsoft Internet Security & Acceleration Server: Guidance
> http://www.microsoft.com/isaserver/t...dance/2004.asp
> http://www.microsoft.com/isaserver/t...dance/2000.asp
>
> Microsoft Internet Security & Acceleration Server: Partners
> http://www.microsoft.com/isaserver/partners/default.asp
>
> Deployment Guidelines for ISA Server 2004 Enterprise Edition
>
http://www.microsoft.com/technet/pro...isaserver.mspx
> -----------------------------------------------------
>
>
>

Ok, sounds good.
On your original quesiton about DNS not updating itself,..I believe that is
the difference between "secure" and "unsecure" updates which is controled in
the configuration of the DNS Service itself. Each Zone (forward or reverse)
has these settings independently.
I'm not entirely positive about "who" causes the update (DHCP or the
Client), but I think it is both. In the Properties of the DHCP Service, in
the DNS Tab there are setting pertaining to this. However "static" Clients
also get themselves entered into the DNS and have no dealings with DHCP. The
AD DNS will also populate based on the contents of Active Directory.

I don't remember ever having the create Reverse Zones myself,...they were
just "there" on thier own. If I ever did create them,..I have forgot that I
did it.

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com




"Will" <westes-(E-Mail Removed)> wrote in message
news:Q96dnVDlKu4f1-vZRVn-(E-Mail Removed)...
> On our network the clients are allowed to talk to the domain controller
> using just these:
>
> DNS
> Kerberos Sec (TCP)
> Kerberos-Sec (UDP)
> LDAP
> LDAP (UDP)
> Microsoft CIFS (TCP)
> NTP (UDP)
> RPC (all Interfaces)
> [ maybe one more variant on the above, not sure right now.... ]
>
> No NetBIOS here thank you very much. And yes you are right it is
hellishly
> hard to get rid of NetBIOS but we forced ourselves to live without it and
to
> fix whatever breaks without it to not use it. We used the firewall to
have
> the existing NetBIOS network continue to work as always, then we created
new
> client segments that use the far more restrictive ruleset. We migrate
> each computer one at a time from the insecure segment to the secure one.
>
> While I understand the huge pain that a firewall in the middle of the LAN
> would cause most admins, once you go through the huge initial learning
curve
> and figure out how to make Windows work with just the above protocols,
what
> you end up with is a far more secure network. And the firewall is there
to
> *force* you to play by certain restricted protocol rules. Once we got
> through the learning curve, I am here to tell you it works extremely
> reliably, and I feel really empowered both by a better understanding of
how
> the different pieces are interacting, and by the ability to finely control
> which segments and which computers use specific protocols.
>
> I will say in defense of your point that it took us *months* to figure out
> the internals of RPC well enough to be able to restrict inside the
protocol
> which RPCs can execute through the firewall, and I came away from that
> pretty scared at how disorganized and random Microsoft's use of different
> RPC services seems to be. If you can live with all RPC (what ISA Server
> 2004 calls "RPC (All Interfaces)" ) then inserting a firewall between the
> client and domain controller is very doable as long as it is done in a way
> that lets you slowly migrate each machine from an insecure existing
network
> to a new segment that is more secure.
>
> I also will say in your defense that most admins spend so much time just
> keeping the mess which is computing today working at all, that there is
not
> a lot of time to think about ideals like building a secure internal
> infrastructure. Probably not a lot of managers would support the
activity
> either.
>
> --
> Will
>
>
>
> "Phillip Windell" <@.> wrote in message
> news:ur$(E-Mail Removed)...
> > > 4) You can enforce restrictions against the old style NetBIOS calls
> (137)
> > by
> > > forbidding access on those ports at all.
> >
> > Only in a "perfect world". The are still too many applications that
> require
> > NetBios to function. In my experiments with software on our LAN that
must
> > have uptime of 100%, these are the protocols that are required. I have
> > verified them by not allowing them and having things fail. I spent
several
> > days verifying these using ISA2004 as the "firewall" with a "routing"
> > relationship between the segments. Using a "nat" relationship would
have
> > been nearly impossible because many of the protocols required
> bi-directional
> > travel.
> >
> > These were needed across all users:................
> > HTTP, HTTPS
> > FTP
> > NNTP
> > DNS
> > Kerberos Sec (TCP)
> > Kerberos-Sec (UDP)
> > LDAP
> > LDAP (UDP)
> > Microsoft CIFS (TCP)
> > NetBios Datagram
> > Netbios Name Service
> > Netbios Session
> > NTP (UDP)
> > Ping
> > RPC (all Interfaces)
> >
> > These were needed for certain users:.................
> > 6341 TCP (proprietary)
> > 2638 TCP (proprietary)
> > 8000-8003 TCP (proprientary)
> > RDP (Terminal Services)
> >
> >
> > As a comparison, these are the only protocols allowed Outbound at the
> > network "edge".
> > HTTP/HTTPS
> > FTP
> > NNTP
> > (SMTP, POP3 are not used or allowed)
> >
> > So.
> > By the time you account for all these protocols and "allow" them at a
> > firewall in the middle of the LAN, there really isn't any point in
having
> > the firewall there to begin with.
> >
> > --
> > Phillip Windell [MCP, MVP, CCNA]
> > www.wandtv.com
> > -----------------------------------------------------
> > Understanding the ISA 2004 Access Rule Processing
> > http://www.isaserver.org/articles/IS...cessRules.html
> >
> > Troubleshooting Client Authentication on Access Rules in ISA Server 2004
> >
>
http://download.microsoft.com/downlo...7/ts_rules.doc
> >
> > Microsoft Internet Security & Acceleration Server: Guidance
> > http://www.microsoft.com/isaserver/t...dance/2004.asp
> > http://www.microsoft.com/isaserver/t...dance/2000.asp
> >
> > Microsoft Internet Security & Acceleration Server: Partners
> > http://www.microsoft.com/isaserver/partners/default.asp
> >
> > Deployment Guidelines for ISA Server 2004 Enterprise Edition
> >
>
http://www.microsoft.com/technet/pro...isaserver.mspx
> > -----------------------------------------------------
> >
> >
> >
>
>