Michael,
Thanks for your quick response! I will submit a bug report.
Our experience with SMB printing (as described below) is much more random than
what you describe. I hope you will forgive me if I am skeptical of Apple's
innocence. The sheer complexity of code on Apple's side to interface with
Microsoft's complex authentication schemes would make a lack of bugs miraculous.
I hope that Apple and Microsoft will be able to work together to solve these
problems to their mutual advantage and the advantage of their customers.
In particular, contrary to your statement below, we have found that unbound
clients can use either "username,password" or "negotiate" _*almost*_ always, and
that they cannot use one, the other, or either _*sometimes*_. We _*always*_ use
FQHNs.
Another example of the myth of deterministic behavior of IT systems.
Yours,
-Rick
On 9/12/16 12:43 PM, Michael Sweet wrote:
Rick,
Please file a bug (bugreport.apple.com) for this issue so we can use it to
track improvements in this area.
SMB printing is a mess, and that mess is not our making - it is a well-known
problem with SMB in general...
The domain username format used by the SMB protocol when doing "username,password" authentication is
"domain\username", matching NetBIOS. The format used by the SMB protocol when doing Kerberos
("negotiate") is "username@domain"...
Hostname issues can also cause lots of problems, none of which are easy to
diagnose. The general rule of thumb is that Kerberos requires the client to be
bound to the domain AND use a fully-qualified hostname for the server
(server.domain). Clients using username,password can use the unqualified
hostname (server) as long as the client and server are on the same subnet OR
the client is bound to the domain. Clients that are not bound to the domain
MUST use a fully-qualified hostname (server.domain) AND MUST use
username,password. Any other configuration will probably fail in random and
hard-to-fix ways, probably at the very moment some VIP needs to print a very
important document.
On Sep 12, 2016, at 10:57 AM, Rick Cochran <[email protected]> wrote:
Hello,
Below is a problem report from a highly skilled IT admin in a department which
uses our print servers.
NetID is our name for AD identities.
Any help would be appreciated.
Yours,
-Rick
In Ithaca: Windows server 2012 R2
In Rome, Italy: Windows server 2008
Servers are domain bound
Mac clients range from 10.7 - 10.11
Clients are not domain bound
Printers are shared with Windows SMB.
In our Rome location, I've modified our print installer script to use "username,
password" as the auth method (this is different from "negotiate" which is what
works, mostly, with the Ithaca server).
Method 1: Most users can print from Mac to the shared windows printer simply
using:
NetID
Method 2: If that doesn't work, I have them remove the printers and install the original
script which uses "negotiate". At this point they can login with:
NetID
Method 3: If both of those methods don't work I have the user install the printer via
method 2 ("negotiate") but use:
domain\NetID
At no point does [email protected] work.
Also, it is seemingly only one of the above methods that work at a time, it's 1
out of 3, not 2 out of 3 or all 3 on any particular machine.
The last Windows update on the Rome server was 9/1
Some anecdotal evidence:
I had a student printing with username,password using just the NetID last week,
this week I had to change them to negotiate and use domain\NetID for login.
Two students had saved their password for the printer in their keychain last week. This week they
tried to print and the printer reported the standard "hold for authentication" or
"authentication required" (can't recall exactly). Killing the keychain, retyping the same
password on the next print job allowed the job to pass through (their password was the same). This
one makes no sense at all...
The server is in Rome, Italy with an extended network from Cornell (clients are
in Italy as well) meaning we are on the Ithaca IP space. AD lookups take about
1 full second.
I have zero auth issues with Windows unbound clients.
Strange side note:
I have a few mac desktops in Ithaca, using the Ithaca server that only seem to work on
"username,password" with domain\ NetID. These machines were literally cloned
with a file level copy from working machines in a lab. 11 of the clones work as expected,
2 of the mac clones need the switch from negotiate to username,password to function with
shared windows printing.
This really seems like a client (mac) issue.
_______________________________________________
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/msweet%40apple.com
This email sent to [email protected]
_________________________________________________________
Michael Sweet, Senior Printing System Engineer
_______________________________________________
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]
