Re: OS authentication question
Date: Wed, 16 Jan 2008 22:20:26 GMT
Message-ID: <Kqvjj.33935$fj2.31584@edtnps82>
fitzjarrell_at_cox.net wrote:
> On Jan 16, 3:23 pm, GS <G..._at_GS.com> wrote:
>> Database is 9.2.0.8 running on W2K server, clients are windows xp pro
>> running 9i client.
>>
>> We've not used OS authentication here for any databases yet, so this is
>> relatively new to me. To make our SOX compliance easier we are thinking
>> about going to OS authentication for a lot of our app's that run on
>> Oracle databases, since our network passwords are now very stringent and
>> the beancounters are saying the database passwords need to meet the same
>> criteria, but if the users connect with the complex OS password then we
>> are ok.
>>
>> So, on a test database I created a login for myself with the following:
>>
>> create user "ops$my_domain\my_network_username" identified externally;
>> grant connect, create session et. to the new user (me)
>>
>> I enter "sqlplus /nolog" then "connect / @testdb" and I am in with no
>> password, as expected. So far so good, so I take an existing user in the
>> test database, and from EOM I highlight this user and choose create like
>> so he will have the correct roles etc., then add
>> "ops$my_domain\his_domain_username" in the database. We try from his
>> machine to connect via sqlplus the same way I did, and I am getting
>> invalid username/password errors. I double checked the new username I
>> created for him and all looks fine.
>>
>> The servers sqlnet.ora file has SQLNET.AUTHENTICATION_SERVICES= (NTS), I
>> thought I might need that on the client side too but my machine is
>> SQLNET.AUTHENTICATION_SERVICES= (NONE) and I can connect ok. I am on my
>> way back over to check his sqlnet.ora file, but is there something else
>> I am missing here?
>>
>> thanks in advance
> > Yes, the fact that using O/S authentication in your database opens > security holes as you also need to set remote_os_authent to TRUE. > This, as discussed in another thread on this same topic, allows anyone > with access (legal or illegal) to your internet/intranet the ability > to connect to the database, and thus do damage. I'm surprised the SOX > auditors are even entertaining this thought. > > Your only real choice in this situation is to enforce a password > complexity check in the database and require all database users to > abide by it. O/S authentication isn't the answer in this case. None > of the SOX-compliant databases I manage allows for O/S authenticated > accounts, nor do the auditors here support such a configuration. > > I would seriously re-think your position on this. > > > David Fitzjarrell
I pointed out to the powers that be that this would not be as secure as having the users enter passwords, but they are more interested in keeping the auditors happy than whats actually the best practice in real life. In any case, I find this whole SOX compliance thing somewhat a joke, since the number of passwords on sticky notes has gone up exponentially since we started enforcing constantly changing complex domain passwords, and I expect the same will happen with database passwords. Of all the things the auditors noticed and put in their findings, in my mind they missed the most obvious potential security breaches, for example not even asking about or looking for user managed backup scripts for embedded passwords, or file restrictions on said scripts.
But I digress, anyway, on the client machine in question his SQLNET.AUTHENTICATION_SERVICES was set to NONE, when I changed it to NTS it connected fine with sqlplus / @testdb. Not sure why, but I can connect fine from mine with it set to NONE. The database is also currently set at remote_os_authent=false and I can still connect, is this setting only for if the OPS$ user has not been created in the DB?
In your example of opening more security holes, the way I understand it is that the users have to be created in the database first before they can connect with external credentials anyway, so there is no danger of Joe from the machine shop connecting to a database he does not usually use, unless he does it from someone else's machine logged in as a domain user that is also in the database, which is a possibility as well I suppose. To me the biggest danger would be if the OS_AUTHENT_PREFIX was set to " " and someone created a network user called sys or system, but even then, would the user "domain_name\system" have to be created with full DBA rights before they could connect with external credentials anyway? Received on Wed Jan 16 2008 - 16:20:26 CST