external passwords vs microsoft SQL Server windows authentication

I have seen a few articles mention that external passwords associated with oracle database accounts are a risk (as if someone compromised that OS account they dont need to supply a password to access the database), but how is it any different to Microsoft SQL Servers windows authentication which is recommended, whereby again you dont need to enter SQL authentication password to access the database?

These are linux servers which house the oracle databases, if that affects it in anyway.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Windows authentication is more secured as the logins get authenticated at OS level (at Kerberos level in a more precise way) which is the most secured way of authentication.

It is not necessary that Windows authenticated users have full access to SQL Server. Ideally, on production servers, OS level administrators wont be provided any access to SQL Server.
So, even though you are an admin at domain or OS level, u wont be having access to SQL server at all!

As such, access to SQL Server is provided only on need basis and mostly the full access lies with DBA team members.

Hope this clarifies!
pma111Author Commented:
not really, are we saying oracle external (OS) passwords are more secure than oracle database passwords?
Not sure about oracle. But from MSSQL end, OS authenticated users are more secured as SQL authenticated ones.
Powerful Yet Easy-to-Use Network Monitoring

Identify excessive bandwidth utilization or unexpected application traffic with SolarWinds Bandwidth Analyzer Pack.

MS SQL Server can be configured to support two kinds of authentication:

1. SQL Server Authentication
This is what you call "external passwords". Users (and their passwords) are defined and stored on the SQL Server level, which will actually do the authentication and allow or restrict some of their rights according to the role for that user.

2. Windows Authentication
users and their passwords are defined at Windows level, so they are first of all defined as Windows users, then they might get assigned on some SQL Server role and get access to data inside SQL Server database. Authentication is done by Windows itself, then SQL Server checks their role and rights of accessing database information.

windows authentication which is recommended

Yes, Windows authentication is recommended as it's done at a superior level (Windows SAM). It is also recommended as Windows users won't need to remember one more password, which they often tend to save in clear-text inside data-connection strings (security breach). Besides, it can be a pretty good advantage for high scale windows domain networks, where the same user can have rights access to several resources (database, email, files etc.)

whereby again you dont need to enter SQL authentication password to access the database

False! You have to enter your Windows password when logging into the system first. Then the authentication process is transparent, as SQL Server communicates with Windows SAM to check up you have been authenticated.

As a conclusion: for Windows users accessing SQL Server database then Windows Authentication is best for the reasons I explained. But if you have some external users (external meaning they are not Windows users, and they should not need access to Windows resources among the entire domain), then SQL Authentication is better (just create their credentials on the SQL Server).

I hope you'll find my explanation useful. Good luck!
slightwv (䄆 Netminder) Commented:
I can't speak to why MSoft recommends transparent access to databases other than what the Experts above posted.

From an Oracle perspective, it has always been frowned upon also for the reasons suggested:  If I compromise an OS account, I also have access to database resources.

The negatives are also posted above:  WAY to often, usernames and passwords are hard-coded in scripts, files, configs, etc...

Put me on a server with an Oracle database or a machine that accesses an Oracle database and I can typically log into the database in a couple of minutes because I can find a username/password someone on disk.

You can further lock down Oracle logins to specific ip addresses to help.  I may compromise an OS account but maybe not on a specific machine.  Therefore, I cannot access your databases (unless the OS account I compromise can log into an 'allowed' machine.

I've used OS Authentication in Oracle before.  A lot of people tend in the security world to over react when they hear about it.

Explain it to them this way:  Apps running on systems need to access the database.  We can either let the OS handle the database connection or we can hard-code the connection information somewhere on disk.

They typically allows OS authentication.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
johnsoneSenior Oracle DBACommented:
Auditors only know that the accounts are OS authenticated and they will stop you right there.  They don't have any type of understanding what that means, they just say it is bad and you need to get rid of them.  They will also make you change scripts that have passwords embedded in them, so the OS search doesn't turn up any connect strings.  Someone built a very small program that kept the passwords in an encrypted format in a file on the OS and there was a utility to retrieve them.  The auditors were OK with that because it was not human readable and only people that needed it could read the file or run the application.
pma111Author Commented:
Can you elaborate on this: ''Auditors only know that the accounts are OS authenticated and they will stop you right there.''
johnsoneSenior Oracle DBACommented:
If your database is subject to audit, auditors are looking for accounts that are externally identified.  If you have them, you will fail that audit control and you will be required to remediate it.
pma111Author Commented:
I just don't really get why though? And if mssql has ''windows authentication'' which by the looks of it is the same concept, I'm struggling to see where the risk is?
slightwv (䄆 Netminder) Commented:
>>and you will be required to remediate it.

Or explain how the risk is mitigated.  I have successfully won debates over security audits.  I've also lost some...  It just depends on if you have the energy to battle and the facts to back it up.

For us some things are just flagged as a 'risk' by the auditors and as long as Management signs off on the risk, it is allowed.  That is until the risk is exploited and Management has to explain it higher up the food chain.  ;)
slightwv (䄆 Netminder) Commented:
>>And if mssql has ''windows authentication''

Both "have it".

The difference is one seems to "recommend" using it.

Different companies.... different philosophies.

MSoft is big on integrating ALL their products together.

Single Sign-on is also a big push.

>>I'm struggling to see where the risk is?

The risk is what we've mentioned above:  Compromised OS account, very likely an automatic compromised database.
johnsoneSenior Oracle DBACommented:
It all depends on the type of audit, the auditor and the company they work for.  I too have won some battles and lost some battles.  Because of the type of audit that was being done (we did so many different kinds because of what we did, I don't know which one was the biggest restriction), OS authenticated accounts were listed as failures and not risks.  There was no option to argue them.

The "why" is because I can compromise one password and get access to the database.  Or, if someone gets up from their desk and doesn't lock their desktop, I can sit down at their desk and get their database access.  If I staked out an admin, then I have full access.  If I staked out someone with elevated privileges, I can certainly do quite a bit of damage and depending on their privileges, I could probably get any privileges they didn't already have.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft SQL Server

From novice to tech pro — start learning today.