[2514] in Enterprise Print Delivery Team
Re: Fwd: Problems Saving Unauthorized LPR Jobs to Restricted
daemon@ATHENA.MIT.EDU (Theresa M Regan)
Tue Jun 25 18:29:53 2002
Message-Id: <5.0.2.1.2.20020625171930.03681a80@hesiod>
Date: Tue, 25 Jun 2002 18:26:20 -0400
To: Susan Starr <sstarr@MIT.EDU>
From: Theresa M Regan <tregan@MIT.EDU>
Cc: IPM-SYS <IPM-SYS@MITVMA.MIT.EDU>, printdel@MIT.EDU, tregan@MIT.EDU
In-Reply-To: <5.0.2.1.2.20020625135309.00aeec78@hesiod>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Hi Susan,
just following up our conversation... for many of us these are not new
issues and the discussions have been long and tedious... So, if I am
understanding your note correctly and it is now possible to feed the list
associated with the "moira" print queue's "restrict list"; therefore,
syncing the moira data with IPM, then, this is terrific news. It may be
helpful to revisit an earlier suggestion.
Since the adding / removing of SAP R/3 authorizations is managed via
R3-accts for Central Offices and the running of the GL statements requires
a specific authorization, possibly, we should suggest to the CAO Process
Owners who may request SAP R/3 authorizations to include a request for a
moira list update. Since R3-admin does "special" account/access handling
for several Central Departments, it could complete the list update when
maintaining SAP R/3 authorizations. In all likelihood, if R3-admin agreed
to manage the list, they would remember the "special handling" when
assigning GL statement authorizations, regardless, of a specific request.
If this approach is taken, everyone should be aware that if the "restrict
list" is out of sync and someone runs the GL statements, they will not make
it to the IPM queue for printing. If I am following the discussion
accurately, if this oversight occurs, the only recourse is to re-run the job.
My comments only reflect the Process Owners, I do not know what FSS' needs
/ expectations are. Their authorizations may be broad enough to have
access to run the GL statements w/o the explicit authorization assigned to
Process Owners.
In closing, if ROLES was an option, then, we could programmatically address
this issue. Logic could be added, such that, when the authorization to run
GL statements is assigned the list was updated or at least a dialog box
reminder could be displayed reminding people of the list dependency.
Hope this helps...
Thanks,
Theresa
At 01:59 PM 6/25/2002 -0400, Susan Starr wrote:
>Hi Theresa,
>
>In hopes of addressing concerns about the acl for GL Statements, we have
>had a meeting with Garry Z, in which he agreed to automate generation and
>downloading of the file(s) by the end of July. We also discussed putting
>control of the user lists in the hands of the manager (in this case, Gill
>Emmons I think). So, with a three-hour lead time, a new user could have
>printing permissions on the GL queues.
>
>I understand the concern about the infrequency of new users being added to
>the list, and the difficulty involved in remembering to update the
>list. Perhaps we should include Gill in the discussion of this issue and
>what can be done to prompt a list addition. There is a need to provide
>adequate security on the print servers, which makes the "unrestricted
>front-end queue" idea somewhat dangerous. By the time the filter is
>applied, the job has already made it past the initial connection
>point. Under the current setup, connection to the machine is allowed, but
>a restricted-queue job is rejected before filtering if the user name is
>not on the acl named in lpd.perms for the queue. The second-tier security
>is checking the incoming IP against a list of MIT masks.
>
>Your suggestion to have the operators release the GL job(s) at a
>particular time is something which could be done, but does not address the
>general security needs of the system. It seems to me that the same
>degree of care could be applied to ensuring that users have been added to
>a user list, maintained by their own group. IAST will be happy to work
>with the affected groups to ramp up this process, as well as issue
>reminders prior to print dates if necessary.
>
>I'd be happy to talk to you further about this; I am still in the
>learning phase, and I am extremely interested in your perspective.
>
>Thanks,
>Sue Starr
>
>
>
>At 05:48 AM 6/17/2002 -0400, Theresa M Regan wrote:
>>Hi Dave,
>>
>>Thank-you for pointing out this e-mail and the clarification that Rockyln
>>and Garry have provided with regard to the relationship between "moira"
>>and LPRng.
>>
>>For the "restricted" queues that I am aware of, there is an additional
>>precaution/complexity since there is application level access control, as
>>well. Very few people are allowed/expected to run these types of jobs
>>which generate print requests for these queues. I am confident that the
>>all the critical relationships could be set-up accurately
>>(initially). It is the on-going maintenance that is a concern.
>>
>>Is the solution a "non-technical" solution?
>>For now, the restricted queue that I am aware of is the GL
>>Statements. Do we go forward with the implementation and the risk that
>>GL statements will be rejected if the userid in not in the acl in
>>"moira"? Do we clarify/emphasize to the business owners (Gill Emmons)
>>and R3-admin that when anyone in addition to Gill, Jay Nickerson, etc.
>>are granted authorizations to execute the GL Statements, they need to be
>>on the moira acl for that queue, as well. If they are not, their print
>>job will be rejected and need to be re-run? (This print job is too large
>>to leave it on the R3 servers for 48 hours which may be a solution in
>>other scenarios.)
>>
>>Or, accept that if a print job hits the GL Statement queue, it is
>>expected to be printed. For the operators, by chance, are there
>>additional relevant pieces of data which could be captured from the
>>originating print request for a decision to print or
>>not. Example: generally, we know when to expect the statements. If a
>>print request arrives in the queue and it is not expected, a set of
>>procedures is followed? If we are expecting a print job and it arrives
>>on-time, there may be still a few other details possibly to check
>>out... verification that the print request originated from SAP R/3.
>>
>>Sorry, I have not been able to come up with other ideas or simpler
>>ones. One of the challenges with the proposed restricted queues and that
>>we anticipate their maintenance to be infrequent. If the business
>>applications tied to restricted queues experienced frequent changes in
>>personnel, there would be less of a risk of just rejecting the print
>>request and the business owner would be fully aware of the impact of the
>>decision and coordination of the data.
>>
>>Thanks,
>>Theresa
>>
>>
>>>Date: Thu, 30 May 2002 14:32:46 -0400
>>>To: Enterprise Printing Delivery Team <PRINTDEL@mit.edu>
>>>From: "Rocklyn E. Clarke" <rclarke@MIT.EDU>
>>>Subject: Problems Saving Unauthorized LPR Jobs to Restricted IPM Queues
>>>Cc: IPM-SYS <IPM-SYS@MITVMA.MIT.EDU>, "Regan,Theresa M" <tregan@mit.edu>
>>>
>>>Hi Team,
>>>
>>>As you know, we plan to automatically download Moira printcap
>>>information to LPRng running on the IPM servers. We would also like to
>>>make use of LPRng's ability to restrict selected print queues so that
>>>only authorized job users can submit jobs through them. Furthermore, we
>>>have a business requirement that a job submitted to a restricted queue
>>>by an unauthorized user be saved in case the job is one that really
>>>should be printed.
>>>
>>>Last week I raised a concern with this plan based on my understanding of
>>>LPRng which Garry has now confirmed (see his email below). If we
>>>attempt to download from Moira a list of authorized users for a print
>>>queue, LPRng will reject lpr submissions from unauthorized users WITHOUT
>>>giving us a chance to grab the print job and save it anywhere.
>>>
>>>In order to implement restricted queues, we would need to download a
>>>list of authorized users to a non-standard file (i.e. NOT
>>>/etc/lpd.perms) and IMPLEMENT OUR OWN LOGIC for checking ALL lpr jobs
>>>for ANY print queue against a new internal list of restricted queues and
>>>authorized users.
>>>
>>>Obviously this is would be a significant departure from our strategy of
>>>paralleling as much as possible the structure of the Athena Print
>>>Services implementation. It would also create more potential points of
>>>failure for our printer service. There may very well be a way to save
>>>print jobs from unauthorized users without incurring these
>>>disadvantages, but nothing elegant springs immediately to mind for
>>>me. I'm willing to give this some more thought, but since I don't have
>>>as much time to devote to this as I used to, I want to give everyone
>>>else out there a chance to come up with something.
>>>
>>>Rocklyn
>>>
>>>P.S. Something inelegant: It occurs to me that we could "front-end" a
>>>restricted queue with an unrestricted queue and "trap" rejected jobs in
>>>the middle. This would add an unfortunate amount of complexity, but
>>>perhaps it would work. I'll let Garry weigh in on it.
>>>
>>>At 5:32 PM -0400 5/21/02, Garry Zacheiss wrote:
>>>> >> Do you have any alternatives to suggest?
>>>>
>>>> No; if you want this feature, you'll need to implement your
>>>>authorization in the filter.
>>>>
>>>>Garry
>
>
>Susan Starr
>Information Systems
>Infrastructure Services
>W91-205b
>Office: 617-253-6639
>Cell: 978-821-9459
>
>
>
>Susan Starr
>Information Systems
>Infrastructure Services
>W91-205b
>Office: 617-253-6639
>Cell: 978-821-9459
