| Author |
Messages |
|
Nicholas Kemp (guest)
 |
| 04/19/2006 12:08 AM |
 Quote
 Reply
 Alert
|
Good day to all.
I have a bit of a problem with Auditing logins and logouts.
I profile all logins/logouts and with this the following things
Events{ Audit Logon, Audit Logout and ExistingConnection} and Data Columns {EventClass,Text Data, DatabaseID, ApplicationName, NTUserName, LoginName, SPID, EndTime, StartTime, HostName and Duration}.
What I am looking for are non authorised applications via ApplicationName.
This works quite well but I have found a security hole within this and it revolves around the use of File data sources.
In excel it is quite easy to connect to a database using a File Data Source and in setting up the data source the application name can be defined. This breaks the secuirty auditing I am doing as the File Data Source can have any type of application name "Default is 'Microsoft Office 2003' etc. and could be changed to a valid application name therby ghosting the access.
Does anyone know of a way to get around this hole? appart from disabling data sources via Group policy? as I it would be good if users could access this feature. |
|
|
|
|
Chip Andrews (guest)
|
| 04/23/2006 11:16 AM |
Quote
Reply
Alert
|
You'll also notice that Application names can be easily set in connection strings even when not using ODBC file and system data sources. I really don't think that the Application Name was ever designed to be more than a convenience and I'm not aware of any way to FORCE it to be authentic.
Again - anyone who can assemble a connection string or set an ODBC Data Source can set this value so the only real way to do what you want is to prevent DSN entries by users and restrict program access to only company-issued software that embeds the proper info in connection strings. Even then - I can think of many ways around both. |
|
|
|
|
Nicholas (guest)
|
| 04/24/2006 12:50 AM |
Quote
Reply
Alert
|
| Yes, thanks for that It was my expectation that there is no way to resolve this. Then only real way I would guess is to use app roles or a slq account, the latter is none to good though. |
|
|
|
|
|