[XP] VBScript Loginscript - Toegang Geweigerd probleem

[Verwijderd]

Hallo,

Ik heb een probleem met het uitvoeren van een VBS loginscript.
Ik ben zelf een newbie op het gebied van VBScript en Windows Script Host.
Ik heb het internet en dit forum afgestruind naar antwoorden maar niks gevonden. 1 topic had hetzelfde probleem maar de user had alles ge-edit (Stond: Opgelost) en deze persoon reageert niet op pm of email.

Het probleem:
Het loginscript moet uitgevoerd bij alle profielen (gebruikers en admins).
Het betreft een omgeving van 108 gebruikeraccounts en allemaal XP Clients met een Win2000 server.

Als een administrator inlogt, werkt het script 'perfect'. (Drivemapping / rechten etc.).

Als een normale gebruiker inlogt, wordt de volgende melding weergegeven:
"Kan instellingen niet laden (Toegang geweigerd)"

Het maakt niet uit of ik de VBS direct mee laat starten als loginscript of aanroep vanuit een batch file die als loginscript dient.
Ik heb verder op de nodige bestanden (volgens sommige fora: wscript.exe, vscript.dll, cscript.exe alle toegang verleend aan alle gebruikers die inloggen op een client (lokaal geregeld dus)).

Het is dus duidelijk een rechten probleem in mijn ogen.
Hoe kan ik ervoor zorgen dat gewone gebruikers (Groep: DCGEBRUIKERS) wel VBS Scripts kunnen laten uitvoeren?

Alvast bedankt voor jullie reacties!

[BtM909]

Ligt het probleem echt aan je VBScript of aan de inhoud. Als je alles eruit stript krijg je dan ook nog de melding?

[TheVMaster]

Probeer bovenstaand eens...enneh..zit er naast de vbs nog een wsh of iets van die strekking bij het loginscript?

plak anders eens alleen een

code:

wscript.ech("Hallo")

in het vbs'je...

[Verwijderd]

Dit is een gestripte versie van de VBS file.
Nu maakt het alleen een drivemap aan die bestaat (werkt onder administrator).

Ik heb ook getest met de echo("Hallo") maar gelijk bij het opstarten, geeft Windows de foutmelding.

code:

Option Explicit
Dim objNetwork 
Dim strDriveLetter, strRemotePath 

strDriveLetter = "K:" 
strRemotePath = "\\fs1\Raid" 

Set objNetwork = CreateObject("WScript.Network") 
objNetwork.MapNetworkDrive strDriveLetter, strRemotePath 

' Extra code just to add a message box
WScript.Echo " K aangemaakt, check: "& strDriveLetter 

WScript.Quit

Hierboven dus een werkende script als je als admin inlogt op het netwerk hier.
Maakt dus een K: aan en geeft een melding.
Als gebruiker inloggen: Toegang geweigerd melding

---

Ik heb wel eens eerder met Group Policies gewerkt maar dit is een zwart gat nu.
Moet ik misschien hierin bepaalde rechten uitgeven naar de gebruikers?

[ Voor 29% gewijzigd door Verwijderd op 14-07-2006 11:00 ]

[TheVMaster]

Ehh..hebben die 'normale' gebruikers wel rechten op de K schijf? Dat is volgens mij het proleem...of heeft een gebruikers geen rechten om een drive mapping aan te maken...

[ Voor 32% gewijzigd door TheVMaster op 14-07-2006 11:01 ]

[Verwijderd]

TheVMaster schreef op vrijdag 14 juli 2006 @ 11:01:
Ehh..hebben die 'normale' gebruikers wel rechten op de K schijf? Dat is volgens mij het proleem...of heeft een gebruikers geen rechten om een drive mapping aan te maken...

Gebruikers hebben deze rechten wel.
We draaien op het moment een batch bestand die ook drivemaps aanmaakt zonder problemen.
Je kan ook bijvoorbeeld geen message tonen via een VBS bestand (zonder drivemapping etc.)

Alleen met een VBS bestand heb ik het gevoel dat je meer functionaliteit kan toevoegen.

[TheVMaster]

Het lijkt overigens wel alsof hij de scriptinghost niet mag laden. Weet je zeker dat die rechten goed staan. Als je onder een gebruiker cscript of wscript uitvoert wat zie je dan?

[Verwijderd]

TheVMaster schreef op vrijdag 14 juli 2006 @ 11:16:
Het lijkt overigens wel alsof hij de scriptinghost niet mag laden. Weet je zeker dat die rechten goed staan. Als je onder een gebruiker cscript of wscript uitvoert wat zie je dan?

Je ziet niks.
Normaal heb je dan de instellingen voor Wscript maar bij een gebruiker gebeurt er niks.

Voer je lokaal vbs bestanden uit wordt de foutmelding (bovenstaande posts) getoond.

Ik weet niet precies waar ik de rechten kan veranderen voor de scriptinghost.
Lokaal werkt niet dus dan moet het aan het profiel / groepsprofiel liggen?

[TheVMaster]

Al op Technet gezocht (op de foutmelding die je krijgt?) -> www.microsoft.com/technet

[Verwijderd]

TheVMaster schreef op vrijdag 14 juli 2006 @ 12:51:
Al op Technet gezocht (op de foutmelding die je krijgt?) -> www.microsoft.com/technet

Ik heb daarop gezocht en niks gevonden.
Microsoft uitgepluist.
Ik ben nu bezig met bepaalde zaken te veranderen in de Registry om misschien op deze manier rechten te verlenen aan WSH

[Rfce]

TheVMaster schreef op vrijdag 14 juli 2006 @ 11:16:
Het lijkt overigens wel alsof hij de scriptinghost niet mag laden.

Lijkt me ook...

Als je nu eens als user inlogt, en dan het vb script vanaf het buroblad start... zo kun je makkelijk testen.
Als je WScript.Echo .... voor objNetwork.MapNetworkDrive....... zet, krijg je wel de melding neem ik aan?

Je hebt toch niet ergens een policy aanstaan die runnen van vb script tegen gaat voor users?? (check Technet)

[alt-92]

Verwijderd schreef op vrijdag 14 juli 2006 @ 13:03:
[...]


Ik heb daarop gezocht en niks gevonden.
Microsoft uitgepluist.
Ik ben nu bezig met bepaalde zaken te veranderen in de Registry om misschien op deze manier rechten te verlenen aan WSH

Da's dus de verkeerde manier van werken.

Je hoort je scripts e.d. dusdanig te maken dat ze met minimale rechten hun werk kunnen doen.
Anders kan je je users net zogoed Domain Admin maken.

[elevator]

Begin eens met de basics - als je nou in een command prompt met een normale user eens "cscript" opstart, wat krijg je dan te zien?

Ga dan eens dit doen: [rml]TheVMaster in "[ XP] VBScript Loginscript - Toegang Gewe..."[/rml] post dat in een textfile, en voer dan uit: cscript //e:vbscript filename.vbs -- wat krijg je dan?

[Verwijderd]

@Backslash
Hier heb je idd gelijk in.
Voor de gebruikers is alles verder dichtgegooid.
Zij hebben alleen toegang tot hun user schijf en verder kunnen zij weinig doen in Windows.
Vandaar dat er in mijn ogen weinig uitmaakt of de gebruikers alle rechten op beide registry groepen LOCAL_MACINE en USERS hebben. Aangezien zij dit niet weten en regedit niet kunnen benaderen of installaties kunnen uitvoeren.

---

elevator schreef op vrijdag 14 juli 2006 @ 22:35:
Begin eens met de basics - als je nou in een command prompt met een normale user eens "cscript" opstart, wat krijg je dan te zien?

Ga dan eens dit doen: [rml]TheVMaster in "[ XP] VBScript Loginscript - Toegang Gewe..."[/rml] post dat in een textfile, en voer dan uit: cscript //e:vbscript filename.vbs -- wat krijg je dan?

Verder, zoals eerder vermeld volgens mij, is het onmogelijk om VBscripts te runnen.
Dus ook lokaal een bestand openen of via de command maakt niet uit.
De standaard melding blijft komen.
Als ik cscript of wscript intik en uitvoer dan gebeurt er helemaal niks.
Je ziet niks en krijg geen foutmelding terwijl je normaal de instellingen kan veranderen.

[ Voor 35% gewijzigd door Verwijderd op 17-07-2006 08:25 ]

[Verwijderd]

Ehm, denk dat je gebruikers op het moment van uitvoeren gewoon nog geen K-drive hebben of dat ze geen rechten hebben op de K-drive of op de script file. Niet zo moeilijk kijken, de oplossing is vaak dichterbij en eenvoudig.

[Verwijderd]

Verwijderd schreef op maandag 17 juli 2006 @ 08:33:
Ehm, denk dat je gebruikers op het moment van uitvoeren gewoon nog geen K-drive hebben of dat ze geen rechten hebben op de K-drive of op de script file. Niet zo moeilijk kijken, de oplossing is vaak dichterbij en eenvoudig.

Hier is allemaal al naar gekeken.
Alle drivemaps in het mogelijke script zijn beschikbaar voor de gebruikers want zoals eerder vermeld wordt er nu een batch file gebruikt die hetzelfde doet qua drivemapping.
De script file is gewoon een loginscript en is voor iedereen toegankelijk en uitvoerbaar. (NETLOGON)

Het zal misschien dieper in de policies zitten.
Ik wil dit toch beter uitgewerkt hebben dan dat ik iedereen alle rechten geef op de register groepen.

Toch nog even bedankt voor iedereen die heeft gereageerd hierboven.

[Verwijderd]

Het probleem is gevonden mensen.

De vorige systeembeheerder had in het standaard profiel scripting uit gezet.
NTUSER.dat file dus.
Dus elke nieuwe gebruiker toendertijd had geen scripting.
Dus een overtreffende policy creëren en dat zal voldoende zijn en een nieuw standaard profiel aanmaken.

[TheVMaster]

Verwijderd schreef op woensdag 19 juli 2006 @ 15:51:
Het probleem is gevonden mensen.

De vorige systeembeheerder had in het standaard profiel scripting uit gezet.
NTUSER.dat file dus.
Dus elke nieuwe gebruiker toendertijd had geen scripting.
Dus een overtreffende policy creëren en dat zal voldoende zijn en een nieuw standaard profiel aanmaken.

Thnx dat je de oplossing nog even met ons gedeeld hebt