Tanuki

Triage Active Directory Linux pour agents de codage IA. Protocol-first, zéro bruit.

Démarrage rapide • Architecture double moteur • Validation en laboratoire réel • Vidéo de démonstration • Échelle de décision • Avant & Après • Outillage & Utilisation • Configuration de l'agent • Filiation & Crédits

---

Démarrage rapide (installation universelle en 1 ligne)

Tanuki est 100 % plug-and-play. Une seule commande installe l'interface CLI unifiée et configure les compétences d'agent IA pour Claude Code, Cursor et Google Antigravity :

Linux & macOS

curl -sSL https://raw.githubusercontent.com/Mafifrizi/tanuki/main/install.sh | bash

Windows (PowerShell)

irm https://raw.githubusercontent.com/Mafifrizi/tanuki/main/install.ps1 | iex

Via Pipx / Pip / Cargo

# Pipx (Isolated CLI environment)
pipx install git+https://github.com/Mafifrizi/tanuki.git

# Local repository install
pip install .

# Note for Linux (Kali, Debian, Ubuntu): If ~/.local/bin is not in your PATH:
export PATH="$HOME/.local/bin:$PATH"

# Rust binary install
cargo install --path crates/tanuki-cli

Vérifiez votre installation :

# Direct CLI binary or universal Python module
tanuki --version
python3 -m tanuki --version

tanuki doctor
tanuki ladder
tanuki triage KRB_AP_ERR_SKEW

Architecture à double moteur

Tanuki embarque deux implémentations complémentaires :

1. Cœur système Rust (crates/tanuki-cli) : Le moteur principal haute performance pour les postes de travail opérateur, les pipelines de validation de sécurité CI/CD et le déploiement autonome. Il se compile en un binaire statique unique avec #![forbid(unsafe_code)], zéro dépendance externe et des temps d'exécution inférieurs à 2 millisecondes.
2. Moteur de repli Python (scripts/) : Une suite de scripts sans dépendance utilisant uniquement la bibliothèque standard Python (struct, io, sys). Il opère directement sur les systèmes cibles distants où le dépôt de binaires compilés est interdit ou surveillé par la détection des terminaux.

Les deux moteurs partagent un schéma JSON et une spécification d'analyse identiques.

---

Validation empirique en laboratoire réel

Tous les analyseurs de protocole, diagnostics et flux de travail CLI sont validés empiriquement dans des environnements de laboratoire virtualisés réels :

• Contrôleur de domaine Active Directory : Windows Server 2022 (DC01.lab.local, IP : 192.168.56.106)
• Poste de travail opérateur : Kali Linux 2024 (kraii@kraiiandreyy, IP : 192.168.56.105)

Parcours complet de bout en bout (validation en laboratoire réel)

📺 Regarder la vidéo de démonstration : youtu.be/wqZRYmEn0eY - Parcours opérationnel complet à travers une infrastructure de domaine réelle.

Vérification visuelle du cycle de vie opérationnel complet en 3 actes à travers une infrastructure de domaine réelle :

Acte	Environnement	Objectifs et primitives validées
Acte 1 : Configuration du contrôleur de domaine	Windows Server 2022 (DC01)	Découverte du domaine (nltest), audit SPN (setspn) et export binaire de keytab AES-256 conforme RFC 4120 (ktpass, KVNO 9).
Acte 2 : Opérateur Linux non privilégié	Kali Linux 2024 (Naga)	Diagnostic passif (tanuki doctor), audit d'arborescence RFC 4120 (tanuki keytab), synthèse de configuration sans root (tanuki config), acquisition de TGT native via ctypes (tanuki auth), validation de l'état du ticket (tanuki doctor) et triage de protocole (tanuki triage).
Acte 3 : Vérification en boucle fermée	Windows Server 2022 (DC01)	Audit Success de l'événement de sécurité ID 4768 du contrôleur de domaine pour tanuki-nhi provenant de l'IP client 192.168.56.105.

Acte 1 : Configuration du service du contrôleur de domaine et provisionnement du keytab (DC01)

Export binaire officiel de keytab conforme RFC 4120 sur le contrôleur de domaine pour le compte de service LAB\tanuki-nhi avec AES-256 moderne (aes256-cts-hmac-sha1-96, KVNO 9) :

Acte 2 : Session opérateur Linux non privilégié et validation de l'état (Naga)

1. Référence de diagnostic de santé pré-vol (tanuki doctor)

Diagnostic de santé pré-vol passif, sans paquet, s'exécutant en 0,96 ms, détectant avec précision l'état non configuré, les keytabs manquants et les caches de tickets inactifs :

2. Ingestion de keytab RFC 4120 et audit d'arborescence (tanuki keytab)

Analyse les structures binaires de keytab, extrait les principaux AES-256, affiche les arborescences hiérarchiques de principaux, vérifie le KVNO 9 et fournit des conseils automatisés pour kinit :

3. Générateur de configuration Kerberos sans DNS (tanuki config)

Génère un fichier de configuration Kerberos local (/tmp/lab_krb5.conf) appliquant les conventions de royaume en majuscules de la RFC 4120 § 6.1, le routage direct vers l'IP du KDC sans DNS et la tolérance au décalage d'horloge de l'hyperviseur :

4. Acquisition de TGT native non privilégiée (tanuki auth)