Setting value to PASSWORD_VERIFY_FUNCTION in a profile

Question

Hi,
i am currently using the script utlpwdmg.sql, located in ORACLE_HOME/rdbms/admin, provided by oracle Typical Installation.
This script will create a function called VERIFY_FUNCTION, which is basically for assigning to the parameter PASSWORD_VERIFY_FUNCTION in CREATE PROFILE or ALTER PROFILE statements.
My problem is: (I have done the steps as listed follows)
1. without PASSWORD_VERIFY_FUNCTION set (ie. set to null, which appear in DBA_PROFILES as UNLIMITED), both user SYSTEM and user A can alter password for user A (that is true, as i know user can change password without the need of ALTER USER system privilege granted)
2. with PASSWORD_VERIFY_FUNCTION set (ie. assign VERIFY_FUNCTION to the PASSWORD_VERIFY_FUNCTION in CREATE PROFILE or ALTER PROFILE statements), only user SYSTEM can change password for user A, while user A cannot change for himself anymore.
3. since utlpwdmg.sql is "start"ed using SYS login (as the comment of the script required), the VERIFY_FUNCTION (name of the function), it appears in USER_OBJECTS view when i am logging in as SYS (and this is reasonable). Thus i try grant EXECUTE privilege on this VERIFY_FUNCTION to my user A. But user A's alter statement still return error (something as if the complexity of the new password does not match that required)
4. So i check the complexity by loggining in as SYSTEM. As the new password is rejected, i reuse it and try changing password (using this new password) for user A, using the same new password as step 3, it returns no error and "user alterd".
5. So now, i am very confused. It seems the function created in SYS schema would result in no one can use it, even i have granted the object privilege. Only SYSTEM can change password. When i set the PASSWORD_VERIFY_FUNCTION back to null again, both user (SYSTEM and user A) can change password for user A again.
What could possibly be wrong in this case ? (i have eliminated certain doubts)
point a: As user SYSTEM can utilize this function to check password complexity, I do not doubt if the content of the function has anything wrong, as long as i am using exactly the same ALTER USER statement, same password in SYSTEM's session and user A's session.
point b: As user SYSTEM can change the password for user A using the rejected new password (when statement is executed using user A's login), i do not doubt it is really the problem of the new password not meeting the requirement of the VERIFY_FUNCTION.
point c: As user A has been granted by SYS with the EXECUTE privilege on that function, I think the user, at least, has no difficulty in executing the function, though user A does not execute the function directly (recall that it is the ALTER USER [for changing password] statement that will make use of this function)
So, do you have any idea on what could be wrong?
-anita.

Answer 1

thanks for the reply.
isum is a number.
When i am using alter user xyz identified by abcd;
i should get 1 in isum but i am getting 0 in isum.
abcd is a value in common_passwords table.