UDL files with TRUSTED authentication - a security risk?

Hi everyone,

So the other day on twitter in #sqlhelp and privately with some friends at Microsoft and elsewhere I had a lively and surprising conversation about UDL files.

We all know that we should be using Windows authentication, but if you're an Ops DBA like me you know that there are p-l-e-n-t-y of legacy systems and (sadly) even modern day vendors that have applications that rely on SQL Server (or non-trusted) authentication.

When someone uses a UDL file to connect to SQL Server with non-trusted authentication mode employed they store passwords. Bad. No question about it.

However, when you use a UDL file with trusted authentication, no password is stored and the UDL can't be used to connect unless your Windows account has access in the database. No passwords are stored.

In the latter case, a UDL file can be used without storing a password.

In the former case, you are using a authentication mode that should be banned in the first place.

So the question is: should UDLs themselves be banned because it is possible to use them in tandem with non-trusted authentication mode to store passwords?

To me this makes as much sense as banning the use of SQL files because it is possible for someone to embed a password in them with sqlcmd syntax ( ":connect").

Security is important, but so is the concept of triage.

We deal with the most urgent issues first.

I have worn both the "Consultant" hat and the "FTE Ops DBA" hat and know both worlds well. It's very easy to identify issues (and that is welcomed) but there is a reason Ops DBAs use the term "real world" for it exists.

I'd love to hear your thoughts on the necessity of banning UDL files employed with TRUSTED authentication. Please share them in the comments section if you would like.

Syndicate content