Hi Folks, I thought I'd share this one with you, quite possibly the ODDEST thing I've seen in VM in over 25 years! In order to satisfy security mandates, we are in the process of changing ALL virtual machines that are not "owned" by individual humans to be LBYONLY (i.e. they won't have unique passwords of their own that they can authenticate with, they can ONLY be logged on by authorized users using LOGONBY). I prefer LBYONLY to AUTOONLY, in case a service virtual machine starts misbehaving we can actually log on to it using LOGONBY to see what's going on (which you can't do if the virtual machine password is AUTOONLY). We have a bunch of users that are DB2 for VM Stored Procedure servers. They get autologged and run some DB2 code that allows work to be offloaded onto them. When we changed their passwords to be LBYONLY the process stopped working. Nobody seemed to know HOW these servers actually get autologged, so I dug through some system logs from prior to the change and found this: AUTO LOGON *** SQLP0001 USERS = 101 BY SQLP0001
Is that the darnedest thing you ever saw?!?!? How can a virtual machine which is NOT logged on execute AUTOLOG, and if it IS logged on and can execute AUTOLOG, then it cannot be AUTOLOGged! This started the whole "chicken and egg" analysis of course, and we were forced to make these very unusual servers AUTOONLY (with many comments documenting this oddity in their VM:Secure server profile!). PS: There is one other group of users that cannot use LBYONLY or AUTOONLY, if a server (that normally runs disconnected) is the subject of FTP operations, the FTP login authentication will fail with either LBYONLY or AUTOONLY as the password. If someone knows of a clever way around this, I'd love to hear it ..... :) -Mike
