1

I'm trying to run the DHCP Server service under a low-permissions account (partly to reduce attack-vectors, and partly just for kicks), as it runs under LOCAL SYSTEM by default.

I've successfully gotten the DNS Server service running with a low access account (.\dns), but the DHCP one just isn't working.

I've been using ProcessMonitor to track any ACCESS DENIED events on the system and/or tcpsvcs.exe, but there are none when I'm starting the service; yet the SCM reports back that 'Access is denied'.

There is nothing in the Event Log (Application,Security,System) regarding the cause of failure, and I've already granted the .\dhcp user account the following permissions:

  • C:\WINDOWS\system32\dhcp [Full Control + Subfolders]
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer [Full Control + Child Keys]
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\{AC8033FD-2B2A-4076-8E04-B7BB090D61CE} [nic, ditto]
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{AC8033FD-2B2A-4076-8E04-B7BB090D61CE} [nic, ditto]

The final operation when the SCM reports back the error is an attempted WriteFile to \\MACHINENAME*\MAILSLOT\NET\NETLOGON - but running this under the default system account results in the identical error (bad network path), so am not sure if this is entirely related.

Does anyone have any tips or suggestions?

OS: Windows Server 2003 R2 Enterprise x86 SP2

EDIT:

With the .\dhcp user in the Administrators group, the service starts. When in the Network Configuration Operators, DHCP Administrators, and Power Users groups the service fails to start.

To check if the adapter is running in promiscuous mode, I tested with nmap when the service is running:

nmap -sU -vv --script=sniffer-detect 192.168.134.202
...
PORT      STATE         SERVICE
53/udp    open          domain
67/udp    open|filtered dhcps
68/udp    open|filtered dhcpc
123/udp   open          ntp
...
MAC Address: 90:B1:1C:87:8A:3B (Unknown)

Host script results:
|_sniffer-detect: Unknown (tests: "11____1_")

Doing a netstat -anb on the server returned:

...
UDP    192.168.134.202:68     *:*                                    3432
[tcpsvcs.exe]

UDP    192.168.134.202:67     *:*                                    3432
[tcpsvcs.exe]

No sign of it listening on 0.0.0.0

2

I don't think you can get this to work because running a DHCP server on Windows requires putting the network card in to promiscuous mode, which is a privilege that requires administrator rights and can't be delegated.

  • I don't think this is correct. Why would the DHCP service need to put the NIC into promiscuous mode? – joeqwerty Aug 18 '13 at 13:43
  • This is looking like the case - the dhcp user in the administrators group works; it doesn't in Network Configuration Operators, DHCP Administrators (longshot), and Power Users. Still looking at it though, might be able to use impersonation... – ZXcvbnM Aug 18 '13 at 14:16
  • @joeqwerty because that was the only way to be able to hear packets destined for 0.0.0.0, but that changedwith 2008, I think. – longneck Aug 18 '13 at 14:25
  • 1
    I've never heard of that and I've never seen a Windows DHCP server NIC running in promiscuous mode. At no time in the DORA process that I'm aware of is the destination 0.0.0.0. Only in the Discover and Request phases is the source 0.0.0.0 but never is the destination 0.0.0.0 so the server isn't listening for DHCP traffic sent to 0.0.0.0. – joeqwerty Aug 18 '13 at 14:41
  • At any rate, my guess is the problem lies in the permissions required for members of the DnsUpdateProxy group to update dynamic DNS entries on behalf of the DHCP clients. Perhaps the OP can try putting his user in that group and seeing if that works. – joeqwerty Aug 18 '13 at 14:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.