Windows Domain interactions with Pi-Hole

Please follow the below template, it will help us to help you!

Windows DC is my DHCP server. It hands out IP, but client get Pi-Hole as the first DNS entry with the DC as second. Pi-Holes upstream server is also the Windows DC. Overall performance is great, browsing is legit faster, and ads are wildly reduced. This in conjunction with Adblock plus saves the day a lot.

A couple issues are persistent, however.

I am running Pi-Hole in a small network environment here. When I add a new machine to the domain or a new user needs to change their password I have to manually remove Pi-Hole from the DNS list on that computer otherwise I can't join it to the domain. Password change produces a 'domain can't be contacted or access denied' generic Windows error.

These are not insurmountable once I did my elimination tests and figured it out. But it would be very convenient to be able to allow domain joining and password changes without this manual process intervening.

Expected Behaviour:

Windows Domain additions and password changes

Actual Behaviour:

Blocked unless I manually remove pi-hole from my DNS list.

Debug Token:

debug token is: q45r2aca0s

There are two IP addresses assigned to the eth0 interface on your Pi-Hole device - 192.168.1.10 and .134. It appears that .10 is your Pi-Hole, but what is the .134 address?

What are the outputs of the following:

cat /etc/network/interfaces

cat /etc/dhcpcd.conf

Your router is at 192.168.1.1. The 5th DNS server listed for the Pi-Hole is 192.168.1.3. What is at that address?

The .134 address was the initial DHCP address that pi-hole got on our network before I set it to a static IP. I thought I had found all the spots to change that.

192.168.1.3 is my Windows DC that is also our DHCP server.

/etc/network/interfaces (dashes added so those lines aren't in BOLD)

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
#iface eth0 inet dhcp
iface eth0 inet static
address 192.168.1.10
netmask 255.255.255.0
broadcast 192.168.1.255
gateway 192.168.1.1
dns-nameservers 192.168.1.3

/etc/dhcpcd.conf
Doesn't exist on the system.

I'm not very familiar with Windows DC, so pardon what may appear to be some basic questions.

Why do your DC DHCP clients get DC as the second DNS entry?

Why does Pi-Hole have DC listed as the 5th DNS?

My clients get the Windows DC as the secondary entry (and its piholes upstream server) for internal DNS resolution. We have servers on-prem and on AWS that have forward DNS zones on the server.

I am not sure where you are seeing the DC as the 5th DNS entry.
The entries should be;
192.168.1.10 (pi-hole)
192.168.1.3 (Windows DC)
I think it's 8.8.8.8 I set for general internet DNS that otherwise couldn't get resolved by the other two.

As to 'why' they get the DC as the second entry, if it's the first entry, pi-hole doesn't get queried and so doesn't get interjected between the request and result to block ads.

DC as 5th DNS is in your debug log:

*** [ DIAGNOSING ]: Setup variables
    PIHOLE_INTERFACE=eth0
    IPV4_ADDRESS=192.168.1.10/24
    IPV6_ADDRESS=
    QUERY_LOGGING=true
    INSTALL_WEB=true
    LIGHTTPD_ENABLED=1
    TEMPERATUREUNIT=F
    WEBUIBOXEDLAYOUT=boxed
    DNSMASQ_LISTENING=single
    PIHOLE_DNS_1=8.8.8.8
    PIHOLE_DNS_2=8.8.4.4
    PIHOLE_DNS_3=4.2.2.1
    PIHOLE_DNS_4=4.2.2.2
    PIHOLE_DNS_5=192.168.1.3
    DNS_FQDN_REQUIRED=false
    DNS_BOGUS_PRIV=true
    DNSSEC=false

The next step - let's fix the IP addresses assigned to the Pi-Hole to eliminate the second (.134). Run

pihole -r

and select the reconfigure option, then enter the correct IP that is statically assigned by your DHCP server.

Then please upload a new debug log and paste the token.

OK done. New token is ri9rt5iytp

I'm a little concerned that my dashboard is all spinning circles like it's trying to query data. Did the pihole -r command basically wipe those stats?

Flush your browser cache and reload. Sometimes the browser cache is out of sync with the log data since the log data has changed.

I get this?

Let's clear up the API then look at your IP addresses again.

Run these commands to check the status of PiHole systems and paste results:

sudo systemctl status pihole-FTL.service

sudo systemctl status dnsmasq

I think you are doing this all the wrong way :

Why isn't Pi-Hole simply one of your Forward Servers for the Windows DC ?!

I think this is the setting you should look at :
http://techgenix.com/dns_conditional_forwarding_in_windows_server_2003/

See the first screenshot shown there for the setting I am talking about :slight_smile:

P.S. : The last time I have touched a Windows Server is at least 10 years ago so don't mind me if I am suggesting something silly here...

If it's a DNS lookup from the Windows DC then all the stats in Pi-hole are useless because all the lookups come from the DC instead of individual users IP addresses.

@fractalsphere Are you still having the problem?

Here's both results.

sudo systemctl status pihole-FTL.service

pihole-FTL.service - LSB: pihole-FTL daemon
   Loaded: loaded (/etc/init.d/pihole-FTL; bad; vendor preset: enabled)
   Active: active (exited) since Fri 2018-07-27 11:35:25 CDT; 2 days ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1217 ExecStart=/etc/init.d/pihole-FTL start (code=exited, status=0/SUCCESS)
    Tasks: 0
   Memory: 0B
      CPU: 0

Jul 27 11:35:25 adblock systemd[1]: Starting LSB: pihole-FTL daemon...
Jul 27 11:35:25 adblock pihole-FTL[1217]: Not running
Jul 27 11:35:25 adblock su[1273]: Successful su for pihole by root
Jul 27 11:35:25 adblock su[1273]: + ??? root:pihole
Jul 27 11:35:25 adblock su[1273]: pam_unix(su:session): session opened for user pihole by (uid=0)
Jul 27 11:35:25 adblock pihole-FTL[1217]: FTL started!
Jul 27 11:35:25 adblock systemd[1]: Started LSB: pihole-FTL daemon.
sudo systemctl status dnsmasq
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
   Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
  Drop-In: /run/systemd/generator/dnsmasq.service.d
           └─50-dnsmasq-$named.conf, 50-insserv.conf-$named.conf
   Active: active (running) since Fri 2018-07-27 11:35:24 CDT; 2 days ago
  Process: 1034 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf (code=exited, status=0/SUCCESS)
  Process: 1020 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=0/SUCCESS)
  Process: 954 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, status=0/SUCCESS)
 Main PID: 1033 (dnsmasq)
    Tasks: 1
   Memory: 16.2M
      CPU: 4.483s
   CGroup: /system.slice/dnsmasq.service
           └─1033 /usr/sbin/dnsmasq -x /var/run/dnsmasq/dnsmasq.pid -u dnsmasq -r /var/run/dnsmasq/resolv.conf -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-

Jul 27 11:35:24 adblock systemd[1]: Starting dnsmasq - A lightweight DHCP and caching DNS server...
Jul 27 11:35:24 adblock dnsmasq[954]: dnsmasq: syntax check OK.
Jul 27 11:35:24 adblock systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server.

@jfb Yes, I am. Pi-hole is now out of the mix in my environment because of this new issue losing connection to the API. I would rather not rebuild the pi-hole box as it'll just have the same Windows Domain authentication and traversal issues. I'm at a loss what to do to get my existing server back functioning though.

It has been noticed that ads are visible again, at least by some of the more savvy developers in-house here. :-/

I would find some web groups for Window Domain control. After you get that sorted out, then you should be able to get your Pi-Hole running again.

My instance of pi-hole broke after performing an action you recommended. Once I get that up and running again I am happy to continue my search for Domain answers, but getting my pi-hole running is not dependent on those answers.

That said, what is it that is amiss in my instance? Or are you recommending a new instance/rebuild? It's just running in a small VM, so it's not like it's a stretch, but still - would rather not have to.

I would recommend moving over to the 4.0 branch. That has all the newest and greatest features and is what the devs are working on now. I have it running on three Pi's and it works nicely. This move will likely fix the spinning API issue as well.

echo release/v4.0 | sudo tee /etc/pihole/ftlbranch 
pihole checkout core release/v4.0 
pihole checkout web release/v4.0
1 Like

So this happened - I'm going to do a fresh install of a new instance. I don't believe that will answer my core question of why domain joins and password changes are block by pihole.

pihole checkout core release/v4.0
Please note that changing branches severely alters your Pi-hole subsystems
Features that work on the master branch, may not on a development branch
This feature is NOT supported unless a Pi-hole developer explicitly asks!
Have you read and understood this? [y/N] y

  [✓] Fetching branches from https://github.com/pi-hole/pi-hole.git
  [i] 32 branches available for Pi-hole Core

  [✓] Switching to branch: 'release/v4.0' from 'refs/heads/master'
  [i] Already up-to-date.
  [i] Running installer to upgrade your installation

  [✓] Root user check

        .;;,.
        .ccccc:,.
         :cccclll:.      ..,,
          :ccccclll.   ;ooodc
           'ccll:;ll .oooodc
             .;cll.;;looo:.
                 .. ','.
                .',,,,,,'.
              .',,,,,,,,,,.
            .',,,,,,,,,,,,....
          ....''',,,,,,,'.......
        .........  ....  .........
        ..........      ..........
        ..........      ..........
        .........  ....  .........
          ........,,,,,,,'......
            ....',,,,,,,,,,,,.
               .',,,,,,,,,'.
                .',,,,,,'.
                  ..'''.

  [i] Existing PHP installation detected : PHP version 7.0.30-0ubuntu0.16.04.1
  [i] Performing unattended setup, no whiptail dialogs will be displayed
  [✓] Disk space check

  [✓] Update local cache of available packages

  [✓] Checking apt-get for upgraded packages... 79 updates available
  [i] It is recommended to update your OS after installing the Pi-hole! 

  [i] Installer Dependency checks...
  [✓] Checking for apt-utils
  [✓] Checking for dialog
  [✓] Checking for debconf
  [✓] Checking for dhcpcd5
  [✓] Checking for git
  [✓] Checking for iproute2
  [✓] Checking for whiptail

  [✓] Check for existing repository in /etc/.pihole
  [✓] Update repo in /etc/.pihole

  [✓] Check for existing repository in /var/www/html/admin
  [✓] Update repo in /var/www/html/admin

  [i] Main Dependency checks...
  [✓] Checking for bc
  [✓] Checking for cron
  [✓] Checking for curl
  [✓] Checking for dnsutils
  [✓] Checking for iputils-ping
  [✓] Checking for lsof
  [✓] Checking for netcat
  [✓] Checking for psmisc
  [✓] Checking for sudo
  [✓] Checking for unzip
  [✓] Checking for wget
  [✓] Checking for idn2
  [i] Checking for sqlite3 (will be installed)
  [✓] Checking for libcap2-bin
  [✓] Checking for dns-root-data
  [✓] Checking for resolvconf
  [✓] Checking for lighttpd
  [✓] Checking for php7.0-common
  [✓] Checking for php7.0-cgi
  [✓] Checking for php7.0-sqlite3

Error: Unable to complete update, please contact support