On Friday, 08/24/2007 at 06:21 EDT, Rob van der Heij <[EMAIL PROTECTED]> wrote:
> My major concern is auditing. While I trust that the implementation > will take care of auditing in the ESM, it makes it much harder to see > who has been messing with it. Normally when a user tells his server > "suddenly failed" you could scan the PROP logging and see which of the > developers reconnected, and tell him to hit his peer over the head > with it. But when neither of the virtual machines has its console > spooled, you would not be able to tell what happened. Command auditing is already provided by ESMs. Nothing would change in that respect. > Oh, and how about RACF restrictions that apply to the LOGON (like > terminal or time) ? How would that apply to the proposed commands? No change. The conditional access list for LOGON is not applied to other CP commands. Further, it only applies at the point the user is logged on. Once logged on, those restrictions are never imposed again. No double jeopardy. > If you really think this is useful, then use different profiles in the > surrogate class (e.g. MAGICBY.<target>) so that an installation can > decide which end users are able to use this. That is what I originally envisioned and remains my fall-back position. Thank you, everyone, for your considered comments. I've gotten what I needed. I should point out, however, that the class G FOR command requires you to be the SECUSER of the target. With an ESM, if you are not the SECUSER, then LOGON BY authority is sufficient. Alan Altmark z/VM Development IBM Endicott
