> I'd like to see all but one delivered userid be NOLOG, AUTOONLY, or > LBYONLY and a LOGONBY statement in the directory PROFILE(s) of the LOGONBY > users. The LOGONBY statement(s) would all list the single userid (eg.
> INSTALL) deliverd with a password. That INSTALL userid should get deleted > sometime during the installation process and replaced with customer > defined userids. Since it's only purpose is to allow logging on to the > LOGONBY userids, the INSTALL userid needs no MDISKS and only the absolute > bare minimum of statements required to define a userid. > > The customer can update the LOGONBYs and PROFILEs as needed to fit their > requirements. Showing an auditor that the INSTALL userid and references > to it have been deleted should go a long way. That's a very elegant solution, Brian. Easy to implement, too, and wouldn't break things for people w/o a directory manager or ESM. Wrt to "why change", the usage of VM has changed. Experienced VMers would make these kinds of changes by habit, but the new shops don't *have* experienced VMers. If your shop is CMS-intensive, you've already got skills. That's not what VM is being used for any longer, and IMHO, it's irresponsible to deliver a system with known holes in it to someone who may not have the experience to fix it. The Unix world has recognized this fact; we should do the same. If you do still have lots of CMS workload, the proposed change is not going to interfere with your life much, as you'll fix it (or your directory manager will) when you merge the new entries into your existing directory. It's a lot safer for total newbies, and it's one less argument to have with the security wonks and other detractors. Interesting that this topic came up in a conversation with a new customer this afternoon. Direct quote from the conference call: "it ships with passwords the same as the userid. That's really insecure -- how do we trust the security of the rest of the system if the manufacturer ships it in such a sad state?" Good question. -- db
