ADBulk/README.md

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

dotnet restore
dotnet run

Typical values

For normal edits:

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:

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:

sudo trust extract-compat

Exact CA trust commands depend on your Linux distribution.