CA VM:Secure secures your system resources such as minidisks, tape volumes etc through rules in which you can specify whether passwords are required for use or not. The directory management commands are authorized via a central product authorization configuration file. The configuration allows for definition of 'roles' through groups so that you can give authorization to a particular group for certain commands. The authorization configuration function is very flexible and powerful. You can do detailed authorization such as allowing a user to use a particular menu, but only certain functions on that menu.
However, the product CA VM:Director, has the ability to interface to your ESM if you prefer for directory management command authorization. If you aren't running an ESM, then the product's authorization configuration file is used for command authorization just as it is for CA VM:Secure with the same flexibility and power. Yvonne DeMeritt CA [EMAIL PROTECTED] ________________________________ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Tuesday, December 11, 2007 9:54 AM To: [email protected] Subject: Re: DIRMAINT authentication John, I agree that security/authentication is pretty much an afterthought in DIRMAINT but I doubt IBM would be interested in a rewrite just because it is a PITA. I am not very familiar with VM-Secure how do they handle security issues? Perhaps if the compitition for buisness were fierce in the directory management sector we could convince them to make improvements. -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Jim Bohnsack Sent: Tuesday, December 11, 2007 8:28 AM To: [email protected] Subject: DIRMAINT authentication About 4-6 weeks ago I was spinning my wheels trying to bring up a new release of DIRMAINT with z/VM 5.3. I was getting nowhere trying to get our userid admin. people authenticated without having to tell each of the to enter "DIRM NEEDPASS NO". There were quite a few postings on the list under the thread of DIRM NEEDPASS NO. Eventually Alan Altmark (or perhaps Chuckie) said I should open a PMR. I did that as a doc problem and had talks with DIRMAINT development. I finally closed the PMR without any resolution because I think that the documentation is really a symptom of the real problem. I told DIRMAINT development that I was going to throw my interpretation of what the "real problem" is out to the list and see if anyone agreed with me and if the list inhabitants could come up with some usable suggestions. I think that the "real problem" is that as DIRMAINT has matured or grown or added features, more and more types of authentication have been discovered as having been needed and have been added in. What we have is an authentication system or a control system in a product that has the original design purpose of managing the system directory and not securing the system but that now, it appears, a lot of DIRMAINT is an authentication system. I think that identification of what different classes of DIRMAINT users such as: Administration DASD Mgmt General Users Helpdesk Password Monitor System Operator DASD Mgmt automated programs, i.e. DFSMS/VM Support Programmer Internal Communication and authentication of those different users or functions sounds a lot like what CP privilege classes do (sort of but without a lot of granularity) or an ESM such as RACF/VM or VM:Secure does. This is not a DIRMAINT documentation problem, it's more basic than that. This involves a greatly different DIRMAINT. A new version or a totally different product. It would most likely also involve, using my suggested uses of CP priv classes or an ESM, so additional or redefined CP priv classes, or ESM extentions such as new RACF (or whatever) CLASSes. What you do all think or am I the only one who thinks that this is a problem in DIRMAINT or an "opportunity" for improvement? Jim Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED]
