Thank you, Nicko. Our ASP.NET application does have impersonate=true in the .config file and is definitely running under a windows account that has permission to connect to the database and do work. We know this to be true because we can connect and return data using out-of-the-box ADO.NET DataAdapters and Commands and the connection string "Data Source=BMT00002;Database=WIAN;Integrated Security=SSPI;Trusted_Connection=yes;" on the same web site that is using log4net. Yet copying and pasting that same connection string into the log4net <connectionString> child element of the AdoNetAppender in the config file fails. And we know everything else is kosher log4net-wise, because we can connect and actually log to tables when we switch over to SQL Server security.
You're of course correct that putting security info in clear-text files is no better than using SQL Server security and we don't want to do it. We don't want to override the windows account ... we want to pass it through. And from what I'm understanding of your words and what we've done, it should be. Any other ideas? -BillyB -----Original Message----- From: Nicko Cadell [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 28, 2005 10:30 AM To: Log4NET User Subject: RE: How to pass integrated security credentials to AdoNetAppender from ASP.NET? By default the SqlConnection will use the credentials of the current user (from the process token or if the thread is impersonating from the thread token). This is the equivalent of System.Net.CredentialCache.DefaultCredentials. As the AdoNetAppender tries to open the SqlConnection during ActivateOptions the credentials will depend on the thread used to configure the appender. If you are loading the configuration file in your ASP.NET Application_Start method then you need to be aware of the security token held by the thread running this method. This depends on how you are hosting ASP.NET. If you are using IIS5 then this will be running as the local user ASPNET. Under IIS6 the user depends on how you have setup the Identity section of the relevant application pool. Do your web users use integrated authentication to authenticate with your web application? Do you have <identity impersonate="true" /> set in your Web.config file? If so then that explains why your users are able to open connections to the database. If you want to use integrated authentication for your web application (rather than a specific user that is using your application) to talk to the database then you need to make the ASP.NET application run under a windows account that has permission to connect to your database. There are various ways of doing this depending on your environment, these are well covered in the MS documentation. The SecurityContext property on appenders allows the thread token to be overridden for the appenders activities. If you cannot allow the Web application to access the database by changing the identity it runs as, and you cannot use sql user logins (sql server in mixed authentication mode) then you can use a SecurityContext to do this. To set the SecurityContext in the config file to use windows integrated authentication use: <appender name="AdoNetAppender" type="log4net.Appender.AdoNetAppender"> <securityContext type="log4net.Util.WindowsSecurityContext"> <userName value="test1" /> <password value="password" /> <domain value="domain" /> </securityContext> ... other properties here ... </appender> >From a security point of view this is no better or worse than specifying the sql user id and password in the connection string. Cheers, Nicko
