How to run as in a deamon

[David Thielen]

Hi;

We have this web app that handles security great. For everything we do we
run as the client so we do not have to store any credentials ourselves and it
handles Sql Server access, reading files from the server, everything.

But... we have a deamon program where users can schedule these same actions.
The problem is, when these deamon programs run, we don't have the client user
attached and therefore cannot get their credentials.

Do we need to get their uname/pw and store it to be able to runAs them -
like services in Windows when running under a user? I hate to store that info
because that is the keys to the kingdom.

--
thanks - dave
david_at_windward_dot_net
http://www.windwardreports.com

Cubicle Wars - http://www.windwardreports.com/film.htm

 

[Joe Kaplan]

Have them set up the scheduled task to run as the required user. That's the
most straightforward way to solve this.

Joe K.

 

[David Thielen]

The problem is that this runs on the server (ASP.NET) and most user's don't
have (and shouldn't have) login rights on the server.

--
thanks - dave
david_at_windward_dot_net
http://www.windwardreports.com

Cubicle Wars - http://www.windwardreports.com/film.htm

 

[Joe Kaplan]

What would be the conceptual difference between running the scheduled task
as the user your need vs. storing their credentials so you could create a
token for them and impersonate them? Basically, that just means it is your
problem to store the credentials vs. the operating system's.

If the process ran as SYSTEM, the server was 2K3 and the AD domain was 2K3
native, you could create an impersonation token for a user based solely on
their user principal name via S4U/protocol transition. I'm not sure if that
really helps you though.

Joe K.

 

[MikeS]

If you want to impersonate them, you will need their credentials, and
use LoginUser. Perhaps save them away somewhere using the crypto API.
There is trouble there then when their password changes and you could
end up locking out their account.

There is nothing like being able to su from root to another user
without a password in Windows as far as I know.

ASP.NET is not a daemon, it is a filter, IIS is a daemon. I am not sure
how one schedules things in IIS though since it only comes to life when
a connection is made.

I am thinking that impersonation may not be an option and whatever API
you are calling on schedule, on behalf of the user, may have to trust
the caller, the scheduler program, and also accept a parameter that
indicates the user and use that to audit which actions are taken.

It would be nice if something like queued components could remember the
original callers id and execute as them on schedule.

The bottom line is that impersonation is a pain and more so when you
want to do it forever.

 

[Steven Cheng[MSFT]]

Hello Dave,

I think the problem here is that the your deamon application doesn't has a
credential store, or can not get crential or authenticated token from IIS.
In such case, I'm afraid you have to pre-store the certain user(you want to
run as)'s username/password credentials in your application storage. This
could be database or configuration file. One example is SQL Server
reporting service which will store the username/password credentials in the
database and used for accessing external resource.

In .net framework 2.0, we have some built-in means to encrpt data such as
the DPAPI wrapper:

#Using the DPAPI through ProtectedData Class in .Net Framework 2.0
http://www.c-sharpcorner.com/UploadFile/mosessaur/dpapiprotecteddataclass010
52006142332PM/dpapiprotecteddataclass.aspx?ArticleID=d6a6c525-1898-45de-b16e
-58c763472348


Also, .net framework 2.0 support RSA or DPAPI provider to encrypt
configuration file sections:
#Encrypting Configuration Information in ASP.NET 2.0 Applications
http://aspnet.4guysfromrolla.com/articles/021506-1.aspx

In addition, as for your deamon application, after it runas/impersonate a
certain user, will it access any remote resource or only the resoruce on
the local machine? If it only accessing resource on local machine, and the
deamon application can run under LOCAL SYSTEM account(as service), you can
consider the kerberos S4U logon approach as Joe has mentioend. Here is a
article introducing this:

#Exploring S4U Kerberos Extensions in Windows Server 2003
http://msdn.microsoft.com/msdnmag/issues/03/04/SecurityBriefs/

For example, you can use the following code to constructor a
windowsIdentity and impersonate it(through user principal name):
============================
WindowsIdentity wi = new WindowsIdentity("username@domainname");


WindowsImpersonationContext ctx = wi.Impersonate();

StreamWriter sw = new
StreamWriter(@"d:\\temp\\testfolder\\jetan_file111.txt");
sw.WriteLine("this file is created by jetan.");
sw.Close();


Response.Write("<br/>IMpersonate: " +
System.Security.Principal.WindowsIdentity.GetCurrent().Name);

ctx.Undo();

=========================



Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



This posting is provided "AS IS" with no warranties, and confers no rights.

 

[David Thielen]

Thank you Joe/Steven/Mike. Boy security is a pain!!!

--
thanks - dave
david_at_windward_dot_net
http://www.windwardreports.com

Cubicle Wars - http://www.windwardreports.com/film.htm

 

[Dominick Baier]

LOL