About this guide

This document describes how to use AdGUARD end to end, from installation through to producing an audit report you can hand over to a client. It covers installation, license activation, how the application name and reports work, connecting to the audited directory, control selection, baselines and compliance frameworks, running audits, reading attack paths, interpreting results and exporting reports.

Who this guide is for

• Auditors and consultants running Active Directory audits for their clients.
• Internal security teams (CISO, IAM, SecOps) tracking the posture of their own directory over time.
• MSPs and resellers operating the application under their own brand across a portfolio of clients.
• Administrators of the audited directory, for the connection and permissions part only (chapter 6).

Documented version

1. Introduction

1.1 What AdGUARD is

AdGUARD is a Windows desktop application that audits the security configuration of an Active Directory domain. It queries the directory read-only over LDAP, compares the actual configuration against a catalog of 176 control points drawn from recognised public frameworks, and produces a compliance score, a control-by-control breakdown, an attack path map and exportable reports.

The principle is simple: where a manual audit means walking through dozens of management console screens, reading security descriptors by hand and noting gaps in a spreadsheet, AdGUARD covers the same ground in a handful of seconds, reproducibly, and keeps the history so progress can be measured.

The dashboard: overall compliance, detailed breakdown and trend over time.

1.2 Design principles

1.3 What AdGUARD does not do

• It does not fix. No automatic remediation. The PowerShell and dsacls commands are provided for guidance, and those that modify the directory ship commented out.
• It does not monitor continuously. An audit is a point-in-time run, started manually. It is a snapshot of the configuration, not a SIEM.
• It does not audit Entra ID. That scope is covered by EntraGUARD, built on the same foundation.
• It does not analyse content. The application reads directory attributes and security descriptors, never the content of shares or mailboxes.
• It does not replace a human audit. It industrialises the mechanical part, freeing time for analysis and recommendations.

1.4 Functional architecture

The application is built on five parts:

• The connector establishes read access to the directory: domain controller, search base, read account, LDAP or LDAPS.
• The control catalog describes what to check: 176 points grouped into 8 packs, each tied to a category, a criticality level and a set of framework mappings.
• Baselines define the scope retained for an engagement: which controls are in scope, which are excluded, and at what level.
• The audit engine runs the selected controls in parallel, assigns a verdict to each and computes a weighted score.
• Reports present the result from six editorial angles and in five file formats.

The About screen: version, technical stack and covered frameworks.

1.5 Terminology

2. Installation and first run

2.1 Requirements

2.2 Installation

The application ships as a standard Windows installer. It installs into C:\Program Files\AdGUARD for all users of the machine, creates a Start menu shortcut, and creates its data area on first run.

An update installs over the previous one: the installed version is detected and replaced. Data — client records, history, connectors, license — is never touched by a reinstall, because it lives outside the program folder.

2.3 Where the data lives

All data lives under a single root, shared by every Windows account on the machine. This is deliberate: on a shared audit workstation, two consultants must find the same clients and the same history.

C:\ProgramData\AdGUARD\
├── license.key            clé de licence installée (commune au poste)
├── control-packs\         packs de contrôles importés (JSON)
└── clients\
    ├── <client-1>\
    │   ├── settings.json  connecteur, export, branding, performances
    │   └── audit.db       base SQLite : historique et résultats détaillés
    └── <client-2>\

The active client is remembered per Windows user: two sessions open on the same machine can work on two different clients while sharing the same set of records.

2.4 First run

Getting started takes six steps:

• Activate the license — Settings › License, paste the key you were given.
• Create the first domain — AD domains › Add a domain, filling in at least the name (§ 5.2). The application name itself comes from your license (§ 4).
• Create the first domain — Domains › Add a domain.
• Connect the directory — Settings › Connectors, fill in the domain and the read account, then test.
• Choose the scope — Baselines › Templates to start from a framework, or Security controls to pick manually.
• Run the first audit — Security audit › Run, then export the report.

On first run, the dashboard is waiting for the first audit.

2.5 The interface

The application has three areas: a collapsible side menu on the left, the active view in the middle, and at the top right the theme (light / dark) and language (FR / EN) selectors. The name shown at the top of the menu is the license holder's name, carried by the license (§ 4).

3. License and activation

3.1 How it works

The license is verified entirely offline, using an asymmetric ECDSA signature on the P-256 curve (SHA-256 digest). The vendor signs the license content with a private key that never leaves their machine; the application embeds the matching public key, which can only verify a signature, never produce one. Decompiling the application therefore does not allow anyone to forge a license, and there is no activation server to reach.

The license file is a block of text wrapped in a readable armor, in the manner of a PEM key:

-----BEGIN GUARD LICENCE-----
...signed content, base64url-encoded...
-----END GUARD LICENCE-----

The signed content carries the following fields:

3.2 Where licenses come from: the GuardLicence application

Licenses are no longer produced by a generator built into the application, as was the case in earlier versions. They are issued by a dedicated application, GuardLicence, held by the vendor and, where applicable, by authorized partners.

GuardLicence holds the signing authority and works as a three-level chain:

• a root (the vendor's private key) signs certificates;
• each certificate authorizes the issuance of bounded licenses: allowed products (EntraGUARD, AdGUARD), domain cap, expiry date;
• from a certificate, individual licenses are issued for each client.

This model lets the vendor delegate issuance to a partner without handing over the root: the partner can only issue within the limits written into their certificate. The AdGUARD application itself knows only the root public key and merely verifies the license it receives.

3.3 Activating a license

Open Settings › License. Two options, depending on how the license was delivered:

• Paste the key: paste the full license text, armor included, into the field, then confirm.
• Load a file: select the supplied license.key file; its content is read and installed.

On activation, the application checks in turn the signature, the product (it is indeed an AdGUARD license), the expiry and the domain cap. It then shows the license state, the holder's name, the expiry date and the number of domains allowed.

3.4 The four states

The state is determined when the license is loaded, then re-evaluated against the date: a valid license switches automatically to Expired on its expiry day.

3.5 The domain quota

The license sets a maximum number of domain records. When that cap is reached, adding a new domain is refused, with a message stating the current limit and the number of records already created. To audit more domains, activate a license with a higher cap. Deleting an existing record frees a slot in the quota.

3.6 Renewal and deployment

Renewing simply means activating a new license with a later expiry: it replaces the previous one, with no other steps. To deploy the same license on several machines, distribute the same license.key file and activate it on each; the license is not tied to a particular machine. On a shared machine, the installed license applies to all Windows accounts.

4. Application name and reports

4.1 The name comes from the license

The Settings › Branding menu from previous versions, which let you set an application name, tagline and logo along with an issuer identity, has been removed. The name the application displays — on the splash screen, in the title bar and at the top of the sidebar — is now the license holder's name, as written in the license.

This name is no longer editable by hand: it applies as soon as a license is activated. Until a license is loaded, the application is called "AdGUARD".

4.2 Identity in reports

Exported reports (HTML, PDF) carry the license holder's name — that is, the application name — together with the generation date, in the header and footer. The detailed issuer customization that existed before (company, website, contact address, header logo, all set in Settings › Branding) is no longer offered: the issuer's identity in reports is limited to the name carried by the license.

4.3 The audited domain's logo

The audited domain's logo, by contrast, is still fully supported — this is a notion distinct from the issuer's identity. From a domain record (§ 5.2) you can attach a logo: it appears on the cover page of that domain's executive report. This is the audited client's logo, on their own report.

Aim for a crisp image, around 180 px tall, on a transparent or white background, in PNG or JPG. This logo is specific to each record: two domains can each have their own.

4.4 Theme and language

The application offers a light and a dark theme, as well as a switch between French and English. These settings are available in the preferences and apply immediately across the whole interface, with no restart. They are independent of the license and specific to each machine.

5. Managing audited domains

5.1 The portfolio

The Domains screen lists every directory you follow, with four headline figures: number of domains, number of audits run, number never audited, and the date of the most recent audit across all clients. A search box filters the list, and Add a domain creates a new record.

The portfolio: headline figures, search and the list of domains.

5.2 The domain record

The record holds the client's details — name, domain, contact, industry, country, engagement reference, notes — the Activity block summarising its posture, and the logo used on report covers.

A domain record: client details, audit activity and the logo for reports.

5.3 The active domain and data separation

At any time, exactly one domain is active. It governs everything else in the application: the connector shown, the baselines available, the history browsed, the dashboard and the reports produced. Switching happens on the fly, with no restart.

Each domain has its own folder on disk, with its own settings and its own history database. A client's directory credentials are therefore never reachable from another client's context.

6. The Active Directory connector

6.1 How it works

The connector is the technical entry point of the audit. It opens read-only access to the directory over LDAP. Until it is configured and tested, the controls stay locked and do not enter the score.

The Connectors screen: domain, domain controller, search base and read account.

6.2 The fields

6.3 The rights required

A plain domain user is enough for the vast majority of controls: reading objects, their attributes and their security descriptors is open by default in Active Directory. This is what makes AdGUARD usable from the very first meeting, with no administrative process.

A few controls target objects with restricted read access, notably the certificate services container and some configuration partitions. Without rights on those objects, these controls report not assessed, with the reason — never 'compliant'.

6.4 Testing and removing

The Test connection button checks actual access: an LDAP bind, then a real read of a directory object. A failed test leaves the connector disabled and locked. The application never enables a connector whose access has not been proven — an audit resting on an unreachable source would produce a falsely reassuring score.

Removing the configuration erases the connector's local settings. Nothing changes in the directory: AdGUARD never wrote to it.

6.5 Security of stored credentials

The read account's password is encrypted with DPAPI at machine scope. A configuration file copied to another machine is unreadable. On the other hand, every Windows account on the machine can decrypt it: this is deliberate, since they share the same audit workstation.

7. Controls and categories

7.1 The catalog

Version 0.1.0 embeds 176 controls across 8 built-in packs, compiled into the application itself: no JSON file ships alongside the executable, and the catalog is available from the very first run.

7.2 Anatomy of a control

7.3 Levels L1 and L2

This weighting matters: failing an L1 control weighs three times more than an L2. It prevents a directory that neglected delegation but enabled many cosmetic hardening settings from showing a flattering score.

7.4 Selecting controls

The Security controls screen presents the catalog grouped by category, with a toggle per control, All / None actions per category, and a running counter 'X / Y controls selected'.

The catalog: controls grouped by category, with their level and an explanation of the check.

7.5 Adding your own controls

Settings › New control extends the catalog without reinstalling, by importing JSON packs from a URL or a file. Imported packs are merged into the built-in catalog; a restart is needed to load them. Built-in packs cannot be deleted.

The New control screen: pack import and the list of installed packs.

Adding a single control, with its framework mappings.

This is the mechanism to carry an organisation's own requirements: an in-house policy, a recurring contractual clause, or a control demanded by an external auditor.

8. Compliance frameworks

8.1 The framework mapping principle

Every control is cross-referenced with the frameworks it satisfies. This mapping is not decorative: it is what allows an 'ANSSI' or 'CIS level 1' baseline to be produced without retyping anything, and a compliance-by-framework report to be issued.

8.2 Coverage

8.3 MITRE ATT&CK

Where the other frameworks answer 'which requirement does this control satisfy', ATT&CK answers 'what does an attacker lose when this is fixed'. That framing carries far better in a steering committee than a clause number.

9. The ANSSI maturity model

9.1 The principle

Every control is tied to a tier from 1 to 5. The level attained is the highest tier N such that no non-compliant control remains at levels 1 through N. You therefore cannot claim a higher tier while a gap at a lower tier persists — that is what sets this reading apart from a plain percentage.

9.2 The five tiers

10. Baselines

10.1 What a baseline is

A baseline is the agreed audit scope: the list of controls retained, those excluded, and any level adjustments. It is what makes an audit reproducible and defensible — without a baseline, the question 'why was this control not assessed?' has no documented answer.

10.2 The templates provided

Ten templates are provided. Each selects the controls matching a framework criterion and excludes the rest. The counts shown are computed from the actual catalog, never hard-coded: they follow automatically when controls are added.

The Templates screen: each card states how many controls it keeps and how many are actually runnable.

10.3 The baseline editor

The editor holds the baseline's name, its scope — global for every domain, or specific to the active client — a free-text description to record exclusion rationales, and the full list of controls with their inclusion and level. The Active, Excluded and Re-levelled counters update live.

The category filter and the label search let you work one domain at a time: show only ACL delegation, or only AD CS controls, without scrolling through 176 rows.

The editor: baseline identity, counters, filters, then the full list of controls.

10.4 Good practice

• Start from a template rather than the full selection: a template carries a framework rationale the client understands.
• Exclude controls outside the technical scope, and document every exclusion in the description: at debrief time, that is what separates a deliberate scope from an oversight.
• Keep a frozen reference baseline, to measure progress over time on a constant basis.
• Do not change a baseline mid-engagement: an audit run on a different scope is no longer comparable to the previous one.

11. Running an audit

11.1 Preparation

• The active domain is the one you expect.
• The connector is configured and tested.
• The scope is settled: baseline applied, or manual selection confirmed.

11.2 Start and follow

The Security audit › Run screen shows the retained scope at the top as 'X / 176 controls enabled', then the start button. During the run, a dial shows overall progress and the stream of evaluated controls scrolls past, with the detailed finding for each warning or non-compliance: the objects actually concerned, named.

11.3 The verdicts

11.4 How the score is calculated

poids d'un contrôle :  L1 → 3      L2 → 1

points obtenus     :  conforme       → 100 % du poids
                      avertissement  →  50 % du poids
                      non conforme   →   0

score = points obtenus / points possibles × 100

A plain 'compliant controls / assessed controls' ratio would treat a dangerous delegation on the administrators container the same as a minor logging setting. The weighting corrects that: the score reflects risk, not headcount.

12. Results, history and comparison

12.1 The results screen

Six headline figures give the immediate reading: controls assessed, compliance percentage, compliant, non-compliant, warnings and not assessed. Three tools refine the display: a search on the label, a filter by control category, and a filter by level. A counter always shows how many controls are displayed out of the total.

Clicking a row expands it to reveal the actual finding with the objects observed, the description, the remediation, the framework mappings, the PowerShell verification command and the documentation link.

An audit's detail: headline figures, filters, export buttons and one control expanded.

12.2 The history

Each row shows the date, the number of controls assessed, the score, the verdict breakdown and the change in points against the previous audit. A filter bar — search, period, applied baseline, and an 'X / Y' counter — makes it possible to find a specific audit in a growing history.

The history: one audit per row, with its filter bar and display counter.

12.3 Comparing two audits

The comparison screen shows the score before and after, the change, the controls that became compliant and left non-compliance, the regressed controls — those that were compliant and no longer are, to handle first because a regression almost always signals an uncontrolled configuration change — and the improved controls, which are the substance of the debrief.

13. The dashboard

13.1 Overall and per-category compliance

Since Active Directory is the only audited referential, a per-referential breakdown would have a single row. The dashboard therefore reasons by control category: the tiles show the eight weakest categories, and the stacked block lists them all, from least to most compliant. That list is what points to where the effort belongs.

Compliance by control category, weighted breakdown, weakest first.

13.2 Trend

The trend chart traces the compliance percentage over time. This is the curve to show in a steering committee: it makes the effect of remediation visible and, just as much, silent drift.

The compliance trend over time.

13.3 How to read the dashboard

• A low overall score is not a failure in itself: a first audit on a directory that was never hardened commonly lands between 40% and 60%. What matters is the trajectory.
• Look at level 1 non-compliances before the percentage: ten failing L1 controls weigh more, in real risk, than thirty L2.
• A sharp drop between two audits calls for a comparison before any conclusion: it comes more often from a scope change than from a real regression.

14. Attack paths and trusts

14.1 What an attack path is

An attack path is a right held by a non-privileged principal over a critical object, allowing them to take control of it. It is not a software vulnerability: it is a legitimate delegation gone dangerous, often granted years earlier for a reason that no longer exists.

AdGUARD extracts these paths from the controls' findings and draws them as a graph: on the left the principal holding the right, on the right the targeted object, and between them an edge coloured by the severity of the right.

The attack path graph: who can compromise what in the directory.

14.2 Reading a path

14.3 Trusts

A poorly filtered inbound trust extends every attack path beyond the audited domain. The trust graph shows the partners, the direction of the relationship and the weaknesses found: SID filtering off, TGT delegation, no selective authentication, RC4 encryption, stale trust password.

The trust graph: partners, direction and weaknesses found.

14.4 The remediation plan

The attack path report includes a dsacls remediation script. The removal commands are deliberately commented out: AdGUARD is a read-only tool and must never modify a directory by accident. The verification commands are active and have no side effect.

15. Reports and exports

15.1 How it works

Exporting combines two independent dimensions: a report type, which sets the editorial angle and the content, and one or more file formats, which set the medium. The chosen type applies to every format exported from an audit's detail.

Settings › Export: choosing the report type and enabling formats.

15.2 The six report types

An exported report, with its branded header and headline figures.

15.3 The five formats

15.4 Which report for which purpose

16. Performance

Settings › Performance sets the number of controls analysed simultaneously, from 1 to 16, with a default of 8. Raising it speeds up the audit but puts more load on the domain controller being queried.

The built-in benchmark measures the duration of a simulated audit at different parallelism levels and points at the optimal setting for this machine. Beyond a certain point, contention costs more than it gains.

The parallelism setting and the built-in benchmark.

17. Appendices

Appendix A — File layout

C:\Program Files\AdGUARD\        programme (remplacé à chaque mise à jour)
C:\ProgramData\AdGUARD\          données (jamais touchées par une réinstallation)
├── license.key
├── control-packs\
└── clients\<client>\
    ├── settings.json
    └── audit.db

Appendix B — Troubleshooting

Appendix C — A typical engagement

Appendix D — Security and confidentiality

• No write on the audited directory: every operation is a read.
• No data leaves the machine: no intermediate service, no telemetry, no reporting back to the vendor.
• Offline license verification: no activation server is contacted.
• Secrets encrypted with DPAPI at machine scope: a configuration file copied elsewhere is unreadable.
• The audit workstation is a sensitive asset: it concentrates read access to several clients' directories. Disk encryption, session locking and restricted physical access are prerequisites, not options.
• Reports contain detailed configuration data. They must be transmitted over a secure channel and retained according to the policy agreed in the contract.

Appendix E — Glossary