[2K] VBS-startupscript kan geen bestanden lezen van share?

Pagina: 1
Acties:

  • Kjev
  • Registratie: Juni 2001
  • Laatst online: 02-01-2024
Ik ben een heel aardig startup- en logon-script aan het opzetten in VBS, voor de computers in mijn domein (alle Win2k SP4). Het idee is dat een hoofdscript alle subscriptjes in een map uitvoert. Die subscriptjes doen ook een aantal bewerkingen met bestanden (kopieren naar lokale schijf).

Nu heb ik een probleem waar ik op internet verdomd weinig over kan vinden. Het userscript werkt naar behoren, maar het computerscript (in de GPO gedefinieerd bij Startup) kan helemaal niets met bestanden op de Sysvol-share op de domeincontroller (\\domain\sysvol). Blijkbaar zorgt de group policy dat 'ie op een ander manier aan z'n startup script komt dan via een aanroep van deze share.

Gevolg is dat ik andere scripts niet kan uitvoeren en geen bestanden van de share naar de lokale schijf kan kopieren. Er zijn natuurlijk wel allerlei workarounds te verzinnen (alles in één script en bestanden kopieren als user), maar dat is eigenlijk m'n eer te na ;).

De rechten op de benodigde bestanden staan nu even op 'Everyone - Read & Execute', dus dat is het probleem niet. Ik heb ook geprobeerd gewoon een CopyFile te doen vanaf het netwerk en ook dat werkt niet.

De code die ik gebruik is als volgt (objecten worden elders gedefinieerd - objFileSystem is FileSystemObject en objShell is Wscript.Shell):
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
' This script will read and execute all scripts in .\computer\ in alphabetical sequence.
' You can add a number to filenames to manage execution order (e.g. 000.drives.vbs)

Set pntComputerScriptsPath = objFilesystem.GetFolder("\\domain\sysvol\[domeinnaam]\scripts\policy\computer")
strComputerScriptsPath = pntComputerScriptsPath.Path
Set pntComputerScripts = pntComputerScriptsPath.Files

objShell.LogEvent INFORMATION, "POLICY_DEBUG: Path is " & strComputerScriptsPath

For Each pntComputerScript In pntComputerScripts
    strComputerScript = strComputerScriptsPath & "\" & pntComputerScript.Name
    Set objComputerScript = objFilesystem.OpenTextFile(strComputerScript, 1)
    strCode = objComputerScript.ReadAll
    objComputerScript.Close
    Execute strCode
Next

Het eventlog meldt vervolgens 'Path is ' zonder pad, dus het hele object pntComputerScriptsPath werkt niet.
Is er een manier om een computer-startupscript toch dingen te laten doen met bestanden op een netwerkshare?

  • StevenK
  • Registratie: Februari 2001
  • Laatst online: 21:38
AFAIK draait je startup-script niet in een user-context, dus dan kun je geen shares benaderen, behalve null-session shares (http://support.microsoft.com/kb/q289655/)

Was advocaat maar vindt het juridische nog steeds leuk. Doet tegenwoordig iets in de metaal.


  • Kjev
  • Registratie: Juni 2001
  • Laatst online: 02-01-2024
Woah. Windows maakt een DFS-root blijkbaar standaard 'null-session'. Het is een klein domein en fileserver is tevens DC. Sysvol staat in een map binnen de DFS-root, dus op die manier kom ik er wel binnen.
Ik moet eens goed gaan nadenken over de beveiligingsconsequenties hiervan... dit is nou iets waar ik nog nooit bij stilgestaan had. Desondanks bedankt voor het op weg helpen! :)

Verwijderd

Kjev schreef op maandag 18 juli 2005 @ 14:38:
Woah. Windows maakt een DFS-root blijkbaar standaard 'null-session'. Het is een klein domein en fileserver is tevens DC. Sysvol staat in een map binnen de DFS-root, dus op die manier kom ik er wel binnen.
Ik moet eens goed gaan nadenken over de beveiligingsconsequenties hiervan... dit is nou iets waar ik nog nooit bij stilgestaan had. Desondanks bedankt voor het op weg helpen! :)
windows maakt helemaal niet standaard null sessies, zoals in dat article al staat moet je 3 keys wijzigen om het mogelijk te maken (in win2k en hoger). in nt4 was het geloof ik wel mogelijk om standaard null sessies te doen.

je kan beter proberen de security context van je scripts te wijzigen, zodat een nullsessie niet nodig is, want dat is inderdaad een groot gat als je dat openzet.

[ Voor 12% gewijzigd door Verwijderd op 19-07-2005 13:48 ]


  • Kjev
  • Registratie: Juni 2001
  • Laatst online: 02-01-2024
Verwijderd schreef op dinsdag 19 juli 2005 @ 13:46:
windows maakt helemaal niet standaard null sessies, zoals in dat article al staat moet je 3 keys wijzigen om het mogelijk te maken (in win2k en hoger). in nt4 was het geloof ik wel mogelijk om standaard null sessies te doen.
o.a. Technet op diverse plaatsen:
Network access: Shares that can be accessed anonymously

The Network access: Shares that can be accessed anonymously policy setting determines which network shares anonymous users can access.

Stand-Alone Server Default Settings COMCFG,DFS$
DC Effective Default Settings COMCFG,DFS$
Member Server Effective Default Settings COMCFG,DFS$
Zo staat 'ie op mijn (redelijk vers geinstalleerde) Win2k/Win2k3 servers in elk geval ook. DFS-roots zijn dus standaard toegankelijk via null-sessie. Of dat goed is, is een ander verhaal... maar permissies voor vrijwel alles staat standaard ook op 'Authenticated Users' ipv op 'Everyone'
je kan beter proberen de security context van je scripts te wijzigen, zodat een nullsessie niet nodig is, want dat is inderdaad een groot gat als je dat openzet.
Daar ga ik zeker eens naar kijken.

[ Voor 6% gewijzigd door Kjev op 19-07-2005 16:53 ]