The Problem:
While you can bind OS X computers to a Windows Domain, getting access to single sign on AD services in the process, there remains a weak link in that the CUPS smbspool process does not support Kerberos. So, while you can setup an Active Directory printer (which are even listed in the Printer Setup Utility Browse list) you can’t print to them without getting an Access Denied error.
The Solution… sort of:
Apparently some Apple SE’s working in conjunction with the French Gov’t have put together a solution: a CUPS backend script (ksmb) that intercepts the print job, then transfers it to a daemon (user_kprintd) that runs in the user space (where it can access the user’s Kerberos ticket). The user_kprintd daemon then nicely transfers the print job, with Kerberos ticket info, to the AD Printer share for printing.
There isn’t much documentation for finding the pieces, or putting it all together, so figured I’d say my thanks to the AFP548 community for all the help they’ve given me by providing this ‘guide’ of how to put the whole thing together.
The Downside:
The only downside I’ve found to this is that you still can’t use the nice Printer Setup Utility browse feature to add those AD printers you can see. I mean you can, but they still won’t work. Hopefully in Leopard I guess – then we can skip this whole workaround.
Instead you need to go into Printer Setup Utility (PSU from here on), click on the Add printer button, then Option click the “More Printers….” button at the bottom of the screen. This will take to where you can manually setup your printer. Select “Advanced” from the first popup list, then select “Windows Printer via SAMBA with Kerberos support v1” from the Device popup. From here you can enter a Device Name (whatever you want), and then the Device URI (in the form of ksmb://servername/printershare). Select the Printer Model and click add.
Of course, if you’ve followed the AD-OD Integration v2.1 whitepaper, you already have these AD integrated machines hooked up with OD, so you can actually just setup these printers once on the server and use the Preferences settings in WGM to setup the ksmb printers that you want the users to have. Voila, centrally managed, sso printers for your OS X computers.
Instructions for Setting this up…
1. Download the ‘French solution’ mentioned at http://forums.macosxhints.com/showthread.php?t=64283. The download link is http://homepage.mac.com/szumlins/scripts/KerberizedPrinting.zip.
2. This contains two files, user_kprintd, which I installed in /usr/bin (it can be installed anywhere, just change the kPrintD script to reference it properly). Also, there is a script called ksmb, which needs to be installed into /usr/libexec/cups/backend/
3. Now, create a small script to launch the user_kprintd daemon at login, as the required user (this needs to be running in user land, not as root)…
a. In terminal, type sudo pico /usr/bin/kPrintD
b. Enter the following as your script:
#! /bin/sh
su $1 –c /usr/bin/user_kprintd &
c. Save the file (Ctrl-O, Return) then exit pico (Ctrl-X)
4. Make kPrintD run at login by adding it as a loginhook…
a. Still in terminal, enter the following:
sudo defaults write com.apple.loginwindow LoginHook /usr/bin/kPrintD
5. Now, when you log in, the user_kprintd daemon will fire up. If you print to an AD printer, it will go into the queue, the ksmb shell script will intercept and transfer it to the user_kprintd process, which grabs the Kerberos ticket and sends the job to the printer.
by 
Be careful, this user_kprintd is not compiled as a universal, only ppc.
I have an installer which is compiled as universal, installs everything
needed in /usr/local/bin and /usr/libexec/cups/backend.
It also installs /Applications/LoginWindows Manager.app as my customer
needed it to enable the loginhook and other settings.
You can find it here :
http://lpertois.free.fr/mosx_scripts/kSMBPrint.dmg
Regards,
—
Laurent Pertois
Agnosys
ACT – ACSA
Here you are :
http://lpertois.free.fr/mosx_scripts/user_kprintd_source.zip
PS : The display of the article is awful in Safari, I had to select UTF-8 to have
something readable, is it normal ?
—
Laurent Pertois
Agnosys
ACT – ACSA
pblolo,
I haven’t had a chance to try your installer yet, but it looks nice and simple
and should be great. One other problem I found after posting this is that the
user_kprintd gets launched for every user that you login as, but then doesn’t
quit when you log out. I solved it by creating a logout script that essentially
did a killall user_kprintd.
As far as the gobblygook in the article I’m a bit surprised, as it didn’t show up
when I was editing the article, nor when I previewed it before submitting. Go
figure…. I don’t see a way to edit the article to try and fix it…
Hey, I’ve never checked but it’s strange, isn’t it launched as the user ? it
should then quit when you logout. I’ll have to test again and try your idea of
logout hook.
As for editing the article, I guess you’ll have to wait for one of the nice admins
🙂
—
Laurent Pertois
Agnosys
ACT – ACSA
Hmm, we’re still dealing with some Geeklog strangeness. I’ll see what I can
track down.
—
Changing the world, one server at a time.
Joel Rennich
not a biggy, but it took me some time to figure out why your installer package did not work, since your launch-script excludes local users, the kprintd daemon did not launch…
in our setup, our macs authenticate to AD but make a local portable home directory, so our users are being seen as local by your script.
Ah okok, I see, it should be arranged by looking if the user is in the AD (dscl
command) instead of checking if a local user is connecting (don’t ask me why
I’ve done it that way, I don’t remember, even if it looks silly).
Just for info, I check because a local user can’t request a kerberos ticket,
that’s all.
Sorry for the trouble and thanks for pointing it to others.
Regards
—
Laurent Pertois
Agnosys
ACT – ACSA
Wow! That worked really well. Before this we were pausing the jobs pprinted and users had to go to a Pcounter web page to authenticate and release their jobs.
One exception is that for users with a period in their login name the print job gets ‘intercepted’ but not sent to the print server, so nothing happens and the job stays in the print queue on the iMac.
so the user bob.jones will fail to print anything
but bobjones (no period) will be OK when he prints.
Any ideas because this is way above my head, maybe I could change the Kerberos settings, or would it be something in the user_kprintd daemon?
Has this changed in Snow Leopard? I’m trying this on a 10.6.5 client and can’t seem to get it to work. The daemon only launches manually (not working with the login hook) and instead of asking for authentication to a print job, the queue momentarily pops up in the dock but doesn’t actually complete the job. The printer on the windows server doesn’t show the job at all.
http://www.seminars.apple.com/seminarsonline/winprtque/apple/index.html?s=203&locs=us_en
—
Changing the world, one server at a time.
Joel Rennich
This is great! but it has another problem…
Using this method we can now finally monitor our print uses on the windows print server (using an event-logger).
But it turns out that the print jobs coming from our macs using this solution are not being properly logged, the page count is always 0 and the filename is always “Remote Downlevel Document”
see this piece of log for a print job:
i’m guessing it’s a side effect of using this “hack” and we will have to wait and hope till it’s natively supported in 10.5
I saw this too. It turned aut that the interceptor script, when in creates the spool directory
chmods only the leaf of the path but not the intermediate directory that mkdir -p creates.
This leaves the path to the spool dorectory inaccessible to the user daemon.
put a colon at the end of the username in the script. Ie; bob.jones:
. used to be the separator for user/group: ie; bob.admin, which is deprecated (old). New format is bob:admin. So anything before : is the username (including the .)
Thanks for working this out…but which script do you mean?
I think I found a fix.
In the ksmb shell script, line 58, it says:
“$chown -R $user $spooldir/$user”
When the user has a period, it equates to “$chown -R $firstname.lastname …”
But, chown thinks the “.” between firstname and lastname is separating between user and group. So, it cannot find group “lastname” . What ended up happening is that the user’s spool directory and temp files were created with root permissions so the user was not able to access their own print spool files.
So, I added “:wheel” to the string and it looks like:
“$chown -R $user:wheel $spooldir/$user”
This worked like a charm and the spool folder and file permissions are now correct, but I will do some more thorough testing.