Lock out of Oracle based on Windows usernameschema shows through standard client connection but not through ODBC connection?Oracle out-of-place upgrade on same host: impdp issuesOracle - Need help with RMAN Active Duplication on Windows 32 bit to a 64 bitGlobal locking for multi-master Oracle GoldenGate replicationOracle alternative edition for Windows Server 2012Oracle connection suddenly refused on windows 8Why doesn't “As SYSDBA” work from SQL Developer?ORA-01017 connecting to example schemas on Oracle VM appliance from Windows hostProblems with connecting to a remote Oracle 12c databaseOracle DBLink with username and password

Can the Gate spell draw a creature larger that 20 feet in every dimension through the portal it creates?

What do you call bracelets you wear around the legs?

Was Tyrion always a poor strategist?

Gambler's Fallacy Dice

What's is the easiest way to purchase a stock and hold it

Why does string strummed with finger sound different from the one strummed with pick?

Why wear sunglasses in indoor velodromes?

How many Dothraki are left as of Game of Thrones S8E5?

Should I twist DC power and ground wires from a power supply?

Why didn't Daenerys' advisers suggest assassinating Cersei?

Why does a table with a defined constant in its index compute 10X slower?

Failing students when it might cause them economic ruin

Parse a C++14 integer literal

Why is choosing a suitable thermodynamic potential important?

Why use a retrograde orbit?

Can 2 light bulbs of 120V in series be used on 230V AC?

Bookshelves: the intruder

Can the word crowd refer to just 10 people?

Why are stats in Angband written as 18/** instead of 19, 20...?

Good examples of "two is easy, three is hard" in computational sciences

What technology would Dwarves need to forge titanium?

pwaS eht tirsf dna tasl setterl fo hace dorw

Lock out of Oracle based on Windows username

How would fantasy dwarves exist, realistically?



Lock out of Oracle based on Windows username


schema shows through standard client connection but not through ODBC connection?Oracle out-of-place upgrade on same host: impdp issuesOracle - Need help with RMAN Active Duplication on Windows 32 bit to a 64 bitGlobal locking for multi-master Oracle GoldenGate replicationOracle alternative edition for Windows Server 2012Oracle connection suddenly refused on windows 8Why doesn't “As SYSDBA” work from SQL Developer?ORA-01017 connecting to example schemas on Oracle VM appliance from Windows hostProblems with connecting to a remote Oracle 12c databaseOracle DBLink with username and password






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








1















I have this logon trigger to only allow certain users to log in to an Oracle database (even if they have the correct password to enter the database):



CREATE OR REPLACE TRIGGER SYS.LOGON_TRIGGER
AFTER LOGON ON DATABASE
DECLARE
THIS_USER VARCHAR2(50);
BEGIN
SELECT OSUSER INTO THIS_USER FROM V$SESSION WHERE SID = SYS_CONTEXT('USERENV','SID');
IF THIS_USER NOT IN (<List of Users>)
THEN RAISE LOGIN_DENIED;
ENDIF;
END;
/


It works for preventing users from entering most schemas but not all (e.g. the SYS or SYSTEM schemas can still be entered regardless of the user - this logon trigger is seemingly completely bypassed).



Is there a way to lock out these users even for these SYS type schemas?




A bit of context:



Due to decisions made way before I got involved with this, all of the logins for this database have the same password. Additionally, most users use the same login as many of our processes that read/write to this database automatically.



We don't want to simply change the passwords because it would be a very large effort to see what impact changing these passwords actually does to the system. (We would have to modify the code that the processes use to access the database, and there are many of these.) An easier solution for us is to just lock out based on usernames, if possible.










share|improve this question

















  • 1





    A trigger is not going to change the security nightmare that "all of the logins for this database have the same password" is.

    – kevinsky
    5 hours ago











  • @kevinsky In that case, it probably is better to just change the passwords and deal with the impacts. I guess the easiest solution isn't always the best.

    – ImaginaryHuman072889
    5 hours ago











  • BTW: the osuser is (if you don’t use Kerberos or Similiar methods) only advisory (the driver can send any name it likes) so it is really not a good security mechanism and having strictly separate passwords is the way to go.

    – eckes
    2 hours ago

















1















I have this logon trigger to only allow certain users to log in to an Oracle database (even if they have the correct password to enter the database):



CREATE OR REPLACE TRIGGER SYS.LOGON_TRIGGER
AFTER LOGON ON DATABASE
DECLARE
THIS_USER VARCHAR2(50);
BEGIN
SELECT OSUSER INTO THIS_USER FROM V$SESSION WHERE SID = SYS_CONTEXT('USERENV','SID');
IF THIS_USER NOT IN (<List of Users>)
THEN RAISE LOGIN_DENIED;
ENDIF;
END;
/


It works for preventing users from entering most schemas but not all (e.g. the SYS or SYSTEM schemas can still be entered regardless of the user - this logon trigger is seemingly completely bypassed).



Is there a way to lock out these users even for these SYS type schemas?




A bit of context:



Due to decisions made way before I got involved with this, all of the logins for this database have the same password. Additionally, most users use the same login as many of our processes that read/write to this database automatically.



We don't want to simply change the passwords because it would be a very large effort to see what impact changing these passwords actually does to the system. (We would have to modify the code that the processes use to access the database, and there are many of these.) An easier solution for us is to just lock out based on usernames, if possible.










share|improve this question

















  • 1





    A trigger is not going to change the security nightmare that "all of the logins for this database have the same password" is.

    – kevinsky
    5 hours ago











  • @kevinsky In that case, it probably is better to just change the passwords and deal with the impacts. I guess the easiest solution isn't always the best.

    – ImaginaryHuman072889
    5 hours ago











  • BTW: the osuser is (if you don’t use Kerberos or Similiar methods) only advisory (the driver can send any name it likes) so it is really not a good security mechanism and having strictly separate passwords is the way to go.

    – eckes
    2 hours ago













1












1








1








I have this logon trigger to only allow certain users to log in to an Oracle database (even if they have the correct password to enter the database):



CREATE OR REPLACE TRIGGER SYS.LOGON_TRIGGER
AFTER LOGON ON DATABASE
DECLARE
THIS_USER VARCHAR2(50);
BEGIN
SELECT OSUSER INTO THIS_USER FROM V$SESSION WHERE SID = SYS_CONTEXT('USERENV','SID');
IF THIS_USER NOT IN (<List of Users>)
THEN RAISE LOGIN_DENIED;
ENDIF;
END;
/


It works for preventing users from entering most schemas but not all (e.g. the SYS or SYSTEM schemas can still be entered regardless of the user - this logon trigger is seemingly completely bypassed).



Is there a way to lock out these users even for these SYS type schemas?




A bit of context:



Due to decisions made way before I got involved with this, all of the logins for this database have the same password. Additionally, most users use the same login as many of our processes that read/write to this database automatically.



We don't want to simply change the passwords because it would be a very large effort to see what impact changing these passwords actually does to the system. (We would have to modify the code that the processes use to access the database, and there are many of these.) An easier solution for us is to just lock out based on usernames, if possible.










share|improve this question














I have this logon trigger to only allow certain users to log in to an Oracle database (even if they have the correct password to enter the database):



CREATE OR REPLACE TRIGGER SYS.LOGON_TRIGGER
AFTER LOGON ON DATABASE
DECLARE
THIS_USER VARCHAR2(50);
BEGIN
SELECT OSUSER INTO THIS_USER FROM V$SESSION WHERE SID = SYS_CONTEXT('USERENV','SID');
IF THIS_USER NOT IN (<List of Users>)
THEN RAISE LOGIN_DENIED;
ENDIF;
END;
/


It works for preventing users from entering most schemas but not all (e.g. the SYS or SYSTEM schemas can still be entered regardless of the user - this logon trigger is seemingly completely bypassed).



Is there a way to lock out these users even for these SYS type schemas?




A bit of context:



Due to decisions made way before I got involved with this, all of the logins for this database have the same password. Additionally, most users use the same login as many of our processes that read/write to this database automatically.



We don't want to simply change the passwords because it would be a very large effort to see what impact changing these passwords actually does to the system. (We would have to modify the code that the processes use to access the database, and there are many of these.) An easier solution for us is to just lock out based on usernames, if possible.







oracle oracle-11g






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked 5 hours ago









ImaginaryHuman072889ImaginaryHuman072889

1155




1155







  • 1





    A trigger is not going to change the security nightmare that "all of the logins for this database have the same password" is.

    – kevinsky
    5 hours ago











  • @kevinsky In that case, it probably is better to just change the passwords and deal with the impacts. I guess the easiest solution isn't always the best.

    – ImaginaryHuman072889
    5 hours ago











  • BTW: the osuser is (if you don’t use Kerberos or Similiar methods) only advisory (the driver can send any name it likes) so it is really not a good security mechanism and having strictly separate passwords is the way to go.

    – eckes
    2 hours ago












  • 1





    A trigger is not going to change the security nightmare that "all of the logins for this database have the same password" is.

    – kevinsky
    5 hours ago











  • @kevinsky In that case, it probably is better to just change the passwords and deal with the impacts. I guess the easiest solution isn't always the best.

    – ImaginaryHuman072889
    5 hours ago











  • BTW: the osuser is (if you don’t use Kerberos or Similiar methods) only advisory (the driver can send any name it likes) so it is really not a good security mechanism and having strictly separate passwords is the way to go.

    – eckes
    2 hours ago







1




1





A trigger is not going to change the security nightmare that "all of the logins for this database have the same password" is.

– kevinsky
5 hours ago





A trigger is not going to change the security nightmare that "all of the logins for this database have the same password" is.

– kevinsky
5 hours ago













@kevinsky In that case, it probably is better to just change the passwords and deal with the impacts. I guess the easiest solution isn't always the best.

– ImaginaryHuman072889
5 hours ago





@kevinsky In that case, it probably is better to just change the passwords and deal with the impacts. I guess the easiest solution isn't always the best.

– ImaginaryHuman072889
5 hours ago













BTW: the osuser is (if you don’t use Kerberos or Similiar methods) only advisory (the driver can send any name it likes) so it is really not a good security mechanism and having strictly separate passwords is the way to go.

– eckes
2 hours ago





BTW: the osuser is (if you don’t use Kerberos or Similiar methods) only advisory (the driver can send any name it likes) so it is really not a good security mechanism and having strictly separate passwords is the way to go.

– eckes
2 hours ago










2 Answers
2






active

oldest

votes


















2














I suggest a multi-phase approach that can be implemented in stages and will minimize the impact of changing to a more secure approach. I assume that you have a development environment to test in and the support of a manager who is interested and will support the effort.



  • use the existing Oracle audit logging to start logging when users logon and logoff.

  • after a period of time consistent with usage (90 days for a fiscal quarter?, a year end?) identify the unused accounts and lock them

  • identify any service accounts that are not used by people to log on.

  • identify the remaining accounts and try to link usernames to people to job roles

  • create Oracle profiles for service accounts, read only accounts and more privileged user accounts

    • set password expiration, complexity, reuse, failed attempts before lockout for these profiles. For example you may decide that service accounts should never change their password but that it should be 24 characters and only one failed attempt before lockout whereas a person's password should only be 8 characters with three failed attempts before lockout.

    • one by one reassign accounts to the correct profile and force a password change


  • at the same time look at creating roles that grant only enough privileges for accounts to do their job and assign the roles.

This is just the tip of the iceberg for securing the database. The level of effort you put in should be commensurate with the potential damage if the information in the database were breached.






share|improve this answer























  • You bring up many good points here. We do have a test environment and yes my manager will support this. Thanks again.

    – ImaginaryHuman072889
    3 hours ago


















1














The reason why your trigger does not work for users like SYS or SYSTEM is because they have the ADMINISTER DATABASE TRIGGER privilege.



The ADMINISTER DATABASE TRIGGER privilege allows you to create database-level triggers (server error, login, and logout triggers). It also allows you to log in regardless of errors thrown by a login trigger as a failsafe.



So, the answer is: no, you cannot prevent login for such users - at least not with a login trigger.






share|improve this answer























    Your Answer








    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "182"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













    draft saved

    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f238350%2flock-out-of-oracle-based-on-windows-username%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    2














    I suggest a multi-phase approach that can be implemented in stages and will minimize the impact of changing to a more secure approach. I assume that you have a development environment to test in and the support of a manager who is interested and will support the effort.



    • use the existing Oracle audit logging to start logging when users logon and logoff.

    • after a period of time consistent with usage (90 days for a fiscal quarter?, a year end?) identify the unused accounts and lock them

    • identify any service accounts that are not used by people to log on.

    • identify the remaining accounts and try to link usernames to people to job roles

    • create Oracle profiles for service accounts, read only accounts and more privileged user accounts

      • set password expiration, complexity, reuse, failed attempts before lockout for these profiles. For example you may decide that service accounts should never change their password but that it should be 24 characters and only one failed attempt before lockout whereas a person's password should only be 8 characters with three failed attempts before lockout.

      • one by one reassign accounts to the correct profile and force a password change


    • at the same time look at creating roles that grant only enough privileges for accounts to do their job and assign the roles.

    This is just the tip of the iceberg for securing the database. The level of effort you put in should be commensurate with the potential damage if the information in the database were breached.






    share|improve this answer























    • You bring up many good points here. We do have a test environment and yes my manager will support this. Thanks again.

      – ImaginaryHuman072889
      3 hours ago















    2














    I suggest a multi-phase approach that can be implemented in stages and will minimize the impact of changing to a more secure approach. I assume that you have a development environment to test in and the support of a manager who is interested and will support the effort.



    • use the existing Oracle audit logging to start logging when users logon and logoff.

    • after a period of time consistent with usage (90 days for a fiscal quarter?, a year end?) identify the unused accounts and lock them

    • identify any service accounts that are not used by people to log on.

    • identify the remaining accounts and try to link usernames to people to job roles

    • create Oracle profiles for service accounts, read only accounts and more privileged user accounts

      • set password expiration, complexity, reuse, failed attempts before lockout for these profiles. For example you may decide that service accounts should never change their password but that it should be 24 characters and only one failed attempt before lockout whereas a person's password should only be 8 characters with three failed attempts before lockout.

      • one by one reassign accounts to the correct profile and force a password change


    • at the same time look at creating roles that grant only enough privileges for accounts to do their job and assign the roles.

    This is just the tip of the iceberg for securing the database. The level of effort you put in should be commensurate with the potential damage if the information in the database were breached.






    share|improve this answer























    • You bring up many good points here. We do have a test environment and yes my manager will support this. Thanks again.

      – ImaginaryHuman072889
      3 hours ago













    2












    2








    2







    I suggest a multi-phase approach that can be implemented in stages and will minimize the impact of changing to a more secure approach. I assume that you have a development environment to test in and the support of a manager who is interested and will support the effort.



    • use the existing Oracle audit logging to start logging when users logon and logoff.

    • after a period of time consistent with usage (90 days for a fiscal quarter?, a year end?) identify the unused accounts and lock them

    • identify any service accounts that are not used by people to log on.

    • identify the remaining accounts and try to link usernames to people to job roles

    • create Oracle profiles for service accounts, read only accounts and more privileged user accounts

      • set password expiration, complexity, reuse, failed attempts before lockout for these profiles. For example you may decide that service accounts should never change their password but that it should be 24 characters and only one failed attempt before lockout whereas a person's password should only be 8 characters with three failed attempts before lockout.

      • one by one reassign accounts to the correct profile and force a password change


    • at the same time look at creating roles that grant only enough privileges for accounts to do their job and assign the roles.

    This is just the tip of the iceberg for securing the database. The level of effort you put in should be commensurate with the potential damage if the information in the database were breached.






    share|improve this answer













    I suggest a multi-phase approach that can be implemented in stages and will minimize the impact of changing to a more secure approach. I assume that you have a development environment to test in and the support of a manager who is interested and will support the effort.



    • use the existing Oracle audit logging to start logging when users logon and logoff.

    • after a period of time consistent with usage (90 days for a fiscal quarter?, a year end?) identify the unused accounts and lock them

    • identify any service accounts that are not used by people to log on.

    • identify the remaining accounts and try to link usernames to people to job roles

    • create Oracle profiles for service accounts, read only accounts and more privileged user accounts

      • set password expiration, complexity, reuse, failed attempts before lockout for these profiles. For example you may decide that service accounts should never change their password but that it should be 24 characters and only one failed attempt before lockout whereas a person's password should only be 8 characters with three failed attempts before lockout.

      • one by one reassign accounts to the correct profile and force a password change


    • at the same time look at creating roles that grant only enough privileges for accounts to do their job and assign the roles.

    This is just the tip of the iceberg for securing the database. The level of effort you put in should be commensurate with the potential damage if the information in the database were breached.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered 4 hours ago









    kevinskykevinsky

    3,1692145




    3,1692145












    • You bring up many good points here. We do have a test environment and yes my manager will support this. Thanks again.

      – ImaginaryHuman072889
      3 hours ago

















    • You bring up many good points here. We do have a test environment and yes my manager will support this. Thanks again.

      – ImaginaryHuman072889
      3 hours ago
















    You bring up many good points here. We do have a test environment and yes my manager will support this. Thanks again.

    – ImaginaryHuman072889
    3 hours ago





    You bring up many good points here. We do have a test environment and yes my manager will support this. Thanks again.

    – ImaginaryHuman072889
    3 hours ago













    1














    The reason why your trigger does not work for users like SYS or SYSTEM is because they have the ADMINISTER DATABASE TRIGGER privilege.



    The ADMINISTER DATABASE TRIGGER privilege allows you to create database-level triggers (server error, login, and logout triggers). It also allows you to log in regardless of errors thrown by a login trigger as a failsafe.



    So, the answer is: no, you cannot prevent login for such users - at least not with a login trigger.






    share|improve this answer



























      1














      The reason why your trigger does not work for users like SYS or SYSTEM is because they have the ADMINISTER DATABASE TRIGGER privilege.



      The ADMINISTER DATABASE TRIGGER privilege allows you to create database-level triggers (server error, login, and logout triggers). It also allows you to log in regardless of errors thrown by a login trigger as a failsafe.



      So, the answer is: no, you cannot prevent login for such users - at least not with a login trigger.






      share|improve this answer

























        1












        1








        1







        The reason why your trigger does not work for users like SYS or SYSTEM is because they have the ADMINISTER DATABASE TRIGGER privilege.



        The ADMINISTER DATABASE TRIGGER privilege allows you to create database-level triggers (server error, login, and logout triggers). It also allows you to log in regardless of errors thrown by a login trigger as a failsafe.



        So, the answer is: no, you cannot prevent login for such users - at least not with a login trigger.






        share|improve this answer













        The reason why your trigger does not work for users like SYS or SYSTEM is because they have the ADMINISTER DATABASE TRIGGER privilege.



        The ADMINISTER DATABASE TRIGGER privilege allows you to create database-level triggers (server error, login, and logout triggers). It also allows you to log in regardless of errors thrown by a login trigger as a failsafe.



        So, the answer is: no, you cannot prevent login for such users - at least not with a login trigger.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 2 hours ago









        Wernfried DomscheitWernfried Domscheit

        1,272612




        1,272612



























            draft saved

            draft discarded
















































            Thanks for contributing an answer to Database Administrators Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f238350%2flock-out-of-oracle-based-on-windows-username%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Canceling a color specificationRandomly assigning color to Graphics3D objects?Default color for Filling in Mathematica 9Coloring specific elements of sets with a prime modified order in an array plotHow to pick a color differing significantly from the colors already in a given color list?Detection of the text colorColor numbers based on their valueCan color schemes for use with ColorData include opacity specification?My dynamic color schemes

            Invision Community Contents History See also References External links Navigation menuProprietaryinvisioncommunity.comIPS Community ForumsIPS Community Forumsthis blog entry"License Changes, IP.Board 3.4, and the Future""Interview -- Matt Mecham of Ibforums""CEO Invision Power Board, Matt Mecham Is a Liar, Thief!"IPB License Explanation 1.3, 1.3.1, 2.0, and 2.1ArchivedSecurity Fixes, Updates And Enhancements For IPB 1.3.1Archived"New Demo Accounts - Invision Power Services"the original"New Default Skin"the original"Invision Power Board 3.0.0 and Applications Released"the original"Archived copy"the original"Perpetual licenses being done away with""Release Notes - Invision Power Services""Introducing: IPS Community Suite 4!"Invision Community Release Notes

            François Viète Contents Biography Work and thought Bibliography See also Notes Further reading External links Navigation menup. 21Google Bookspp. 75–77Google BooksDe thou (from University of Saint Andrews)ArchivedGoogle BooksGoogle BooksGoogle BooksGoogle booksGoogle Bookscc-parthenay.frL'histoire universelle (fr)Universal History (en)ArchivedAdsabs.harvard.eduPagesperso-orange.frArchive.orgChikara Sasaki. Descartes' mathematical thought p.259Google BooksGoogle BooksGoogle Bookspp. 152 and onwardGoogle BooksGoogle BooksScribd.comGoogle Books1257-7979Google BooksGoogle BooksGoogle BooksGoogle BooksGoogle BooksGoogle BooksGallica.bnf.frGoogle BooksGoogle Books"François Viète"Francois Viète: Father of Modern Algebraic NotationThe Lawyer and the GamblerAbout TarporleySite de Jean-Paul GuichardL'algèbre nouvelle"About the Harmonicon"cb120511976(data)1188044800000 0001 0913 5903n82164680ola2013766880073431702w6vt1sb70287374827140948071409480