> The bogosity index is extremeloy high on this one. But it's certainly a common one. I can think of at least a dozen sites that have heard this "requirement" from IBMers. I've always thought the proper solution to this was to add a badge reader to the HMC to allow IBMers to enable these ids only when they are physically present (and responsible for them).
> Each person who > accesses the HMC should be given their own ID. No sharing. Multiple > CEs? > Multiple IDs. Best Practice is to change all of the passwords to the > default user IDs or delete them. Kind of like when you install RACF, > the > instructions tell you to remove authority from IBMUSER and REVOKE it. And herein lies some of the resistance. Agreed, this is the Right and Proper Way. If I am to operate in this way, I need to engineer Yet Another identity management system (at best a plugin to an existing one, at worst an entire new system). There is not a single commercially available identity management system (including Tivoli products) that would know what a HMC is if it bit them in the rear. None of them understand any of the roles you describe, and none of the IT security weenies who run this stuff day to day have any grasp of this. It doesn't show up in their point-to-click-to-manage world -- you're dealing with people who think AD is the be-all, end-all, not RACF. After all, it's just a PC, right? (*snort*) -- doesn't work with *their* tool, doesn't happen. I concede the point that that will change over time, since this is more likely to impact z/OS sites and thus actually cause money to be spent, but you're moving too fast for the real world here. (I made this point in the design discussions about ensembles in Research; clearly I didn't have a big enough tantrum to crack the light of reality over this horizon). > Local password management? I'm not following you on this. My client > has > all 'normal' HMC IDs authenticated with the corporate directory server > (Active Directory). See above. AD integration for an HMC requires modifying the default AD schema to allow somewhere to store all those nifty new attributes, which is a one-way street. You can't go back. Windows admins (unless they are very very good) flee screaming from this, as it's an irrevocable step and it changes the support posture for a lot of other products, including some ones that have nothing to do with System Z (try calling Microsoft with a Exchange problem if you have a modified AD schema. You won't like it. Trust me.) > Leave the HMC behind the RSA gear. It's not like general users of the > operating systems are going to need HMC IDs. They may not need them, but setting up a separate provisioning process with all the attendant auditing, etc to manage them in a responsible way (let alone letting a non-human agent do anything to configurations without having exits for MY change management system (whatever that may be), as some of the ensemble code proposes to require in the near future) is pretty much a non-starter. Separation of powers, if nothing else -- if I can change the hardware configuration, I'm not allowed to change the user authorizations, and otherwise, WYSIWG wrt HMC management, and that doesn't include letting automation tinker with it. I guess the message we're trying to convey is that if this thing is to become the "management endpoint" for the System Z, a lot more thought needs to be put into deployment integration with other parts of the environment before people are going to be comfortable with the level of power that this thing has over the crown jewels. If it's treated as the control point, it's got to play nice with OUR control points. IBM can't revoke support for it when we install the stuff that makes it work for our businesses. The current message from IBM is a little too blue-centric for that to be realistic. -- db PS - jfrye: I *told* you so. dude. Nyah. 8-)
