• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1633
  • Last Modified:

LOGON USER SCRIPT RIGHTS

Hello:

I have the following script that updates the computer description in active directory with the logged user but it only works if the logged user has admin rights. Can anyone tell me how can I modify the following code to make it work for users that have not any admin rights...lets say to impersonate another domain account to run this script.

strComputer = "."

Dim adsinfo,nw
Set adsinfo = CreateObject("adsysteminfo")
Set ThisComp = GetObject("LDAP://" & adsinfo.ComputerName)
Set oUser = CreateObject("WScript.NetWork")
Thiscomp.put "description", " User: " & oUser.UserName
ThisComp.Setinfo
Next


This is very urgent for me as I have to do it this weekend for 5000 computer accounts.

thanks a lot in advance
0
Pollin
Asked:
Pollin
  • 10
  • 5
1 Solution
 
Chris DentPowerShell DeveloperCommented:

Perhaps this little tool will help...

http://www.joeware.net/win/free/tools/cpau.htm

It would allow you to run the script as Admin without having to write the password in a place people can "borrow" it.

Chris
0
 
PollinAuthor Commented:
Hello Again Chris:

is there any way to pass the password encrypted?
I am not allowed to use unencrypted passwords as many users has read access to the domain policies.
0
 
Chris DentPowerShell DeveloperCommented:

Yep, that's one of the features of the tool and really why I suggested it over something like the runas command.

You need to create a Job file first, then that's what you end up running. Lets see, it should be something like:

cpau -u yourdomain\administrator -p <password> -ex "<VbScriptName>" -file "<This is the file we're creating>" -enc

i.e.

cpau -u domain\administrator -p Password324 -ex UpdateCompDescription.vbs -file UpdateCompDescription.txt -enc

Now all you need to do is run that Job file from the logon script:

cpau -file UpdateCompDescription.txt -dec -profile

Chris
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
Chris DentPowerShell DeveloperCommented:

By the way, you will need to put CPAU in a shared location as well as the VbScript and the Job file you create.

Chris
0
 
PollinAuthor Commented:
thanks Chris,
I am trying to use the syntaxis you gave me but there is an error:

To encode I use:

     cpau -u testdomain\teastadmin -p PWD$$ -ex pcdescription.vbs -file pcdescription.txt -en

To run it:

     cpau -file pcdescription.txt -dec -profile

The Error:

          CPAU V01.11.00cpp Joe Richards (joe@joeware.net) November 2005

          Current Security Context: testdomain\testuser
          Attempting to use job file pcdescription.txt
          Successfully Processed Job File
          Error: Couldn't create Process: (193) Unknown Error

The command did not complete successfully.


Do you have any idea why?
0
 
Chris DentPowerShell DeveloperCommented:

-en should be -enc but I guess that's just a typo in the question if it's created the Job file.

Chris
0
 
Chris DentPowerShell DeveloperCommented:

The pcdescription.vbs file is in the same place you're running cpau from right?

I just wonder if you need more of a path there.

Chris
0
 
PollinAuthor Commented:
Yes all are in the same directory, I am testing before configuring it as a logon script.
Also I have been reading the help file of the utility and it says something like if it will be used as a logon script it should be copied locally as the utility doesn't work with network paths... here is the notes:

Notes:
  I had to add some protection to this app. It seems people were running this with
  a networked drive for the current working directory. Microsoft prevents cross-
  security context access of network drives on purpose, this causes CPAU
  to not be able to fire the process up. To correct for that, if CPAU realizes
  your current working directory is a network drive it will change the CWD to the
  default local path (usually c:\windows\system32). To override this functionality
  you must specify the CWD option, note that if you set it to a network
  drive you most likely will not function properly. Also note that this is
  not a bug in CPAU, this is purposeful functionality from MS. You can see this
  out of anything that changes your local security context.

  If you are using this for a logon script or something else where
  you need the permissions to take affect locally, you need to specify the
  -lwp (or -profile) switch. By default the process spawned has the current
  user's security context locally and the new security context remotely. Also
  keep in mind the note above concerning network drives, logon scripts run from
  network drives, you will need to set the CWD to a local machine
  (c:\temp maybe) and copy whatever files are necessary locally and then run cpau.

What do you think?

thanks
0
 
Chris DentPowerShell DeveloperCommented:

Reading the help files would always be helpful and it sounds like it describes the problem you're having.

The user should have permission to write to their own temp directories at the very least, i.e. %userprofile%\local settings\temp. It would certainly be worth copying the files there before running them to see if it solves the problem.

Chris
0
 
PollinAuthor Commented:
just done it but still doesn't work.

What about using the createprocess method from WMI to impersonate a user?
I have this code that runs a command on a remote computer impersonating a domain user account but don't know how to convert my script to access active directory using WMI impersonation.

This script optain the free space data on a remote server:

strComputer = "Server1"
Set objWMIService = GetObject("winmgmts:" _
    & "{authenticationLevel=Pkt}!\\" _
    & strComputer & "\root\cimv2")
Set colDisks = objWMIService.ExecQuery _
    ("Select * from Win32_LogicalDisk")
For each objDisk in colDisks
    Wscript.Echo "DeviceID: " & vbTab & _
        objDisk.DeviceID & vbNewLine & _
        "FreeSpace: " & vbTab & objDisk.FreeSpace
    NextstrComputer = "."
    Set objServices = GetObject( _
        "winmgmts:{impersonationLevel=impersonate," _
        & "authenticationLevel=pktPrivacy}!root/cimv2")
    Set objProcessSet = objServices.ExecQuery _
        ("SELECT Name FROM Win32_Process",,48)
    For Each Process in objProcessSet
        WScript.Echo Process.Name
    Next
Next

do you know how to change it to update an active directory object?
0
 
Chris DentPowerShell DeveloperCommented:

You're not actually raising your priviledges with the WMI script though, that's not what the ImpersonationLevel and AuthenticationLevel are there for - so it wouldn't help too much with allowing a User to update AD (even though there is a WMI interface for AD).

With ImpersonationLevel set to Impersonate you're basically executing the remote WMI query with the User Account running the script. I believe Impersonate is the default as the two lower levels of impersonation (Anonymous and Identify) really aren't all that useful for running scripts remotely.

Authentication Level is used to control the data flow, and in effect it requests that it be secure. There's no guarantee of that security though.

You can read all about WMI monikers on the MS Site:

http://www.microsoft.com/technet/scriptcenter/guide/sas_wmi_vzbp.mspx?mfr=true

Except for using a tool such as CPAU I can't really think of a way to allow end-users to update AD.

Chris
0
 
Chris DentPowerShell DeveloperCommented:

Can a standard user actually run the Job file with CPAU after logon (that is, not as part of the logon script)? Or does it just not work at all?

If it doesn't work does it work when run as Administrator?

Chris
0
 
Chris DentPowerShell DeveloperCommented:

Incidently you could use something like CreateProcess to launch the script on the local machine as Administrator. But if you're doing that you may as well just run the entire thing remotely as the currently logged on user and the computer model (discussed in the other question) are available to anyone with access to WMI.

While that method isn't good for a continual update, or even for dealing with PCs where the user is away it should be able to capture the majority.

Chris
0
 
PollinAuthor Commented:
using the utility doesn't work even if i am logged as the administrator, it returns the same error.
Maybe I am using wrong the utility? the .txt is created so I think is not a problem when encoding.
do I need the parameters -profile or -pdw ?
please help me Chris!!!!
I just want my users to update the computer description in AD doesn't matter how, I just don't wanna give them any additional rights.
thanks much
0
 
Chris DentPowerShell DeveloperCommented:

Sorry for the delay, bit of a busy weekend.

-profile should really achieve the same as -lwp, if it doesn't work with either then it implies something else is wrong. Did you also copy the script locally and do -cwd <local path>?

If that is the case then it should all be simplified a little, first try running the script with CPAU but without encrypting everything:

CPAU -u domain\administrator -p <Password> -ex <ScriptName> -profile -cwd <Local Path of script>

We could potentially just run through every PC on the network and pull the details from WMI to write into the computer account, but it would be difficult to ensure that the right details are being added. However, if you're interested in trying it then let me know and I'll drop something in.

Chris
0

Featured Post

Prepare for your VMware VCP6-DCV exam.

Josh Coen and Jason Langer have prepared the latest edition of VCP study guide. Both authors have been working in the IT field for more than a decade, and both hold VMware certifications. This 163-page guide covers all 10 of the exam blueprint sections.

  • 10
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now