• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content




oracle foreign key primary key constraints performance tuning MTS IOT 9i block size backup rman corrupted column drop rename recovery controlfile backup clone architecture database archives export ...

oracle foreign key primary key constraints performance tuning MTS IOT 9i block size backup rman corrupted column drop rename recovery controlfile backup clone architecture database archives export dump dmp duplicate rows extents segments fragmentation hot cold blobs migration tablespace locally managed redo undo new features rollback ora-1555 shrink free space user password link TNS tnsnames.ora listener java shutdown sequence



Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Userpasswrd Userpasswrd Document Transcript

    • Forcing Users to Change their Passwords Administration TipsForcing Users to change their passwordsIts good general security practice to force Users to change their passwords (although ifyoure too vigorous about it, youll soon discover that Users, unable to rememberconstantly changing passwords, start writing them down on scraps of paper -which is arather worse security outcome than simply doing nothing in the first place!).Until Oracle version 8.0, however, there was no automatic way of doing this. The best Ican think of for Oracle 7 is to run the following sort of query:SET HEAD OFF TERMOUT OFF VERIFY OFF FEEDBACK OFF ECHO OFF PAGESIZE 0SPOOL CHANGEPWD.SQLSELECT ALTER USER || USERNAME || PASSWORD EXPIRE; FROM DBA_USERSWHERE USERNAME<>SYS AND USERNAME <> SYSTEM;SPOOL OFF/That will produce a text file output (called, in this case, "changepwd.sql") containing thefollowing sort of output:SQL> SELECT ALTER USER || USERNAME || PASSWORD EXPIRE; FROM DBA_USERS 2 WHERE USERNAME<>SYS AND USERNAME <> SYSTEM;ALTER USER DBSNMP PASSWORD EXPIRE;ALTER USER HOWARD PASSWORD EXPIRE;ALTER USER OUTLN PASSWORD EXPIRE;ALTER USER SCOTT PASSWORD EXPIRE;SQL> SPOOL OFFYou need just to trim out the first few lines containing the actual select statement, andthe last line. Then you are left with a script which can be executed (in this case, it wouldbe done by typing @changepwd within SQL Plus), and which will have the effect ofexpiring the existing password for all Users apart from SYS or SYSTEM.Note that the fact the password has expired does not mean that Users will automaticallybe forced to change their password. All that happens is that the next time they attemptto log on using their old passwords, they will generate an error condition. The error stateis ORA-28001: the password has expired. Provided your application traps that error andresponds appropriately, theyll be able to change their passwords; otherwise theyll just beunable to connect. SQL Plus is capable of trapping the error automatically and promptingfor a new password; Server Manager is not.In Oracle 8.0 and above, things are much easier. The trick is to use resource profiles tolimit the lifetime of passwords, and specifically to use the password_life_time attribute ofprofiles.Every User starts off with a profile called DEFAULT, unless you explicitly assign them aprofile as part of the create user... command, or subsequently assign them one with thealter user... command. A quick way to enforce password limits would therefore be toissue the following:ALTER PROFILE DEFAULT LIMITCopyright © Howard Rogers 2001 10/18/2001 Page 1 of 3
    • Forcing Users to Change their Passwords Administration TipsPASSWORD_LIFE_TIME 30;That means that anyone using the default profile now has their password automaticallyexpired every 30 days. The change takes place immediately, and there is no need toswitch profiles on with the alter system set resource_limit=true command.If you want some people to have passwords expire every 30 days, and some after 60 days,then youll need to create named profiles to do the deed, and then assign the right profileto the right Users. For example:CREATE PROFILE HIGHSECURE LIMITPASSWORD_LIFE_TIME 30;CREATE PROFILE LOWSECURE LIMITPASSWORD_LIFE_TIME 60;ALTER USER FRED PROFILE HIGHSECURE;ALTER USER MARY LOWSECURE;Once again, be aware that all the profile does is to expire the password automatically.That simply puts the User into the ORA-28001 error state, and your application needs totrap that error and respond appropriately (by prompting for a password change) before theUser can log on again.Also note that profiles can contain all sorts of other limits for passwords which can helptighten security.For example, failed_login_attempts can be used to prevent an unlimited number ofattempts to connect, testing all sorts of possible passwords each time. You either manageto get it right within the specified number of attempts, or your account is locked out.Password_reuse_time can be used to stop a user changing a password into itself, byspecifying how many days must elapse between successive uses of the same password.If youd rather not have passwords reused at all, then password_reuse_max allows you tospecify a maximum number of times a password can be set as the account password. Set itto 1, and every password someone uses to connect must be unique.Finally, theres password_verify_function, which can be set to the name of a function youwrite yourself to perform password complexity checks (for example, the passwordminimum length, whether it must contains numbers as well as letters and so on). You canwrite your own function, and call it anything you like (though the function must be createdin the SYS schema), or you can take a look at the utlpwdmg.sql script in theORACLE_HOME/rdbms/admin directory, which is supplied by Oracle and (when run) createsa sample function for you called "verify_function". The sample script tests that passwordsare at least 4 characters long, contain at least one alphabetic character, one numericcharacter, and one special character (such as "$",%" or "!") -which strikes me as being justa tad too enthusiastic. It also checks that the password cannot be equal to the username(a good test to perform, I think), and that the new password must differ from the old oneby at least three characters (which, in my experience, almost guarantees that requests tochange a password fail for no obvious reason, and thus causes Users to start writing theirCopyright © Howard Rogers 2001 10/18/2001 Page 2 of 3
    • Forcing Users to Change their Passwords Administration Tipspasswords down in an attempt to make sure the requisite differences are present... andpasswords which are written down are NOT good passwords!).I suggest you use the utlpwdmg.sql script as an example of how to do the tests -but thenwrite your own that makes a bit more sense.If you utilise all these profile attributes, you might end up with something that looks likethis (Ive shown the units of measure for each one, in case theres any confusion):CREATE PROFILE SECURITY LIMITFAILED_LOGIN_ATTEMPTS 3 --[MEASURED IN NUMBER OF ATTEMPTS]PASSWORD_LIFE_TIME 30 --[MEASURED IN DAYS]PASSWORD_REUSE_TIME 30 --[MEASURED IN DAYS]PASSWORD_REUSE_MAX 3 --[MEASURED IN NUMBER OF REUSES]PASSWORD_VERIFY_FUNCTION MY_FUNCTION; --[NAME OF PASSWORD VERIFICATIONFUNCTION]This is not a complete listing of all possible password attributes for profiles, but it coversthe most important and useful ones.Just bear in mind that a User can only have one profile at a time, so if you want tocombine this sort of password-limiting functionality with resource-limiting functionality(such as restricting the number of sessions a User can have at a time), then both sorts ofprofile attribute needs to be set within the one profile.Copyright © Howard Rogers 2001 10/18/2001 Page 3 of 3