Before configuring LDAP synchronization in MyQ X, determine which directory objects should be imported, which attributes and groups MyQ requires, and how the MyQ server will connect securely to the directory.
This preparation applies to:
-
Active Directory Domain Services
-
OpenLDAP
-
Google Workspace Secure LDAP
-
Novell
-
Lotus Domino
-
Microsoft Entra Domain Services using LDAPS
For help choosing between LDAP, Microsoft Graph, and other synchronization methods, see User Synchronization.
Before You Start
Identify who will complete each part of the deployment. In smaller environments, one administrator may perform all the work. In larger organizations, coordination may be required between:
-
The directory or identity administrator
-
The network or security administrator
-
The MyQ administrator
The directory administrator should provide the directory structure, required attributes, group information, and an account that MyQ can use to read them. The network or security administrator may need to configure firewall access and certificate trust. The MyQ administrator uses this information to configure the authentication server and synchronization source.
Plan the Synchronization Scope
Determine which directory users MyQ should import.
Identify:
-
The domains and organizational units containing the required users
-
The Base DN or Base DNs from which MyQ should search
-
Any users, contacts, service accounts, shared accounts, or disabled accounts that should be excluded
-
The LDAP filter required to select the intended population
-
Whether groups are stored within the same directory branch as users
A Base DN defines the starting point from which MyQ searches the directory. For example:
OU=Prague,DC=example,DC=com
This limits the search to the Prague organizational unit and its descendants.
An LDAP filter can restrict the results further. For example:
(&(objectCategory=person)(objectClass=user)(department=Sales))
The available attributes and correct filter syntax depend on the directory service. Test the intended Base DNs and filters against the directory before using them for production synchronization.
A user can appear to be missing when they are moved outside the selected Base DN or no longer match the filter. Consider this when planning user deactivation.
Plan Attribute Mapping
Identify which directory attributes will provide the MyQ user properties required by the deployment.
These can include:
|
MyQ property |
Planning consideration |
|---|---|
|
Username |
Must support the identity strategy described in Understanding Job Detection. |
|
Full name |
Select an attribute containing a suitable display name. |
|
|
Required for features that send email to users. |
|
Alias |
Can store additional identities detected in print jobs or used during login. |
|
Personal number |
Must be unique and persistent if it is used to pair users. |
|
Card |
Can import one or several card identifiers. |
|
PIN |
Can import one or several PIN values. |
|
Language |
The source values must correspond to language codes supported by MyQ. |
|
User storage |
Must contain a complete storage path usable by the required scan workflows. |
|
Notes |
Can store additional directory information where required. |
Confirm that the selected attributes:
-
Exist in the directory schema.
-
Are populated consistently for users in scope.
-
Contain values in the format expected by MyQ.
-
Are readable by the account used for synchronization.
-
Are unique where MyQ relies on them to identify or pair users.
If a source attribute contains several values that must be separated or reformatted, MyQ can apply a regular expression transformation during synchronization.
Sensitive Attributes
Take particular care when synchronizing card numbers, PINs, personal numbers, or other sensitive values. Review who can read the source attributes in the directory. If necessary, store sensitive values in protected attributes and grant access only to the account used by MyQ.
Decide whether the directory or MyQ will be authoritative for cards and PINs. This determines whether synchronization should replace existing MyQ values, update them only when the directory value is populated, or add new values without removing existing ones.
Plan Group Synchronization
Synchronized groups can be used in MyQ for:
-
Access control
-
User policies
-
Quotas and credit
-
Projects and cost centers
-
Reporting and accounting
Determine which directory groups MyQ requires and how they should be represented. MyQ can derive groups:
-
From an attribute stored on each user object
-
From one organizational unit in the user’s distinguished name
-
From an organizational-unit tree in the user’s distinguished name
-
From the user’s
memberOfattribute
Groups Derived from a Distinguished Name
Consider this user DN:
CN=Anna Novak,OU=Sales,OU=Prague,DC=example,DC=com
MyQ could derive only the Sales group or reproduce the hierarchy:
Prague > Sales
Before configuring this method, identify:
-
Which DN component represents the user
-
Which components represent organizational units
-
Which domain components must be excluded
-
Whether a single organizational unit or the complete hierarchy is required
-
Which imported group should become the user’s default accounting group
Groups Derived from memberOf
When importing groups from memberOf, identify a Groups Base DN that contains only the relevant groups. Without an appropriate scope, MyQ may import directory groups that have no purpose in the printing environment.
Determine whether MyQ should:
-
Import only groups referenced by synchronized users
-
Include empty groups
-
Preserve the directory group hierarchy
-
Import groups as a flat structure
Default Accounting Group
A user can belong to several groups, but only one group can be their default accounting group.
Decide:
-
How the default group will be selected
-
Whether synchronization may replace an existing default group
-
What should happen when the user loses membership in their current default group
For guidance on using synchronized groups, see Group-Based User Management.
Prepare a Directory Account
Create or select an account that MyQ can use to query the directory. A dedicated service account is recommended so that synchronization does not depend on an administrator’s personal account.
The account requires read access to:
-
Every directory branch included in the synchronization scope
-
Every user attribute mapped to a MyQ property
-
Group objects and membership attributes used for group synchronization
The account does not require permission to modify directory objects.
Apply the principle of least privilege and establish a process for managing the account throughout the deployment. Consider:
-
Password expiration and rotation
-
Account lockout
-
Monitoring failed login attempts
-
Ownership of the service account
-
Updating MyQ when its credentials change
Use a username format accepted by the directory server. If the account belongs to a subdomain, a domain-qualified username may be required. For example:
Administrator@cz.example.local
Prepare Network Connectivity
The MyQ server must be able to connect to every LDAP server required by the deployment.
Confirm:
-
DNS resolution from the MyQ server
-
Firewall access between the MyQ server and the LDAP servers
-
The hostname and port of each LDAP server
-
Connectivity to servers required for directory availability or failover
-
Any routing or firewall requirements between cloud-hosted MyQ servers and on-premises directories
LDAPS commonly uses TCP port 636. LDAP commonly uses TCP port 389, although a directory can use a different configured port.
LDAPS is recommended because it protects directory credentials and data in transit. Use unencrypted LDAP only when it is intentionally permitted by the organization’s security policy.
For broader firewall and network planning, see
Prepare Certificate Trust for LDAPS
For LDAPS, the certificate presented by the directory server must be trusted by the MyQ server.
Confirm that:
-
The certificate is valid and has not expired.
-
The certificate is suitable for server authentication.
-
Its subject or subject alternative name matches the DNS hostname used by MyQ.
-
The complete issuing CA chain is trusted by the MyQ server.
-
Required certificate revocation services are reachable.
-
The certificate-renewal process is understood.
Import the required root and intermediate CA certificates into the appropriate Windows certificate stores on the MyQ server.
Use the directory server’s DNS hostname rather than its IP address when the certificate identifies the server by name. A hostname mismatch can prevent a secure connection even when the issuing CA is trusted.
Test the LDAPS connection from the MyQ server before configuring user synchronization.
For general certificate guidance, see Security and Certificates.
Validate the Directory Preparation
Before continuing to MyQ configuration, confirm that:
-
The synchronization scope contains the intended users.
-
The Base DNs and LDAP filters return the expected results.
-
Required user attributes are populated.
-
Required attributes contain values in the expected format.
-
Personal numbers and other identifiers that must be unique do not contain duplicates.
-
Required groups and group relationships can be read.
-
The intended default accounting-group strategy is defined.
-
The directory account has the necessary read access.
-
DNS resolution and network connectivity work from the MyQ server.
-
The LDAP or LDAPS connection succeeds.
-
The complete certificate chain is trusted when using LDAPS.
-
Certificate and service-account renewal responsibilities are documented.
Continue in MyQ X Server
After preparing the directory, service account, network connection, and certificate trust:
-
Add the LDAP server under MyQ > Settings > Authentication Servers.
-
Create an LDAP synchronization source under MyQ > Settings > User Synchronization.
-
Configure the Base DNs, attribute mappings, options, filters, transformations, and group import.
-
Run the synchronization with a limited test population.
-
Review the results before expanding the synchronization scope.
For detailed configuration, see also: