Kerberos AuthInfoRequired negotiate Printing

Hello,
I'm in the same situation. I personally haven't found a solution, but if there is one, I'm interested ;)

Have you tried mapping the printer via Line Printer Daemon instead of browsing for in via Bojour to map it?  That's worked for me.

from meddling around, I was able to script setting a default password we use for new accounts, its still not ideal, looking further though there is possibly the ability to update the pw via jamf connect keychain syncing, which I haven't implemented yet, but its on my to do list. not ideal as Kerberos would be my preferred method. other the combination of the two.

the third part seemingly is to do with the printers.conf when the printer is added:
sudo lpadmin -p MyOfficePrinter -o auth-info-required=negotiate
as sometimes by default it is set with username,password

I have reached out to paper cut support to see if they might be able to elude to the issue.

I suspect running sudo lpadmin -p MyOfficePrinter -o auth-info-required=negotiate
for the printers mapped on AD bound computers, might then make AD devices work with Keberos, I haven't gotten that far in testing, as I moved onto implementing Escrow Buddy for FileVault. But it would then help point towards the keberos capacities of Jamf Connect or something I am missing in Jamf Connect for it to work correctly. 

air print is preferred, we would regular see printing issues with page format size issues being most of the culprit, using direct to windows print shares, or also similar problems back in the day when we run a Mac print server.

I won't rule it out, but it's not prefered at this point.

Paper cuts response:

Mobility Print uses our own authentication stack - it does not interface in any way with Kerberos. For a macOS client, we are leveraging how AirPrint connections on these devices operate to tell the OS to issue a prompt, but the credentials are handed directly to us to validate against the sync source in MF.
 
There is a way to run Mobility Print in a special mode where no authentication is required, but every job that passes through it will be logged as a single, static user (so you will lose the ability to understand who printed, and therefore how to charge them).
 
There is another option that may work, but only if...
 

1.       These are managed macOS devices (not BYOD), and...
2.       You are able to use another feature of ours called Print Deploy, to add the Mobility Print queues instead of using DNS, and...
3.       The users login to macOS itself with credentials, and importantly a username form, that is always known to PaperCut (e.g. I have to login to macOS to use the device, and I supply domain credentials, username jfitzgerald, which is a user in PaperCutalso synced from the domain).

 
If those conditions are met, there is a way to instruct Print Deploy to trust the OS reported user account, and give this username value to the Mobility Print server, and instruct it to not require a password.
 
If you can tell me a little bit more about these macOS devices (are they managed or BYOD, or a mix, and how to people sign into them - local accounts or domain), I can let you know if there might be a way to make things work :)

So it would appear the direct use of mobility print and air print that it populates discovery for, simply won't work with keberos, cause its an independent authentication to kerberos, which explains why when I attempted the auto negotiate setting for the printers and it didn't work still for AD devices.

I will update here on the instructions they provide for the alternate integration process, although I will need to work out which method might be best moving forward, their solution or integrating jamf connect keychain sync, to update the keychain record, which I am yet to address but will be attempting to do implement next week.

Their method might be best, if it works, as it suggests it will do away with the authentication altogether.