[Previous entry: "Revoking PUBLIC Execute on SYS.DMP_SYS"] [Next entry: "New Oracle Security Book, UKOUG and Finland"]
OS Authentication
November 19th, 2009 by Pete
Post to del.icio.us
Post to Furl
Gary pointed us to an article written on database journal by james in a forum post titled "OS Authentication". The article is titled "Securing Client Connections: OS Authentication" and it discusses the virtues of externally (OS) authenticated accounts.
There are some issues with this article and Gary has picked up on some already with his comment there at the end of the article but i wanted to mention something else.
The article checks the parameter OS_AUTHENT_PREFIX which in the example is set to a NULL string - not the default value. The article then suggests setting back to a value of OPS$, its default. Oracle recommends in its hardening guide (and indeed there are many other sources saying the same) that setting it to the NULL string is best. This is to prevent dual authentication of externally authenticated accounts.
James does make a good point though; check that no externally authenticated accounts exist before you change this value as it would stop them logging in.
The other point in the article about root access is that the acticle suggests that if you have root access you could randomly guess OS account names and create them in the hope of connecting as an externally authenticated account; why? just su to the software oracle owner and connect "as sysdba" and then do what you want.
I do agree with James that when done correctly externally authenticated accounts (local only not remote) are a good way to manage external jobs that must remain outside the database. This is OK, if OS access is limited, the OS and DB accounts have the least privileges necessary, the account is designed and used for one purpose only and its ever move is audited. Security in layers is good.
