win 2003 login script vbs global local groups

[Verwijderd]

Hallo,

Bij mijn weten heb je users, steek je die in global groups, global groups in local groups. Dan kan je rechten toekennen aan een local group.
Ik heb hier een domaincontroller en een fileserver.
Op een bepaalde map (share) heb ik rechten toegekend op local group niveau volgens bovenstaande uitleg => werkt perfect.

Probleem zit hem in mijn login script:

set objShell = WScript.CreateObject("WScript.Shell")
set objNetwork = WScript.CreateObject("WScript.Network")

strDomain = objNetwork.UserDomain
strUser = objNetwork.UserName


'Check ICT membership
'if user is member map the M: drive
if IsMember("LS_dir_ict_read") = true then
objNetwork.MapNetworkDrive "W:", "\\SFILEX2\Vanheede\Vanheede Environment Group\ICT"
end if

Function IsMember(sGroup)
dim objAdmins, user
IsMember = False
set objAdmins = GetObject("WinNT://Vanheede/" & sGroup & ",group")
for each user in objAdmins.members
if user.name = strUser then
IsMember = True
end if
next
End Function


De mapping met de W: drive werkt niet. Stop ik een user echter rechtstreeks in LS_dir_ict_read dan lukt het direct. Zit de user in een global en die global in LS_dir_ict_read, dan lukt het niet.

Dit vind ik wel bizar, ligt de fout ergens in mijn login script ?

Iemand die mij hierbij kan helpen?

Alvast bedankt!

[WaSteiL]

Je moet je group membership op een andere manier uitlezen. Stel dat je nu namelijk 1000 mensen in een group hebt staan en toevallig heeft deze persoon ook nog eens een naam met bijvoorbeeld de Z dan zal hij alles moeten doorlopen. Zonde van de tijd en mogelijk loopt hij daar op stuk.

Als ik het nog even verder kijk dan lijkt het wel alsof je de rechten op de map zelf uitleest terwijl je beter de group membership van de gebruiker in AD kan uitlezen.

Ik gebruik zelf onderstaand script die ik even voor je heb aangepast met jouw gegevens. Op die manier heb je sowieso duidelijker je gegevens die mogelijk kunnen wijzigen in beeld (bijvoorbeeld je shares en drives):

VBScript:

Option Explicit
DIM ObjNetwork, ObjUser, CurrentUser
DIM bForce, bUpdateProfile
DIM strDriveLetter, strGroup

bForce = "True"
bUpdateProfile = "True"
err.number = vbempty

'--------------------------------- CONST BLOK ---------------------------------------------------

' Definieren drive-letters
CONST strDriveLetter1 = "W:"

' Definieren UNC-paden
CONST strRemotePath1 = "\\SFILEX2\Vanheede\Vanheede Environment Group\ICT"

' Definieren groepsnamen
CONST LS_dir_ict_read_Group = "cn=LS_dir_ict_read"

'--------------------------------- CODE BLOK ---------------------------------------------------

SET ObjNetwork = CreateObject("WScript.Network")
SET ObjUser = CreateObject("ADSystemInfo")
SET CurrentUser = GetObject("LDAP://" & objUser.UserName)
strGroup = LCase(Join(CurrentUser.MemberOf))


'Verwijderen alle oude netwerkschijven
On Error Resume Next
objNetwork.RemoveNetworkDrive strDriveLetter1, bForce, bUpdateProfile
On Error Goto 0

' Indien lid van de groep LS_dir_ict_read: koppel W: drive
IF InStr(strGroup, LS_dir_ict_read_Group) Then
    objNetwork.MapNetworkDrive strDriveLetter1, strRemotePath1
    END IF

WScript.Quit

EDIT: pas alleen even de naam van de groep aan naar de global group waar de gebruiker inzit. Ik heb heb het dan over Regel 19.

[ Voor 3% gewijzigd door WaSteiL op 05-12-2006 13:58 ]

[WaSteiL]

En heeft het nog geholpen?

spoiler:

Waarschijnlijk kom je niet eens meer terug gezien je posthistorie. Beetje jammer.

[Verwijderd]

Hallo,

Geholpen, ja en nee, ik heb het eigenlijk niet uitgetest => heb nie zoveel kennis van vbs en kvind script nogal ingewikkeld...
Kheb het wel kunnen oplossen met het bestaand script => is wel omslachtig en niet ideaal, maar als ik eens wat meer tijd heb zal ik je script zeker bestuderen. Het ziet er een stuk professioneler uit moet ik zeggen!

In ieder geval bedankt voor de moeite, tis gesaved!

[WaSteiL]

Het script was eigenlijk al helemaal klaar voor je. Het enige wat je eigenlijk nog hoefde te doen was de correcte groepsnaam zoals je die gebruikt in de AD te wijzigen.
Probeer maar eens als je nog hulp nodig hebt hoor ik het wel.

[mookie]

volgens mij was het probleem dat hij lid van een groep was die weer lid van de groep was die hij uitlas. Je moet dus ook alle groepen van die groep weer uitlezen om uiteindelijk de user te vinden.

het aglp model is wel leuk en windows houd er op ntfs nivo rekening mee dat als jij rechten geeft op een map op groep X en groep X bevat groep Y en jij zit in groep Y dat je alsnog de rechten krijgt.
Helaas werken niet alle MS applicaties perfect en als je dus niet meteen in die juiste groep zit maar in een subgroep werkt het niet.
Pas nog met ISA 2004 ontdekt.

In het geval van het tweede script werkt het waarschijnlijk ook niet, dat leest vanaf de andere kant maar ook maar 1 nivo diep.

Dus:

gebruikerA -> GroepB -> groepC(LS_dir_ict_read)
Als je de membership van gebruikerA uitleest krijg je alleen groepB en hij checked op groepC
Als je de membership van groepC uitleest krijg je alleen groepB en niet gebruikerA

Daarom is het ook niet zo slim om meer dan 2 nivo's van groepen te gebruiken maar slecht global groups in local groups te plaatsen.
Anders kan het berekenen van rechten best wel eens bijzonder traag worden.

[WaSteiL]

Je moet wel vanuit de juiste kant de lidmaatschap uitlezen. Niet vanuit de groepskant, maar vanuit de userkant. Indien je vanuit filesysteem gaat kijken dan moet je veel te diep gaan kijken, namelijk:
Je leest de groepen uit die recht hebben op een bepaalde map.
Daar komen een X aantal groepen uit. Daar doe je een check op of de gebruiker lid van is.
Dat zal de gebruiker nooit zijn aangezien je gebruik maakt van Local groups.
Je zal dus moeten kijken welke Global Groups lid zijn van de gevonden Local Groups.

Reken even mee:
• Stel je hebt 3 Local Groups die rechten hebben op een bepaalde map.
• Van elke Local Group zijn er ook weer 5 Global Groups lid (als je geluk hebt).
• Je zal dan sowieso 3*5=15 groepen helemaal moeten uitlezen of daar de gebruiker inzit waarmee aangelogd wordt.
• Stel dat er in elke Global Group ook weer eens 100 gebruikers zitten dan moet je max 15*100 lidmaatschappen uitlzen voordat het uiteindelijk gevonden is.
Samenvatting: heel veel groepen moet je uitlezen en met nog meer users vergelijken. Zeker als een Global groep 100en leden heeft.

Wat je moet doen is:
• Zelf uitzoeken welke Global Groups toegang hebben tot een bepaalde map door de lijn te volgen.
• Je doet een check of de gebruiker die lid is van de betreffende groep.
• Hiervoor gaat het script alle groepen langs waar de gebruiker lid van is.
Samenvatting: Stel dat een gebruiker lid is van 30 Global Groups zal deze max 30 keer iets moeten vergelijken.

Je moet twee zaken los van elkaar zien:

1. Rechten op je filesysteem. kan je dus maken volgens de MS manier: Gebruikers in een global group. Deze Global Group maak je lid van een Domain Local Group. Deze groep gebruik je om rechten te zetten op een map.
2. In het script zorg je ervoor dat je alleen maar checked of een gebruiker lid is van een global group. Je gaat dus niet dieper zoeken. Dit zorgt ook nog voor een sneller script. Dit staat los van hetgeen wat je op filesysteem niveau uitvoert. Je moet alleen goed in de gaten houden welke Global group uiteindelijk toegang krijgt op een bepaalde map voor je script. Door goede benamingen te gebruiken is dit niet zo lastig.

Ik maak ook gebruik van dit script en van nesting van groepen. Nergens last van. Werkt perfect en ook nog eens snel geladen en ik merk geen zichtbare belasting op mijn Domain Controllers. Ik kan bedenken dat in een grote omgeving het andere script zeker voor problemen kan zorgen omdat er enorm veel lidmaatschap checks worden uitgevoerd voor elke gebruiker die aanlogd.

[mookie]

Ik wil niet flamen maar ik denk dat de TS iets anders wilt.
Het heeft niets met groepen die rechten op mappen hebben te maken...

Je moet wel vanuit de juiste kant de lidmaatschap uitlezen. Niet vanuit de groepskant, maar vanuit de userkant

Het maakt niet zoveel uit hoe je start.
Hij kijkt wie er in een groep zit en als de huidige user in die groep zit krijgt hij de drive mapping.
Jij kijkt van welke groepen een user lid is en als daar een bepaalde groep tussen zit dan maak je de drive mapping.
Feitelijk komt dat op hetzelfde neer, welke kant je opgaat maakt niet uit.
Kijken of een user lid is van een groep of dat een user in een groep zit, technisch is het anders, functioneel komt het op hetzelfde neer.

De TS kijkt ook niet naar een map.
GetObject("WinNT... werkt op de NT4 manier.
GetObject("LDAP://... werkt op de w2k en hoger manier.
NT4 heeft geen ldap, w2k en hoger kan NT4 (lan manager RPC calls) simuleren.
Ik denk dat de LDAP manier sneller werkt dan de winnt manier maar de winnt manier werkt wel altijd.
GetObject("WinNT.. leest dus niet de rechten uit van een map.

IfMember is een resource kit tool die toevallig op dezelfde manier werkt als het script deel dat de TS gebruikt, die kijkt ook niet in de groepen in de gespecificeerde groep, enkel naar user accounts die lid zijn van die groep.
Of hij nu zijn eigen script gebruikt of dat van jou, hij moet kijken naar een groep waar useraccounts in zitten en niet naar een groep waar weer groepen in zitten, of (beide) scripts moeten worden aangepast zodat ze de "subgroepen" doorzoeken.

Dus in jouw stelling:
Reken even mee:
• Stel je hebt 3 Local Groups die rechten hebben op een bepaalde map.
• Van elke Local Group zijn er ook weer 5 Global Groups lid (als je geluk hebt).
• Je zal dan sowieso 3*5=15 groepen helemaal moeten uitlezen of daar de gebruiker inzit waarmee aangelogd wordt.
• Stel dat er in elke Global Group ook weer eens 100 gebruikers zitten dan moet je max 15*100 lidmaatschappen uitlzen voordat het uiteindelijk gevonden is.
Samenvatting: heel veel groepen moet je uitlezen en met nog meer users vergelijken. Zeker als een Global groep 100en leden heeft.

Hij kijkt niet naar mappen dus heb je geen 3 local groups. Hij kijkt enkel naar 1 groep.
Als daar weer 5 groepen in zitten moet je inderdaad al die 5 groepen doorlezen.
Dan kom je dus uit op 5 * 100 = 500 maar hoe hypotetisch je het ook maakt, als je op die manier de groepen wil doorlopen (dus met subgroepen) om je drive mappings te maken dan kunnen daar wel eens pittige queries uitkomen.

Ik denk dat je een beetje verward bent geraakt door het GetObject("WinNT.. en dat je dacht dat dat is om rechten op een map uit te lezen. Echter doet het praktisch hetzelfde als wat jij doet.
Hij kijkt alleen naar de users in een group en jij kijkt naar de groups van een user.

Wat ik me echter wel afvraag:
Ik maak ook gebruik van dit script en van nesting van groepen
dit statement: strGroup = LCase(Join(CurrentUser.MemberOf)) kijkt alleen naar de groepen van die user en niet naar groepen in groepen.
Dus of je gebruikt een ander script dan dat je hier post, of je werkt niet met geneste groepen om te bepalen welke drive mapping je moet maken.

De beste methode lijkt mij altijd nog om te kijken naar de groep waar de user inzit en niet naar de groep waar de groep in zit waar die user weer in zit.
Je script blijft dan razendsnel.
Tis alleen jammer als je 1 global groep hebt en 20 local groeps en je moet voor al die 20 local groeps dezelfde drive mapping maken.

Je moet dan de group memberships van de user ophalen, dat is het efficientst en dan krijg je zoiets als:
IF InStr(strGroup, localgroup1) Then
objNetwork.MapNetworkDrive strDriveLetter1, strRemotePath1
END IF
IF InStr(strGroup, localgroup2) Then
objNetwork.MapNetworkDrive strDriveLetter1, strRemotePath1
END IF
etc, etc...
Script blijft razendsnel want je haalt maar 1 keer de memberships op en die if then statements draaien lokaal op je PC dus dat zal weinig tijd in beslag nemen

[WaSteiL]

Reactie @mookie

Je moet dan de group memberships van de user ophalen, dat is het efficientst en dan krijg je zoiets als:
IF InStr(strGroup, localgroup1) Then
objNetwork.MapNetworkDrive strDriveLetter1, strRemotePath1
END IF
IF InStr(strGroup, localgroup2) Then
objNetwork.MapNetworkDrive strDriveLetter1, strRemotePath1
END IF
etc, etc...
Script blijft razendsnel want je haalt maar 1 keer de memberships op en die if then statements draaien lokaal op je PC dus dat zal weinig tijd in beslag nemen

Heb je gezien dat mijn script eigenlijk hetzelfde doet, maar alleen niet gaat kijken op basis van Local Groups, maar naar de Global Groups. Reden daarvoor is omdat je tussen de Group Memberships van een user nooit een Local Group zal tegenkomen (in de ideale situatie: praktijk is helaas soms anders).

Ik denk dat je hetzelfde probeert te vertellen als ik in mijn verhaal, maar je haalt de groepen een beetje door elkaar.