GPO overriden in een vm view omgeving

[nasdude]

Basis:
- VMWare View
- 80 users op een linked clone floating pool
- Windows 7 gold image (office 2010 is een vast onderdeel van de base image)

Ik heb in onze AD een GPO ingesteld voor alle medewerkers in onze locatie die de macro security van excel regelt (alle macro's toegestaan). De macro functie in excel is vervolgens grayed out en kan door een user of admin niet worden aangepast.

Nu vraagt een medewerker of ik het mogelijk kan maken voor deze gebruiker om deze security feature uit te zetten, hij schrijft:

Voor veel van de tools die ik ontwikkel gebruik ik Excel (vaak VBA UserForms).
Deze tools maken allemaal gebruik van Macro's.
Voor het geval dat gebruikers in hun Excel de Marcos uitgeschakeld hebben staan moet ik ook een functie in de tool inbouwen, en deze functie moet ik natuurlijk ook kunnen testen.

Ik wil natuurlijk niet te veel uitzonderingen maken, en al helemaal niet een gpo maken waar alleen hij in zit.


Heb zo geen idee hoe ik dit het beste aan kan pakken... jullie?

[Question Mark]

nasdude schreef op donderdag 16 augustus 2012 @ 09:43:
Ik wil natuurlijk niet te veel uitzonderingen maken, en al helemaal niet een gpo maken waar alleen hij in zit.

Als de uitzondering voor enkel deze gebruiker geld, ontkom je er niet aan om iets voor hem alleen te regelen. Je hebt dan twee opties.

1. Een andere OU aanmaken voor useraccounts waar middels een incremental policy deze setting aangepast wordt en vervolgens het userobject hiernaar verplaatsen
2. Een extra GPO aanmaken en middels security regelen dat deze enkel voor leden van de groep "relaxed security" (oid) toegepast wordt.

[kroegtijger]

En optie 1 is naar mijn mening de netste. Dit houdt het zo overzichtelijk mogelijk

[Equator]

kroegtijger schreef op donderdag 16 augustus 2012 @ 13:16:
En optie 1 is naar mijn mening de netste. Dit houdt het zo overzichtelijk mogelijk

Dat ben ik toch niet met je eens. Wat als je nu voor de zelfde gebruiker een uitzondering voor een andere setting wilt maken.. Moet je dan nog een nieuwe OU maken? Probleem: een gebruikersaccount kan niet in twee OU's tegelijk zitten.

Het regelen van uitzonderingen met ene aparte groep is veel netter IMO. Deze GPO laat je gewoon op dezelfde OU staan.

[ Voor 6% gewijzigd door Equator op 16-08-2012 14:35 ]

[kroegtijger]

Equator schreef op donderdag 16 augustus 2012 @ 14:34:
[...]

Dat ben ik toch niet met je eens. Wat als je nu voor de zelfde gebruiker een uitzondering voor een andere setting wilt maken.. Moet je dan nog een nieuwe OU maken? Probleem: een gebruikersaccount kan niet in twee OU's tegelijk zitten.

Het regelen van uitzonderingen met ene aparte groep is veel netter IMO. Deze GPO laat je gewoon op dezelfde OU staan.

Dat is waar inderdaad, maar is een beetje organisatie-afhankelijk denk ik. Soms zal het handiger zijn om via de OU's het te regelen (dan zie je in 1 oogopslag welke GPO er wordt toegepast), en soms is het handiger om dat op basis van exceptions te doen, zoals in het voorbeeld dat jij hier schetst.
Als je organisatie het toe laat om 2 of 3 verschillende gebruikers-niveau's te maken en that's it, dan is optie 1 van toepassing. Bij grote(re) organisaties zou ik inderdaad dan voor exceptions kiezen. Met de policy result wizzard kun je uiteindelijk toch ook je gevraagde informatie verkrijgen. Kost alleen wat meer moeite, maar je komt er uiteindelijk ook dan.

[Pirtkoei]

Met Equator vanaf 2008 kun heel goed met zgn filter GPOs werken.

@kroegtijger, dat is imho de manier om te kijken welke policies voor een bepaalde user op een bepaal de computer van toepassing zijn, of ga je alle user- en computerGPOs door zitten klikken om te kijken elke er geset zijn?

[Equator]

Pirtkoei schreef op donderdag 16 augustus 2012 @ 15:04:
Met Equator vanaf 2008 kun heel goed met zgn filter GPOs werken.

Nou, dat kon in een Windows 2000 AD al. Policies zet je op een GPO, en met groepen bepaal je welke policies voor welke personen gelden. Filtering in een GPO is gekomen vanaf 2003.

kroegtijger schreef op donderdag 16 augustus 2012 @ 15:00:
[...]

Dat is waar inderdaad, maar is een beetje organisatie-afhankelijk denk ik. Soms zal het handiger zijn om via de OU's het te regelen (dan zie je in 1 oogopslag welke GPO er wordt toegepast), en soms is het handiger om dat op basis van exceptions te doen, zoals in het voorbeeld dat jij hier schetst.
Als je organisatie het toe laat om 2 of 3 verschillende gebruikers-niveau's te maken en that's it, dan is optie 1 van toepassing. Bij grote(re) organisaties zou ik inderdaad dan voor exceptions kiezen. Met de policy result wizzard kun je uiteindelijk toch ook je gevraagde informatie verkrijgen. Kost alleen wat meer moeite, maar je komt er uiteindelijk ook dan.

IMO is er maar 1 reden om accounts in een andere OU te zetten, en dat is als het gaat om accounts die afwijken van de standaard gebruikersaccounts. Account van extern personeel, service accounts etc. Op die manier kun je ook een stukje delegation doen van de mogelijkheden op deze OU's. Een helpdesk kan zo wel het recht hebben om een wachtwoord van een gebruikersaccount te resetten, maar niet die van een service account.

In 2008 R2 hebben we nog een reden om een account in een andere OU te stoppen, en dat is om een alternatief wachtwoordbeleid op een aparte groep met accounts te plaatsen. Dat is iets wat je ook op de service accounts kunt doen, maar het kan op die manier ook voor andere accounts.

[Razwer]

Equator schreef op donderdag 16 augustus 2012 @ 20:10:
[...]

Nou, dat kon in een Windows 2000 AD al. Policies zet je op een GPO, en met groepen bepaal je welke policies voor welke personen gelden. Filtering in een GPO is gekomen vanaf 2003.


[...]


IMO is er maar 1 reden om accounts in een andere OU te zetten, en dat is als het gaat om accounts die afwijken van de standaard gebruikersaccounts. Account van extern personeel, service accounts etc. Op die manier kun je ook een stukje delegation doen van de mogelijkheden op deze OU's. Een helpdesk kan zo wel het recht hebben om een wachtwoord van een gebruikersaccount te resetten, maar niet die van een service account.

In 2008 R2 hebben we nog een reden om een account in een andere OU te stoppen, en dat is om een alternatief wachtwoordbeleid op een aparte groep met accounts te plaatsen. Dat is iets wat je ook op de service accounts kunt doen, maar het kan op die manier ook voor andere accounts.

hear hear.
er is trouwens ook nog (kan complementair zijn aan filtering) een manier om gpo's specifiek te scopen, delegation aanmaken en specifieke read deny op zetten. werkt als een tiet, gpo wordt niet deployed op waar je de deny zet.

[alt-92]

Of je doet een GPPreference met een item-level targeting voor die usergroep, die je op een lagere order zet (en dus na de standaard policy).

[ Voor 7% gewijzigd door alt-92 op 16-08-2012 21:40 ]

[nasdude]

alt-92 schreef op donderdag 16 augustus 2012 @ 21:39:
Of je doet een GPPreference met een item-level targeting voor die usergroep, die je op een lagere order zet (en dus na de standaard policy).

oeh, das een goeie.. morgen even mee spelen .. thanks!!

heb het tijdelijk opgelost, heb een vbs scriptje gemaakt dat HKCU\Software\Policy\Office\14\Excel\Security\VBASecurity (als ik het me goed herinner) uitleest, en op basis van de waarde, de waarde van het dword veranderd, excel restart en opgelost.

dat werkte goed op mijn laptop, maar niet bij de user... user had geen rechten om die registry value te veranderen. in zijn ntuser.dat op de persona management server heb ik de rechten aangepast.. werkt prima.


had nog niet gedacht aan item level targetting ..

morgen post ik het scriptje hier en laat ik weten of item level werkt

[The Eagle]

En anders zijn er ook tooltjes te vinden op internet waarmee je de Group policy client volledig kunt disablen. Kwestie van een command line openen met een system user en met sc de service disablen.
Kan een tijdelijke oplossing zijn, en daarna mag je hem weer enablen. Ook dat zou je zelfs kunnen scripten voor hem volgens mij

[redfoxert]

AppSense is je vriend

[kroegtijger]

Equator schreef op donderdag 16 augustus 2012 @ 20:10:


IMO is er maar 1 reden om accounts in een andere OU te zetten, en dat is als het gaat om accounts die afwijken van de standaard gebruikersaccounts. Account van extern personeel, service accounts etc. Op die manier kun je ook een stukje delegation doen van de mogelijkheden op deze OU's. Een helpdesk kan zo wel het recht hebben om een wachtwoord van een gebruikersaccount te resetten, maar niet die van een service account.

Afhankelijk van de situatie. In sommige omgevingen wordt bijvoorbeeld het startmenu, printers etc via GPO geregeld, en is per afdeling weer anders (andere applicaties e.d.). Dan baseer je je AD juist op de organisatie-structuur, en heb je dus je default domain policy die op alle OU's van toepassing is, waarna je per OU weer een afdelings-specifieke GPO zet. Zomaar alles in 1 groep flikkeren is dan juist weer geen goed plan.

In 2008 R2 hebben we nog een reden om een account in een andere OU te stoppen, en dat is om een alternatief wachtwoordbeleid op een aparte groep met accounts te plaatsen. Dat is iets wat je ook op de service accounts kunt doen, maar het kan op die manier ook voor andere accounts.

Onder andere dus, maar ook om printers toe te wijzen dus bijvoorbeeld.

[Razwer]

kroegtijger schreef op donderdag 16 augustus 2012 @ 23:44:
[...]

Afhankelijk van de situatie. In sommige omgevingen wordt bijvoorbeeld het startmenu, printers etc via GPO geregeld, en is per afdeling weer anders (andere applicaties e.d.). Dan baseer je je AD juist op de organisatie-structuur, en heb je dus je default domain policy die op alle OU's van toepassing is, waarna je per OU weer een afdelings-specifieke GPO zet. Zomaar alles in 1 groep flikkeren is dan juist weer geen goed plan.

[...]

Onder andere dus, maar ook om printers toe te wijzen dus bijvoorbeeld.

niet mee eens. dit regel je met groepen. Een marketing user zit altijd wel in een generieke marketing groep, etc etc. Computer accounts zou ik nog in mee kunnen gaan maar voor user accounts ben ik het niet eens. Wat jij wilt kan prima hoor, maar ik vind het geen fijne manier van werken.
Delegation is vaak op basis van fysieke locatie, en op die manier structuur leggen is dan wel gegrond.

[Equator]

kroegtijger schreef op donderdag 16 augustus 2012 @ 23:44:
[...]

Afhankelijk van de situatie. In sommige omgevingen wordt bijvoorbeeld het startmenu, printers etc via GPO geregeld, en is per afdeling weer anders (andere applicaties e.d.). Dan baseer je je AD juist op de organisatie-structuur, en heb je dus je default domain policy die op alle OU's van toepassing is, waarna je per OU weer een afdelings-specifieke GPO zet. Zomaar alles in 1 groep flikkeren is dan juist weer geen goed plan.

[...]

Persoonlijk vindt ik dergelijke software en profiel zaken helemaal niet interessant om met GPO's te doen. Tooling als RES Workspace Manager maakt dat vele malen handiger en flexibeler. Maar dat ligt natuurlijk aan de omgeving..

Tenslotte gaat het erom dat de partij die het beheert ook daadwerkelijk begrijpt hoe het werkt. Of dat nu via manier A of manier B is, zal mij uiteindelijke de kont oxideren.

[alt-92]

The Eagle schreef op donderdag 16 augustus 2012 @ 22:59:
En anders zijn er ook tooltjes te vinden op internet waarmee je de Group policy client volledig kunt disablen.

Die tool staat ook bekend onder de naam RG* en heeft wel eens vaker gezorgd voor CLM**s.


*Resume Generator **Career Limiting Move

[ Voor 8% gewijzigd door alt-92 op 17-08-2012 12:35 ]

[The Eagle]

Dat weet ik Heb die dan ook alleen gebruikt met medeweten van mijn BU-manager, die vond dat ik gewoon moest kunnen werken ipv lastig gevallen worden met een virtuele omgeving waar ik nog niet eens Windows-E of Windows-R uit mocht voeren
Onze ICT-afdeling was op de stoel van de eindgebruikers gaan zitten en wij konden vrijwel niks meer. Zu allemaal gefixt worden, maar wij moesten natuurlijk wel door kunnen werken. Uiteindelijk werd het niet gefixt en moesten we maar wennen...
Eind van het liedje overigens: Group Policy client nog steeds uitgeschakeld, en die desktop vormt nu middels Teamviewer mijn persoonlijke gateway tot het netwerk. Onze ICT afdeling denkt nog steeds dat die bak als ie opstart, braaf citrix start als shell en niet explorer.exe

---

Maar iets als bovenstaande was ook niet de bedoeling van mijn post. Het was meer een handreiking: als er iets tijdelijk nodig is, kun je ook een dergelijke tool inzetten die met medeweten van de ICT afdeling bewust tijdelijk gebruikt wordt, omdat het beide partijen een hoop kopzorgen scheelt
Beleid is namelijk iets wat je samen afspreekt

[Razwer]

The Eagle schreef op zaterdag 18 augustus 2012 @ 17:10:
Beleid is namelijk iets wat je samen afspreekt

be·leid (het; o)
gedragslijn voor de verwezenlijking van bep. doelstellingen: inkomensbeleid, kabinetsbeleid, prijsbeleid

dat is niet specifiek iets wat je samen afspreekt. Feit dat je beleidszaken kan afspreken is dan weer een beleid van je directie...
In de definitie wordt beleid opgedragen, niet afgesproken

[ Voor 52% gewijzigd door Razwer op 18-08-2012 18:51 ]

[The Eagle]

Toch wel, het wordt alleen niet op jouw niveau afgesproken, en wordt jou als werknemer opgedrongen. Jij bent er de dupe van, da's wat anders

Overigens is mijn lijfkreed de laatste tijd "Is dat beleid, of is er over nagedacht?". Dus ik snap hoe je je voelt

Back ontopic: als TS de genoemde oplossing van het tijdelijk uitschakelen van de policy editor kan gebruiken en het past binnen zijn kader van bevoegdheden om dat in overleg met de gebruiker zo te doen, zie ik geen bezwaren. Het wordt anders als je werkgever SOx compliant moet zijn en/of beursgenoteerd is

[ Voor 60% gewijzigd door The Eagle op 18-08-2012 22:59 ]

[nasdude]

code:

Option Explicit

Const HKCU = &H80000001
Set WshShell = WScript.CreateObject("WScript.Shell")

Dim VBA_Security 
Dim strComputer
Dim RegistryObject
Dim strKeyPath
Dim strValueName
Dim strValue
Dim WshShell, RegValue, RegEntry, RegNoRemove, RegNoModify, UniPath  


RegEntry="HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\excel\security\vbawarnings"

VBA_Security = ReadReg("HKCU\Software\Policies\Microsoft\Office\14.0\excel\security\vbawarnings")

If VBA_Security = 1 Then
    WshShell.RegWrite RegEntry, 2, "REG_DWORD"
    wscript.echo "Macro Security now: Disabled"
End If

If VBA_Security = 2 Then
    WshShell.RegWrite RegEntry, 1, "REG_DWORD"
    wscript.echo "Macro Security now: Enabled"
End If



Function ReadReg(RegPath)
     Dim objRegistry, Key
     Set objRegistry = CreateObject("Wscript.shell")
     Key = objRegistry.RegRead(RegPath)
     ReadReg = Key
End Function

[Razwer]

gpo preferences gebruiken is beter dan VBS gebruiken. wat je daar doet kan makkelijker en sneller. user hoeft geen admin te zijn en je kan item level targetting gebruiken om te scopen.