altool publishapp: --authentication UserPassword has no way to supply credentials

[dreasan]

1. Describe the bug

altool publishapp and the equivalent al_publish MCP tool accept --authentication UserPassword as a valid value, and the docs list it as supported, but there is no documented mechanism to actually supply NavUserPassword credentials. No --username / --password flag, no environment variable, no interactive prompt, and altool auth only handles Entra ID/AAD (per altool auth --help). On failure, the CLI prints "Run 'altool auth login' (interactive) and retry", which leads to the AAD browser flow (wrong path for NavUserPassword).

Net effect: UserPassword is parsed but not reachable. The standalone CLI / MCP is unusable against on-prem BC containers configured with -auth NavUserPassword. NavUserPassword is one of the four supported -auth modes in BcContainerHelper's New-BcContainer, and is a typical choice for BcContainerHelper tutorials, CI/CD examples, and any setup driven from a non-Windows host (where the alternative Windows mode is unusable).

The general capability already exists in my view: The AL VS Code extension publishes to NavUserPassword containers via LSP to Microsoft.Dynamics.Nav.EditorServices.Host, which prompts for credentials and forwards them to the same Microsoft.Dynamics.Nav.Deployment.* assemblies altool uses. So the fix is likely more around exposing the existing implementation through the CLI/MCP surface.

This affects macOS and Linux users in particular. Windows auth requires SSPI/Kerberos (Windows-host only), AAD requires a real Azure AD tenant, leaving UserPassword as the only practical option for local dev containers, and it's the one missing from the CLI/MCP surface.

Verified on macOS and Windows. CLI is a cross-platform .NET 8 tool so Linux likely exhibit the same gap, but I haven't reproduced there.

2. To Reproduce

1. Build a BC dev container with NavUserPassword auth (BcContainerHelper default):

   New-BcContainer -accept_eula -containerName my-bc -auth NavUserPassword `
       -Credential (New-Object PSCredential("admin", (ConvertTo-SecureString "P@ssw0rd1!" -AsPlainText -Force))) `
       -artifactUrl (Get-BCArtifactUrl -Type Sandbox -Country w1 -Select Latest) `
       -includeAL -multitenant:$false -isolation process `
       -additionalParameters @("--publish","7049:7049")

2. From a macOS or Linux machine that can reach the host on port 7049, install the AL CLI:

   dotnet tool install --global Microsoft.Dynamics.BusinessCentral.Development.Tools

3. Build any AL extension to produce a .app file.
4. Run:

   altool publishapp \
       --environmentType OnPrem \
       --server http://<container-host> \
       --serverInstance BC \
       --port 7049 \
       --authentication UserPassword \
       "/path/to/MyExtension_1.0.0.0.app"

// N/A: CLI/auth issue, no AL code involved. Any compiled .app reproduces it.

3. Expected behavior

Expose the language server's existing NavUserPassword code path through the standalone CLI / MCP surface. Any of the following would resolve it:

• --username / --password CLI flags (and equivalent userName / password MCP parameters)
• A --credentialFile flag pointing at a secure file
• Environment variables such as BC_USERNAME / BC_PASSWORD
• An interactive prompt analogous to PowerShell's Get-Credential
• An altool auth login --userPassword mode that caches credentials similarly to AAD tokens

4. Actual behavior

Publishing AL package...
Publishing /path/to/MyExtension_1.0.0.0.app (auth=UserPassword)
Targeting server 'http://<container-host>' and server instance 'BC'.
Exception of type 'Microsoft.Dynamics.Nav.Deployment.Authentication.UserNotAuthenticatedException' was thrown.
Publish failed: Authentication required for method 'UserPassword'. Run 'altool auth login' (interactive) and retry.

Following altool auth login opens a Microsoft Entra ID browser flow, the wrong scheme for NavUserPassword. No --help-discoverable command supplies NavUserPassword credentials.

5. Versions:

• AL Language: Microsoft.Dynamics.BusinessCentral.Development.Tools (standalone altool .NET 8 global tool) 17.0.34.45391+89ddc161d3e4421fa7ecef442abf29ca6e6ebfba. Same version is bundled inside the AL VS Code extension at ~/.vscode/extensions/ms-dynamics-smb.al-17.0.2273547/bin/{darwin,linux,win32}/altool.
• Visual Studio Code: N/A. Issue reproduces in the standalone altool CLI / al_publish MCP tool.
• Business Central: BC 28.x sandbox (Get-BCArtifactUrl -Type Sandbox -Country w1 -Select Latest), in a BcContainerHelper-built Windows container with -auth NavUserPassword.
• List of Visual Studio Code extensions: N/A. No VS Code involvement.
• Operating System (where bug was verified):
  • Windows (verified, Windows 11 ARM, AL ext 17.0.2273547)
  • Linux (likely affected, not verified)
  • MacOS (verified, macOS 26.x Tahoe, Apple Silicon)

Final Checklist

• Search the issue repository to ensure you are reporting a new issue
• Reproduce the issue after disabling all extensions except the AL Language extension (N/A: bug is in the standalone CLI/MCP, not the VS Code extension)
• Simplify your code around the issue to better isolate the problem (reproducer is the CLI invocation, no AL source involved)

Internal work item: AB#634874