Regini ownership registry key aanpassen

[Erik070]

Via verschillende wegen probeer ik een scriptje, batch file te maken waarmee we de "share" optie in Windows Explorer Context menu kunnen verwijderen en de "Share with" knop in de Windows Explorer command bar te verwijderen.

Nou had ik al vrij snel de 2 registry keys gevonden waarmee dit geregeld wordt:
HKEY_CLASSES_ROOT\CLSID\{f81e9010-6ea4-11ce-a7ff-00aa003ca9f6}\InProcServer32
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\CommandStore\shell\Windows.Share

Bij de eerste kan je de value van (default) wijzigen is iets willekeurig anders, en daarmee wordt de share optie in de context menu verwijderd.
De tweede key is voor de share with knop in de command bar. Daar moet de value van CanonicalName leeg gemaakt worden om die knop te verwijderen.

Het probleem is dat beide registry keys als owner Trustedinstaller hebben staan. Dus je zal eerst jezelf of in mijn geval de Administrator group owner moeten maken en daarna kan je values pas aanpassen.

Na wat zoeken kwam ik uit op 2 tools die dit kunnen uitvoeren: Regini & SetACL

In beide gevallen loop ik tegen het probleem aan dat ze de owner van HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\CommandStore\shell\Windows.Share om 1 of andere rede niet mogen aanpassen, access denied met beide tools. Bij HKEY_CLASSES_ROOT\CLSID\{f81e9010-6ea4-11ce-a7ff-00aa003ca9f6}\InProcServer32 heb ik hier helemaal geen last van en wordt de owner gewoon aangepast.

Ik heb de volgende scripts samengesteld. Het betreft 1 VBscript die ik met Regini gebruik:

VBScript: regini

' Create temp file with the script that regini.exe will use

'
set oFSO = CreateObject("Scripting.FileSystemObject")
strFileName = oFSO.GetTempName
set oFile = oFSO.CreateTextFile(strFileName)
oFile.WriteLine "HKEY_CLASSES_ROOT\CLSID\{f81e9010-6ea4-11ce-a7ff-00aa003ca9f6}\InProcServer32 [1 5 8 17]"
oFile.WriteLine "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\CommandStore\shell\Windows.Share [1 5 8 17]"
oFile.Close
' Change registry permissions with regini.exe
'
set oShell = CreateObject("WScript.Shell")
oShell.Run "regini " & strFileName, 8, true
' Delete temp file
'
oFSO.DeleteFile strFileName

' The following will change the registry settings to hide the Share tab and Share button in the commandribbon

Dim objShell, RegLocate, RegLocate1
 Set objShell = WScript.CreateObject("WScript.Shell")
 On Error Resume Next
 RegLocate = "HKEY_CLASSES_ROOT\CLSID\{f81e9010-6ea4-11ce-a7ff-00aa003ca9f6}\InProcServer32\"
 RegLocate1 = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\CommandStore\shell\Windows.Share\CanonicalName"
 ' Take great care with the line above 
 ' Note the space between \Internet and Settings\

objShell.RegWrite RegLocate,"","REG_EXPAND_SZ"
objShell.RegWrite RegLocate1,"","REG_SZ"

 WScript.Quit ' Tells the script to stop and exit.

En met SetACL heb ik een batch scriptje gemaakt:

Batchfile: SetACL

@Echo off

set SourceDir=%~dp0

Rem changing owner of registry keys to Administrators
%sourcedir%setacl.exe -on "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\CommandStore\shell" -ot reg -actn setowner -ownr "n:Administrators"
%sourcedir%setacl.exe -on "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\CommandStore\shell\Windows.Share" -ot reg -actn ace -ace "n:Administrators;p:full"
%sourcedir%setacl.exe -on "HKEY_CLASSES_ROOT\CLSID\{f81e9010-6ea4-11ce-a7ff-00aa003ca9f6}\InProcServer32" -ot reg -actn setowner -ownr "n:Administrators"
%sourcedir%setacl.exe -on "HKEY_CLASSES_ROOT\CLSID\{f81e9010-6ea4-11ce-a7ff-00aa003ca9f6}\InProcServer32" -ot reg -actn ace -ace "n:Administrators;p:full"


Rem changing registry keys to desired values
reg add "hklm\Software\Microsoft\Windows\CurrentVersion\Explorer\CommandStore\shell\Windows.Share" /t REG_SZ /v CanonicalName /d "" /f
reg add "HKEY_CLASSES_ROOT\CLSID\{f81e9010-6ea4-11ce-a7ff-00aa003ca9f6}\InProcServer32" /t REG_EXPAND_SZ /ve /d "" /f

Is er een rede dat de owner bij de ene key wel aangepast mag worden bij de andere niet? Ik heb niet kunnen achterhalen waar dat verschil nu zit. Met mijn admin account kan ik uiteraard wel de owner aanpassen maar we willen dit automatiseren aangezien het uiteindelijk naar honderden pc's uitgerolt moet worden.

Ik heb ook gelezen dat het met Powershell mogelijk is om dit aan te passen alleen is systeembeheer niet echt happig om Powershell scripts te gebruiken (o.a. omdat ze gesigned moeten worden).

Iemand suggesties waarom dit fout gaat of misschien heeft iemand een idee hoe we hetzelfde kunnen bereiken via een andere methode?

[GNID]

Ik denk dat je de verkeerde afslag aan het nemen bent ..

(onderstaande onder voorbehoud, want uit mijn hoofd en je hebt geen Windows versie vermeld)


Sharing uitschakelen kan met Explorer > Tools > Options > View. Daar staat ergens een sharing-vinkje tussen.
De bijbehorende regkey kun je normaal gesproken terugvinden onder HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced.

.... Of je gebruikt natuurlijk GPO's om dit op een nette manier te regelen ....

[ Voor 4% gewijzigd door GNID op 31-05-2016 21:53 ]

[Erik070]

Ah dat is wel handig van me, gaat om Windows 7 64-bit.

GPO lijkt mij ook de beste manier, maar mijn systeembeheer collega dacht dat daar geen policy voor bestond. Ik ga het nog even met hem uitzoeken, lijkt mij ook een veel netter en vooral robustere manier van werken.
Correctie, van de GPO waren ze wel op de hoogte maar wordt dan alleen toegepast op user niveau. Ze willen het op computer niveau regelen zodat ook administrators geen mogelijkheid hebben om te sharen. En dat valt dus kennelijk niet met een GPO te regelen.

[ Voor 34% gewijzigd door Erik070 op 01-06-2016 10:15 ]

[GNID]

Dat wordt dan ineens een heel andere vraag ....

Tuurlijk valt dat wel met policies te regelen. Fluitje van een cent. Het klinkt meer alsof "ze" dit niet willen .....

Je kunt natuurlijk ook altijd nog de bij de policy behorende reg-key inschieten bij de admin accounts (maar dat zou "Plan C" moeten zijn)

[Erik070]

Zou je een tipje van de sluier kunnen lichten hoe dit dan via een GPO geregeld kan worden?

Ik weet dat de systeembeheers al via group policy preferences hebben geprobeerd, maar daar lopen ze tegen het probleem aan dat ze die keys niet mogen aanpassen omdat ze geen owner zijn. Via GPresult zie je dan dat het toepassen van de policy niet lukt met de melding "Access Denied".

[Orion84]

En dan sloop je dat knopje en typ de gebruiker/admin gewoon "net share ..." in op de commandline...

Klinkt allemaal nogal als security through obscurity dit?

[Killah_Priest]

Erik070 schreef op woensdag 01 juni 2016 @ 16:49:
Zou je een tipje van de sluier kunnen lichten hoe dit dan via een GPO geregeld kan worden?

Ik weet dat de systeembeheers al via group policy preferences hebben geprobeerd, maar daar lopen ze tegen het probleem aan dat ze die keys niet mogen aanpassen omdat ze geen owner zijn. Via GPresult zie je dan dat het toepassen van de policy niet lukt met de melding "Access Denied".

Dan verstaan zij hun vak niet (en dit is geen flame richting de TS natuurlijk want die moet ook roeien met de riemen die hij heeft), dit soort zaken richt een beetje beheerder zo in, ook mbt GPOs.
Geen Powershell scripts willen gebruiken ivm het signen : het signen van een PS script is natuurlijk een kwestie van enkele minuten werk, geen uren. Tevens is de ExecutionPolicy (welke dus de restrictie oplegt mbt signed scripts) erg makkelijk te omzeilen dmv -ExecutionPolicy Bypass als argument te geven bij het starten van PS.

[ Voor 5% gewijzigd door Killah_Priest op 01-06-2016 16:58 ]

[Erik070]

Orion84 schreef op woensdag 01 juni 2016 @ 16:55:
En dan sloop je dat knopje en typ de gebruiker/admin gewoon "net share ..." in op de commandline...

Klinkt allemaal nogal als security through obscurity dit?

Dat was ook mijn eerste opmerking (en die van de beheerder), maar kennelijk wilt men dat dit uitgevoerd wordt. Ik zit helemaal onderin de keten, ik heb ook geen idee wie dit verzonnen heeft.

Killah_Priest schreef op woensdag 01 juni 2016 @ 16:58:
[...]

Dan verstaan zij hun vak niet (en dit is geen flame richting de TS natuurlijk want die moet ook roeien met de riemen die hij heeft), dit soort zaken richt een beetje beheerder zo in, ook mbt GPOs.
Geen Powershell scripts willen gebruiken ivm het signen : het signen van een PS script is natuurlijk een kwestie van enkele minuten werk, geen uren. Tevens is de ExecutionPolicy (welke dus de restrictie oplegt mbt signed scripts) erg makkelijk te omzeilen dmv -ExecutionPolicy Bypass als argument te geven bij het starten van PS.

Ik zal de flame aan ze doorgeven , maar dan mooi verpakt zodat ik ze hopelijk kan overtuigen dat ze het toch even via een GPO moeten proberen te regelen.

[GNID]

Ik weet dat de systeembeheers al via group policy preferences hebben geprobeerd, maar daar lopen ze tegen het probleem aan dat ze die keys niet mogen aanpassen omdat ze geen owner zijn. Via GPresult zie je dan dat het toepassen van de policy niet lukt met de melding "Access Denied".

Vergeet die registry keys; zoals gezegd: dat is echt de verkeerde afslag.
Wat je nog wel zou kunnen proberen op een test-systeem (klein kansje dat het werkt):
Onder die inprocserver32 staat een DLL-naam. Als dat niet een algemene Windows DLL is (als bv shell32, oleaut32), zou je die DLL voor de test kunnen de-registreren (regsvr32.exe /u dinges.dll ; ongedaan maken met regsvr32.exe dinges.dll ). En kijken of dan de sharing interface verdwenen is (voor de zekerheid eerst herstarten).

Zou je een tipje van de sluier kunnen lichten hoe dit dan via een GPO geregeld kan worden?

Ik weet niet wat je kennisniveau is (laat staan van de beheerders; daar lijkt me wel het een en ander aan te schorten), dus "vanaf nul":

Group policies bestaan uit 2 delen: een machine deel en een user gedeelte.
Je logt met jouw account aan op een willekeurige machine. Dan krijg je de machine policies uit de OU waarin de computer staat en de user policies uit de OU waarin je account staat.

Simpelste oplossing is om de Sharing policy (dat is inderdaad een user setting) in te stellen op de OU's waarin de "gewone klanten" staan" èn op de OU waarin de beheerders-accounts staan. Klaar.

Dan is er nog een iets ingewikkeldere optie: Loopback policies.(merge variant)
Dat zorgt ervoor dat de usersettings uit de OU van de computer geladen worden in plaats van / in combinatie met de usersettings uit de OU van het useraccount.

Killah_Priest schreef op woensdag 01 juni 2016 @ 16:58:
Tevens is de ExecutionPolicy (welke dus de restrictie oplegt mbt signed scripts) erg makkelijk te omzeilen dmv -ExecutionPolicy Bypass als argument te geven bij het starten van PS.

... of eenmalig instellen dat lokale PowerShell scripts uitgevoerd mogen worden met:
Set-ExecutionPolicy RemoteSigned -force

[Erik070]

Nou, we (of eigenlijk de systeembeheer) zijn eruit gekomen.

Het wordt nu toch via een GPO geregeld, maar dan wel om de permissies en de registry keys aan te passen. De mogelijkheid om een policy op de administrator OU toe te passen was de beheerder bekend mee, maar dat mag kennelijk niet vanwege beleid van het bedrijf.

In elk geval bedankt voor de suggesties die gedaan zijn.

[GNID]

Succes dan maar.
Iets anders: zou je voor me na willen vragen waarom dat beleid is ingesteld om geen policies op administrators-OU toe te staan? Kan ik er mogelijk ook wat van leren (ben dit namelijk nog niet eerder tegen gekomen en kan zo 1-2-3 ook geen argumenten verzinnen).

[Erik070]

Ik krijg op die vraag helaas niet echt een duidelijk antwoord van mijn collega's (of eigenlijk gewoon geen). Zou het je graag willen uitleggen, maar ik weet ook niet waarom dit zo is.