<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Ansible on Aperture Zone</title>
    <link>https://aperturezone.com/tags/ansible/</link>
    <description>Recent content in Ansible on Aperture Zone</description>
    <image>
      <url>https://aperturezone.com/logo.webp</url>
      <link>https://aperturezone.com/logo.webp</link>
    </image>
    <generator>Hugo -- gohugo.io</generator>
    <language>fr-fr</language>
    <lastBuildDate>Thu, 02 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://aperturezone.com/tags/ansible/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Backing up GPOs with Ansible and WinRM</title>
      <link>https://aperturezone.com/posts/backup_gpo/</link>
      <pubDate>Thu, 02 Apr 2026 00:00:00 +0000</pubDate>
      
      <guid>https://aperturezone.com/posts/backup_gpo/</guid>
      <description>&lt;p&gt;Group Policy Objects are at the heart of any robust Active Directory infrastructure. They define security settings, permissions, device configurations, and software restrictions. In the event of a disaster, human error, or simply a need to roll back after a change, not having a backup of your GPOs means facing hours of tedious reconstruction.&lt;/p&gt;
&lt;p&gt;The graphical interface of the Group Policy Management Console does offer a backup feature, but it is manual, easy to overlook, and, most importantly, not versioned. The goal of this article is to automate this process cleanly using Ansible via WinRM, on an infrastructure comprising &lt;strong&gt;two separate Active Directory domains&lt;/strong&gt;, with long-term archiving on a NAS and reporting via email.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Active Directory: krbtgt, from theory to practice</title>
      <link>https://aperturezone.com/posts/krbtgt2/</link>
      <pubDate>Wed, 01 Apr 2026 00:00:00 +0000</pubDate>
      
      <guid>https://aperturezone.com/posts/krbtgt2/</guid>
      <description>&lt;p&gt;In the &lt;a href=&#34;https://aperturezone.fr/posts/krbtgt/&#34;&gt;first part of this article&lt;/a&gt;, we laid the groundwork: what the krbtgt account is, why the Golden Ticket is a serious threat, and a theoretical Ansible architecture for automating rotations. If you haven’t read that part, I encourage you to start there.&lt;/p&gt;
&lt;p&gt;Now we’re getting down to business. The playbook in Part 1 was intentionally simplified to illustrate the concept. In a real production environment, things get complicated—the interactive script that refuses to be controlled, the XML file that can’t be found, the Kerberos double-hop that blocks everything, the root forest that isn’t what we think it is. These are all obstacles I’ve encountered and resolved, which I’m documenting here.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Active Directory: krbtgt the scary account</title>
      <link>https://aperturezone.com/posts/krbtgt/</link>
      <pubDate>Wed, 25 Mar 2026 00:00:00 +0000</pubDate>
      
      <guid>https://aperturezone.com/posts/krbtgt/</guid>
      <description>&lt;p&gt;There are elements in Active Directory that we completely forget about because they never come up in day-to-day operations. The &lt;strong&gt;krbtgt&lt;/strong&gt; account is one of them. Though invisible in everyday use, it is at the heart of all Kerberos authentication in your domain—and its compromise is one of the most catastrophic scenarios an attacker could trigger.&lt;/p&gt;
&lt;p&gt;In this article, we’ll explore what this account really is, why you need to change its password regularly, and how to automate this process cleanly with &lt;strong&gt;Ansible&lt;/strong&gt;.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Automate network device configuration backup with Ansible</title>
      <link>https://aperturezone.com/posts/ansible2/</link>
      <pubDate>Mon, 23 Mar 2026 00:00:00 +0000</pubDate>
      
      <guid>https://aperturezone.com/posts/ansible2/</guid>
      <description>&lt;p&gt;Whether in a home lab or a professional infrastructure, network equipment is often overlooked in backup strategies. We think about backing up VMs, data, and servers—but rarely the configurations of switches and Wi-Fi access points. However, in the event of a failure or hardware replacement, not having the configuration on hand can result in hours of work to rebuild the system.&lt;/p&gt;
&lt;p&gt;In this article, we’ll set up an Ansible playbook that automatically backs up our network equipment configurations, stores them locally with a 30-day retention period, and sends an HTML report via email after each run.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Automation with Ansible</title>
      <link>https://aperturezone.com/posts/ansible/</link>
      <pubDate>Tue, 24 Feb 2026 00:00:00 +0000</pubDate>
      
      <guid>https://aperturezone.com/posts/ansible/</guid>
      <description>&lt;h3 id=&#34;package-updates-ntp-synchronization-and-html-email-notifications-on-ubuntu-2404&#34;&gt;Package updates, NTP synchronization, and HTML email notifications on Ubuntu 24.04&lt;/h3&gt;
&lt;hr&gt;
&lt;p&gt;Manually managing multiple Linux servers quickly becomes tedious and prone to errors: forgotten updates, undetected time zone differences, inconsistent NTP configurations, etc. Ansible solves this problem by allowing you to automate system administration in a reproducible way, without having to install an agent on the target machines.&lt;/p&gt;
&lt;p&gt;We will set up an Ansible server on &lt;strong&gt;Ubuntu 24.04 LTS&lt;/strong&gt;, configure a server inventory, and deploy a complete playbook that performs the following in a single execution:&lt;/p&gt;</description>
    </item>
    
  </channel>
</rss>
