Logon script "permission denied"
JaR
computer with Admin credentials, the script runs perfectly, with normal
user logins, I get an "permission denied" error. I have given the group
Read & Execute permissions to the file. Even tried Full Control.
What the heck am I doing wrong?
--
JaR
When the very best is not nearly enough
Remove hat to reply
Florian Frommherz [MVP]
JaR wrote:
> I am having trouble with a logon .vbs script. If I log into a network
> computer with Admin credentials, the script runs perfectly, with normal
> user logins, I get an "permission denied" error. I have given the group
> Read & Execute permissions to the file. Even tried Full Control.
What does the script do? What are the permissions on the share the
script is on? Have you checked "Authenticated Users" is still listed in
the ACL?
cheers,
Florian
--
Microsoft MVP - Group Policy
eMail: prename [at] frickelsoft [dot] net.
blog: http://www.frickelsoft.net/blog.
Maillist (german): http://frickelsoft.net/cms/index.php?page=mailingliste
JaR
> Howdie!
>
> JaR wrote:
> > I am having trouble with a logon .vbs script. If I log into a
> > network computer with Admin credentials, the script runs perfectly,
> > with normal user logins, I get an "permission denied" error. I have
> > given the group Read & Execute permissions to the file. Even tried
> > Full Control.
>
> What does the script do? What are the permissions on the share the
> script is on? Have you checked "Authenticated Users" is still listed
> in the ACL?
>
> cheers,
>
> Florian
Howdie! to you too, and thanks for the reply.
The script removes McAfee Enterprise AV from the computers in our
domain. The script is in NETLOGON on the AD server, and Authenticated
Users, SYSTEM, Everyone, & Users all have Read & Execute permissions.
Dunno about the ACL, how can I check that? I can't seem to get to the
netlogon share from the command prompt to run calcs.
Raptor
> Howdie! to you too, and thanks for the reply.
>
>
> The script removes McAfee Enterprise AV from the computers in our
> domain. The script is in NETLOGON on the AD server, and Authenticated
> Users, SYSTEM, Everyone, & Users all have Read & Execute permissions.
>
> Dunno about the ACL, how can I check that? I can't seem to get to the
> netlogon share from the command prompt to run calcs.
>
> --
> JaR
> When the very best is not nearly enough
> Remove hat to reply
It sounds as though the permission denied is coming from the fact that the
user does not have the permission to remove program files and not that they
are being denied from the script.
JaR
That's what I was afraid of. I was under the missaprehension that logon
scripts deployed thru GP would run regardless of the user's permissions.
Is there a way around this? The users here are all running XP Pro. Can
one do some variation of Runas?
JR
By the way; apologies for the "unmitigated gall" in that reply.
Inadvertently used an identity usually reserved for less serious NGs ;-)
--
JaR
Muddlin' thru
JR
Oboy. When I tried earlier with *my* login it ran. I also have specific
local admin rights on that machine. I tried giving the test users admin
in AD and it still errors out. The only way it works is if I give them
local admin rights. What gives?
--
JaR
Muddlin' thru
Florian Frommherz [MVP]
JR wrote:
> Oboy. When I tried earlier with *my* login it ran. I also have specific
> local admin rights on that machine. I tried giving the test users admin
> in AD and it still errors out. The only way it works is if I give them
> local admin rights. What gives?
"admin in AD" does mean what? You put them into the domain admins group?
That should work, too. You'd basically have to - as you already figured
- give those users permission to uninstall the software locally which
would be local admins. I guess you don't want that so let's try a
computer start up (hook the script to the computers on startup rather
than for the users on logon). That has the effect that the script (like
all startup scripts) runs in the local machine's SYSTEM context and
therefore has sufficient rights to perform the uninstall (again: user
logon scripts run in the user's context therefore with the user's
permission). Depending on what the uninstall does, it should work (if it
needs a "real" profile and logon credential for whatever reason, it may
fail, though - I've seen that before). In most cases using a startup
script works fine.
Iskandar Zulkarnain@discussions.microsoft.com Bobby Iskandar Zulkarnain
"JaR" wrote:
Dear JaR,
To successfully running the script as you mentioned above, please give the
user account the user right capability--> Log on as a batch job.
You can set it easy by editing GPO on the container where the user reside.
If it is on an OU, set and modify the GPO for the OU so that the user right
assigment on that user has log on as a batch job.
Good luck...
Bobby Iskandar Zulkarnain, MCT
www.zulkarnain.com
http://wss-id.org/blogs/bobby
JR
Hi Bobby;
Sorry I wasn't able to respond until today, but a few other emergencies
have been occupying my time since you responded ;-)
I did as you suggested, and gave the container "Log on as a batch job"
permission, but the script still gets an error box saying "permission
denied" when one of the users from that container logs on.
Thank you for the suggestion.
--
JaR
Muddlin' thru
JR
> Howdie!
>
> JR wrote:
> > Oboy. When I tried earlier with my login it ran. I also have
> > specific local admin rights on that machine. I tried giving the
> > test users admin in AD and it still errors out. The only way it
> > works is if I give them local admin rights. What gives?
>
> "admin in AD" does mean what? You put them into the domain admins
> group? That should work, too. You'd basically have to - as you
> already figured - give those users permission to uninstall the
> software locally which would be local admins. I guess you don't want
> that so let's try a computer start up (hook the script to the
> computers on startup rather than for the users on logon). That has
> the effect that the script (like all startup scripts) runs in the
> local machine's SYSTEM context and therefore has sufficient rights to
> perform the uninstall (again: user logon scripts run in the user's
> context therefore with the user's permission). Depending on what the
> uninstall does, it should work (if it needs a "real" profile and
> logon credential for whatever reason, it may fail, though - I've seen
> that before). In most cases using a startup script works fine.
>
> cheers,
>
> Florian
Hullo Florian!
Sorry for not getting back sooner, but I've been swamped here last few
days. Got some time to play with this again now.
Yes, as you guessed, "admin in AD" meant that I tried giving a couple
of the users Administrator rights. I created an OU called "test staff"
that I populated with users "test1, test2, etc" and have been trying to
deploy the script to this group in advance of going Domain-wide. No
worries about giving someone something they shouldn't have ;-)
Weirdly, granting them Admin privs doesn't seem to work, either.
I added the script in the startup properties for that OU, but it seems
that nothing at all is happening. No error message, nada.
Thanks for bearing with me.
--
JaR
Muddlin' thru
Florian Frommherz [MVP]
"JR" wrote:
> Weirdly, granting them Admin privs doesn't seem to work, either.
>
> I added the script in the startup properties for that OU, but it seems
> that nothing at all is happening. No error message, nada.
So a machine startup script wasn't a go? What if you pipe the script's
output to some place on the harddisk like
script.bat >> C:\script_output.txt ? When executed locally, does the script
run?
JR
> JR,
>
> "JR" wrote:
> > Weirdly, granting them Admin privs doesn't seem to work, either.
> >
> > I added the script in the startup properties for that OU, but it
> > seems that nothing at all is happening. No error message, nada.
>
> So a machine startup script wasn't a go? What if you pipe the
> script's output to some place on the harddisk like script.bat >>
> C:\script_output.txt ? When executed locally, does the script run?
>
> cheers,
>
> Florian
G'day Florian;
It seems that it just took a day for the change to GP to propagate. I
came in this AM and tried one last time to see if the startup script
would run and it did. I don't know why it took so long, but at least it
works!
Can't thank you enough.
--
JaR
Muddlin' thru
Florian Frommherz [MVP]
> It seems that it just took a day for the change to GP to propagate. I
> came in this AM and tried one last time to see if the startup script
> would run and it did. I don't know why it took so long, but at least it
> works!
I'm glad you got it working. I can't really think of a good reason why
it would take so long to show effect. Reasons could be replication delay
(FRS or AD) or the machine just hasn't rebooted as startup scripts are
only executed on reboot.
Good to hear it's working how. Thanks for the feedback!