Authorization levels and login scripts

[Ryan Nordman]

Note: cross-posted to microsoft.public.scripting.vbscript and
microsoft.public.windowsxp.security_admin

Hi guys,

I'm in need of some information about how the security and
impersonation of scripts works. I'm trying to create a login vbscript
that will enumerate certain types of files on the HD. The problem is
that we want it to run more often than when the computer is rebooted,
so it can't be a startup script. As a login script, the user logging
in doesn't have priveleges to see all the directories on the machine
(notably the documents & settings folders for other users), but we
want to enumerate the contents of those folders. What would you
suggest? Is there a way to use the machine account instead of the
user account when it's a login script? (from what I've read, it seems
not)

From the reading I've done, it seems the only way really to do it is
to provide other credentials and run the script as another user. I'd
prefer not to use this option as storing the credentials of another
user with elevated priveleges in the script would be a security risk.
If this is the only way to do it, does anybody have tips on making
this option as secure as possible?

Thanks very much,
-Ryan

 

[Yevgen Lazaryev]

....You may try to use Scheduled Tasks to run the script ...Set it to start
"On user's logon" under Admin (or System) account ....

"Ryan Nordman" <[email protected]> a écrit dans le message de
| Note: cross-posted to microsoft.public.scripting.vbscript and
| microsoft.public.windowsxp.security_admin
|
| Hi guys,
|
| I'm in need of some information about how the security and
| impersonation of scripts works. I'm trying to create a login vbscript
| that will enumerate certain types of files on the HD. The problem is
| that we want it to run more often than when the computer is rebooted,
| so it can't be a startup script. As a login script, the user logging
| in doesn't have priveleges to see all the directories on the machine
| (notably the documents & settings folders for other users), but we
| want to enumerate the contents of those folders. What would you
| suggest? Is there a way to use the machine account instead of the
| user account when it's a login script? (from what I've read, it seems
| not)
|
| From the reading I've done, it seems the only way really to do it is
| to provide other credentials and run the script as another user. I'd
| prefer not to use this option as storing the credentials of another
| user with elevated priveleges in the script would be a security risk.
| If this is the only way to do it, does anybody have tips on making
| this option as secure as possible?
|
| Thanks very much,
| -Ryan

 

[Colin Nash [MVP]]

Note: cross-posted to microsoft.public.scripting.vbscript and
microsoft.public.windowsxp.security_admin

Hi guys,

I'm in need of some information about how the security and
impersonation of scripts works. I'm trying to create a login vbscript
that will enumerate certain types of files on the HD. The problem is
that we want it to run more often than when the computer is rebooted,
so it can't be a startup script. As a login script, the user logging
in doesn't have priveleges to see all the directories on the machine
(notably the documents & settings folders for other users), but we
want to enumerate the contents of those folders. What would you
suggest? Is there a way to use the machine account instead of the
user account when it's a login script? (from what I've read, it seems
not)

From the reading I've done, it seems the only way really to do it is
to provide other credentials and run the script as another user. I'd
prefer not to use this option as storing the credentials of another
user with elevated priveleges in the script would be a security risk.
If this is the only way to do it, does anybody have tips on making
this option as secure as possible?

Thanks very much,
-Ryan

Have you considered using Scheduled Tasks instead of login scripts?
http://support.microsoft.com/default.aspx?scid=kb;en-us;308569&sd=tech

 

[Al Dunbar [MS-MVP]]

Have you considered using Scheduled Tasks instead of login scripts?
http://support.microsoft.com/default.aspx?scid=kb;en-us;308569&sd=tech

I'm wondering why the OP wants to do this kind of thing in a logon script.
Other options would include various schemes for remote script execution; WMI
scripting; or simply mapping to the local hard drive of a remote system as
\\computername\c$, and enumerating the contents.

/Al

 

[Ryan Nordman]

Thanks for your responses. We don't really want to use scheduled
tasks if we can avoid it. We have the task scheduler disabled with GP
because we don't want our users messing around with it. The main
reason behind doing this is to track all the files on the disk in case
a laptop is stolen. So the problem is we can't be sure when these
machines will be connected to the network or not. They can use cached
credentials and may be away for something like a week at a time. Some
kind of remotely executed script on an arbitrary schedule doesn't seem
like a good option because we couldn't be sure how often it would
actually find the machine connected. Is there a way we could trigger
a remote script when they log in to the network somehow? All our
workstations will be running Win XP Pro and all our servers are
running Windows Server 2003...

-Ryan

 

[Al Dunbar [MS-MVP]]

Had your first post provided the background as to why you were looking at
doing this (i.e. to manage stealable laptops that are used with cached
credentials), I would not have given the remote scripting suggestions.
Whatever you do, you definitely want it to be simple to maintain, generate
as minimal an impact on the user as possible, and fit well with your other
administrative processes. I'd suggest you investigate one of the stronger
"runas" packages (Run as Pro, perhaps), and make sure you leave no loopholes
in how you set it up, then run your script from the logon script. If this is
too much of an impact, on the user, you could have the logon script start a
low priority process to do the collection in the background.

But I'm still a bit confused as to what you will get out of a list of files
in the event that one of your laptops is stolen. Are you going to review
those files by name to determine what type of information might have been
stolen along with the computer.

Suppose someone logs on today and you get a completely accurate listing of
the files that exist at that time. The user then creates some new files and
copies some sensitive information from your network to work on at home. He
then takes the laptop home and generates all kinds of sensitive reports.
Then the laptop is stolen. Would your list tell you what was on the laptop
at the moment it was stolen?


/Al

Thanks for your responses. We don't really want to use scheduled
tasks if we can avoid it. We have the task scheduler disabled with GP
because we don't want our users messing around with it. The main
reason behind doing this is to track all the files on the disk in case
a laptop is stolen. So the problem is we can't be sure when these
machines will be connected to the network or not. They can use cached
credentials and may be away for something like a week at a time. Some
kind of remotely executed script on an arbitrary schedule doesn't seem
like a good option because we couldn't be sure how often it would
actually find the machine connected. Is there a way we could trigger
a remote script when they log in to the network somehow? All our
workstations will be running Win XP Pro and all our servers are
running Windows Server 2003...

-Ryan

"Al Dunbar [MS-MVP]" <[email protected]> wrote in message

I'm wondering why the OP wants to do this kind of thing in a logon script.
Other options would include various schemes for remote script execution; WMI
scripting; or simply mapping to the local hard drive of a remote system as
\\computername\c$, and enumerating the contents.

/Al

 

[Yevgen Lazaryev]

"Ryan Nordman" <[email protected]> a écrit dans le message de

| Is there a way we could trigger
| a remote script when they log in to the network somehow? All our
| workstations will be running Win XP Pro and all our servers are
| running Windows Server 2003...
|
| -Ryan
|

.... I risk to receive global criticism from Al again ... ... But I'll try
to suggest that you can use logon/logof audit along with an Event Log
monitoring script like this one
http://www.microsoft.com/technet/community/scriptcenter/monitor/scrmon21.mspx
to monitor for logon event, to retrieve computer name and then pass the name
and trigger another remote script (I would suggest just "dir /b
\\computer\C$\something >log.txt" - which is fast) ...perhaps you can use a
logoff event too but you never know how fast users can close the laptop ...

 

[Ryan Nordman]

After further review, I think we're going to use a scheduled task that
runs at user login after all. I'm having trouble getting my scripts
to run right now, I think it has to do with the computer thinking it
can't complete the script in the background (it doesn't prompt the
user for any info so I don't know why that is--but I digress, that's a
different topic).

Yes, as you said, the file logs will be there so we can see the names
of the documents and then check the network copies to know what was in
them. You're absolutely right about the usefulness of the file logs,
they won't be 100% up to date when the user is away. But I think most
of the sensitive data will be stuff that is from the network and not
really generated by the users in the span of time they're off the
grid. It's a bit of a silly exercise, but I don't make the decisions
on what is or isn't necessary for our security.

Thanks for your help Al, I really appreciate your input.
-Ryan

Had your first post provided the background as to why you were looking at
doing this (i.e. to manage stealable laptops that are used with cached
credentials), I would not have given the remote scripting suggestions.
Whatever you do, you definitely want it to be simple to maintain, generate
as minimal an impact on the user as possible, and fit well with your other
administrative processes. I'd suggest you investigate one of the stronger
"runas" packages (Run as Pro, perhaps), and make sure you leave no loopholes
in how you set it up, then run your script from the logon script. If this is
too much of an impact, on the user, you could have the logon script start a
low priority process to do the collection in the background.

But I'm still a bit confused as to what you will get out of a list of files
in the event that one of your laptops is stolen. Are you going to review
those files by name to determine what type of information might have been
stolen along with the computer.

Suppose someone logs on today and you get a completely accurate listing of
the files that exist at that time. The user then creates some new files and
copies some sensitive information from your network to work on at home. He
then takes the laptop home and generates all kinds of sensitive reports.
Then the laptop is stolen. Would your list tell you what was on the laptop
at the moment it was stolen?


/Al

Thanks for your responses. We don't really want to use scheduled
tasks if we can avoid it. We have the task scheduler disabled with GP
because we don't want our users messing around with it. The main
reason behind doing this is to track all the files on the disk in case
a laptop is stolen. So the problem is we can't be sure when these
machines will be connected to the network or not. They can use cached
credentials and may be away for something like a week at a time. Some
kind of remotely executed script on an arbitrary schedule doesn't seem
like a good option because we couldn't be sure how often it would
actually find the machine connected. Is there a way we could trigger
a remote script when they log in to the network somehow? All our
workstations will be running Win XP Pro and all our servers are
running Windows Server 2003...

-Ryan

"Al Dunbar [MS-MVP]" <[email protected]> wrote in message

I'm wondering why the OP wants to do this kind of thing in a logon script.
Other options would include various schemes for remote script execution; WMI
scripting; or simply mapping to the local hard drive of a remote system as
\\computername\c$, and enumerating the contents.

/Al

Note: cross-posted to microsoft.public.scripting.vbscript and
microsoft.public.windowsxp.security_admin

Hi guys,

I'm in need of some information about how the security and
impersonation of scripts works. I'm trying to create a login vbscript
that will enumerate certain types of files on the HD. The problem is
that we want it to run more often than when the computer is rebooted,
so it can't be a startup script. As a login script, the user logging
in doesn't have priveleges to see all the directories on the machine
(notably the documents & settings folders for other users), but we
want to enumerate the contents of those folders. What would you
suggest? Is there a way to use the machine account instead of the
user account when it's a login script? (from what I've read, it seems
not)

From the reading I've done, it seems the only way really to do it is
to provide other credentials and run the script as another user. I'd
prefer not to use this option as storing the credentials of another
user with elevated priveleges in the script would be a security risk.
If this is the only way to do it, does anybody have tips on making
this option as secure as possible?

Thanks very much,
-Ryan


Have you considered using Scheduled Tasks instead of login scripts?
http://support.microsoft.com/default.aspx?scid=kb;en-us;308569&sd=tech

 

[Al Dunbar [MS-MVP]]

You're welcome.

As to the silly exercise, how prevalent is the problem of laptop theft in
your organization? And, when stolen, how serious is the issue of information
disclosure, or is it more that they were stolen for the hardware?

Taking this a little further, consider what the worst case scenario would be
for your organization, then try to figure out what proportion of the
resulting losses (whether financial, loss of clients, loss of trust, etc)
would be re-couped simply by having some idea as to what information might
have disappeared along with the laptop.

Now consider how much it would cost to invest in *preventive* measures, and
see if that is more or less than the net loss of the calculation in the
above paragraph.

Measures *are* available for preventing the disclosure of information on
stolen computers, mainly in the area of encryption. The sophistication (and
cost) required will depend on the sophistication you would expect your
attackers to bring to bear.

Your exercise might indeed be *silly*, but the problem your company is
attempting to address might not be.

/Al

After further review, I think we're going to use a scheduled task that
runs at user login after all. I'm having trouble getting my scripts
to run right now, I think it has to do with the computer thinking it
can't complete the script in the background (it doesn't prompt the
user for any info so I don't know why that is--but I digress, that's a
different topic).

Yes, as you said, the file logs will be there so we can see the names
of the documents and then check the network copies to know what was in
them. You're absolutely right about the usefulness of the file logs,
they won't be 100% up to date when the user is away. But I think most
of the sensitive data will be stuff that is from the network and not
really generated by the users in the span of time they're off the
grid. It's a bit of a silly exercise, but I don't make the decisions
on what is or isn't necessary for our security.

Thanks for your help Al, I really appreciate your input.
-Ryan

"Al Dunbar [MS-MVP]" <[email protected]> wrote in message

Had your first post provided the background as to why you were looking at
doing this (i.e. to manage stealable laptops that are used with cached
credentials), I would not have given the remote scripting suggestions.
Whatever you do, you definitely want it to be simple to maintain, generate
as minimal an impact on the user as possible, and fit well with your other
administrative processes. I'd suggest you investigate one of the stronger
"runas" packages (Run as Pro, perhaps), and make sure you leave no loopholes
in how you set it up, then run your script from the logon script. If this is
too much of an impact, on the user, you could have the logon script start a
low priority process to do the collection in the background.

But I'm still a bit confused as to what you will get out of a list of files
in the event that one of your laptops is stolen. Are you going to review
those files by name to determine what type of information might have been
stolen along with the computer.

Suppose someone logs on today and you get a completely accurate listing of
the files that exist at that time. The user then creates some new files and
copies some sensitive information from your network to work on at home. He
then takes the laptop home and generates all kinds of sensitive reports.
Then the laptop is stolen. Would your list tell you what was on the laptop
at the moment it was stolen?


/Al

Thanks for your responses. We don't really want to use scheduled
tasks if we can avoid it. We have the task scheduler disabled with GP
because we don't want our users messing around with it. The main
reason behind doing this is to track all the files on the disk in case
a laptop is stolen. So the problem is we can't be sure when these
machines will be connected to the network or not. They can use cached
credentials and may be away for something like a week at a time. Some
kind of remotely executed script on an arbitrary schedule doesn't seem
like a good option because we couldn't be sure how often it would
actually find the machine connected. Is there a way we could trigger
a remote script when they log in to the network somehow? All our
workstations will be running Win XP Pro and all our servers are
running Windows Server 2003...

-Ryan

"Al Dunbar [MS-MVP]" <[email protected]> wrote in message

I'm wondering why the OP wants to do this kind of thing in a logon script.
Other options would include various schemes for remote script

execution;
WMI

scripting; or simply mapping to the local hard drive of a remote

system
as

\\computername\c$, and enumerating the contents.

/Al

Note: cross-posted to microsoft.public.scripting.vbscript and
microsoft.public.windowsxp.security_admin

Hi guys,

I'm in need of some information about how the security and
impersonation of scripts works. I'm trying to create a login vbscript
that will enumerate certain types of files on the HD. The

problem
is

that we want it to run more often than when the computer is rebooted,
so it can't be a startup script. As a login script, the user logging
in doesn't have priveleges to see all the directories on the machine
(notably the documents & settings folders for other users), but we
want to enumerate the contents of those folders. What would you
suggest? Is there a way to use the machine account instead of the
user account when it's a login script? (from what I've read, it seems
not)

From the reading I've done, it seems the only way really to do it is
to provide other credentials and run the script as another user. I'd
prefer not to use this option as storing the credentials of another
user with elevated priveleges in the script would be a security risk.
If this is the only way to do it, does anybody have tips on making
this option as secure as possible?

Thanks very much,
-Ryan


Have you considered using Scheduled Tasks instead of login scripts?

http://support.microsoft.com/default.aspx?scid=kb;en-us;308569&sd=tech

 

[Al Dunbar [MS-MVP]]

"Ryan Nordman" <[email protected]> a écrit dans le message de

| Is there a way we could trigger
| a remote script when they log in to the network somehow? All our
| workstations will be running Win XP Pro and all our servers are
| running Windows Server 2003...
|
| -Ryan
|

... I risk to receive global criticism from Al again ... ...

Hahaha! But, given that I assume from your name that we are not both in
Canada, the only *kind* of criticism available to me is global...

LOL. you caught be on a good day, as I don't much feel like criticizing. At
least in this case, the OP seems to be up to properly evaluating the various
bits of advice he is getting to see what suits best...

/Al