Connecting to a database with integrated security from a web app is all about the identity of the process (I know you all are aware of this, I'm just providing context for the message). And the way this is done, well, depends on how the application is configured. I've outlined some steps you'll need to take to get this set up.
1. Create A Domain Service Account Create a service account in your domain for your application. It could be a workgroup or machine account, but domain accounts offer a wider scope on the network. I don't often see this done, but as time goes by I see the value of an application service account more and more. In fact, if you install any server products by Microsoft, the installation guide often recommends doing this. 2. Grant Database Permissions to the Service Account Create a login account in the database for the service account and give appropriate permissions. Nothing special here. 3. Configure Applications to Run Under the Service Account If you're running on Windows Server 2003, you've got it easy. Simply configure the identity of the Application Pool to which your web app is assigned and enable impersonation. The ASP.NET process (w3p.exe) will now run using the credentials of the service account. If you're running on Windows Server 2000, you'll need to jump thru the traditional hoops depending on how the site is configured. If you have an Anonymous-only site, you can set the anonymous identity in the virtual directory to be the service account from above. In all other cases (Windows or Basic authentication), you'll need to configure the <identity> element in web.config to use the username/password of the service account. I know this isn't ideal because the creds are in plain-text, but you can mitigate a security breach by hardening access to the server, applying ACLs to web.config, etc. My current project is configured for the last case above, so if any of the details don't work for you (I'm writing this off the top of my head), reply back and I'll help you get this straightened out. -----Original Message----- From: Georg Jansen [mailto:[EMAIL PROTECTED] Sent: Monday, October 03, 2005 7:33 AM To: 'Log4NET User' Subject: RE: How to pass integrated security credentials to AdoNetAppender from ASP.NET? 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]
