Re: SSH and LDAP/RACF
Florian Bilek writes: 2.) In principle the login via SSH is working very good. I encountered recently a kind of weakness in the configuration: A RACF user that uses its own RSA keys to log into the system. When I do a RACF revoke on that user, it seems that the LDAP check not takes place and the user can still login. What can be done about that? There's a section of the sshd(8) man page beginning: Regardless of the authentication type, the account is checked to ensure that it is accessible. An account is not accessible if it is locked, listed in DenyUsers or its group is listed in DenyGroups. The definition of a locked account is system dependant. Some platforms... and which then (as I try to ignore the misspelling of dependent) gives O/S-specific ways that it checks for locked accounts, usually by special contents of a directly-accessed shadow password field such as *LK, Nologin, !. From that, I'd guess that sshd may not invoke PAM in a way that would let you use pam_ldap to do the appropriate lookup via LDAP. What about, as a workaround, creating a RACF group named NOLOGIN, connecting revoked users to that group (an extra step, but that's why I called it a workaround not a proper solution) and then putting DenyGroups nologin in your sshd_config? If z/VM LDAP doesn't special case group membership lookups for revoked users then I think that may work. --Malcolm -- Malcolm Beattie Mainframe Systems and Software Business, Europe IBM UK -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: STP
On Saturday, 07/21/2012 at 03:39 EDT, Rob van der Heij rvdh...@gmail.com wrote: Ever since my presentation in 2005, I find customers who were told by their friendly IBMer not to get STP/ETR on the machine because it's not supported by z/VM The STP/ETR feature is a priced feature that is best negotiated into the deal early rather than acquired separately later. When the LPAR TOD is kept in synch with the world, by pure magic CP, CMS as well as Linux guests will see accurate time. There is no need for ntpd in Linux (in fact, doing that will make things worse). The only disruptive time shift would be when you POR with the feature on. Since the LPAR also picks up the actual time at activation, there should not be a jump. And STP/ETR will nicely speed up TOD increments to make it match real time. Except when the leap second meets a software bug and takes the system down :-) While one can get this information from the published IBM Redbooks on STP and the Principles of Operations, I will summarize the best I can. Warning: My terminology is sloppy in the interests of understandability. - If you have STP enabled and configured, TOD clock steering will occur. It doesn't matter if the OS supports STP or not. - On modern machines, STP steers the TOD at a rate of approximately 1 second in 7 hours (ETR takes 11 hours). - That means it will take about 7 hours for QUERY TIME to match the external time source after a leap second has been added. - Good news, that means QUERY TIME will be correct when you come in a 8am (leap seconds are added at 11:59:60). - If your Linux guests can't live within that tolerance, then you need to consider ntp for Linux. - When the difference between the LPAR TOD and the time source is +/- 50 ยต s (model dependent), an STP-sync-check interrupt is raised. - When I/O timestamps are being used, CP uses the STP-sync-check interrupt to re-calculate the correct time adjustments to apply to the TOD used in the I/O. - The oscillators are extremely stable, so it doesn't take much pull on the wheel for STP to steer out the drift, as it were. Alan Altmark Senior Managing z/VM and Linux Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SSH and LDAP/RACF
On 7/21/12 3:39 PM, Florian Bilek wrote: 2.) In principle the login via SSH is working very good. I encountered recently a kind of weakness in the configuration: A RACF user that uses its own RSA keys to log into the system. When I do a RACF revoke on that user, it seems that the LDAP check not takes place and the user can still login. What can be done about that? Ssh apparently bypasses the pam auth step if it has a ssh key match. Perhaps experiment by adding a pam account or pam session step which refers to pam_ldap? I'm unclear if the pam_ldap module supports these steps, though, the documentation is unclear. One other useful pam module which may apply here is pam_access. Pam_access does explicitly support the account and session module types, and it's quite flexible. You might be able to craft an e.g. denied_users group which would deny access to any member of that group. One final thought, I seem to recall there's patches flying around which allow ssh public keys to be stored in LDAP. Perhaps investigate this idea. If pubkeys could only be in a user's LDAP entry, then as part of a revoke process, these keys could be removed. Google ssh public key ldap Hope that helps, -- Pat -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
