Wrong Password? S'alright, you logged into Windows!



  • Starting with Oracle 9i (I think, who fucking knows with Oracle documentation) you can configure it to use Windows to manage authentication. Not that big a deal, infact probably a good thing.

    Normally you can't connect to Oracle as SYS without the magic AS SYSDBA keywords. This is good because SYS is the God-mode account. But Oracle will prefer OS Authentication, even if you give it the wrong password when you add that AS SYSDBA.

    So the command:

    [code]sqlplus SYS/LarryPageEatsBabies AS SYSDBA[/code]

    lets you log into Oracle no-questions-asked if the current user is in the ORA_DBA group.

    Guess who get's added by default? The installing user. Maybe a DBA, maybe someone who can't spell the word Oracle. In my case it is the previous. And it's not one person, it's hundereds.

    I think I could tolerate this flaming pile of goat crap feature if I could turn off or on. I mean, a user who jams the wrong password for God-mode on a database can do no wrong, right?



  • @MathNerdCNU said:

    But Oracle will use whichever Authentication method specified in its config files, in an order of preference
     

    FTFY.

    @MathNerdCNU said:

    So the command:

    <font face="Lucida Console" size="2">sqlplus SYS/LarryPageEatsBabies AS SYSDBA</font>

    lets you log into Oracle no-questions-asked if the current user is in the ORA_DBA group.

     

    If the current user is in the ORA_DBA group, you have no need to specify a username and password:

    <font face="Lucida Console" size="2">sqlplus / AS SYSDBA</font>

    (that's the point of using OS auth - the OS is validating your credentials, not the username/pass you provide)

    @MathNerdCNU said:

    Guess who get's added by default? The installing user.

    Because it makes the assumption that the installing user may actually be the DBA, and is probably correct in the majority of occasions.

    You do know that it's possible to remove the installing user from the ORA_DBA group, right? Defaults can always be modified later - quite a neat feature of most operating systems, I find.


  • ♿ (Parody)

    @MathNerdCNU said:

    Guess who get's added by default? The installing user. Maybe a DBA, maybe someone who can't spell the word Oracle. In my case it is the previous. And it's not one person, it's hundereds.

    Adding the installing user by default seems reasonable for a default. But...how did hundereds [sic] of users install Oracle on a particular machine?



  • @boomzilla said:

    Adding the installing user by default seems reasonable for a default
     

    It is, in Windows land.

    Or rather: under *nix, Oracle first requires you to create a DBA group and an OINSTALL group, then create one user that's a member of DBA and another that's a member of both. The latter will be used to install Oracle then never touched again (it should be deactivated), the former is an OS user that can walk in AS SYSDBA and used to start/stop Oracle, plus make structural changes.  Oracle refuses to install as root: it makes it clear that the processes shouldn't be running priviledged, and will barf mid-install if this pre-requisite work hasn't been satisfied.

    In Windows land, Oracle discovered the DBA group had already been grabbed for some other purpose (MS-SQL Server?) so they used ORA_DBA instead, and rather than expect Windows admins to do preparation they just added some routines to do "groupadd" and "usermod", Billy-stylee. Unfortuntely they don't prevent the install from being performed by Administrator, causing some issues with file ownership and permissions further down the line.

    Hence that default behaviour. I'm not really sure if this default behaviour is user-friendly or system-hostile.



  • Hence that default behaviour. I'm not really sure if this default behaviour is user-friendly or system-hostile.

    user-friendly and system-hostile are generally synonyms


Log in to reply