WinPassage is an EU-oriented Windows password self-service toolkit for small offices and local networks where a regular Windows 11 Pro machine is used as the central file and user machine instead of running Active Directory or Windows Server.
It provides a Windows background agent, an admin desktop app, and a client desktop app for controlled local-user password changes, mapped drive credential refresh, and audit-friendly password change workflows.
Warning
WinPassage is not a compliance certificate, not an Active Directory replacement, and not a way to bypass Microsoft licensing. It is a small-network helper for environments where Windows Pro is intentionally used as a central machine. Validate the final deployment with your legal, licensing, and security requirements.
Read on to understand the intended network model. Or jump straight to Get started if you already have a Windows Pro central machine and want to install the agent.
Small companies often start with a single Windows 11 Pro workstation that stores shared folders and local user accounts. That can be enough for a small internal network, but it creates operational problems:
- users cannot safely change their own central-machine password without admin help;
- mapped drives keep using old credentials after a password change;
- password resets are hard to audit consistently;
- password handling often happens through chat, paper notes, or direct admin intervention;
- introducing Active Directory, Windows Server, Intune, or Entra ID may be disproportionate for a very small office.
WinPassage adds a controlled password-change layer around that central Windows Pro machine.
The central machine runs winpassage-server.exe as a Windows Service. It exposes a restricted local-network API for:
- listing local Windows users for admins;
- creating, disabling, deleting, and managing local Windows users;
- granting and revoking local administrator access;
- listing and logging off Windows sessions for offboarding;
- resetting local user passwords from the admin app;
- allowing users to change only their own password by providing the current password;
- writing audit events without logging secrets.
The admin and client apps are Tauri 2 desktop apps. They are intentionally separate:
WinPassageAdminis for the owner, IT operator, or trusted administrator;WinPassageClientis for regular users who only need self-service password change.
WinPassage is designed for EU small-business environments that need more disciplined password handling without adding a full domain infrastructure.
It helps implement practical controls around:
- self-service password changes;
- password policy validation before submission;
- least-privilege client behavior;
- local audit trails;
- no cloud dependency;
- no stored plaintext passwords;
- mapped drive credential refresh after a successful password change.
Important
NIS2 and similar audit frameworks are organization-level obligations. WinPassage can support access-control and cyber-hygiene processes, but it cannot make an organization compliant by itself. For the official EU text, see Directive (EU) 2022/2555.
WinPassage is not:
- Active Directory;
- Windows Server;
- an LDAP or Kerberos implementation;
- a remote desktop product;
- a password vault;
- a public-internet admin panel;
- a replacement for MFA, backups, endpoint protection, or documented security policies.
If the environment grows beyond a small local network, move to Windows Server, Active Directory, Entra ID, Intune, a NAS with proper identity management, or another managed identity platform.
WinPassage is used in three places:
central Windows Pro machine -> winpassage-server.exe Windows Service
administrator workstation -> WinPassageAdmin
user workstation -> WinPassageClient
Detailed deployment and service setup belongs in CONTRIBUTING.md. This README focuses on daily usage and operational behavior.
Important
Run the server agent only on trusted private networks. Do not expose the API directly to the public internet. Use VPN, firewall allowlists, and TLS/mTLS in production.
Download the latest Windows release assets from:
https://github.com/rozsazoltan/winpassage/releases/latest
On the central Windows Pro machine, place these files in the same folder:
WinPassageAdmin installer or executable
WinPassageClient installer or executable
winpassage-server.exe
winpassage-agentctl.exe
winpassage-updater.exe
Install WinPassageAdmin on the central computer, sign in with a local administrator account, open the app, and use Make this computer a WinPassage server:
Binary source folder: folder containing the three service executables
Install folder: C:\Program Files\WinPassage
Bind host: 0.0.0.0
Port: 4487 or your chosen private-network port
Admin token: long random token, at least 16 characters
The service installs the server tools into the install folder and starts the Windows Service. Clients and admin profiles connect with:
http://SERVER-IP:PORT
Example:
http://192.168.1.10:4487
Install the desktop apps where needed:
WinPassageAdmin -> central machine or administrator workstation
WinPassageClient -> user workstations
Both desktop apps may be installed on the same computer. They are separate applications and their app names intentionally do not contain spaces.
Open WinPassageAdmin, add the central machine by IP/DNS address, load users, and test with a disposable local Windows account first.
Tip
If you open WinPassageAdmin from a standard Windows account, the app shows a lock screen. If you are signed in with an administrator account but the app is not elevated, the console opens, but local service install/remove actions still require Run as administrator.
Important
Do not expose the WinPassage port to the public internet. Keep it on a trusted LAN/VPN and use a long random admin token.
The central machine is the Windows 11 Pro computer that owns the local user accounts and shared folders. A machine becomes a WinPassage server only after the server service is installed from WinPassageAdmin with administrator privileges.
Use Settings → Advanced → Remove local server service in WinPassageAdmin to stop and remove the local WinPassage service. This removes only WinPassage service components and optionally the copied WinPassage executables. It never deletes Windows users or profiles.
Before users start using WinPassage, the operator should confirm:
- the WinPassage service is running
- the API is reachable from the private network
- the admin token is configured
- the audit log path is writable
- the Windows firewall allows the selected private-network port
- backups for shared data exist
Health check:
Invoke-RestMethod http://CENTRAL-PC:4487/healthExpected response:
{
"status": "ok",
"service": "winpassage-server"
}A single WinPassageAdmin installation can keep local shortcuts for multiple standalone WinPassage servers. This is useful when one operator manages several small networks, branches, workshops, or office rooms where each location has its own Windows Pro central machine.
Each server profile contains only connection metadata:
Display name
Network or location name
IP address or DNS name
Port
Protocol
Operator notes
The profile does not store Windows users and should not store admin passwords. User lists, sessions, administrator status, and account changes are always loaded from the selected Windows machine at request time.
Important
Treat each server as a separate authority. Switching the active profile changes which Windows machine receives user-management actions. Verify the selected server before creating, deleting, disabling, or resetting users.
Install WinPassageAdmin on the central machine or an administrator workstation.
On the central machine, the app requires a Windows administrator account for local server installation, demotion, and service management. Standard users see a locked screen with instructions to switch to an administrator account.
On first launch, complete the short setup screen before the in-app guide starts. Then register one or more server profiles:
Name: Office server
Network: Budapest office
IP/DNS: 192.168.1.10
Port: 4487
Protocol: http or https
Admin token: the value from WINPASSAGE_ADMIN_TOKEN
Use Load users & sessions to list users and sessions from the selected server. Select a user, type a new password, add a reason, and run Reset password. The active server is shown in the dashboard because every operation changes the selected Windows machine directly.
Warning
Admin reset does not require the user's current password. Use it only for administrator-controlled recovery, onboarding, and emergency flows. Regular users should use the client app.
Install WinPassageClient on each workstation that maps shared drives from the central machine.
On first launch, complete the short setup screen before the in-app guide starts. The server address is configured during deployment or support. It is shown to the user, but its modification is kept behind Advanced connection settings so regular users do not accidentally point the app at the wrong machine.
For normal use, the user enters:
Username
Current password
New password
Confirm new password
After a successful password change, the client can reconnect configured mapped drives with the new credentials.
WinPassageClient starts with zero default drive mappings. Add only the drive letters and share paths used on that workstation. Each drive can be mounted, unmounted, edited, or deleted individually.
WinPassage reads the current local Windows accounts from the selected central machine. It does not keep a separate user database and does not try to mirror Windows users into application storage.
The admin console is designed to support these local Windows account operations:
- list current local Windows users
- create a local user
- delete a local user
- enable or disable a local user
- reset a user's password as an administrator
- grant or revoke local administrator access
- list active Windows sessions
- log off a selected session before offboarding or account deletion
Warning
User creation, deletion, administrator grants, administrator revokes, and session logoff are privileged Windows operations. Use a dedicated test account first and keep the service reachable only from a trusted private network, VPN, or mTLS-protected admin channel.
Important
The local Administrators group is resolved through the built-in Administrators SID where possible. The UI should display administrator access as a capability, not as a localized group name.
Use the admin app when the administrator needs to set a new password for a local user without knowing the old one.
API equivalent:
$body = @{
new_password = "NewStrongPassword123!"
reason = "Owner-approved reset"
request_id = [guid]::NewGuid().ToString()
} | ConvertTo-Json
Invoke-RestMethod `
-Method Post `
-Uri "http://CENTRAL-PC:4487/v1/users/julia/password/reset" `
-Headers @{ Authorization = "Bearer replace-with-a-long-random-token" } `
-ContentType "application/json" `
-Body $bodyUse the client app for normal user-driven password changes. The server verifies the current password through Windows and only changes that user's own password.
API equivalent:
$body = @{
username = "julia"
current_password = "OldPassword123!"
new_password = "NewStrongPassword123!"
request_id = [guid]::NewGuid().ToString()
} | ConvertTo-Json
Invoke-RestMethod `
-Method Post `
-Uri "http://CENTRAL-PC:4487/v1/me/password/change" `
-ContentType "application/json" `
-Body $bodyAfter a successful password change, the client app can reconnect configured mapped drives using the new credentials.
The current implementation uses Windows network-drive APIs instead of passing passwords through net use command-line arguments.
Typical flow:
1. user changes central password
2. server returns success
3. client reconnects configured drives with username + new password
4. individual drives can also be mounted or unmounted manually
5. Windows updates remembered mappings for the user profile
Note
Windows may reject multiple simultaneous SMB sessions to the same server using different credentials. Close open Explorer windows and applications using the share before reconnecting drives.
The server writes JSON Lines audit events to:
C:\ProgramData\WinPassage\audit.jsonl
Each event records:
timestamp
event name
actor
subject user
request id
source IP
result
reason
Passwords are never written to the audit log.
Example:
{"timestamp":"2026-06-09T10:30:00Z","event":"self_password_change","actor":"julia","subject":"julia","result":"success","request_id":"..."}winpassage-updater.exe is the dedicated updater entrypoint. It must only use the official repository:
https://github.com/rozsazoltan/winpassage
Do not configure custom update hosts or mirrors. Update application should verify artifact names, checksums, and the official GitHub source before replacing installed binaries.
Use the manual Delete Release workflow only when a release must be withdrawn, for example after publishing assets with incorrect names or broken binaries.
GitHub Actions input:
version: 0.2.0
confirm: DELETE 0.2.0
The workflow deletes the GitHub Release and the matching vX.Y.Z tag. It does not change already installed machines. Publish a corrected patch release for normal users whenever possible.
Warning
Release deletion is destructive. Prefer a new patch release if the incorrect release may already have been downloaded.
Windows 11 Pro can work as a small central file machine, but it remains a client operating system. Microsoft Windows 11 use terms allow up to 20 other devices to access software on the licensed device for features such as file services, print services, IIS, Internet connection sharing, and telephony services.
For practical deployments, treat WinPassage as suitable for roughly the same scale:
| Environment | Recommendation |
|---|---|
| 1-5 users | Good fit for a simple local network. |
| 6-15 users | Good fit if network shares are modest and backups are disciplined. |
| 16-20 users | Works only if the Windows Pro connection limit and performance are acceptable. |
| 20+ users | Use Windows Server, AD/Entra ID, NAS identity management, or a proper domain setup. |
Warning
The 20-device limit is a Windows licensing and platform boundary, not a WinPassage feature flag. Do not design around it with multiplexing or connection pooling.
WinPassage follows these rules:
- regular users can only request a password change for themselves;
- self-service change requires the current password;
- admin reset requires an admin bearer token;
- passwords are accepted only in JSON request bodies, never URL query strings;
- passwords are not logged;
- mapped drive reconnect happens only after server-confirmed password change;
- generated audit records avoid secrets;
- the API is intended for private LAN or VPN use;
- admin server profiles are connection shortcuts, not an application user database;
- client server address changes are intentionally hidden behind an advanced confirmation flow.
Recommended production controls:
- private network profile only
- inbound firewall allowlist
- VPN or overlay network
- TLS/mTLS in front of the agent
- long random admin token
- regular audit log review
- endpoint protection on the central machine
- offline backups of shared data
The server reads configuration from environment variables.
| Variable | Default | Description |
|---|---|---|
WINPASSAGE_BIND |
127.0.0.1:4487 |
Address and port for the server API. |
WINPASSAGE_ADMIN_TOKEN |
empty | Required for admin endpoints. |
WINPASSAGE_REQUIRE_TLS |
true |
Refuses non-TLS deployment when set to true. |
WINPASSAGE_AUDIT_LOG |
C:\ProgramData\WinPassage\audit.jsonl |
Audit log output path on Windows. |
WINPASSAGE_PASSWORD_MIN_LENGTH |
12 |
Minimum accepted password length. |
Tip
Use Windows system environment variables for the service account context. Restart the service after changing them.
Admin and client app settings are local workstation settings:
| Setting | Stored by | Secret? | Notes |
|---|---|---|---|
| Server profiles | Admin app | No | Display name, network name, IP/DNS, port, protocol, notes. |
| Active server | Admin app | No | Determines which standalone Windows machine receives admin actions. |
| Server URL | Client app | No | Hidden behind advanced connection settings to avoid accidental changes. |
| Username and drive paths | Client app | No | Stored only for user convenience. |
| Admin token | Admin app | Yes | Session-only by default; do not store without secure storage. |
| Passwords | Neither app | Yes | Never stored. |
A Windows 11 Pro central machine is practical for very small networks, but it is not built for larger file-service workloads. For more than 20 accessing devices, use a server-grade setup.
The admin app can remember multiple server profiles, but those profiles do not create federation, synchronization, replication, or shared identity between servers. Each Windows Pro machine remains independent.
WinPassage targets local Windows accounts on the central machine. Microsoft accounts, domain accounts, and Entra ID identities are outside the first implementation scope.
WinPassage performs early validation, but Windows remains the authority. Password history, complexity, and local security policy may still reject a password.
Mapped drives can remain open in Explorer or other applications. If reconnect fails, close applications using the share and retry.
WinPassage helps with audit-friendly password change workflows, but NIS2, ISO 27001, and similar frameworks require wider organizational, technical, and procedural controls.
See: CONTRIBUTING.md.
WinPassage is released under the GNU Affero General Public License v3.0 only.
Created by Zoltán Rózsa.