[W2K] Login script voor Organisational Unit

[Verwijderd]

Ik gebruik een login script (WSH) waarbij wordt gekeken in welke groep een gebruiker zit. Aan de hand van die groep krijgt hij een aantal regels om z'n oren van het login script.

Nu ben ik al een tijdje aan het uitvogelen of dat niet op OU-niveau mogelijk is, maar ik kom er niet uit.

Even een klein stukje van de code:

code:

Dim DomainName, Username
Dim WSHNetwork, WshShell
Dim oGroupList
Dim netDrives
Dim n

Set WSHNetwork = createObject("wscript.network")
Set oGroupList = CreateObject("Scripting.Dictionary")
Set WshShell = Wscript.CreateObject("Wscript.Shell")
Set Environment = wshshell.environment("Process")

UserName = Environment( "username" )
DomainName = Environment( "userdomain" )

Call LoadNTGroups(DomainName, Username) 

'Group mapping...
If InGroup("groepnaam") Then
  WSHNetwork.MapNetworkDrive "n:", "\\server\mapping"
End if

Sub LoadNTGroups(vDomainName, vUsername)

  Dim oUser
  Dim oGrp

  Set oUser = GetObject("WinNT://" & vDomainName & "/" & vUsername)

  oGroupList.CompareMode = vbTextCompare
  For Each oGrp In oUser.Groups
    oGroupList(oGrp.name) = True
  Next

End Sub

Function InGroup(sGroup)
  InGroup = oGroupList.Exists(sGroup)
End Function

Zoals je ziet gebruik ik een functies LoadNTGroups en InGroup om de groepsnaam te bepalen waar een gebruiker in zit, maar voor een OU kan ik deze maar niet vinden. Het is uiteindelijk de bedoeling dat alle gebruikers in/onder de OU én de onderliggende OU's worden getriggerd.

Iemand een idee?

[Semt-x]

Dan zet je een login script middels een policy op een OU ? ipv uitvragen in welke ou iemand zit.

Ik zou die kant opzoeken.

succes

[Muppet]

Het kan wel maar dan moet je de LDAP provider gebruiken en niet de WINNT. Maar wat SEMt-x hierboven zegt lijkt me stukken makkelijker.

[Verwijderd]

Tja, dat antwoord had ik al verwacht, maar ik wil één centraal login script ipv 26(!) individuele scriptjes op de policies. Dat maakt het alleen maar foutgevoelig en onoverzichtelijk.

LDAP is idd een optie. Op zich is een scriptje dat alle OU's opzoekt via LDAP niet zo moelijk, maar hoe kan ik bepalen waar de gebruiker in (of onder!) zit...

[Semt-x]

Policies zijn altijd "gelaagd". 1 voor iedereen , en dan per afdeling iets specifieks.
Een goed loginscript wordt volgens dezelfde methode opgebouwd.
Het betaalt zich terug op het moment er OU's gaan veranderen. ( naam, indeling etc. )

In 1 groot login script zou je deze scructuur nabouwen ( if in die groep dan etc.. ) terwijl dit al functionaliteit is die in AD zit. Dat zit je met een eigen gebouwde scructuur en die van AD zelf (voor de policies). dat lijkt me storings gevoeliger dan en reguliere implementatie.

Overgins vind ik 26 OU's wel aan de hoge kant. ik ken de situatie niet dus kan ook niet oordelen of dit wel zo handig is gedaan.

Ik ben nog nooit een implementatie tegen gekomen die uitvraagt in welke OU iemand zit.

[Rataplan_]

heb ik voor je. Ik heb hetzelfde probleem gehad, aangezien ik hier een omgeving aan het ontwikkelen ben waar initieel 200 scholen in komen te zitten en over een jaar of 4 zullen dit er 2000 zijn...


'Uitlezen OU naar variable
Set AdsSysteminfo = CreateObject("adsysteminfo")
Set WshShell = Wscript.CreateObject("WScript.Shell")
Set WshEnv = WshShell.Environment ("PROCESS")

'Bind to the currently logged on user.
Set UserObj= Getobject("LDAP://" & adsSysteminfo.UserName)

'bind to the OU.
Set OUobj=GetObject(UserObj.Parent)

WshEnv("OU") = replace(OUobj.name,"OU=","")


Ik zet hem hier in een tijdelijke variabele, maar dat moet je maar even bekijken verder.

[Verwijderd]

Ik ben het deels met je eens, Semt-x_ : de gelaagdheid van policies werkt prima, mits de ze goed opbouwd. Dit geldt uiteraard ook voor de login scripts.
Echter, als we ons even concentreren op de uitsluitend de login scripts, wordt het overzicht van de configuraties per OU al snel onduidelijk, zeker als je veel "uitzonderingen" op de regel hebt.
Maar volgens mij is dit ook voor een groot deel persoonlijk

Overigens: dat laatste is lijkt me toch geen vreemde vraag? Ik kan me diverse senarios bedenken dat er reuze handig is om uit te lezen in welke OU iemand zit, zeker voor de scripters onder ons.

[Rataplan_]

Laat je even weten of bovenstaand scriptje werkt? zo niet kan ik het eventueel beetje voor je aanpassen...

[Verwijderd]

Thanx, Rataplan!
Lijkt me een prima om mee te stoeien! Ik laat het je weten.

[ Voor 17% gewijzigd door Verwijderd op 08-03-2004 12:36 ]

[Semt-x]

Verwijderd schreef op 08 maart 2004 @ 12:02:
Ik ben het deels met je eens, Semt-x_ : de gelaagdheid van policies werkt prima, mits de ze goed opbouwd. Dit geldt uiteraard ook voor de login scripts.
Echter, als we ons even concentreren op de uitsluitend de login scripts, wordt het overzicht van de configuraties per OU al snel onduidelijk, zeker als je veel "uitzonderingen" op de regel hebt.
Maar volgens mij is dit ook voor een groot deel persoonlijk

Ik denk dat het verschil van inzicht komt doordat jij het login script los ziet van policies. Deels logisch, uit historisch oogpunt , en technisch oog punt ( kix / vbs is andere techniek dan policy "scripts" )

Terwijl ik van mening ben dat een login script een methode is om policies aan te vullen. Ik zie het als 1 punt (policy editor) waar je alles regelt. Precies waar jij ook naar toe wilt.

Overigens: dat laatste is lijkt me toch geen vreemde vraag? Ik kan me diverse senarios bedenken dat er reuze handig is om uit te lezen in welke OU iemand zit, zeker voor de scripters onder ons.

Ik kan er denk ik ook wel verzinnen, echter zijn ze allemaal te herleiden naar de structuur die ik beschreef.

[Verwijderd]

Toch niet helemaal:
Bekijk dit senario

OU1
--- OU2
------ OU3
------ OU4
--- OU5

Op OU staan de meest besale policies ingesteld, alsmede het algemene login script. Dit geldt ook voor OU2, alleen iets meer gedetailleerd. OU2 heeft een ander login script dan OU5.
Nu wil ik op OU3 wel policies erven van OU2, maar niet van het loginscript. Wel moet het login script van OU door worden gevoerd.
OU4 moet wel alle bovenliggende lagen erven.

Dat gaat dus niet werken, he?
Het scheiden van policies en loginscripts heeft voor mij dus weldegelijk waarde en is zeker niet terug te vinden in de structuur zoals jij deze beschreef.

Overigens Rataplan: script werkt prima en is inmiddels uitgebreid naar de gewenste situatie!

Thanx!

[Semt-x]

Verwijderd schreef op 08 maart 2004 @ 14:11:
Toch niet helemaal:
Bekijk dit senario

OU1
--- OU2
------ OU3
------ OU4
--- OU5

Op OU staan de meest besale policies ingesteld, alsmede het algemene login script. Dit geldt ook voor OU2, alleen iets meer gedetailleerd. OU2 heeft een ander login script dan OU5.
Nu wil ik op OU3 wel policies erven van OU2, maar niet van het loginscript. Wel moet het login script van OU door worden gevoerd.
OU4 moet wel alle bovenliggende lagen erven.

Dat gaat dus niet werken, he?

Ik zie geen probleem, als je het algemene login script stuk op OU1 zet (alles waar je geen "if ingroup(OU dus:)" voorzet)
en vervolgens de specifieke onderdelen van de scripts op elke OU zet, het doorerven instellen en klaar.

Maar ik lees dat je het al precies hebt draaien zoals je wil, dus alles is opgelost :]

[Verwijderd]

Rataplan:

Het volgende heb ik er inmiddels van gemaakt:

code:

Dim UserObj
Dim OUobj

Set AdsSysteminfo = CreateObject("adsysteminfo")
Set UserObj= Getobject("LDAP://" & adsSysteminfo.UserName)
Set OUobj=GetObject(UserObj.Parent)
Set OUobjparent=GetObject(OUobj.Parent)

Environment( "OU" ) = replace(OUobj.name,"OU=","")
Environment( "OUparent" ) = replace(OUobjparent.name,"OU=","")
OU = Environment( "OU" ) + "." + Environment( "OUparent" )

Zoals je ziet wil ik ook de bovenliggende OU weten. Dat is op deze wijze voor 2 niveau prima te doen. Echter als we het mooi willen hebben moet een dergelijk script alle bovenliggende OU detecteren.
Weet iemand hiervoor een mogelijkheid?