Hi Malcom, I will give this work around a try. But the idea was that a simple CMS 'rac alu userid' revoke would deny access of a user to all systems.
With the workaround I need again a sort of exec that connects/disconnects the user to a NOLOG group. Or I need to disable the whole feature with the RSA keys which is also quite painful when you have to maintain a lot of LINUX guests. Maybe I find another way to configure the PAM properly. BTW: I find it a pity that there is no easy way to use the OVM segment of the RACF user profile to save the default shell, uid and gid etc. It is required to mess around with the posixAccount objectclass which is not even part of the official delivery of the IBM/Tivoli LDAP server and requires schema modifications etc. It works but it requires a lot of work to make that work. Seems there is a lot of "room for improvements". ;-) BR Florian On Mon, Jul 23, 2012 at 11:25 AM, Malcolm Beattie <[email protected]>wrote: > 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 [email protected] 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/ > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] 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/
