[2041] in Enterprise Print Delivery Team
Re: Queue Name
daemon@ATHENA.MIT.EDU (David F Lambert)
Tue Dec 11 09:17:03 2001
Message-Id: <200112111416.JAA23775@fort-point-station.mit.edu>
Date: Tue, 11 Dec 01 08:25:11 EST
From: David F Lambert <LAMBERT@MITVMA.MIT.EDU>
To: Theresa M Regan <tregan@MIT.EDU>
cc: "Huxley, Bil" <huxley@MIT.EDU>, "Lynne E. Durland" <durland@MIT.EDU>,
R3-Print@MIT.EDU,
Enterprise Printing Delivery Project Team <printdel@MIT.EDU>
In-Reply-To: Message of Tue, 11 Dec 2001 06:09:57 -0500 from <tregan@MIT.EDU>
Well, let's try again to explain this to everyone's satisfaction (although
I'm beginning to wonder if that's possible :)).
On Tue, 11 Dec 2001 06:09:57 -0500 you said:
>Hi Dave,
>
>You reference SAP's inability to use klpr. Since kerberized printing is
>not a requirement in the administrative space, I am not sure why it is
>being raised. As far as I can remember, it was decided that it was not a
>requirement by several teams early on and we have never made a request of SAP.
The reason I raised this was to point out that all current non-SAP queues
are authenticated. Queues for SAP use the kludge with the username passed
with the file. The other queues use existing authentication infrastructure
elements - SSL and klpr. Therefore, today, we need duplicated queues
in some cases to handle both SAP and truly authenticated submits from
non-SAP environments. It would be less confusing, more consistent,
and certainly more secure if all central printing used the two
standard authentication mechanisms for print submission.
All past (pre-SAP) central printing had been authenticated. The mechanism
used was the mainframe login id. A few non-mainframe appls such as those
provided by SIS also used host system login for authentication in
conjunction with a dedicated link to the mainframe. No one in DOST was
asked about any authentication requirements for SAP printing. Had we
been given the opportunity to express our opinions, we surely would have.
As you may recall from our recent talk in your office, Theresa, there
were two driving reasons for our desire to provide authenticated
central printing services (note these two requirements are only
relevant when thinking about central printing). First, we need to
do worry about indirect cost recovery allocations and produce appropriate
usage reports. Hopefully we won't have to implement chargeback. So,
we need to ensure these reports and ICR issues are handled accurately.
Second, we need to ensure that only authorized folks are allowed to
access specific secure resources such as payroll checks. We do not
want Random Hacker to be able to place a print file in the queue
which instructs the ops to place blank check stock, use the Grade Report
eform or otherwise access secured forms in the printers. I would
assume this is similar to some of the authorizations already implemented
in SAP to address other restricted processing such as running the
Monthly GL batch job.
>Is it being raised because some of the queues on IPM are being set to
>accept only kerberized print requests? Is there an expectation that IPM
>queues will only accept kerberized print requests in the future?
It would be nice if we could work towards providing only authenticated
central queues in the future for the two reasons stated above. Obviously,
we've made an exception to our goals to accommodate SAP.
>When administrative users mention "security" with their printouts, they
>request a printer isolated from general access. The most common comment is
>that if they cannot get to the printer quickly and the documents are
>"confidential", then, they fine comfort limiting who can pick-up documents
>from that printer. I have never heard concerns (within the administrative
>community) about the data stream to the printer.
Please note in the legacy central printing service, a "secure queue"
exists which requires not only limitations for pick-up, but also
requires shrinkwrap, a packing slip, and a sign-off sheet for each
person who touches the output from the printer to the final recipient.
Both SIS and ITAG expressed significant concerns around clear text printing
from the submitter to the print server and from the print server to
the printer. Please note the point-to-point conncection from the old
SIS servers to the mainframe was replaced by an encrypted print file
submission to the MF via MITnet with their new servers.
The delivery team tried very hard to get ITAG to say encrytion was
not required. They would not make that statement. Rather they indicated
the level of protection required for print datastreams was a matter
for the custodian of the data to determine and provide.
VM-SST has also expressed concerns about our desire to move the IP60
printers from direct MF attachment to network based connectivity. This
is a reasonable concern from our perspective since central printing
has *always* provided non-networked connectivity of the printers to
the legacy print server (MF). Discussions with MF printing customers
has been in the works for months. Bil will recall this agenda item
at a CAO management meeting many months ago.
>Today, for DLCs, with the exception of the DTRs and Summary statements,
>most SAP R/3 transactions are completed via the web. If/when print
>requests are needed, they are completed via "desktop" printing solutions
>and in most cases, klpr is not involved. The trend for SAP R/3
>functionality is to continue with web browser solutions; thereby, bypassing
>the print queue approach in most cases (not all).
>
>With regard to the Queue Names, I was not able to attend R3-admin
>yesterday; so, I still need to follow-up on that detail.
>
>Thanks,
>Theresa
Email did not feel like the best way for these questions to be posed or
the best mechanism for my response. I think this was an opportunity
for a real face-to-face discussion which could be a lot more interactive
to ensure we're all on the same page. Therefore, Printdel would like
to offer to meet with R3-Print or anyone else to improve our common
understandings.
-Dave (for Printdel)
>At 06:20 PM 12/10/2001 -0500, David F Lambert wrote:
>>Hi Bil,
>>
>>Actually we may want to eliminate EP1 altogether at some point. Our
>>primary goal initially for EP1 was to move it as transparently as possible
>>from CAO's perspective. Since we can handle PS output on the IP60 printers,
>>we could just point output there with new or existing logical destination/
>>queue names. I think it makes sense to minimize and/or eliminate
>>different queues which basically do the same thing (forms, handling, etc.)
>>
>>Some duplication is required now due to accommodating SAP's inability
>>to use klpr. So, at some point you can expect EP1's name to change or
>>be replaced with a queue which performs similarly.
>>
>>Hope that helps...
>>
>>-Dave
>>
>>On Mon, 10 Dec 2001 18:04:35 -0500 Bil said:
>> >Hi,
>> >
>> >Doesn't this imply that you would want to rename EP1 too?
>> >
>> >Confused,
>> > Bil
>> >
>> >At 12/10/2001 01:47 PM -0500, Lynne E. Durland wrote:
>> >>Greetings,
>> >>
>> >>Dave Lambert and Theresa met briefly last week to discuss the name
>> >>EP60/EP62 for the new general queue for SAP central printing. Dave
>> >>expressed concern that EP60 was not as descriptive as it might
>> >>be. Theresa agreed to entertain other proposed names. In our printdel
>> >>this morning we came up with DC1 and DC12 for the names. The DC standing
>> >>for Data Center. Our current goal is to get this new queue implemented by
>> >>Friday.
>> >>
>> >>Please let un know if the proposed new name is acceptable.
>> >>
>> >>Thanks
>> >>
>> >>Lynne
>> >>Lynne E. Durland
>> >>Information Systems
>> >>Database Services
>> >>W91-109
>> >>O: 617-258-5857
>> >>C: 617-293-8091
>> >>H: KB1FEM
>> >>
>> >>"When one door of happiness closes, another opens; but often we look so
>> >>long at the closed door that we do not see the one which has been opened
>> >>for us."
>> >>
>> >> --Helen Keller
>> >
>> >
>
>
