NTFS Security and login scripts

[Des Norton]

Hi NG

In an environment where login scripts are used, is it possible to set the
permissions on either the scripts folder or individual .bat files, so that
users cannot view the contents of the files?

I need to pass DomainAdminUser/Password to an application on all client
machines. This is done via login script. However, users being what they
are, can open the script file and see the DomainAdminUser/Password. They
then use this to ... like naughty children.

I have tried playing around with various security combinations, but it would
appear that if the users cant read the contents of the files, then they cant
execute them.

What about putting sensitive information into a seperate script file (in a
different folder, if necessary) and calling the second file from the
standard script?

Any help will be greatly appreciated.
Regards
Des Norton

 

[Paul Adare]

microsoft.public.win2000.security news group, Des Norton

Hi NG

In an environment where login scripts are used, is it possible to set the
permissions on either the scripts folder or individual .bat files, so that
users cannot view the contents of the files?

I need to pass DomainAdminUser/Password to an application on all client
machines. This is done via login script. However, users being what they
are, can open the script file and see the DomainAdminUser/Password. They
then use this to ... like naughty children.

I have tried playing around with various security combinations, but it would
appear that if the users cant read the contents of the files, then they cant
execute them.

What about putting sensitive information into a seperate script file (in a
different folder, if necessary) and calling the second file from the
standard script?

You can't do this. Since the login script is being executed in the
security context of the user logging in, they need to be able to read
the script in order to be able to execute it.

Why exactly do you need to pass the domain administrator user name and
password in your script. If you can describe in detail exactly what
you're trying to do, someone maybe able to come up with an alternate
solution.

 

[Veronica Loell]

Des Norton wrote / skrev:

I need to pass DomainAdminUser/Password to an application on all client
machines. This is done via login script. However, users being what they
are, can open the script file and see the DomainAdminUser/Password. They
then use this to ... like naughty children.

Can't you do this via scheduled tasks instead?

 

[Des Norton]

Hi Paul

Thanks for your response.


We are deploying software via login script. Users do not have local admin
rights, but due to various reasons, admin rights are required for a
successful install.

We get around this by passing the AdminUser/Password into the setup package
as a parameter. It then creates a new process under the AdminUser profile
and does the installation.

I will therefor perform a crude form of encryption on the
AdminUser/Password, and have the setup package decypher it at runtime.


Regards
Des Norton

 

[Des Norton]

Hi Veronica

Unfortunately I know very little about networking and security.
Could you please elaborate on how to use scheduled tasks to roll out
software across large networks. Also, how would this hide the
AdminUser/Password from prying eyes?

Regards
Des Norton

 

[Paul Adare]

microsoft.public.win2000.security news group, Des Norton

We are deploying software via login script. Users do not have local admin
rights, but due to various reasons, admin rights are required for a
successful install.

Do you have an Active Directory domain, and if yes, is this software in
the form of an MSI file (or can it be packaged up as such)? If so, then
your best solution is software deployment via GPO. If you deploy an MSI
package via GPO, then by default, elevated privileges are used for the
install. You can even set a Group Policy setting that allows all MSI
packaged software to be installed with elevated privileges.

 

[Des Norton]

Hi Paul

This deployment is for a commercial software package.
Not all of the clients have AD domains.
We do not use MSI packages.

I have just finished modifying the setup packeg to use a crude form of
encryption, so the problem is now resolved.

Once again, thanks for your input.

Regards
Des Norton

 

[Veronica Loell]

Des Norton wrote / skrev:

Hi Veronica

Unfortunately I know very little about networking and security.
Could you please elaborate on how to use scheduled tasks to roll out
software across large networks. Also, how would this hide the
AdminUser/Password from prying eyes?

Scheduled tasks are used to run processes not connected with the desktop
as a specific user. Since you said you used login scripts I was just
wondering why you could not run the scripts as a scheduled task instead.
If you do then you supply the password when setting up the task if you
have it run as an admin, and it is not visible to the user.

 

[Des Norton]

Hi Veronica

Does this require that somebody has to create the scheduled task on each
machine?
How much work is entailed in setting up a scheduled task on all client
machines on the network?

The login script is a simple .bat file on the server, which is run
automatically whenever a user logs on.

Regards
Des Norton

 

[Veronica Loell]

Des Norton wrote / skrev:

Hi Veronica

Does this require that somebody has to create the scheduled task on each
machine?
How much work is entailed in setting up a scheduled task on all client
machines on the network?

I have not looked into automating the creation of scheduled tasks but it
should be possible I would think.

The login script is a simple .bat file on the server, which is run
automatically whenever a user logs on.

You can do this with scheduled tasks, just create a task that is run at
logon and make sure that it is visible to all users. Once created on one
machine you can copy-paste it. I have not tried doing this over
different machines, but it should be ok as long as you have the same
admin-name and password. It seems as if you might have to access each
computer remotely and copy the task into the scheduled tasks folder:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;310424
Alternative to this seems to be:
http://www.microsoft.com/technet/tr...echnet/scriptcenter/scrguide/sas_man_lpja.asp

 

[Veronica Loell]

The job should be placed in systemroot\Tasks. So you should be able to
automate this.

 

[Guest]

If you'd like, you can create a user that has domain admin priveledges, and disable the account shortly after the login script runs for the majority of the users. It's not the safest, but it'll save you from giving out the Admin account password.

 

[Veronica Loell]

pborkstrom wrote / skrev:

If you'd like, you can create a user that has domain admin priveledges,
and disable the account shortly after the login script runs for the
majority of the users. It's not the safest, but it'll save you from
giving out the Admin account password.

If one uses scheduled tasks there is no need to give out admin account
password.