none
prevent rogue/unauthorized dhcp server(non-windows base) RRS feed

  • Question

  • hello there,

    our company computers/servers are all domain joined, and I wondering how to prevent the rogue/unauthorized DHCP server which is not windows base.

    I read the arctile :

    https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc754792(v=ws.11)

    but if the rogue DHCP server is not windows base, e.g. some syslink or tp-link router,

    if the domain joined client will accept the dhcp offer which is released by that kind of device?

    PS: I know the network devices ACL or dhcp snooping  can help me out, but if that is the only way?

    Friday, July 5, 2019 4:12 AM

Answers

  • hello ...

     I build a Linux based DHCP server for test.

    as my result, the domain joined client (windows 10) able to get the IP from the linux !!!

    that's mean even the domain controller and dhcp (authorized DHCP) is online, the client (domain joined) still able to has a change to get and accept the IP from unauthorized DHCP.

    in the test, I stop the authorized server DHCP service  for test, then the client get the IP from the linux server. and then I start the DHCP service again, but the client stiil get IP from linux. (I use ipconfig/release to release the IP)

    Tuesday, July 9, 2019 9:37 AM

All replies

  • Hi,

    In AD environment, the client only accepts DHCP offer from authorized DHCP server, regardless of the device used.

    Meanwhile, I would suggest you prevent anyone from plugging an unauthorized device into the LAN.

    Best regards,

    Travis


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Friday, July 5, 2019 7:18 AM
    Moderator
  • hello , thanks for your reply.

    I wondering if there have any document/article mention this ?

    since the article I read is only mentioned windows based DHCP server won't release the IP, it didn't mention the domain joined client will only accept the IP which released by authorization DHCP  :)

    thanks

    :)

    Monday, July 8, 2019 11:38 AM
  • Hi,

    Although it is not recommended, you can use a stand-alone server as a DHCP server as long as it is not on a subnet with any authorized DHCP servers. When a stand-alone DHCP server detects an authorized server on the same subnet, it automatically stops leasing IP addresses to DHCP clients. 

    As mentioned in the link you provided, only authorized server can work properly in AD. 

    Best regards,

    Travis



    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Tuesday, July 9, 2019 7:59 AM
    Moderator
  • do you mean if the "router (rouge dhcp)" detect an authorized DHCP server in the same subnet, it will stop release the IP ?

    really ? how come a network device (router) can able to "understand" what is AD authorized DHCP server?

    Tuesday, July 9, 2019 8:12 AM
  • hello ...

     I build a Linux based DHCP server for test.

    as my result, the domain joined client (windows 10) able to get the IP from the linux !!!

    that's mean even the domain controller and dhcp (authorized DHCP) is online, the client (domain joined) still able to has a change to get and accept the IP from unauthorized DHCP.

    in the test, I stop the authorized server DHCP service  for test, then the client get the IP from the linux server. and then I start the DHCP service again, but the client stiil get IP from linux. (I use ipconfig/release to release the IP)

    Tuesday, July 9, 2019 9:37 AM
  • Hi,

    Thanks for your sharing.

    I think you are right that authorization function can't block third party DHCP servers.

    As a result, the best way is preventing third party devices from connecting to the LAN.

    Best regards,

    Travis


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Wednesday, July 10, 2019 6:56 AM
    Moderator