Novell Home

Authenticating to iPrint Without Another Login

Novell Cool Solutions: Tip

Digg This - Slashdot This

Posted: 2 Mar 2004
 

Question: I have set up the trial version of Pcounter on my NetWare 6.0 sp3 server. It works, but as the iPrint printer must be secure, it requires the user to login a second time with iPrint authentication requiring the user to enter their Fully Qualified Name (FQN) and password. This is not practical in a school environment. Do you know any way to authenticate people to the secure iPrint printer from their initial client32 login? (no second login)

Answer: OPEN CALL: Anyone got some suggestions for this? Let us know.
Also, take a look at the follow-up question to see if you can lend a hand for a NW 5.1 user with the same problem.

Suggestions

Ian B.

This won't help you on NW 6.0, but NetWare 6.5 ships with the NetIdentity Agent which captures details at logon and uses them for subsequent authentication.

[Editor's Note: The NetIdentity agent works with eDirectory authentication to provide background authentication to Windows Web-based applications that require eDirectory authentication. iPrint supports the NetIdentity agent included with NetWare 6.5 running on Windows NT/2000/XP only. If the NetIdentity agent is installed on the workstation, iPrint will use NetIdentity when authenticating.]

Mike Mason

This might not directly relate to the open call but it is close and might be useful knowledge for someone.

We wrestled with this issue many moons ago and we solved it quite simply by giving [public] read and filescan rights to the IPPDOCS directory. However, in Novell's great quest to tighten security, in NW6SP3 they introduced what I consider to be a bug that screwed it all up. Even though public had read & filescan rights users still had to log in. It was easily fixed though with a different build of PORTAL.NLM. Engineering claimed that it would appear in the next support pack.

Note: I did not want the IPPDOCS directory on the SYS: volume because we have clustered iPrint.

Here is a quote from my incident explaining the problem I had:

It appears that NW6P3 has changed the behavior of HTTPSTK.NLM quite significantly. I have completed some testing and I am able to easily replicate this problem Before applying SP3 my users had straight http access to a directory (IPPDocs) on a server here (NDPS1). This directory had/has R and FS rights for the [Public] object. As soon as I applied NW6SP3 users had to start logging in when going to any file in that directory. Of course my users don't know what their context is and Lord knows they won't be able to cope with another login prompt.

How to recreate the problem:

On a NW6SP3 server called NDPS1

  1. Created a directory called pub on volumes TestSP3: and on Sys: and gave the public object Read and Filescan rights to them both.
  2. Put a file called hello.gif in both of the pub directories.
  3. Opened a browser and went to http://ndps1.company.com/sys/pub/hello.gif and it displayed the graphic without any problem.
  4. I then went to http://ndps1.company.com/testsp3/pub/hello.gif. I was presented with a security alert/certificate.
  5. Clicked yes to accept/proceed.
  6. Got a Enter Network Password dialog box asking for uid and password.
  7. Entered my full NDS name and context and password.
  8. Displayed the gif and the address in my browser was https://ndps1.company .com:8009/testsp3/pub/hello.gif.

On a NW6SP2 Server

I followed exactly the same procedure.

The graphic was displayed without any problem from either volume.

Daron Sperry

System: NW6 SP3 current patch for NDPS applied and Pcounter for Netware (NDPS configured).

Since my installation is on a private company WAN this workaround would not be acceptable in many other installations. The only way I was able to work around this issue was to add all users to the manager role. This does create security issues. For me it became more important to still provide print logging functionality and most users are unaware of the additional capabilities that the manager role allows.

Unfortunately, because the user does not authenticate to the printer queue the username in the Pcounter log is not as easy to read.

Additionally, the name is not always logged the same each time a user prints. Again, this was not of much concern for my installation and I do not use account balances in Pcounter.

(Of course, I would prefer that these issues were fixed rather than work around them.)

Follow-Up Question

Joyce Murray

So how do you get around this on 5.1 if 6.5 is NOT in your near future?

Let us know.

Tony Skalski

Do the printers need to be secure?

We use Pcounter here with Medium security NDPS printer agents (which do not require an iPrint logon). We uncheck Pcounters' "Allow unknown users to print" option (in the configuration for printer agents) so that print jobs are dropped if the user does not have a server connection. Pcounter matches the IP address of incoming print jobs and looks up the corresponding user in the server's connection table and logs it.

Unfortunately, there is no notification that the print job is dropped, but this is only a problem for us on Macs as we require Windows users to authenticate to NDS. Mac users know they have to mount their home directory to be able to print (home directories reside on the same server as the NDPS printer agents).


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell