MyQ X Desktop Client

The MyQ Desktop Client employs robust security mechanisms to ensure secure communication, authentication, and data integrity across enterprise printing environments. This document details the protocols, authentication methods, and configuration best practices that underpin the Desktop Client’s security architecture, with a focus on TLS encryption, Integrated Windows Authentication (IWA), Kerberos, NTLM, and Entra ID integration. Technical implementations such as Service Principal Name (SPN) registration, certificate management, and silent login flows are analyzed to demonstrate compliance with modern security standards.

Secure Communication Architecture

TLS Encryption by Default

Print and Central Servers enforce TLS 1.2+ encryption for all communication channels, including interactions with the Desktop Client. This ensures data confidentiality and integrity during job spooling, authentication, and reporting. Administrators must configure HTTPS endpoints using Fully Qualified Domain Names (FQDNs) to prevent man-in-the-middle (MITM) attacks.

Certificate Validation Modes

• Strict Mode: Requires server certificates to be issued by a trusted Certificate Authority (CA) or manually added to the system’s trust store. Connection attempts fail if validation fails. We recommend using Strict Mode whenever possible.

• Normal Mode: Allows users to bypass untrusted certificate warnings, with accepted certificates stored in %ProgramData%\MyQ\Desktop Client\cert.store for future sessions.

Authentication Mechanisms

Integrated Windows Authentication (IWA)

IWA enables seamless authentication in domain-joined environments using Kerberos or NTLM. The server leverages the Windows HTTP Server API (http.sys) to handle incoming HTTP requests and validate Service Principal Names (SPNs), ensuring protocol integrity.

Kerberos Workflow

1. Ticket Granting Ticket (TGT) Acquisition: Domain-joined clients obtain a TGT from the Key Distribution Center (KDC).

2. Service Ticket Request: The client requests a service ticket for HTTP/<FQDN> from the KDC.

3. Token Validation: MyQ Server validates the service ticket against the registered SPN.

Critical Configuration:

• The server must have a properly configured SPN for Kerberos authentication to function correctly.

• Access via IP addresses bypasses Kerberos, forcing fallback to NTLM.

Kerberos Enforcement

For environments requiring stricter security, it's possible to configure the application to exclusively use Kerberos and disallow NTLM fallback. This is done on a Server level basis, not exclusively for the Desktop Client.

1. Disable NTLM via KerberosOnly=True in config.ini.

2. Register SPNs for all MyQ servers using setspn.

3. Use FQDNs instead of IP addresses for server endpoints.

NTLM Fallback

NTLM serves as a fallback in non-domain or IP-based scenarios. While less secure, it uses a challenge-response mechanism hashed with the user’s password. To enforce Kerberos exclusively, follow the suggestion above.

Entra ID Silent Login

For Entra ID-joined or hybrid devices, Desktop Client uses the Microsoft Authentication Library (MSAL) and Windows Authentication Manager (WAM) to acquire tokens silently via the OS account. The flow involves:

1. Token Acquisition: MSAL retrieves an ID token using WAM.

2. Token Exchange: The ID token is exchanged for a MyQ access token to authenticate REST API calls.

OAuth 2.0 Authorization Code Flow

For non-Windows environments, Desktop Client supports OAuth 2.0 via the authorization_code grant:

1. User Redirection: The client redirects users to the MyQ login page.

2. Code Exchange: After authentication, the authorization code is exchanged for an access token.

Entra ID Configuration

• Enable Sign in with Microsoft in the MyQ Server settings for hybrid-joined devices.

• Ensure devices are Entra ID-registered to leverage silent authentication.

Certificate Management

Trusted Root Certificates

• Strict Mode: Certificates must be preinstalled in the OS trust store (e.g., via Group Policy).

• Normal Mode: User-approved certificates are stored in cert.store and reused for subsequent sessions.

Validation Workflow

1. Server certificate validation checks the trust chain.

2. If validation fails, users receive a prompt to accept or reject the certificate (this is only the case if Normal rather than Strict Validation mode is in use).

3. Accepted certificates are cached to prevent repeated prompts (this is only the case if Normal rather than Strict Validation mode is in use).

Certificate Best Practices

We recommend always deploying enterprise CA-signed certificates for MyQ servers.

Conclusion

MyQ Desktop Client integrates enterprise-grade authentication and encryption to mitigate risks such as credential theft and eavesdropping. By enforcing Kerberos, TLS, and certificate validation, organizations can align with Zero Trust principles while maintaining usability through silent authentication flows.