Forum Stats

  • 3,873,737 Users
  • 2,266,635 Discussions


Enhanced User Password Management (International CAB)

Tmicheli-Oracle Member Posts: 24 Red Ribbon
edited Jan 11, 2016 6:18PM in Database Ideas - Ideas

Coordinating an application account’s database password change with the configuration changes across multiple application servers (Weblogic, Tuxedo, etc.) is a challenging task. The consequence of an unexpected event during the process can result in service disruption.

This enhancement is to allow a period of overlap where both the old and new passwords will be accepted for authentication on the database for a user/schema’s connections. Supporting views would allow the DBA to ensure that no sessions are connecting with the old password before it is disabled.

Geeky NerdmanUser259623 -OracleDer Babovinaykumar2user10212775Manish ChaturvediPravin TakpireBrian BakulaArpit Jain -OracleJagadekarabhagatsinghZlatko SiroticSven W.berx
16 votes

Active · Last Updated


  • Pravin Takpire
    Pravin Takpire Technical Services Manager Member Posts: 1,763 Gold Trophy

    In Oracle Applications there is FNDCPASS utility which takes care of changing password for application/db users specifically APPS user. I think this type of utility should be there in other applications also where one change in password has to be propagated to many places.



  • Tmicheli-Oracle
    Tmicheli-Oracle Member Posts: 24 Red Ribbon

    We, Oracle are working on our internal process as to how to evaluate and prioritize the IDEAS submitted.  But the more votes obviously the more priority we will put on the request.  However votes/popularity alone will not determine the priority.

    As we move through the process the IDEA will change stages: (not in flow order)

    - Active

    - Already Offered

    - Archived

    - Coming Soon

    - For Future Consideration

    - in Progress

    - Partially Implemented

    - Under Review

  • abhinivesh.jain
    abhinivesh.jain Member Posts: 307 Blue Ribbon

    Have 2 passwords working at the same time is something that is not very common so why do we want to do this in oracle?

  • Gerald Venzl-Oracle
    Gerald Venzl-Oracle Member, Moderator Posts: 85 Employee

    Thanks for your contribution!

    I am not sure how this would solve the problem. Even if there is an overlap where both passwords would work for a period of time, how would that guarantee that somebody is actively changing that password in the application before the old one expires?

    This sounds much more an issue of bad design. Every application should have its own (set of) user(s) with which it connects to the database. That user has the appropriate grants to the actual schema(s) required. Therefore it is also guaranteed that a single application can be easily locked out in the event of a breach. For example, if you have 10 different applications working all against the same schema, a breach in one application would compromise all of the other applications because they all now have to change their password too. The interruption caused by such an scenario would be much higher.

  • Sven W.
    Sven W. Member Posts: 10,559 Gold Crown

    "Supporting views would allow the DBA to ensure that no sessions are connecting with the old password before it is disabled."

    Does this mean, that for some grace period session that still connect with the old password can be monitored to find out who it is and inform those people / apps about the new password?

    That's an excellent idea!

  • Gerald Venzl-Oracle
    Gerald Venzl-Oracle Member, Moderator Posts: 85 Employee

    After some research I can confirm that Oracle does already provide this via user profiles. Profiles have a couple of password parameters, the two interesting ones for this idea being:

    PASSWORD_GRACE_TIME:  Specify the number of days after the grace period begins during which a warning is issued and login is allowed. If you omit this clause, then the default is 7 days.

    PASSWORD_LIFE_TIME:  Specify the number of days the same password can be used for authentication. If you also set a value for PASSWORD_GRACE_TIME, then the password expires if it is not changed within the grace period, and further connections are rejected. If you omit this clause, then the default is 180 days.

    The information of whether or when a password is expiring is also already available in DBA_USERS:




    Account status:

    • OPEN
    • LOCKED



    Date of expiration of the account