Fog Creek Software
Discussion Board




Enterprise security question

The short question is what are some best practices for writing software that has to make use of an NT domain admit account? (We're using C# here.)

My client needs a series of applications written that will run on their internal servers that will need to impersonate the domain admin, so my application needs to know a domain admin account and login.

I'm not about to hard-code it, and storing it in the applications config file is out of the question since it would be stored in cleartext.

One way to do it is to store the encrypted login and password in our Oracle database and then each application would make calls to Oracle to retrieve the information. This allows all of the applications to retrieve the login information from one place and makes it easy to update when we change the password of the domain admin.

This seems like a reasonable approach to me, but I wanted to get some feedback from other developers and architects before I decided to move forward.

Thanks!

Mark Hoffman
Thursday, August 21, 2003

You shouldn't have to log in programmatically -- the admin either logs in then launches your app and you inherit the security rights, or the admin can otherwise configure your app to run as a different user (e.g. through dcomcnfg) or specify the rights like if you run as a service.

Rick
Thursday, August 21, 2003

You don't need to have the user account and password. In the NT 4 world you have impersonation, which allows you to act on behalf of the caller (i.e. from a COM component. If you're talking about a local app then it is already running in their context), though this was limited to the single machine (i.e. IIS could impersonate the user logging on in its connection to SQL Server. The IIS server used challenge response, so the middleware app never needs to know the user's password). Windows 2000 brought us Delegation, which is a more powerful method and is cross-machine.

Take a look at ms-help://MS.MSDNQTR.2002APR.1033/cossdk/htm/pgservices_security_3yer.htm (do a start/run with it if you have MSDN installed).

Cheers

Dennis Forbes
Thursday, August 21, 2003

I probably misused the word application.

It's actually code-behind on an ASP.NET web site. For the most part, we use the user's credentials to communicate to other systems.

However, there are times when we have to impersonate an admin account. For example, one page creates Active Directory groups "behind the scenes". This requires the web server to impersonate a different user.

We also force AD to synchronize with other AD systems, which also requires an impersonation.

One page communicates with SharePoint and creates several directories within SharePoint. Once again, this requires a different user to be logged in.

Granted, I could turn all of this code into Windows application and use MSMQ to sync the communication between the web server and the apps, but I'm working with a system that is already in place and user names and passwords are hard-coded.

Mark Hoffman
Thursday, August 21, 2003

Oh... good thing you cleared that up!  I was going to recommend using a Windows Service running under an account with the necessary permissions...

For a web application, the first thing that comes to my mind is using an out of process Serviced Component.  After you register your component in Component Services, this option allows you to run code under any identity you choose. 

There are more options though, so check out this rather large reference guide:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/secnetlpMSDN.asp

GuyIncognito
Thursday, August 21, 2003

*  Recent Topics

*  Fog Creek Home