Summary
Phase 2 of Password Synchronisation, tracked under the epic #1119 and split out of it now that Phase 1 has shipped. This is the remaining committed scope: a way for a password change captured outside JIM to enter the password channel.
Everything downstream of the entry point already exists and is proven. A change arriving here fans out, coalesces, retries, expires, reports and is retained exactly like one an administrator makes today, so this issue is about the endpoint and its wire contract, not about delivery.
PRD: engineering/prd/doing/PRD_PASSWORD_SYNCHRONISATION.md (Phase 2 section). No implementation plan yet.
Scope
An API-key-authenticated endpoint that an external capture agent posts password change events to:
- Payload envelope encryption, so a TLS-terminating reverse proxy cannot recover the password from the request body. TLS alone is not enough where the deployment terminates it before JIM.
- A versioned wire contract, so an agent deployed across an estate can be upgraded independently of JIM.
- Replay protection, so a captured request cannot be resubmitted to re-set an old password.
- Per-agent check-in reporting, so an administrator can see which capture agents are healthy and which have gone quiet. An agent that silently stops is indistinguishable from a domain where nobody changed their password.
Surface parity applies as everywhere else: whatever an administrator can see or configure about agents needs to reach the portal, the REST API and PowerShell.
Explicitly not in scope
The agent's signing prerequisite, which does not gate this endpoint
Recorded so the sequencing decision stays visible: building the endpoint first is safe, building the agent first is not. The full prerequisite list lives on #1625.
A password filter is a native DLL loaded into LSASS, and where a customer has enabled LSA Protection (RunAsPPL), which JIM's target sectors do, LSASS loads only plugins carrying a Microsoft signature. Checked against Microsoft's current documentation, that is a submission service rather than an approval gate: LSA plugins explicitly do not go through Windows Hardware Lab Kit qualification (that is for drivers), and the shim review board that reviews submitted source applies to UEFI firmware only. The route is register for the Windows Hardware Developer Program, obtain an EV code-signing certificate for Tetron, package the DLL as a single signed CAB whose signature matches that certificate, submit it under Partner Center's File Signing Services, and download the signed package. Microsoft signs binaries; no source is submitted.
Two residual risks, one documented and one an assumption to test: plugins must conform to Microsoft's Security Development Lifecycle guidance, and Microsoft states non-conformance can cause a plugin to fail to load even when correctly signed; and while no review step is published for LSA plugins, a filter that captures cleartext passwords and forwards them off the host is structurally what a credential-exfiltration implant looks like, with no published service level or appeal route. Decided: do not pre-contact Microsoft, submit and find out.
None of this touches this issue. The ingress API is authenticated HTTP and can be built and tested against a stub client.
Related
Summary
Phase 2 of Password Synchronisation, tracked under the epic #1119 and split out of it now that Phase 1 has shipped. This is the remaining committed scope: a way for a password change captured outside JIM to enter the password channel.
Everything downstream of the entry point already exists and is proven. A change arriving here fans out, coalesces, retries, expires, reports and is retained exactly like one an administrator makes today, so this issue is about the endpoint and its wire contract, not about delivery.
PRD:
engineering/prd/doing/PRD_PASSWORD_SYNCHRONISATION.md(Phase 2 section). No implementation plan yet.Scope
An API-key-authenticated endpoint that an external capture agent posts password change events to:
Surface parity applies as everywhere else: whatever an administrator can see or configure about agents needs to reach the portal, the REST API and PowerShell.
Explicitly not in scope
The agent's signing prerequisite, which does not gate this endpoint
Recorded so the sequencing decision stays visible: building the endpoint first is safe, building the agent first is not. The full prerequisite list lives on #1625.
A password filter is a native DLL loaded into LSASS, and where a customer has enabled LSA Protection (RunAsPPL), which JIM's target sectors do, LSASS loads only plugins carrying a Microsoft signature. Checked against Microsoft's current documentation, that is a submission service rather than an approval gate: LSA plugins explicitly do not go through Windows Hardware Lab Kit qualification (that is for drivers), and the shim review board that reviews submitted source applies to UEFI firmware only. The route is register for the Windows Hardware Developer Program, obtain an EV code-signing certificate for Tetron, package the DLL as a single signed CAB whose signature matches that certificate, submit it under Partner Center's File Signing Services, and download the signed package. Microsoft signs binaries; no source is submitted.
Two residual risks, one documented and one an assumption to test: plugins must conform to Microsoft's Security Development Lifecycle guidance, and Microsoft states non-conformance can cause a plugin to fail to load even when correctly signed; and while no review step is published for LSA plugins, a filter that captures cleartext passwords and forwards them off the host is structurally what a credential-exfiltration implant looks like, with no published service level or appeal route. Decided: do not pre-contact Microsoft, submit and find out.
None of this touches this issue. The ingress API is authenticated HTTP and can be built and tested against a stub client.
Related