Self-Service Portal

The Windows self-service portal lets a signed-in endpoint user start approved Ordyn jobs without opening the Ordyn web UI.

The portal is intended for controlled user-facing actions such as installing assigned software, repairing an application, collecting diagnostics, or running an approved remediation job. It is not a generic remote execution surface: Ordyn decides which endpoints and jobs are visible and whether a run request is allowed.

Availability

The portal is Windows-only.

Users can open it through:

• the Ordyn tray context menu item Portal
• the ordyn://portal Windows URI handler

The portal UI talks to the local agent service through a service-owned local pipe. It does not authenticate directly to the Ordyn server and it does not decide which Windows account is active.

Runtime Flow

1. A signed-in Windows user opens the portal.
2. The portal connects to the local agent service over the self-service portal IPC pipe.
3. The agent service impersonates the pipe client and resolves the caller from the Windows token.
4. The agent sends a signed request to Ordyn with:
   • the source endpoint identity
   • the resolved Windows account
   • the requested list or run action
5. Ordyn verifies the endpoint-originated signed message.
6. Ordyn applies tenant, endpoint, job, assignment, and self-service policy checks.
7. Ordyn returns the allowed portal entries or creates the requested job run.

The portal request does not trust a username supplied by the UI. The username used for authorization is derived by the local agent service from the operating system token of the pipe client.

Portal Views

The portal has these logical areas.

This Device

This Device lists self-service jobs that the signed-in Windows account may run on the endpoint where the portal was opened. Jobs in this area run their steps on that endpoint.

Multi-device

Multi-device appears when the current endpoint has self-service jobs configured to run on all eligible assigned endpoints. The job is still started from the current endpoint, and the portal shows how many endpoints are included.

When the user starts a job from this area, Ordyn creates one grouped job run for every endpoint that matches all normal self-service checks for the signed-in Windows account.

Other Devices

Other Devices lists other endpoints in the same tenant where the same Windows account is allowed to run self-service jobs.

This is useful when the same person is allowed to service more than one device, for example a primary user who also has explicit access to another endpoint.

Endpoint visibility stops at the tenant boundary. A source endpoint from tenant A can only list or run jobs on endpoints from tenant A. This applies even if the same Windows username appears in policies in tenant B.

Both endpoint and job lists are paginated.

Job lists include a category sidebar. All / Alle is a built-in virtual category that does not have to be assigned and always shows every visible self-service job for the current view. Additional categories are global reusable labels and jobs can belong to multiple categories. Selecting a category only filters the already-authorized job list; it does not grant access to jobs by itself.

Job Eligibility

A job appears in the portal only when all of these conditions are true:

• the job definition is marked as self-service enabled
• the job is assigned to the endpoint through the normal assignment model
• the endpoint has not disabled that job locally
• the signed-in Windows account is allowed by the endpoint's effective self-service policy
• the source endpoint and target endpoint are in the same tenant
• the target endpoint is approved

Starting a self-service job still uses the normal job run creation path. Validity windows and other normal run constraints still apply.

Portal Run Scope

Each self-service job has a portal run scope.

Scope	Portal behavior	Run behavior
Run only on the triggering endpoint	The job appears under This Device or the selected Other Devices endpoint.	Starting the job creates a run for the selected endpoint only.
Run on all eligible assigned endpoints	The job appears under Multi-device on each eligible source endpoint.	Starting the job creates one grouped run across every eligible assigned endpoint visible to the signed-in Windows account.

An endpoint is included in a multi-device self-service run only when:

• the job is assigned to that endpoint
• the endpoint has not disabled that job locally
• the signed-in Windows account is allowed by that endpoint's effective self-service policy
• the endpoint is approved
• the endpoint is in the same tenant as the source endpoint

If the same job is assigned to many endpoints, the portal starts only the endpoints that pass these checks at request time.

Self-service categories and job icons are presentation metadata:

• categories control where the job appears in the portal filter sidebar
• the virtual All / Alle category is always available and is not stored
• uploaded job icons are shown next to jobs in the portal list where supported
• icon uploads are restricted to small PNG images

Neither categories nor icons affect Ordyn authorization.

Policy Inheritance

Self-service access is configured at tenant, folder, and endpoint scope.

The effective policy is resolved in this order:

1. tenant
2. folder ancestors, from parent to child
3. endpoint

Each scope can override these values:

Setting	Values	Default if nothing is configured
Self-service enabled	inherit, enabled, disabled	disabled
Allow primary user	inherit, yes, no	no
Explicit Windows accounts	account list	empty

inherit means the scope does not change the value inherited from earlier scopes. Since the root defaults are disabled and no primary-user access, a tenant, folder, and endpoint that all inherit will result in self-service being disabled.

Explicit Windows accounts are additive across the scopes that participate in the effective policy. If tenant, folder, and endpoint policies all add accounts, the endpoint's effective allow-list contains the unique normalized accounts from all of those scopes.

If a scope disables self-service, the effective enabled value becomes disabled from that point until a more specific scope enables it again.

Primary User Access

When Allow primary user is enabled in the effective policy, the endpoint's primary user is allowed to use self-service on that endpoint.

Primary-user matching uses the normalized Windows account name stored for the endpoint user. If primary-user access is disabled, being the endpoint's primary user is not enough; the Windows account must then be explicitly allowed by policy.

Explicit Windows Accounts

Explicit accounts are stored as normalized Windows account strings.

Windows accounts can include a domain, workgroup, or computer prefix, or they can be a bare username. Use the same form that is configured on the endpoint's primary user or explicit account policy.

Account example	Normalized account
ACME\Alex	ACME\alex
acme/Alex	ACME\alex
WORKGROUP\Alex	WORKGROUP\alex
Alex	alex

A prefixed account matches the same normalized prefix and username. For example, ACME\alex matches acme/Alex, but it is separate from alex. A bare username matches a bare username in the effective policy or primary-user record.

The portal authorizes by normalized account name, not by a globally unique identity object. Because the same account name can exist in different tenants and refer to different real people, every portal list and run request is additionally constrained by the source endpoint's tenant.

This tenant boundary is mandatory:

• tenant A source endpoints cannot list tenant B endpoints
• tenant A source endpoints cannot run jobs on tenant B endpoints
• matching usernames across tenants do not grant cross-tenant visibility

Running A Job

When a user clicks Run, Ordyn creates a normal job run for the selected self-service scope.

The job run records self-service metadata:

• source endpoint ID
• normalized Windows account
• source Windows session ID
• authorization basis, such as primary_user or explicit_account
• target endpoint IDs and target endpoint count

Job steps can also read the same run origin through trigger variables:

• trigger.type is self_service
• trigger.self_service.windows_account
• trigger.self_service.source_session_id
• trigger.self_service.source_endpoint_id
• trigger.self_service.source_endpoint_hostname
• trigger.self_service.target_endpoint_id
• trigger.self_service.target_endpoint_hostname
• trigger.self_service.target_endpoint_ids
• trigger.self_service.target_endpoint_count
• trigger.self_service.authorization_basis

See Variables for the full trigger field list.

Log message steps can use these values, but their rendered text is kept in the administrative job history. The portal shows the step status and overall progress without exposing the rendered message to the signed-in endpoint user.

The requester is represented as a self-service Windows account rather than as a web user.

Audit Data

Successful self-service run requests create an audit entry:

• action: self_service.job_run.requested
• causer: normalized Windows account
• auditable: target endpoint
• related auditable: source endpoint
• metadata:
  • source endpoint ID and hostname
  • target endpoint ID and hostname
  • target endpoint IDs and target endpoint count
  • Windows account
  • authorization basis
  • job definition ID and name
  • job run ID

This makes it possible to answer:

• who requested the job
• from which endpoint the request originated
• which endpoint was targeted
• why that Windows account was authorized
• which job run was created

Threat Model

Ordyn is the authority for self-service authorization. The local portal is only a user interface.

Threat	Expected behavior
A normal user opens the portal	The user can see and run only jobs allowed for their resolved Windows account in the source endpoint's tenant.
A user sends custom JSON to the portal IPC pipe	The service ignores any claimed username and derives the caller from the pipe client's Windows token.
A username exists in multiple tenants	The source endpoint tenant bounds all listing and run requests, so matching names in another tenant do not grant access.
A user has another user's Windows credentials	Windows has authenticated that user as the other account, so Ordyn treats the token as that account.
A local administrator tampers with the endpoint	Local administrators can generally subvert local process, token, service, or agent boundaries. This is treated as endpoint compromise.
The endpoint agent or endpoint private key is compromised	Ordyn may receive signed assertions from an endpoint that cannot be trusted. This is treated as endpoint trust compromise.
The edge relay is compromised	Edge can route traffic, but it does not become the business authority. Backend signature and authorization checks are still required.

The main security properties are:

• the portal UI does not choose the caller identity
• caller identity is derived through Windows token impersonation
• requests are signed by the enrolled source endpoint
• target endpoint selection is tenant-scoped
• job availability requires self-service enablement and a normal job assignment
• run requests are audited

Operational Notes

Self-service is disabled by default. Enable it deliberately at the tenant, folder, or endpoint scope, then mark only appropriate jobs as self-service enabled.

Prefer narrow assignments for powerful jobs. A self-service flag does not make a job globally available; assignment still controls which endpoints can run it.

For high-risk actions, use validity windows, endpoint-local job disables, and explicit allow-lists rather than broad primary-user access.