More fun with Grid Control and EBS

Last week, I was asked to investigate a problem with some E-Business Suite instances being monitored by Grid Control.  Apps tier targets across three different instances were reporting an "Unknown" status. After confirming that the services themselves were actually functioning correctly, I checked the Grid Control monitoring agents, and discovered a slew of metric collection errors with the message "ORA-28001: The password has expired":

ORA-28001 metric collection error

My first thought: WTF?*

My next thought: "Oh, right, the Grid Control uses the em_monitor schema to monitor E-Business Suite components. Maybe something's wrong with that account."

A quick look at the DBA_USERS table revealed that the password for EM_MONITOR had indeed expired, and apparently not due to repeated login failure:

SQL> select account_status, lock_date, expiry_date
2 from dba_users
3 where username = 'EM_MONITOR';

ACCOUNT_STATUS                   LOCK_DATE       EXPIRY_DATE 
-------------------------------- --------------- ---------------
EXPIRED                                          25-FEB-09

The password expiration dates across all three instances weren't all the same, but they were clustered pretty close together. This made me suspect an automatic expiration that would correspond to my initial monitoring configuration a few months ago. Sure enough, after resetting the password to get metric collections going again, a new expiration date was set on the account:

SQL> alter user EM_MONITOR identified by hey_look_new_password_whee!!!;
User altered.

SQL> select account_status, expiry_date
2 from dba_users
3 where username = 'EM_MONITOR';

ACCOUNT_STATUS                   EXPIRY_DATE
-------------------------------- ---------------
OPEN                             18-MAY-09

There we have it. A future expiration date is definitely being set automatically; this is not the result of another administrator's intervention. I happen to know that this is not the default configuration for this test system, so it's time to check for a non-default profile.

SQL> select profile from dba_users where username = 'EM_MONITOR';

PROFILE
------------------------------
EM_OAM_MONITOR_PROFILE

SQL> select resource_name, resource_type, limit
2 from dba_profiles
3 where profile='EM_OAM_MONITOR_PROFILE'
4 and limit <> 'DEFAULT';

RESOURCE_NAME                  RESOURCE LIMIT
------------------------------ -------- -----------------------------------
FAILED_LOGIN_ATTEMPTS          PASSWORD 3
PASSWORD_LIFE_TIME             PASSWORD 60
PASSWORD_LOCK_TIME             PASSWORD .0416
PASSWORD_GRACE_TIME            PASSWORD 10

Ta-dah! 60-day password expiration, as expected. No doubt this was set up by the Applications Management Pack patch that created the em_monitor schema in the first place.

With all of that out of the way, the question becomes: what to do about this? Even if the password expiration is a good standard procedure, practically speaking it's not very convenient to have to change/reset the password for an internal account like this every two months. As with every "security-vs-operational-complexity" tug-of-war, it all comes down to your organization's tolerance for such things.

Should you decide to to disable the 60-day expiration limit, with the blessing of your management and/or network security czars, here's the command:

alter profile EM_OAM_MONITOR_PROFILE limit password_life_time unlimited;
*Where's The Failure? ...why, what did you think I meant?

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*