DHCP: How to prevent a client from obtaining an IP address

How would one go about denying a specific client (or clients) the
ability to obtain an IP address, preferably based on their MAC address?

I looked in the Reservations section of the Scope I'm interested in, and
all it says about it is that "an exclusion prevents a DHCP client from
ever obtaining an address from a specified range. Exclusion ranges can
be defined in Address Pool."

But all it seems to want to let me do is exclude a range of IPs. What I
want to do is totally deny a client from even obtaining an IP address at
all (i.e. set up a black hole).

I tried various things re: address pool exclusions and reservations, but
what it wants to let me do make no sense to me.

I can find nothing about this in the help system or knowledgebase search.

Is this even possible with the Windows DHCP server?

Thanks much,
-Marc

Why not try making a reservation for the MAC address of the machine
(seeing that you want to use that) that gives them an address that
doesn't work. I would create a dummy scope (10.10.10.1-254) and then
reserve that for those MAC addresses.

Marc Holland wrote:
> How would one go about denying a specific client (or clients) the
> ability to obtain an IP address, preferably based on their MAC address?
>
> I looked in the Reservations section of the Scope I'm interested in, and
> all it says about it is that "an exclusion prevents a DHCP client from
> ever obtaining an address from a specified range. Exclusion ranges can
> be defined in Address Pool."
>
> But all it seems to want to let me do is exclude a range of IPs. What I
> want to do is totally deny a client from even obtaining an IP address at
> all (i.e. set up a black hole).
>
> I tried various things re: address pool exclusions and reservations, but
> what it wants to let me do make no sense to me.
>
> I can find nothing about this in the help system or knowledgebase search.
>
> Is this even possible with the Windows DHCP server?
>
> Thanks much,
> -Marc

Marc Holland <(E-Mail Removed)> wrote in
news:#(E-Mail Removed):

> How would one go about denying a specific client (or clients) the
> ability to obtain an IP address, preferably based on their MAC address?
>
> I looked in the Reservations section of the Scope I'm interested in, and
> all it says about it is that "an exclusion prevents a DHCP client from
> ever obtaining an address from a specified range. Exclusion ranges can
> be defined in Address Pool."
>
> But all it seems to want to let me do is exclude a range of IPs. What I
> want to do is totally deny a client from even obtaining an IP address at
> all (i.e. set up a black hole).
>
> I tried various things re: address pool exclusions and reservations, but
> what it wants to let me do make no sense to me.
>
> I can find nothing about this in the help system or knowledgebase search.
>
> Is this even possible with the Windows DHCP server?
>
> Thanks much,
> -Marc

Hi Marc --

Just to clarify -- a reservation ensures that a specific DHCP client,
identified by MAC addr, receives a specific IP address from the DHCP
server.

An exclusion range is used to prevent the DHCP *server* from leasing the
excluded addresses; this is typically used for circumstances where the
excluded addresses are used to configure printers, routers, and other
devices with static IP addresses.

The other poster's suggestion of creating a reservation for a "bad" IP
address is a good idea and might work, but it doesn't completely block a
host from the network. To do that, you need an 802.1X authenticating
switch, which when used with IAS allows you to keep unauthorized computers
and users from connecting to the network or getting any kind of IP address.
(They don't get an IP address from DHCP until after they are authenticated
and authorized to access the network by IAS.)

If you are interested in the L3 switch idea, the deployment paper is
"Deployment of IEEE 802.1X for Wired Networks Using Microsoft Windows" at
http://www.microsoft.com/downloads/d...05951071-6b20-
4cef-9939-47c397ffd3dd&DisplayLang=en

--
James McIllece, Microsoft

Please do not send email directly to this alias. This is my online account
name for newsgroup participation only.

This posting is provided "AS IS" with no warranties, and confers no rights.

Except for 802.1x that James mentioned, you really need to consider the physical
security of the building itself. A "stranger" should not be allowed to gain
physical access to a wall jack that is DHCP endabled on that "wire".

In our building there are no "free" wall jacks in the public part of the
building. You can also make the public areas of the building Wireless using
WEP, WPA, PEAP, (or whatever),...they can't get an IP# until they authenticate
with the Wireless devices first and they can not do that if you don't give them
to tools to do it. With a good WAP you can reduce the signal power so that it
doesn't reach clear across the parking lot and down the street also. You do a
Site Survey and make sure the signal reaches only as far as you want it to.

On the "wired side" our internet access and access to all LAN resources are
carefully controlled by user account, not by IP#,...so an IP# does not give them
"squat". Even Internet access is based on user accounts and the "path" out to
the Internet does not even use the "Default Path" of the LAN so they can use
their wildest imaginations for a Default Gateway and accomplish nothing.

In our conference room, the jack available to "guests" runs through an isolated
"NAT Device" and goes right out into the public side of the system,...they are
never "on the LAN". If they don't use the provided NAT Device, there is no DHCP
on that "wire" so they can't get an address, and they wouldn't know what Public
IP# to configure their laptop with, so they wouldn't get anywhere.

As far as them bringing in a virus,...we have virus protection out the "wazzoo"
in half a dozen different ways. I'm not worried at all about that.

So in the end, having them "get an IP#" isn't that big a deal when you deal with
the big picture and don't put all your "security eggs in one basket".

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

The views expressed (as annoying as they are, and as stupid as they sound), are
my own and not those of my employer, or Microsoft, or anyone else associated
with me, including my cats.
-----------------------------------------------------
"Marc Holland" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> How would one go about denying a specific client (or clients) the ability to
> obtain an IP address, preferably based on their MAC address?
>
> I looked in the Reservations section of the Scope I'm interested in, and all
> it says about it is that "an exclusion prevents a DHCP client from ever
> obtaining an address from a specified range. Exclusion ranges can be defined
> in Address Pool."
>
> But all it seems to want to let me do is exclude a range of IPs. What I want
> to do is totally deny a client from even obtaining an IP address at all (i.e.
> set up a black hole).
>
> I tried various things re: address pool exclusions and reservations, but what
> it wants to let me do make no sense to me.
>
> I can find nothing about this in the help system or knowledgebase search.
>
> Is this even possible with the Windows DHCP server?
>
> Thanks much,
> -Marc

Kirrin, James, Phillip:

Thanks all for your helpful info. I did setup a dummy scope, though no
longer need it, so I deactivated it. We had a machine in a building
where there are no publicly accessible jacks that was infected with a
worm, and I needed to identify the owner without our network manager
here, who would have simply shunned the port in question until we
resolved it. But we found it anyway, so didn't need the DHCP black hole.

We are planning on going 802.1X, but we don't have all of our switches
at L3 yet. Anyway, most of our "public users" (students) use our
wireless network, which does require authentication.

Thanks again,
-Marc



Phillip Windell wrote:
> Except for 802.1x that James mentioned, you really need to consider the physical
> security of the building itself. A "stranger" should not be allowed to gain
> physical access to a wall jack that is DHCP endabled on that "wire".
>
> In our building there are no "free" wall jacks in the public part of the
> building. You can also make the public areas of the building Wireless using
> WEP, WPA, PEAP, (or whatever),...they can't get an IP# until they authenticate
> with the Wireless devices first and they can not do that if you don't give them
> to tools to do it. With a good WAP you can reduce the signal power so that it
> doesn't reach clear across the parking lot and down the street also. You do a
> Site Survey and make sure the signal reaches only as far as you want it to.
>
> On the "wired side" our internet access and access to all LAN resources are
> carefully controlled by user account, not by IP#,...so an IP# does not give them
> "squat". Even Internet access is based on user accounts and the "path" out to
> the Internet does not even use the "Default Path" of the LAN so they can use
> their wildest imaginations for a Default Gateway and accomplish nothing.
>
> In our conference room, the jack available to "guests" runs through an isolated
> "NAT Device" and goes right out into the public side of the system,...they are
> never "on the LAN". If they don't use the provided NAT Device, there is no DHCP
> on that "wire" so they can't get an address, and they wouldn't know what Public
> IP# to configure their laptop with, so they wouldn't get anywhere.
>
> As far as them bringing in a virus,...we have virus protection out the "wazzoo"
> in half a dozen different ways. I'm not worried at all about that.
>
> So in the end, having them "get an IP#" isn't that big a deal when you deal with
> the big picture and don't put all your "security eggs in one basket".
>