> I will try to find out where this is coming from and see if there are > some > adjustments that can be made. I note that the checklist in 4.6.5 of > the > SAPR Guide only says > Requirements for passwords and userids > for the Hardware Management Console > and Support Element of the 2817 Server > have been determined.
Simple suggestion: ship the default ids defined, but disabled after one use (where you create a customer specific id with admin privs -- SELinux is capable of this level of access management w/o a lot of special coding). Provide a customer procedure executable from an authorized id to enable the IBM standard ids for a defined period (number of hours) and schedule a task to fire after the defined period to disable them again. DEC/HP does this for the predefined FIELD id on VMS, and it's worked pretty well over time. @SYS$MANAGER:FIELD ENABLE /HOURS=nn. Enables the FIELD id and produces a new password valid for nn hours which you give to the CE. After nn hours, the id is automatically disabled again. It's a nice compromise between a known set of ids and passwords, and a secure environment. Could also be done via the RSF link to IBM -- in most cases, the reason the CE is there is because of the phone-home link, and would provide a good audit trail. > This isn't a z-specific issue. Further, Microsoft says that AD > Lightweight Directory Service (AD LDS) can be used in such a way that > it > isn't necessary to extend the AD schema. > http://www.microsoft.com/windowsserver2008/en/us/ad-main.aspx > > Not being an AD admin, I can admit that the subtleties escape me. LDS bypasses some of the AD auditing process by using a privileged proxy id to bind to the directory (thus masking the actual query source), so many sites do not allow its use. But, you're right, it's not just about Z. It's just more visible in that the risk is substantially higher than your random PC server -- this is where the paychecks get printed. > Stay your sword, good man! The good news is that the z196 introduced a > way for you to do that. It is no longer required to pre-define HMC > users > to the HMC. > > 1. Create one or more "User Templates". These are "model" user IDs > that > can be associated with an HMC user for whom no User Profile exists. > Except > for the fact you can't use them for authentication purposes, they are > conceptually the same as user profiles. > > 2. Create one or more "User Patterns". This is a pattern that, when > matched against a login ID (for example, u...@company.com) for which no > user profile exists, identifies how to decide if the user can log in > and, > if so, what user template should be associated with them. > > Hopefully that will take a big bite out of the problem. Better, but then the problem becomes to provably associate a user with an action on a consistent basis. If the user is dynamically bound at execution time to a profile, then there is no way to provably assert that the same actions would take place if the same user attempts the same action a second time w/o change control on the profiles, which leads us back to the original problem -- no integration with existing tools to do that proof in an auditable way. A certain amount of this is individual risk tolerance and how trainable your auditors are to understand what is really going on, but on the ground at the moment, most of them DON'T get it yet. It'd be really useful if there was a required professional certification for IT auditors where they had to update their skills periodically to stay certified (hmm.... I'll patent that). Unfortunately, not yet. -- db
