Friday, April 20, 2012 1:46 PM
NPS/DHCP on 2008R2 SP1.
I have a set of policies mandating access to compliant clients only, ie non-compliant clients receive no IP config.
In this scenario I have observed that the DHCP still sets a lease for each non-compliant client asking for IP configuration, and the lease is kept active until it normally expires according to the scope options, even if the IP is not given to the client due to the NPS RADIUS reject.
Is there a way to have the IP lease that won't be ever given to the non-compliant client to expire immediately after the NPS RADIUS reject?
I am worried about rogue clients that may fill up the scope and prevent legitimate clients to obtain a lease?
Monday, April 23, 2012 3:01 AMModerator
Thanks for your post.
Please note that the NAP DHCP is using for secure your network environment. It can restrict the noncompliant client full access to network. But any computer bring to your local network will be given an IP address, only with limit network access. If you need to block the DHCP server lease IP address to the rogue clients, you need to use MAC filter which may complicate to deployment.
DHCP Server Callout DLL for MAC Address based filtering
Step-by-Step Guide: Demonstrate NAP DHCP Enforcement in a Test Lab
Health Enforcement and Remediation
TechNet Community Support
Monday, April 23, 2012 8:11 AM
what you are describing is a possible scenario, but what I have been implementing is denying IP configuration to non-domain computers. I have achieved this goal by means of NPS policies enforcing the domain membership, and I have verified that non-domain computers are not being offered IP config by the DHCP.
However, even if the DHCP does not ACK a DHCPRequest, it does create the lease with the standard scope expiration time, which may lead to lack of available IPs due to non-domain computers' requests.
Hope it's clearer now.
Tuesday, April 24, 2012 1:01 PM
Can you provide me with more detail as to how exactly you have configured your NPS policy to deny IP addresses to non-domain computers?
Tuesday, April 24, 2012 2:47 PM
oddly enough I could not find an existing example in the forum for this, so I have created one network request policy accepting all requests from the DHCP server, and a set of network policies as follows:
* NAP DHCP Compliant (Grant Access)
Conditions: Machine groups= MYDOMAIN\Domain Computers
* NAP DHCP Non NAP-Capable (Deny Access)
Conditions: NAP-Capable= Computer is not NAP-capable
* NAP DHCP Aliens (Deny Access)
Conditions: Calling Station ID=*
By means of these policies, DHCP should provide IP leases to domain computers only (regardless of any health status), where non nap-capable computers or computers that are not part of domain MYDOMAIN should not receive IP configuration.
As a result, I have non-domain computers not getting IP config (see here for a related issue though), but the DHCP still keeps the lease in its database until it normally expires.
Tuesday, April 24, 2012 4:19 PM
Still not working; my non-domain test computer (W7) with no NAP client is still getting a DHCP address.
I have added the * to calling Station ID
What does your network request policy look like? Perhaps I am not telling the DHCP server how to talk ot the NPS? They are on different machines.
Do I have to do anything special on the DHCP server other than enable NAP? How does the DHCP serve know where the NAP server is?
Tuesday, April 24, 2012 4:22 PMAh a clue: on the DHCP server Event 1070
Iashlpr initialization failed: The DHCP service was unable to access path specified for the audit log. , so DHCP server cannot talk to NPS server. It could be that IAS service is not started.
Wednesday, April 25, 2012 7:24 AM
I had the DHCP on another server. I moved it as I could not quickly find clear instructions for the proxy thing, and now all is fine.
Wednesday, April 25, 2012 7:26 AMdo you experience the same issue ie lease stays on also for a denied client?
Wednesday, April 25, 2012 7:27 AMYes I deleted them manually and then they did not come back.
Wednesday, April 25, 2012 9:44 AMfor me these leases are recreated as soon as the DHCP server receives DHCPRequests from non-domain computers.
Wednesday, April 25, 2012 10:45 AM
You are right, after a while (8 horus) they come back. However the computer does not actually get the address - it gets ends up with a 169.x.x.x
If I do an ipconfig/renew they also come back.
So do you think the incoming DHCP request is accepted, the lease is generated, then it checks with the NPS server and does not send it back?
Wednesday, April 25, 2012 10:56 AM
This is exactly what I think it's happening, and to me it's a bug given that it may cause the scope to be filled by invalid leases.
Thursday, May 10, 2012 9:41 AMAnyone from MS who can confirm this issue?
- Edited by Luigi Capriotti Thursday, May 10, 2012 9:41 AM
Sunday, May 13, 2012 7:41 AMOwner
I've confirmed the same behavior that you reported. Clients that are denied a lease still use a DHCP lease on the DHCP server. Thanks for reporting this, it doesn't seem to be ideal behavior & I'll notify the product team to discuss a possible fix.
Keep in mind that there isn't a greater danger here of rogue clients using all the leases than there is already if NAP were not deployed. The difference is that with NAP at least the clients don't have network access.
- Marked As Answer by Greg LindsayMicrosoft Employee, Owner Monday, August 13, 2012 10:58 PM
Monday, May 14, 2012 7:03 AM
tks for confirming, I agree the impact can be minimised once the behaviour is taken into proper consideration, but I hope a fix will be provided anyway.
Monday, August 13, 2012 6:26 PMAny news on the fix for this yet. I have the same problem.
Monday, August 13, 2012 6:41 PMOwnerI've submitted a bug for this and requested a fix for 2008, 2008 R2, and 2012. I don't yet have a status for if and when this fix will happen. Sorry - I wish I could provide more information. I did assign this a high priority because it isn't expected behavior.
Monday, August 13, 2012 6:50 PMThanks for the quick reply, I'll keep a look out for it. Maybe in the next Service Pack.