As of PaperCut NG/MF versions 24.1.3 and later, Kerberos is used to authenticate users in Windows environments before falling back to legacy NTLM.
Organizations may want to manage this setting to completely disable NTLM which has been
deprecated by Microsoft
.
The authentication mode (NTLM or Kerberos) can be forced in PaperCut MF or NG by editing the
Advanced Config Editor
to manage the config key auth.source.config-arg.
These are the valid values:
-f Force modern authentication using Kerberos-l uses Legacy authentication using NTLM
Log in to the PaperCut admin web interface.
Navigate to Options > Actions > Config editor (advanced).
Use Quick find to search for the auth.source.config-arg config key.
In the blank field in the Value column enter -f for Kerberos or -l for NTLM.
Click Update next to the Value field to apply the change.
Comparing Kerberos and NTLM
This table explains some of the technical differences to help you decide which authentication protocol best suits your environment.
Modern authentication (Kerberos) | Legacy authentication (NTLM) |
|---|
| |
Kerberos overview
Kerberos uses a ticket-based system to authenticate a user without sending the user’s password over the network. Instead, the App Server requesting authentication verifies a ticket presented by the user, proving the user has been authenticated by a trusted Key Distribution Center (KDC). Interactive Kerberos authentication with PaperCut involves three systems: User client system - embedded device, Mobility client, PaperCut software client, user web pages. App Server - to which the user is requesting authentication. Key Distribution Center (KDC) - where information related to the user’s password (used to issue tickets) is kept.
The user client system obtains a ticket granting ticket (TGT) from the KDC. When the user attempts to access the App Server, the client requests a service ticket for the App Server from the KDC using the TGT. The KDC issues this service ticket, which the client then presents to the App Server. The App Server verifies this ticket. The PaperCut authentication workflow using Kerberos, like NTLM in PaperCut, is also considered a form of non-interactive authentication as the user does not need to repeatedly enter their credentials for each service request after initially obtaining their TGT. | NTLM overview
NTLM uses an encrypted challenge/response protocol to authenticate a user without sending the user’s password over the network. Instead, the App Server requesting authentication performs a calculation that proves it has access to the secured NTLM credentials. Interactive NTLM authentication with PaperCut involves three systems: User client system - embedded device, Mobility client, PaperCut software client, user web pages App Server - to which the user is requesting authentication Domain Controller - where information related to the user’s password is kept.
|
Kerberos authentication workflow The authentication workflow below is adapted from the article Microsoft Kerberos. User requests a TGT.
A user accesses a client system and provides their username and password. The client system sends this information to the KDC. The KDC is a trusted server that manages Kerberos authentication. The KDC authenticates the user.
The KDC verifies the user's credentials (typically by checking against a database like Active Directory). If the credentials are valid, the KDC issues a TGT to the client. This TGT acts as a temporary credential for the user. The client requests a service ticket.
When the user attempts to access the App Server, the client uses the TGT to request a service ticket from the KDC. This ticket is specific to the App Server. The KDC issues a service ticket.
The KDC verifies the TGT and issues a service ticket for the App Server. This ticket is encrypted and can only be used by the App Server. The client presents the service ticket to App Server.
The client presents the service ticket to the App Server. The App Server authenticates the user.
The App Server decrypts the service ticket using its own secret key. If the ticket is valid, the App Server authenticates the user and grants access.
| NTLM authentication workflow The PaperCut authentication workflow is otherwise known as non-interactive authentication. The following authentication workflow is adapted from the article Microsoft NTLM. The first step provides the user’s NTLM credentials A user accesses a client system (as described above) and provides a user name and password. The client system sends the user name to the App Server in plaintext. However, keep in mind that PaperCut client systems automagically upgrade their authentication connections to the App Server from HTTP to HTTPS, so passwords will not traverse the network un-encrypted with one exception: authentication attempts through user or admin webpages using the HTTP:// URL instead of HTTPS://. In any case, the App Server computes a cryptographic hash of the password and discards the actual password. The domain controller generates a 16-byte random number, called a challenge or nonce, and sends it to the App Server. The App Server encrypts this challenge with the hash of the user’s password and returns the result to the Domain Controller. This is called the response. The App Server sends the following three items to the domain controller: User name, Challenge and Response The domain controller uses the user name to retrieve the hash of the user’s password from the Security Account Manager database. It uses this password hash to encrypt the challenge. The domain controller compares the encrypted challenge it computed (in step 5) to the response computed by the App Server (in step 3). If they are identical, authentication is successful.
|
Comments