We’ve discovered some strange behavior with Kerberos authentication for SMB 
printing and the use of multiple AD accounts by one user. In particular, the 
issue involves the use case where a day-to-day non-admin AD account is used 
primarily along with an AD admin “super user” account. When the user is logged 
in as “standard user” but elevates privileges (e.g., unlocks a System 
Preferences pane or installs something requiring admin privileges using 
Installer.app) as the “super user” a Kerberos ticket is created for “super 
user” and print jobs go through to the server as “super user”. This causes 
confusion and issues with access control and our print management software 
(PaperCut).

Most of our investigation is with 10.11 and our interest lies primarily there 
(and in future releases), but we’ve gathered some information for 10.10 and 
10.9 as well.

Basic details:
- printing through a Kerberos-enabled SMB printer connection 
(auth-info-required=negotiate)
- user is logged in as “standard user” and printing is fine in general
- user unlocks a System Preferences pane (also tested using Installer.app on 
10.11) as “super user”
- you can see that a Kerberos ticket for “super user” has been created when you 
check with Ticket Viewer.app

what happens on 10.11:
- print jobs begin going through as “super user” instead of “standard user"
- Kerberos tickets persist for both “standard user” and “super user”
- re-locking System Preferences does not help - the “super user” Kerberos 
ticket persists and jobs keep going through as “super user"
- taking computer offline and letting Kerberos tickets both expire, then get 
renewed (e.g., via screen unlock) results in jobs going through as “standard 
user” again
- logging out and logging back in fixes the issue, as you’d expect

what happens on 10.10:
- 10.10 is much better behaved (at least according to our goals and 
expectations)
- unlocking System Preferences as “super user” still creates new Kerberos 
ticket for “super user” but jobs still go through as “standard user”
- Kerberos renewal (without expiration) still allows jobs to go through as 
“standard user”
- Kerberos expiration (machine is offline) leads to failure of Kerberos when 
printing - falls back on username/password authentication, which is OK - this 
creates a new Kerberos ticket for “standard user” although username/password 
authentication prompts still persist - we can live with that - people could 
just log out and back in to regain benefits of Kerberos authentication for 
printing - just thought I’d share that peripheral datapoint

what happens on 10.9:
- Kerberos authentication for SMB printing on 10.9 seems a bit flakier overall 
(e.g., sometimes falls back to username/password authentication under 
apparently “normal” circumstances anyway) - sorry if there’s something 
additionally weird with my 10.9 test machine that may be a red herring
- unlocking System Preferences as “super user” results in Kerberos ticket for 
“super user” and disappearance (from Ticket Viewer) of Kerberos ticket for 
“standard user”
- printing goes through as “super user” with Kerberos authentication but only 
for one job
- after that, I’m finding that username/password authentication occurs
- authenticating as “standard user” renews Kerberos ticket for that account 
although username/password authentication prompts persist
- Kerberos ticket auto-renewal does not seem to help
- manually removing and re-adding the identity via Ticket Viewer helps but only 
for the next print, after which username/password prompts occur
- again, something seems to be off more generally, at least on my 10.9 test 
machine

Does anybody have any thoughts on this? Again, the focus of our concerns is on 
10.11 (and going forward).

Thanks,

Jake
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Printing mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/printing/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to