1 Reply Latest reply on Apr 16, 2013 3:29 PM by Jason Lee

    MFP Pass-through Authentication (Bizhub)

    Jason Lee Adventurer

      I could kick myself as I have this working for one of our copiers, a Bizhub C352, for 32bit XP/Vista/WIn7 and 64bit Vista/Win7 on a Win2003 R2 x32 server.   Basically I have the device setup with the User Account/Track system that Bizhubs use (internal user listing with a passcode).  The print queue does not have it setup.   Pharos is setup to auth. to AD via LDAP Bank.  When a user prints to the Pharos printer, they auth as normal, then Pharos sends to queue which sends to device and since the device printer has the set Auth account, the print job is accepted by the copier.


      Recently our primary copier has been brought down due to mechanical problems and we are waiting on parts.  We have a Bizhub C351 in reserve and I've created the device, queue and package identical settings to previous other than driver.


      For some reason jobs send to this copier are failing due to the copier receiving the currently logged in user's credentials... i.e. its like the job is going directly to the printer rather than through Pharos and since we have a dedicated ID/passcode for Pharos, the job fails because individual users are not setup in User Auth/Acct Track on the copier.


      I'm racking my brain and comparing property pane after pane to see what simple setting I'm over-looking, but I'm not having much luck.   Hopeing someone can slap me a V8 on what I'm missing here.  Have a support request in and if I get a resolution, will post.


      BTW... for the Bizhub's to work both 64 and 32bit driver on the 32bit server, I had to alter the x64 driver inf to match the name of the x86 and then added them via the Additional Drivers button on the device (note I was not able to use the Print Mangement RSAT tool to do this as indicated in a few KB articles).

        • Re: MFP Pass-through Authentication (Bizhub)
          Jason Lee Adventurer

          OK, looks like this is driver specific.  After talking to Pharos support, indeed all settings between driver, queue and package for the printer are identical; however, the C352 passes configured device Account Auth settings while the C351 does not.


          So in looking at driver, checking found that I'm at the latest driver available both on the x32 and x64 for the C351.  Tried setting the Auth  Account on the queues, no change so removed it.


          Set the Auth Account info on the printer setup on the Client and low and behold, it works.  As a test, removed the Account Auth on the C352 device, added to the client printer and no go, the account info was not passed on.


          So this leads me to believe it is how the Account info is encoded into the print job per driver/printer and thus where it is interpreted is different per system.  The horrible, bad, bad portion is that you can only update the printer properties if the logged on user has higher than User rights (i.e. admin or power user) on a system AND the Account Auth/Track settings are PER USER!!!  So for the C351, for every user profile for every pc we will have to manually set the Account Auth/Track ID/PWD which is horrible.


          My next venture will be to determine if it is a registry entry, if so, can I export it then for GPO or login script check to see if it exists and import it if not.  If only we could specify on the printer that the built-in Public account can only Print (not copy/scan/etc) and then limit the copier to accept print requests from specific IP's... which it doesn't.  IP issue we could handle with a hardware router inline to the copiers network connection, but that doesn't help with disabling the public account so anyone can't just starting copying/scanning physically at the copier.   I feel like I'm dealing with a Mac... the programming/feature set is always 80% there and they never follow through with the other 20% that is soo needed in a multi-OS, secure minded environment for easy deployment.   Speaking of OSX... I did not try manually setting the Auth Account/Track setting on an OSX system so I don't know if the workaround functions there.