IPP Printing over HTTPS broken after 2.2.5

[marioraccagni]

Hello everybody.
Looks like internet printing configured via IPP over HTTPS is broken after 2.2.5.

We tried with the latest CUPS 2.2.9 on MACOS Mojave version 10.14.3 and with other intermediate versions on different Linux Distro, but the result is always the same.. the print job remains in the local queue and never get submitted to the server.

This is what we get on the IIS log on the print server:
2019-02-11 15:25:00 10.4.1.61 POST /printers/Stampante1/.printer - 443 - 10.4.66.16 CUPS/2.2.9+(Darwin+18.2.0;+x86_64)+IPP/2.0 - 401 2 5 0
2019-02-11 15:25:11 10.4.1.61 POST /printers/Stampante1/.printer - 443 - 10.4.66.16 CUPS/2.2.9+(Darwin+18.2.0;+x86_64)+IPP/2.0 - 401 2 5 0
2019-02-11 15:25:54 10.4.1.61 POST /printers/Stampante1/.printer - 443 - 10.4.66.16 CUPS/2.2.9+(Darwin+18.2.0;+x86_64)+IPP/2.0 - 401 2 5 0
NO username and error Access Denied returned..

When using the version 2.2.5, on the IIS server we can see the user name correctly and no errors:
2019-02-11 14:39:48 10.4.1.61 POST /printers/Stampante1/.printer - 443 Domain\username 10.4.66.53 CUPS/2.2.5+(Darwin+17.7.0;+x86_64)+IPP/2.0 - 200 0 0 15
2019-02-11 14:39:48 10.4.1.61 POST /printers/Stampante1/.printer - 443 Domain\username 10.4.66.53 CUPS/2.2.5+(Darwin+17.7.0;+x86_64)+IPP/2.0 - 200 0 0 0
2019-02-11 14:39:50 10.4.1.61 POST /printers/Stampante1/.printer - 443 Domain\username 10.4.66.53 CUPS/2.2.5+(Darwin+17.7.0;+x86_64)+IPP/2.0 - 200 0 0 15
2019-02-11 14:39:50 10.4.1.61 POST /printers/Stampante1/.printer - 443 Domain\username 10.4.66.53 CUPS/2.2.5+(Darwin+17.7.0;+x86_64)+IPP/2.0 - 200 0 0 0
2019-02-11 14:39:50 10.4.1.61 POST /printers/Stampante1/.printer - 443 Domain\username 10.4.66.53 CUPS/2.2.5+(Darwin+17.7.0;+x86_64)+IPP/2.0 - 200 0 0 1051
2019-02-11 14:39:50 10.4.1.61 POST /printers/Stampante1/.printer - 443 Domain\username 10.4.66.53 CUPS/2.2.5+(Darwin+17.7.0;+x86_64)+IPP/2.0 - 200 0 0 15

Is this a known problem? is there anything new to configure in the CUPS to make this work as before?

Thanks!
-mario

[michaelrsweet]

@marioraccagni What version of Windows Server are you using?

[marioraccagni]

Windows Server 2008 R2 or 2012 R2 doesn't make any difference.. CUPS 2.2.5 works fine in both environments .. 2.2.9 looks like is not able to perform the authentication correctly.

Thanks
-mario

[michaelrsweet]

Hmm, OK I'm testing with Win2016 now and the server isn't responding with Basic as an option for authentication, just NTLM and Negotiate (Kerberos). Kerberos will work if you are bound to the same AD server, but CUPS doesn't support NTLM.

I'll try testing with an earlier version of CUPS.

[michaelrsweet]

CUPS 2.2.5 does the same thing.

[michaelrsweet]

OK, did some digging and managed to enable Basic authentication on Win2016 (I wish they didn't keep moving things around...)

With the configuration change, CUPS 2.2.5 works but current CUPS 2.2.x and 2.3.x does not. The debug logs show that we see Negotiate first and give up (no Kerberos credentials) rather than trying Basic... Investigating...

[michaelrsweet]

OK, turns out we didn't have a way to try Basic if Negotiate failed.

[master 1ce6909] Non-Kerberized IPP printing to Windows was broken (Issue #5515)

[branch-2.2 bafbb26] Non-Kerberized IPP printing to Windows was broken (Issue #5515)