Error: "HTTP 401 - Unauthorized." when uploading drivers to the Broker

  • 3696528
  • 11-Mar-2008
  • 27-Apr-2012

Environment

Novell iPrint
Novell iPrint Client 4.05
Novell NetWare 6.5 SP3

Situation

Error: "HTTP 401 - Unauthorized." when uploading drivers to the Broker.
Error: "iPrint Client- You do not have sufficient privileges to fulfill the request."
Unable to access secure page https://ipaddress/ipps
Unable to install secure printer.
Error: "Winsock 10061." when uploading drivers to the broker.
Error: "Printer Authentication Failed. Do you want to try again?" after attempting to authenticate to create a Printer Driver Profile.

Resolution

The architecture of the driver upload process and creation of printer driver profiles has changed in the latest iPrint plugin and iPrint client. This change eliminates the need for the workstation to attempt a second authentication to perform these operations. Follow the steps below:

1. Download and install the latest iPrint Plugin for NetWare.
- Go to download.novell.com.
- Choose "iPrint" from the drop down list under "Product or Technology"
- Important: Click the "View" button for Install Instructions.
- Complete the installation of the new iPrint Plugin.
2. Install the latest iPrint client.
- Search Novell's File Finder for nipp.exe.
- Install this version of the iPrint client to the workstation performing this iPrint/iManager operation.

Additional Information

Support Pack 3 makes use of LDAP Authentication for iPrint functionality such as the uploading of printer drivers to the Broker. This authentication is handled in the background by Apache and Mod_AuthLDAP. If your network is not properly setup for LDAP, the authentication may fail, returning a 401 error. For the sake of simplifying this TID, these causes and their associated resolutions are listed in the Notes sections below.
For those receiving the 401 error when doing secure printing, the above fix (updating iprint plugin and client) will not help. The rest of this TID must be read and followed to resolve the problem. There are several reasons the LDAP authentication can fail:

1. Duplicate CN's
As far as NDS is concerned, admin.acct and admin.marketing are two different users. However, LDAP sees both of these users as admin. A 401 error is returned when the iPrint client queries LDAP for admin and receives multiple responses.

2. The uniqueID attribute is not set on the user.
Users created by iManager or ConsoleOne will have a uniqueID attribute set for each account. The uniqueID string will match the CN. For example, the uniqueID for admin.acct is admin. The LDAP authentication performed by the iPrint client relies on this uniqueID attribute. If the attribute is not present, then the authentication will fail. Users created with NWAdmin will not have a uniqueID.

3. The uniqueID attribute cannot be found during the LDAP query.
When uploading drivers through iManager to the broker when Support Pack 3 is installed, the user that logged into iManager will be sent to Apache for authentication. Before the authentication can occur, the user's uniqueID attribute must be found by an LDAP query. Below lists 3 reasons the uniqueID (UID) may not be found:

a. Rights to find the uniqueID
If [PUBLIC] does not have rights to the uniqueID attribute, or if those rights are not inherited by a proxy user, then the lookup for the UID will fail.

b. CN doesn't equal the UID
If the value for the CN does not match the value of the uniqueID, then the UID will not be found during the LDAP lookup. Unmatching CN's and UID's will occur only if the CN or UID was manually changed.

c. Multiple Organization objects
By default, the sys:\Apache2\iprint\ipp.conf specifies the Organization object that will be searched to find the user that logged into iManager. If the tree has multiple O's (Organization objects), then users only in the O listed in the ipp.conf will be searched. Users outside of that O will see the 401 error.

4. Certificate Timeout
SYS:\Apache2\iprint\ipp.conf references the authenticating server by DNS name. If the DNS lookup takes longer than expected, a 401 error will be returned.

5. Rootcert.der is corrupt
The authentication goes through a certificate. By default, iPrint's implementation of LDAP uses SYS:\public\ROOTCERT.DER. The two following messages can be found in an LDAP trace when the server returns a 401 error due to a certificate problem:
setting err = -5875. Error stack:
sslv3 alert bad certificate - SSL alert number 42

6. PHP is installed on the server.
PHP has a conf file that is loaded through the httpd.conf file using an include statement. (include sys:\Apache2\conf\mod_php.conf). The PHP apache configuration file loads other NLMS, one of which is PHP_LDAP.NLM. PHP_LDAP and AuthLDAP (AuthLDAP is used by iPrint) conflicts with each other.

No code changes are planned to be made to address this error. Determine which condition is causing the 401 error in your environment and make the change suggested below to resolve the problem. The below suggestion numbers correlate to the above cause numbers:

1. Duplicate CN's
Create a unique user in the tree that is not found in any other context. Give that user rights to manage the Broker and Manager. Log into iManager with that user to upload drivers or create Printer Driver Profiles.

2. The uniqueID attribute is not set on the user.
For more information to see if the that attribute is set for the user and how to populate the uniqueID, see TID 3110036.

3. The uniqueID attribute cannot be found during the LDAP query.
Reason 1: Rights to find the uniqueID - Verify that [PUBLIC] has READ and COMPARE rights for the uniqueID:
a. Launch ConsoleOne
b. Right click on the Organization select Trustees of this Object.
c. Highlight [PUBLIC] in the trustee list, select Assigned Rights.
d. Click on Add Property, check the box next to Show all properties, then scroll down the list until you find uniqueID.
e. Highlight uniqueID and click OK.
f. Check COMPARE and READ and Inheritable under Rights, then click OK

These rights can also be obtained by creating a proxy user for the LDAP Group Object:
a. Go to iManager: https://ipaddress/nps/iManager.html
b. Choose "eDirectory Administration"
c. Choose "Create Object" - create a user that has no rights and no password
d. Choose "Modify Object" - browse to the LDAP Group object (resides in the
same container as the server object) for the server that is hosting iPrint.
Note: Each server has an LDAP Group object named "LDAP Group - [ServerName]".
e. Under the "Authentication Options", browse to the user created in Step c. Click Apply.

Reason 2: CN doesn't equal the UID - Compare the CN value to the uniqueID attribute by going to the properties of the user and choosing the "Other" tab. If there is a difference, then change the uniqueID value to match the CN.

Reason 3: Multiple Organization objects - Modify the sys:\Apache2\conf\ipp.conf file from:
AuthLDAPURL "ldaps://[IPorDNSofPrintServer]/O=[OrganizationName]???(objectClass=user)"

to

AuthLDAPURL "ldaps://[IPorDNSofPrintServer]/???(objectClass=user)"
Restart Apache to make that take affect. (ap2webdn.ncf and ap2webup.ncf)

4. Certificate Timeout.
In the SYS:\Apache2\iprint\ipp.conf, change:
AuthLDAPURL ldaps://[DNS]/O=[OrganizationName]???(objectClass=user)
to
AuthLDAPURL ldaps://localhost/O=[OrganizationName]???(objectClass=user)

Use the word localhost. Restart Apache to make that take affect. (ap2webdn.ncf and ap2webup.ncf)

5. Resolve the certificate problem.
There are two types of certificate problems.
a. Rootcert.der certificate problem. Export the Self Signed Certificate from ConsoleOne. See the NOTE section below titled: "How to export the Self Signed Certificate using ConsoleOne".
b. SSL Certficate problem. See the NOTE section below title: "How to export the SSL Certificate using ConsoleOne."

6. PHP is installed on the server.
Any one of the following three changes will resolve this problem.

a. If PHP is not needed on the server, simply comment out
the "include sys:\Apache2\conf\mod_php.conf" statement
from sys:\Apache2\conf\httpd.conf. Restart Apache.
b. Copy (not move) SYS:/PUBLIC/rootcert.der to SYS:\PHP5\Certs\.
c. Change the value of the ldap.ssl_cert_dir variable in the PHP.INI file
to point to SYS:\PUBLIC. Restart Apache.

7. Use NWAdmin to upload drivers.
NWAdmin does not use the iPrint client to upload drivers and therefore the above problems will not be encountered. Novell does not recommend this as a solution, but as a temporary workaround until the real cause and resolution is determined. To upload drivers using NWAdmin, you must have the Novell Client installed with the NDPS component. You must also launch the executable with a /disableTLSMgr switch. For example: SYS\PUBLIC\WIN32\nwadmn32.exe /disableTLSMgr.

8. Install iPrint client version 3.x on administrator workstations.
The iPrint client prior to version 4.x does not perform the additional authentication to upload drivers to the Broker using iManager. Novell does not recommend this as a solution, but as a temporary workaround until the real cause and resolution is determined. When using the 3.x iPrint client, the rights are obtained through the Public trustee assignment to the XFER directory.

.
How to export the Self Signed Certificate from ConsoleOne
a. Run PKIDIAG
- type PKIDIAG at the server console
- enter administrator username and password
- option 4
- option 6
- option 0
b. Open CA object in O=Security
c. Select Certificates -> Self Signed Certificate
d. Do not export the private key.
e. Make a back up of SYS:\PUBLIC\RootCert.der
f. Export the file in DER format; name it c:\RootCert.der
g. Copy new Self-signed certificate from c:\RootCert.der to SYS:\PUBLIC\RootCert.der
h. Restart apache and tomcat
- Stop Tomcat: tc4stop
- Stop Apache: ap2webdn
- Start Tomcat: tomcat4
- Start Apache: ap2webup

How to export the SSL Certificate from ConsoleOne
a. To find out which certificate the LDAP server is using:
- properties of the LDAP server object
- Select the SSL/TLS configuration tab
- Server Certificate will show which certificate is being used.

b. To resolve the certificate problem:
- Delete the SSL Certificate that LDAP is using in ConsoleOne.
- Manually recreate the Certificate.
- Right-click the container object
- Select New, Object, NDSPKI:Key Material
- Give the Certificate a name. This can be the same name as the previous certificate or a different name.
- Creation Method should be standard
- Click Next, click Finish
- Go into the LDAP server object
- Select the SSL/TLS configuration tab
- Enter in the new certificate in the Server Certificate field
- Go back to the General tab and click Refresh NLDAP Server Now
- Click OK

How to capture an LDAP trace using DSTrace:
DSTrace configured to capture LDAP information and debug apache logs are ways to determine which problem you are encountering.

1. Configure the LDAP Server Object

Using iManager:
a) Launch iManager (https://IPaddressOrDNS/nps/iManager.html)
b.) eDirectory Administration
c.) Modify Object
d.) Browse to container where the iPrint server resides, choose the"LDAP Server - [ServerName]" object.
e.) Go to the "Tracing" properties on this object.

Using ConsoleOne:
a.) Launch ConsoleOne
b.) Highlight the container that contains the iPrint Server object.
c.) Right click the "LDAP Server - [ServerName]" object and choose Properties.
d.) Click the "Screen Options" tab

Continued steps using Either ConsoleOne or iManager:
f.) Make sure all of the following options have check marks in their boxes:

- Critical Error Messages
- Non-critical Error Messages
- Configuration Processing
- Informational Error Messages
- Search Response Summary
- Messages from LDAP Extended Operations
- Connection Information
- Server Console Messages for LDAP

g.) Click Apply

2. Configure DSTrace (Server Console):

a.) DSTRACE (this will load the NLM, and of note, none of the + or - flags are case sensitive)
b.) DSTRACE -ALL (clears all trace options, which you should verify by seeing all trace options greyed out)
c.) DSTRACE ON (turns on tracing to file and screen)
d.) DSTRACE +TIME +TAGS +LDAP (turns on what we want to look at in the trace)
e.) Unload NLDAP (you will most likely see a -5975 error in dstrace when doing this, it is not a problem)
f.) Load NLDAP (doing this when the trace is on will help verify LDAP is listening on it's ports)
g.) Duplicate the problem.
h.) DSTRACE OFF (turns off tracing to file and screen)
j.) Read the log file at SYS:\SYSTEM\DSTRACE.LOG file

How to capture debug Apache logs

1. Modify the following line in sys:\Apache2\conf\httpd.conf

LogLevel warn
to
LogLevel debug

2. Restart Apache:
ap2webdn
ap2webup

3. Duplicate the problem

4. Read the log files contained in sys:/apache2/logs/

.

Formerly known as TID# 10097177

Change Log

2008-11-09 - Ray Dassen - Updated TID link: 10088627 -> 3110036; added product tags.