# AD Bulk Tool prototype

A small Avalonia + C# prototype for bulk Active Directory edits from a CSV.

## What it currently does

- Load a CSV file.
- Show all CSV headers in a human-readable dropdown, including duplicate column names as `1: Name`, `2: Name`, etc.
- Select one of these actions:
  - Disable user
  - Enable user
  - Add to group
  - Remove from group
  - Set random password
  - Set password change at next login
  - Set random password + change at next login
- Preview changes locally.
- Run a real AD dry run that binds to LDAP/LDAPS and validates users.
- Execute changes against AD.
- Test DNS, TCP 389, TCP 636, LDAP bind on 389, and LDAPS bind on 636 before running a job.
- Use two presets:
  - `Use LDAP 389 (normal edits)`
  - `Use LDAPS 636 (password edits)`

## Important safety notes

- Test with a dedicated test OU and test accounts first.
- Leave `Dry run` enabled until you are sure the mapping is correct.
- Normal edits such as enable, disable, add to group, and remove from group can use LDAP 389.
- Password reset actions require LDAPS 636 and are blocked if LDAP 389 is selected.
- `Set password change at next login` sets `pwdLastSet=0`; it does not generate a new password.
- Do not use `Ignore cert errors` in production. Install your internal root CA on the Linux machine instead.
- The prototype shows generated passwords in the result list. Treat the screen as sensitive.

## Run

```bash
dotnet restore
dotnet run
```

## Typical values

For normal edits:

```text
LDAP host:      [DomainController hostname]
Port:           389
Use LDAPS:      unchecked
Search base DN: DC=Your,DC=domain
Bind username:  Your\your-admin-user or your-admin-user@YourDomain
```

For password reset actions:

```text
LDAP host:      [DomainController hostname]
Port:           636
Use LDAPS:      checked
Search base DN: DC=Your,DC=domain
Bind username:  Your\your-admin-user or your-admin-user@YourDomain
```

## Recommended test order

1. Enter host, search base, bind username, and bind password.
2. Click `Test ports + LDAP/LDAPS`.
3. Confirm whether LDAP 389 works.
4. Confirm whether LDAPS 636 works.
5. Load a tiny CSV with test users.
6. Run `Preview`.
7. Run with `Dry run` checked.
8. Only then run without `Dry run`.

## Linux LDAPS trust

For proper LDAPS, your Linux machine must trust the CA that issued the domain controller LDAP certificate.
On Arch/CachyOS, this is commonly done by placing your root CA certificate under `/etc/ca-certificates/trust-source/anchors/` and running:

```bash
sudo trust extract-compat
```

Exact CA trust commands depend on your Linux distribution.