Office Technology · Guide · 9-minute read
On most networks the copier is the one device nobody trusts. It sits outside the domain, it holds its own separate list of users, and it reaches network folders using a service account somebody set up years ago and wrote on a sticky note.
Active Directory integration fixes that by making the MFP an actual domain member. Current Sharp devices can join the domain as a computer rather than as a printer, which is the distinction that makes everything else possible: Kerberos token authentication, true single sign-on from the print driver, and scan destinations that resolve against the person standing at the panel instead of a shared credential.
This is what it does, what your environment needs before it will work, and the handful of things that cause nearly every failed registration.
The short version
- Joining as a computer is what unlocks Kerberos SSO. Joining as a printer doesn’t.
- Three things cause most failures: DNS, the device registration account, and the clock.
- Users stop typing credentials at the panel. That’s the part they’ll notice.
In this guide
What actually changes
Five capabilities come with registration, and they build on each other.
Trusted device, trusted traffic
The MFP appears in the Computers container in Active Directory Users and Computers, like any workstation. Communication with the domain becomes authenticated rather than anonymous.
Authentication against the domain
People sign in with the credentials they already have, validated by Kerberos. No second user list on the copier to maintain, and offboarding happens in one place.
Single sign-on to resources
Once signed in, the user reaches network folders, their home directory and their own mailbox without entering anything again. The token does the work.
Authenticated printing
The device accepts jobs only from valid domain users, and the print driver can pass the Kerberos token from the user’s Windows session rather than storing a username and password.
The fifth is administrative: once the device is in the domain you can map Active Directory groups to the MFP’s own authority group, page limit group and favorite operation group. That means color permissions, page quotas and panel defaults follow the user’s existing group membership instead of being maintained separately on each machine.
Computer or printer?
Not every device joins the same way. Current Sharp models register as a computer, which is what enables Kerberos token single sign-on from the print driver. Some older models join as a printer instead — useful, but without driver-level SSO. Worth confirming which applies to the machines you actually have before promising your users a seamless experience.
Prerequisites, in the order they matter
Get these right before touching the Active Directory settings page and registration usually works first time. Skip one and you’ll be looking at an authentication failure with no obvious cause.
- DNS, both directions. The MFP must resolve in the domain’s forward and reverse lookup zones. Reverse is the one that’s usually missing — you may need to create a pointer record manually. Test it from any domain-joined PC with
nslookupagainst both the name and the IP address. - The clock. Kerberos will not tolerate a device whose time is more than five minutes from the authentication server. Set date, time and time zone on the MFP, and check daylight saving handling while you’re there. A surprising number of “it just stopped working” calls trace back to this.
- The realm, in capital letters. Kerberos realms are case-sensitive here. Lowercase fails silently in a way that looks like a credential problem.
- A registration account with the right permission. The account used to enroll the device needs write access to the Computers container. Without it the device cannot create its own object, whatever else is correct.
- The search attribute pointing at Computers. This is where the AD settings differ from a standard LDAP configuration, and it’s the step most often copied incorrectly from an existing LDAP setup.
One formatting detail worth knowing in advance: enter the registration account as a plain username. Adding a domain prefix or an email-style suffix will fail, because the device supplies the domain itself.
ID card login, and the choice nobody explains
Typing a network password on a touch panel is the fastest way to make people resent authentication. Card login solves it, and a device supports up to 1,000 registered cards. Users enroll their own: swipe once, enter credentials that one time, and the card is bound to the account from then on.
What rarely gets explained is that there are two modes, and the difference is a security decision rather than a technical one.
Convenience mode
The device caches the user’s credentials after first login. From then on a card swipe is the entire interaction — no typing at all. Fastest for busy shared floors. The trade is that credentials are stored on the machine.
Secure mode
Only the username and card identifier are stored — never the password. The card identifies you, then you type your password. Slower by a few seconds, and the right default for regulated environments or anywhere a lost card shouldn’t equal access.
This is worth deciding with whoever owns your security policy rather than defaulting to whichever is quicker to configure. One behaviour to expect either way: when a user changes their network password, the next login at the panel will prompt for the new one.
If you’re weighing card login against PIN entry or a central pull-print queue, our guide to secure print release methods compares all four and covers the card readers involved.
What scanning and printing look like afterward
Scan to folder stops requiring a credential prompt. The signed-in user can browse network folders and subfolders directly from the panel, reaching exactly what their account is permitted to reach — no more, no less. Where an address book entry has its own stored credentials those are used; where it doesn’t, the logged-in user’s are.
Scan to home directory and scan to self become one-touch. The device pulls the user’s home directory path and email address from Active Directory and can pre-populate either as the default destination, so the common case — scan this and send it to me — needs no address entry at all.
Scan restrictions become enforceable. You can limit destinations to the user’s own home directory or their own email address, and restrict domains and manual address entry — which is a practical control against documents leaving by accident. Single sign-on also extends to Exchange and to cloud destinations including OneDrive, SharePoint Online, Google Drive and Box, with the option to store only a user ID and prompt for the password, or disable cloud SSO entirely if storing anything on the device is unacceptable.
On the printing side, selecting single sign-on in the driver’s job handling tab means the user’s existing Kerberos token authenticates the job — no stored username or password in the driver. It requires a current print driver and it’s only available once the device has actually joined the domain, which is why driver SSO and registration need to be planned together. The same authentication also enables serverless print release, so held jobs can be released by card at the device without a print server.
When registration fails, check these six
In roughly this order, because the cheap checks are also the most common causes.
- Reboot the device. It re-attempts registration on startup, and this genuinely resolves a share of cases.
- DNS. Confirm the server address is right and that the device resolves in both lookup zones.
- The registration account format. Plain username, no domain prefix, no email suffix.
- That account’s permissions. It must be able to write to the Computers container.
- The attribute settings. These differ from a plain LDAP configuration — the Computers container has to be specified.
- The clock, again. Five minutes of drift is enough to fail Kerberos, and drift accumulates quietly.
One behaviour that looks like a fault and isn’t: if the Active Directory server becomes unreachable, the path field for scan to home directory will simply be blank. Browse still works. Domain and local authentication can also run side by side, with the method chosen at login — useful during a migration or for a shared device that visitors use.
Free Download
Get the full implementation guide
The step-by-step version with the exact menu paths, settings screens and configuration diagrams your IT team will want. Tell us where to send it — no cost, no spam.
Or let us set it up
None of this is difficult, but it spans DNS, the directory, the device and the print driver — four places that usually belong to different people. RDI configures Active Directory integration as part of every Sharp MFP installation, and our managed IT team owns the network side too, so there’s nobody to hand off to halfway through. Our help desk answers in about 90 seconds and our on-site average across NYC and Long Island is four hours.
If you already have an IT team and want help only with the device side, co-managed IT covers that. And if you’re tightening Microsoft 365 security, note that scan-to-email configured years ago is the most common reason businesses can’t disable legacy authentication — our guide to Microsoft 365 security defaults explains why.
Frequently asked questions
What do I need before integrating a Sharp MFP with Active Directory?
Correct date, time and time zone on the device — within five minutes of the authentication server, because Kerberos requires it. DNS entries in both the forward and reverse lookup zones. The Kerberos realm entered in capital letters. And a registration account that can write to the Computers container in Active Directory.
Why won’t my MFP register with Active Directory?
Work through six checks in order: reboot the device, verify DNS including the reverse lookup zone, confirm the registration account is entered as a plain username with no domain prefix or email suffix, confirm that account can write to the Computers container, check the attribute settings specify Computers, and verify the clock is within five minutes of the authentication server.
What’s the difference between joining as a computer and joining as a printer?
Joining as a computer makes the MFP a trusted domain member and is what enables Kerberos token single sign-on from the print driver. Devices that join as a printer still get Active Directory authentication and single sign-on to scan destinations, but not driver-level SSO. Confirm which applies to your specific models before planning the rollout.
Should we use convenience mode or secure mode for ID card login?
Convenience mode caches credentials on the device so a card swipe is the whole login — fastest for busy shared floors. Secure mode stores only the username and card identifier, so the user still types a password. Choose secure mode where a lost card shouldn’t equal access, or where a policy prohibits credentials being stored on devices. It’s a security decision, not a technical one.
Can local and Active Directory authentication run at the same time?
Yes. Domain authentication and local authentication can both be enabled, with the method selected at login. That’s useful during a migration, or on a device that occasional visitors need to use without a domain account.
Can we control color printing and page limits through Active Directory groups?
Yes. Once the device is registered, directory attributes can map users to the MFP’s authority group, page limit group and favorite operation group — so permissions, quotas and panel defaults follow existing group membership instead of being maintained device by device.
Want Us to Handle the Integration?
We’ll check your prerequisites, register the devices, configure scan destinations and set up driver single sign-on — and tell you first if anything in the environment needs fixing before it will work.