Univention Bugzilla – Bug 49521
99ucs-school-umc-printermoderation.inst fails using Machine Account
Last modified: 2022-02-28 13:14:12 CET
It looks to be better to use the Administrator account to set the driver via rpc and only use the machine account as fallback. In the customer environment (4.4-0 e109) the machine account fails with 'result was WERR_ACCESS_DENIED', the Administrator account worked.
A Workaround might be ============================================================ # rpcclint -U Administrator -c 'setdriver PDFDrucker "MS Publisher Color Printer"' $(hostname) Enter DOMAIN\Administrator's password: Successfully set PDFDrucker to driver MS Publisher Color Printer. # ucr set ucsschool/printermoderation/windows/driver/assign=false # univention-run-join-scripts # ucr unset ucsschool/printermoderation/windows/driver/assign ============================================================
this happens again in the customers environment.
Created attachment 10052 [details] using Administrator credentials instead of machine credentials This might fix the issue in a hurry.
(In reply to Nico Stöckigt from comment #3) > Created attachment 10052 [details] > using Administrator credentials instead of machine credentials > > This might fix the issue in a hurry. This only works on non-DC-Master systems (→ no credentials are passed to join script). This is why the use of the machine account had been implemented in the first place, to make it work on all system roles.
(In reply to Sönke Schwardt-Krummrich from comment #4) > (In reply to Nico Stöckigt from comment #3) > > Created attachment 10052 [details] > > using Administrator credentials instead of machine credentials > > > > This might fix the issue in a hurry. > > This only works on non-DC-Master systems (→ no credentials are passed to > join script). This is why the use of the machine account had been > implemented in the first place, to make it work on all system roles. But why doesn't the machine account work? It's in 'Print Operators' but receives a 'WERROR_ACCESS_DENIED'.
I don't know about the details of this bug, but * "Print Operators" in UCS is a bit special. In OpenLDAP it's called "Printer-Admins" (see Bug 42675) * Memberservers behave in a special way, because lookups via winbind are redirected to the DCs and the idmapping behaves differently (see e.g. Bug 26712) * "Printer-Admins" used to have the SePrintOperatorPrivilege, maybe not any longer with Samba4? (see e.g. historic Bug 22246 for a case like that) Also, I'm not sure that the machine account should be allowed to do this. > But why doesn't the machine account work? It's in 'Print Operators' but receives a 'WERROR_ACCESS_DENIED'. That would need some research.
Is this still an issue? The Bug has been reported only once 11 months ago - did it happen again? I'll recduce "Who will be affected" in the meanwhile.
Customer reported actual occurrence; so a clear yes to your question Ingo. You can find closer details in the second attached ticket. Happened on a fresh UCS4.4-5 UCS@school installation. So vote to do the deeper research Arvid mentioned.