Importing users from multiple domains

Multiple network domains are common on larger networks, or special environments such as schools where there is a need to partition the network for security reasons. A common example is:

A secure domain for staff users.

A domain for student accounts.

The student domain trusts the staff domain. (The staff domain doesn’t trust the student domain. i.e. it is a one way trust).

PaperCut can track printing from multiple domains, however the initial import of users needs to come from a single source. There are three common methods to ensure all users from both domains are listed in PaperCut.

Important:PaperCut and Windows printer software assumes that usernames are unique and will normalize the domain by ignoring the originating domain. For example, mary.jane from domain A is assumed to be the same person as mary.jane from domain B. Even if PaperCut recorded the domain of users it would not be able to use it to identify printer jobs as only the SAMAccountName information in included in job metadata.

Method 1 - Built-in multi-domain support

Note: Depending on the default trust relationship between domains, it may be necessary to ensure that PaperCut has permission to query all the domains. For more information and instruction see the multiple domain security configuration article.

Method 2 – Taking advantage of Active Directory’s nested groups

Active Directory includes a powerful notion called Nested Groups. This allows a new group to be formed by two child groups. Depending on the trust relationship between the domain and the rights granted to administrator and the System accounts, it is possible to create a new group composed of sub-groups from each domain. For example, if we take the school example,

Create a group called All Users in the student domain.

Add the Student group as a member of this group.

Add the Staff group from the other trusted domain.

PaperCut has native Active Directory integration and can leverage nested groups. The nested group composed of users from both domains can be selected as the user source via the option to “import users from group” is selected either in the setup wizard, or after via Options→User/Group Sync.

Note: Depending on the default trust relationship between domains, it may be necessary to ensure that PaperCut has permission to query all the domains. For more information and instruction see the multiple domain security configuration article.

Method 3 – Adding users on first print

If trust relationships, or other technical issues prevent Method 1. An alternate approach is to import users from the main domain - for example, in our school example, we’d import all the students – and the users from the other domain (staff/teachers) will be added to PaperCut on first-print. That is, when an “unknown” user prints for the first time, they will be automatically added to the PaperCut system.

Typically PaperCut would be first installed on a server in the student domain. This is also consider best practice from a security standpoint.

Method 4 – Adding users via text file import

A variation on Method 3 above is rather than waiting for the users from the secondary domain to be added via first-print, an alternative is to import via a text file. PaperCut NG includes a batch import option that accepts the list of users via tab-delimited text file. Most large organizations should have such file contain a list of users on hand. In PaperCut NG, the import of users is covered under the chapter section title, Batch User Import and Update.

Method 5 - Custom User Directory Plug-ins

PaperCut is a modern application designed with a modern architecture. It supports plug-ins and extensions at a number of different levels. One such layer is the User Directory source. Organizations with very complex domains, such as those seen in large universities, can be accommodated either with the standard options, or if the standard options are not sufficient, via a custom plug-in. For example, a University may have multiple domains, one running Active Directory and the other LDAP/NIS. A custom plug-in could support this by first querying Domain A, and if the user is not found, the query Domain B via LDAP. Further information and links to sample code can be found here

Hey there! We use cookies. Why? They let us personalize content, track usage, and analyze data on our end to improve your experience. By continuing to browse our site, you accept our use of cookies per our privacy policy.