Billy, I forgot to mention in my previous response, that I did move the code back into the Application_Start event - but I did not use impersonating. I am no expert on this but as fare as I have understood this; The Application_Start runs under the aspnet process user, no mater if you are using impersonating or not.
When it comes to choosing how to login/connect/store login information, well that's actually a question about security policy in the company you are working for. Storing password in clear text in config files is usually never considered as a good choice. Storing it inside a program is safer than a text file, but a program can be reverse engineered. You could use an "anti reverse engineering tool" - to make it harder to break. But you also have a maintenance problem - passwords should be changed from time to time. A couple of additional alternatives you may want to consider: Store the password/user information encrypted a separate config file, the .NET has pretty good support for encryption (as far as I know) and it should be fairly easy to implement. When it comes to logging, you could put the log table in a separate database, and give the ASPNET access only to that database. If you prefer to log to separate tables from different applications you need to define several tables. If you prefer to keep the log table in the same database as the application uses, you could grant the ASPNET user access to (and only to) the log table. Create a stored procedure for inserting rows to the log table, and grant ASPNET access to (only) that procedure is also an alternative. I found a couple of checklist for securing asp.net applications you may find useful: http://channel9.msdn.com/wiki/default.aspx/Channel9.ASPNETSecurityCodeReview http://channel9.msdn.com/wiki/default.aspx/Channel9.ASPNETSecurityChecklist Regards, Georg www.l4ndash.com - Log4Net Dashboard -----Original Message----- From: Billy Barnum [mailto:[EMAIL PROTECTED] Sent: 30. september 2005 23:00 To: 'Log4NET User' Subject: RE: How to pass integrated security credentials to AdoNetAppender from ASP.NET? OK, Georg. I've successfully connected to a local database via a trusted connection that is similar to yours. Thank you, sir. I have also been able to connect to a remote database using a trusted connection that is a windows domain account in what the SDK calls "user mode". Like this in the .config file <securityContext type="log4net.Util.WindowsSecurityContext"> <UserName value="MyUserName" /> <Password value="MyPassword" /> <DomainName value="MyDomain" /> </securityContext> Or like this in code: WindowsSecurityContext securityContext = new log4net.Util.WindowsSecurityContext(); securityContext.DomainName = " MyDomain"; securityContext.UserName = " MyUserName"; securityContext.Password = " MyPassword"; securityContext.ActivateOptions(); adoAppender.SecurityContext = securityContext; Now, I understand that code in Application_Start() runs under the security context of ASPNET, not a user, even an anonymous one. And I understand that we do our lo4net setup work in this method because we don't want to do the config work for every page for every user. I'm just a back-end DBA / database access developer and don't know much about the ASP.NET request/response cycle and security contexts therein. But it seems like my choices are (A) putting passwords in code (B) Giving ASPNET access to all databases at an installation that want to use log4net instead of reducing risk by having a separate account for each database, or (C) doing my log4net config work over and over in Application_BeginRequest() or some spot where I have enough security context to use the "process" mode of log4net.Util.WindowsSecurityContext, therefore hurting performance. Can anyone advise me on this? How secure is putting a password in .NET code? I thought it was a no-no. Or is there a way to use security from the anonymous account without doing a lot of unnecessary work? Whatever, I'm grateful for the help I've gotten so far. Thanks again. -BillyB WILLIAM BARNUM [EMAIL PROTECTED]
