Rocky linux e join su AD ( foresta 2008 )

Come tutti sappiamo , il progetto Centos verrà abbandonato a breve , pertanto molti utenti ricorreranno ai “ripari” , ovvero si cercherà un rimpiazzo a tale distro .

Esattamente 2 anni orsono , Red Hat divulgò la notizia che avrebbe cessato lo sviluppo di CentOS , ponendo lo stato di fatto che tale sistema era giunto in EOL .

Personalmente ho iniziato a cercare delle alternative e quindi tra queste ho optato per la distro “Rocky Linux” , compatibile con sistemi Red Hat . Questa offre la potenza e la stabilità in contesti di produzione server e workstation davvero apprezzabili . Ho eseguito l’installazione di tale distro su un sistema cluster Proxmox , che tra l’altro , aggiungo , che ho dovuto apportare piccole modifiche nella creazione di tale VM , in quanto si presentavano continui Kernel Panic al boot .

Le modifiche anzi la modifica necessaria per l’avvio di tale sistema , sta nel cambiare il default della cpu KVM in host CPU , con l’opzione CPU MAX per un contesto cluster . Fatto questo , la distro si avvia regolarmente senza alcun problema di sorta .

Avendo una rete gestita da un server Linux con servizi AD ( foresta 2008 ) elenco qui a seguire i passi necessar per l’accredito al dominio AD :

In primis , occorre entrare in console del sistema e procedere all’installazione dei pacchetti essenziali per effettuare il join su AD .

sudo dnf install realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
sudo realm join ad.mycompany.local
sudo update-crypto-policies --set DEFAULT:AD-SUPPORT
search internal2.lan
nameserver 192.168.3.123 
realm join -u administartor ad.internal2.lan
[sssd]
domains = ad.internal2.lan
config_file_version = 2
services = nss, pam, ssh
default_domain_suffix = ad.internal2.lan
[nss]
homedir_substring = /home
[domain/ad.internal2.lan]
ad_gpo_access_control = permissive
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = AD.INTERNAL2.LAN
realmd_tags = manages-system joined-with-adcli 
id_provider = ad
override_homedir = /home/%u   
fallback_homedir = /home/%u@%d
override_shell = /bin/bash
ad_domain = ad.internal2.lan
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
default_shell = /bin/bash
dyndns_update = true
dyndns_refresh_interval = 43200
dyndns_update_ptr = true
dyndns_ttl = 3600

Molto importante risulta la direttiva “override_shell= /bin/bash ” , in quanto senza questo parametro risulta impossibile avere la shell bash subito dopo aver effettuato il login in ssh .

Bene , eseguite tutte le operazioni sopra descritte , si è pronti per effettuare e provare le connessioni in ssh , chiaramente utilizzando utenti del dominio AD . Per chi volesse installare l’interfaccia GUI , personalmente ho utilizzato GDM e la suite Gnome , senza riscontrare alcun problema di sorta , tranne la sezione di autentica che può essere risolta aggiungendo “adm” allo user del dominio con il quale si effettua il collegamento RDP . Inoltre è importante modiifcare la sezione visudo inerente ai permessi o meglio all’uso del comando “SU” .

Quando un lease DHCP “abbandonato” genera record DNS sbagliati: analisi di un caso reale con pfSense, Unbound e Pi‑hole

In molte reti basate su pfSense, è comune utilizzare:

  • pfSense come router/firewall e server DHCP
  • Unbound come DNS Resolver con registrazione dinamica
  • Pi‑hole come DNS primario per filtraggio e caching

Questa combinazione è potente, ma può generare problemi difficili da diagnosticare quando entrano in gioco:

  • hostname duplicati
  • lease DHCP scaduti ma non rimossi
  • record DNS dinamici generati da lease “abandoned”
  • cache DNS persistente di Pi‑hole

In questo articolo analizziamo un caso reale in cui un dispositivo IoT ha causato un conflitto DNS che ha portato a risoluzioni errate e incoerenti tra DHCP, DNS Resolver e Pi‑hole.

Sintomo del problema

Il comportamento osservato era il seguente:

  • DHCP mostrava Mini4 → 192.168.8.101
  • DNS Lookup mostrava Mini4 → 192.168.8.100
  • Pi‑hole rispondeva sempre con 100
  • pfSense rispondeva con 100 anche dopo reboot

Una situazione apparentemente impossibile: il lease attivo era corretto, ma il DNS continuava a servire un IP vecchio.

La causa reale: un lease DHCP “abbandonato” con hostname duplicato

Nel file reale dei lease di pfSense:

/var/dhcpd/var/db/dhcpd.leases

era presente questo blocco:

lease 192.168.8.100 {

  binding state abandoned;

  client-hostname “Mini4”;

}

Questo lease:

  • era scaduto
  • era “abandoned”
  • non compariva nella GUI
  • ma era ancora presente nel file
  • e conteneva l’hostname “Mini4”

Perché è un problema?

Perché Unbound genera i record DNS dinamici leggendo tutti i lease, anche quelli:

  • expired
  • abandoned
  • free
  • rewind

Di conseguenza, Unbound continuava a generare:

A record: mini4.local.lan → 192.168.8.100

PTR record: 100 → mini4.local.lan

anche se il lease attivo era 101.

La causa originale: un dispositivo IoT che si è spacciato per “Mini4”

Il dispositivo incriminato era un Aubess (wlan0), che:

  • non rispetta DHCP Option 12
  • non invia un hostname coerente
  • si presenta con nomi casuali
  • in questo caso si è presentato come “Mini4”

pfSense ha quindi creato un lease per:

192.168.8.100 → Mini4

Quando il Mac mini ha richiesto un IP, ha ottenuto:

192.168.8.101 → Mini4

Risultato: hostname duplicato.

Il secondo problema: la cache DNS di Pi‑hole

Pi‑hole aveva memorizzato:

mini4.local.lan → 192.168.8.100

Quindi:

  • anche dopo aver corretto pfSense
  • anche dopo aver cancellato il lease fantasma
  • anche dopo il reboot di pfSense

Pi‑hole continuava a rispondere con l’IP sbagliato.

Solo dopo:

pihole restartdns

la cache è stata svuotata e il DNS si è riallineato.

Perché il reboot di pfSense non ha risolto?

Perché pfSense non elimina i lease scaduti dal file.

Il file rimane identico.

E Unbound, al boot, ricostruisce i record DNS dinamici anche dai lease “abandoned”.

Quindi il record sbagliato veniva ricreato ogni volta.

Soluzione definitiva

1. Identificare il lease fantasma

cat /var/dhcpd/var/db/dhcpd.leases | grep -i mini4 -A5 -B5

2. Eliminare il blocco incriminato

vi /var/dhcpd/var/db/dhcpd.leases

Cancellare:

lease 192.168.8.100 { … }

3. Rigenerare i lease DHCP

GUI → DHCP Server → Save

4. Reload DNS Resolver

GUI → DNS Resolver → Save

5. Svuotare la cache di Pi‑hole

pihole restartdns

Risultato finale

  • Il dispositivo IoT ha preso un nuovo IP (es. 187)
  • Mini4 è rimasto correttamente su 101
  • Nessun hostname duplicato
  • Nessun record DNS sbagliato
  • pfSense e Pi‑hole perfettamente allineati

Conclusioni

Questo caso dimostra come un semplice dispositivo IoT con hostname errato possa:

  • generare un lease DHCP “abandoned”
  • sporcare il DNS dinamico di pfSense
  • creare record A/PTR sbagliati
  • essere ulteriormente amplificato dalla cache di Pi‑hole

La diagnosi richiede:

  • analisi del file reale dei lease
  • comprensione del comportamento di Unbound
  • gestione della cache DNS di Pi‑hole

È un problema raro, ma estremamente insidioso.