print as user?

  • Thread starter Thread starter Eric
  • Start date Start date
E

Eric

..Net 3.5 added ability for a client machine to run .Net programs on a
server, but if we run a VB.Net program on a server and use the printer
object to create a printout, it adds a printout to the queue with the name
administrator. If we run it from the client, we get the logged in username.
Is there a method to run it on the server and still see documents in the
queue with the user names?
 
Eric said:
Nobody knows, or this is not possible?
Click to expand...

Well, to me its sort of a odd question.

You always had the ability for a process to run another process on the
server side. .NET does not have a copyright on that idea.

But I can imagine .NET 3.5 possibly added easier logic to establish
the child process credentials, which by default if not specified, the
spawned process will inherit the parent process credentials.

When initiating it from a client, the client is the user so the code
is running under the context of the user.

When doing it from the server, well, typically this is done under the
account established for .NET applications, it may be the local account
or administrator or whatever secured ANONYMOUS credentials used for
..NET applications.

You can probably use this context to browse all the queues and get the
one you want or their might be a lookup by user name.

But if you want to get the information for a user context, I believe
you need to either login as that user or impersonate that user.

Once you know the basic requirements for both client/server
credentials, then look up the commands in .NET to do it.

--
 
Eric said:
Nobody knows, or this is not possible?
Click to expand...

Well, to me its sort of a odd question.

You always had the ability for a process to run another process on the
server side. .NET does not have a copyright on that idea.

But I can imagine .NET 3.5 possibly added easier logic to establish
the child process credentials, which by default if not specified, the
spawned process will inherit the parent process credentials.

When initiating it from a client, the client is the user so the code
is running under the context of the user.

When doing it from the server, well, typically this is done under the
account established for .NET applications, it may be the local account
or administrator or whatever secured ANONYMOUS credentials used for
..NET applications.

You can probably use this context to browse all the queues and get the
one you want or their might be a lookup by user name.

But if you want to get the information for a user context, I believe
you need to either login as that user or impersonate that user.

Once you know the basic requirements for both client/server
credentials, then look up the commands in .NET to do it.

--
 
Mike said:
Well, to me its sort of a odd question.

You always had the ability for a process to run another process on the
server side. .NET does not have a copyright on that idea.
Click to expand...

For example, RSH (Remote Shell) is a long time common practice. You
have a RSH command in Windows.

c:> rsh /?
rsh: remote terminal session not supported

Runs commands on remote hosts running the RSH service.

RSH host [-l username] [-n] command

host Specifies the remote host on which to run command.
-l username Specifies the user name to use on the remote host.
If omitted, the logged on user name is used.
-n Redirects the input of RSH to NULL.
command Specifies the command to run.

What you probably talking about in .NET is this was added or some
form of it was added with an new assembly.

In any case, notice the -l username option?

That establishes the user context the remote server will spawn the
process under.

If not specified, there is a default user context. You are probably
running it as a non-user context, the .NET default credentials.

See if the new .NET 3.5 commands you are talking about has a user
credentials option or has a very deep remark on the subject of
security as this would be a major threat entry point. I would be very
surprise if it does not.

--
 
Mike said:
Well, to me its sort of a odd question.

You always had the ability for a process to run another process on the
server side. .NET does not have a copyright on that idea.
Click to expand...

For example, RSH (Remote Shell) is a long time common practice. You
have a RSH command in Windows.

c:> rsh /?
rsh: remote terminal session not supported

Runs commands on remote hosts running the RSH service.

RSH host [-l username] [-n] command

host Specifies the remote host on which to run command.
-l username Specifies the user name to use on the remote host.
If omitted, the logged on user name is used.
-n Redirects the input of RSH to NULL.
command Specifies the command to run.

What you probably talking about in .NET is this was added or some
form of it was added with an new assembly.

In any case, notice the -l username option?

That establishes the user context the remote server will spawn the
process under.

If not specified, there is a default user context. You are probably
running it as a non-user context, the .NET default credentials.

See if the new .NET 3.5 commands you are talking about has a user
credentials option or has a very deep remark on the subject of
security as this would be a major threat entry point. I would be very
surprise if it does not.

--
 
Back
Top