Changing Exadata Cell access parameters

One challenge is with Exadata cells in a lab environment is that they are secure! This means that it has long lock out times in the event of an incorrect login and tough lock settings. You can manually change these.. but every time you update your cell there is a chance they will be reset.

A more permanent way is to use /opt/oracle.cellos/host_access_control on each storage cell. https://docs.oracle.com/cd/E58626_01/html/E58630/z40036a01393423.html#scrolltoc

For example, if you want to drop the lock time in the event of a failed login from 10 minutes to a more manageable 60 seconds  you would issue the command

/opt/oracle.cellos/host_access_control pam-auth --lock=60

You can combine multiple pam-auth commands on the same line.. e.g. if I also want to say that the cell only remembers one previous password I could say

/opt/oracle.cellos/host_access_control pam-auth --lock=60 --remember=1

 

There are a lot of options for this tool – you can set the system back to secure defaults, or make it even more secure, such as locking an account after a single failed login!

Logins, Pam and sorting it out..

A colleague reported a problem with a server.. when he tried to ssh as the user Oracle to one server it constantly failed with :-

oracle@ed2qcomp05's password:
Permission denied, please try again.

He could su to oracle as root, he could ssh as oracle from another server with user equivalency, so was confident that the home directory was intact.

When we looked in the /var/log/secure we saw the following message:

Nov  7 12:23:20 ed2qcomp05 sshd[27305]: pam_tally2(sshd:auth): user oracle (1000) tally 49, deny 5
Nov  7 12:23:21 ed2qcomp05 sshd[27305]: Failed password for oracle from 10.130.3.216 port 39519 ssh2

In /etc/pam.d/sshd it was configured to deny access after 5 attempts

auth       required     pam_tally2.so deny=5 onerr=fail

So, it looked like pam had locked out the oracle user due to multiple failed login attempts. At this point on a production system you should start to investigate who has been trying to access your system, however,we knew what had caused the problem.

First check  how many failed logins pam had counted for that user.

[root@ed2qcomp05 pam.d]# pam_tally2 --user oracle
Login           Failures Latest failure     From
oracle             49    11/07/11 12:23:20  c1718-3-216-mgt.ssclabs.net

Then you reset the ‘tally’ for oracle

[root@ed2qcomp05 pam.d]# pam_tally2 --user oracle --reset
Login           Failures Latest failure     From
oracle             49    11/07/11 12:23:20  c1718-3-216-mgt.ssclabs.net

Verify that it has been reset

[root@ed2qcomp05 pam.d]# pam_tally2 --user oracle
Login           Failures Latest failure     From
oracle              0

And now the Oracle user can log in to the system