Q: Can PRM be done at the Global Zone Level, like a web user given permission to log in and run /start processes on two zones that host different web sites? A: Each zone is an independent administrative domain; a user will need to know account information in order to log in to a zone. Q: I am using the Solaris 9 and 8 Operating System, doing a password change for a user as root: # passwd john New Password: Re-enter new Password: passwd: password successfully changed for john # I am just pressing the Enter key instead of typing any characters or numbers. The system accepts the Enter key as the user's password, and I am able to log in using the Enter key as the password.
I have this entry in the PASSLENGTH=8 What is the problem? How do I prevent a system from accepting the Enter key as a password? A: The Superuser has permission to set any password he wants for any account. The restrictions apply only to ordinary users. Q: Is there any way to give elevated privileges to ordinary user accounts? Or do they still have to su into an RBAC profile account? For example, what if I have a user named "test" that I want to be able to change passwords and add new users? A: In principle, yes; however, the particular operations you describe are not covered by simple process privileges as they are fairly complicated operations with full access to a limited set of files. It is possible to give such rights to ordinary users by awarding them profiles and a profile shell directly; it is not necessary to make their accounts into roles. Q: One of the things we are interested in doing is preventing service account users (i.e. Oracle) from logging in directly as that service account. We would much rather have users log in with a standard user account and then 'su' to the Oracle account. Does the new PRM system allow one to prevent an account's direct login? A: This has already been possible with RBAC since the Solaris 8 OS. You create the user as "role" and make sure that the pam_roles.so module is in the stack. |
 | |||||
 | |
