GPO computer policy security settings

[monta]

Ik wil graag een standaard user (Windows 7) op de lokale machines schrijfrechten geven op de registry en bijv. program files.
Volgens de documentatie kun je dan via Group policy Computer Configuration Windows Settings Security Settings Registry en File system rechten uitdelen. Ik heb hier de accounts toegevoegd. Ook geprobeerd om de domein users rechten te geven op bijv. program files en op alle keys in de registry.
Toch voert Windows het niet door. In bijv. Local Machine zie ik iedereen nog bijstaan maar geen user of domein users die toegevoegd zijn. D epolicy is wel met succes uitgevoerd.
UAC staat uit op de Windows 7 machine.


Zijn er nog andere policy's die hiervoor aangepast moeten worden? om dit te berwerkstelligen?

[alt-92]

monta schreef op dinsdag 25 januari 2011 @ 14:58:
Ik wil graag een standaard user (Windows 7) op de lokale machines schrijfrechten geven op de registry en bijv. program files.
Volgens de documentatie kun je dan via Group policy Computer Configuration Windows Settings Security Settings Registry en File system rechten uitdelen. Ik heb hier de accounts toegevoegd. Ook geprobeerd om de domein users rechten te geven op bijv. program files en op alle keys in de registry.

Laat eens een uitdraai zien via GPMC wát je precies aan het doen bent?

[monta]

zal ik morgen doen. Ga morgen eerst nog even testen met replace settings. De groep "iedereen" blijft natuurlijk staan als je niet replace settings doet.

[alt-92]

Ik zou daar héél voorzichtig mee zijn omdat je daarmee ook system ACLs mee aanpast (well known SIDs).

[Dysmael]

Waarom maak je de Domain Users dan geen lid van de Local Administrators? Als je ze rechten tot het wijzigen van het register geeft hebben ze toch eigenlijk die macht al. Ik denk dat je heel veel problemen gaat krijgen als je op deze manier gaat 'prutsen'. Zelfs een Local Administrator hoort op sommige registersleutels geen rechten te hebben. Als je de ACL's gaat vervangen help je echt de boel helemaal om zeep.
Overigens ontgaat me het nut hiervan compleet maar dat zal wel aan mij liggen.

[alt-92]

Tja, ik snap wel waarom hoor..
In [win7] local admin account is er juist de nadruk op gelegd dat users in principe helemaal geen localadmin zouden moeten krijgen.

Nu zijn er wel apps die echt niet zonder kunnen, maar de topicstarter pakt liever the next best railgun en past een setting die je liefst alleen voor één subfolder / regtree wil doen en gaat deze toch weer op het hele systeem uitrollen.
Moet ie zelf weten, maar daarmee hebben we wel een MontaOS 7 in plaats van Windows 7.
Support tot aan de stoepgoot.

Monta moet de balans nog even zien te vinden wanneer je wat en waarom doet.

[ Voor 18% gewijzigd door alt-92 op 25-01-2011 21:44 ]

[Dysmael]

Tja, als ik het fijn vind om elke nacht even kort te werken en daarvoor bij mijn baas vraag of hij de voordeur niet gewoon open wil laten staan dan wordt ik toch echt uitgelachen. Ik zal maar moeten accepteren dat er een speciale sleutel en code nodig zijn om toegang tot het pand te verschaffen. Datzelfde geldt ook voor automatisering; een 'standaard' eindgebruiker administrative rechten geven is uit den boze. Dan moet je als systeembeheerder maar wat minder lui zijn en zorgen dat alles correct wordt ingesteld.

[Mental]

De principele bezwaren tegen local admin rechten uitdelen worden over het algemeen vrij rap omver gekegeld door een knap staaltje bedrijfspolitiek.
Als een applicatie niet vervangen kan worden en niet zonder local admin kan dan zal toch echt de betreffende gebruiker local admin worden.
Dit is geen onderbruikgevoel maar een kwestie van ervaring bij zowel de publieke- als de commerciele sector.

[alt-92]

Geen reden om dan maar de handdoek in de ring te gooien hoor
En als je in een beetje SAS70 certified toko werkt gaat de bedrijfspolitiek toch echt het onderspit delven (lees: dan worden dit soort workarounds tot het absolute minimum beperkt).

[Mental]

alt-92 schreef op dinsdag 25 januari 2011 @ 22:39:
(lees: dan worden dit soort workarounds tot het absolute minimum beperkt).

Zoals ik al zei, alles wat aan die 2 voorwaarden voldoet wordt gewoon doorgevoerd (kan niet zonder rechten, kan niet vervangen worden), tenzij het onder citrix wel kan draaien (op het moment nog vaak nog obv server 2003 ipv vista/win7 wat op de werkplek voor de nodige problemen zorgt met oude meuk).
Handoek in de ring gooien heeft hier niets mee te maken; het is een kwestie van een applicatie weigeren te migreren vanwege compatibility issues / benodigde rechten die vervolgens ondanks deze bezwaren alsnog gemigreerd moet worden.
Theorie is leuk, werkt alleen in de praktijk bijzonder vaak heel anders (ik doe niets anders dan migraties).

edit: nog even ontopic dan:

Bovenstaande "oplossing" is schreeuwen om problemen.
Je kunt beter users local admin maken omdat ze dan nog een prompt voor hun kiezen krijgen wanneer ze iets op een plek willen wijzigen die voor normale users niet schrijfbaar is.
Nu is dat niet zo heel spannend, maar applicaties die daar niet mogen schrijven normaal gesproken mogen dat na toepassing van je gpo ook.. UAC zet je volledig buitenspel voor de plekken waar je ze rechten geeft, niet heel slim.

[ Voor 22% gewijzigd door Mental op 25-01-2011 22:51 ]

[Dysmael]

Mental schreef op dinsdag 25 januari 2011 @ 22:33:
De principele bezwaren tegen local admin rechten uitdelen worden over het algemeen vrij rap omver gekegeld door een knap staaltje bedrijfspolitiek.
Als een applicatie niet vervangen kan worden en niet zonder local admin kan dan zal toch echt de betreffende gebruiker local admin worden.
Dit is geen onderbruikgevoel maar een kwestie van ervaring bij zowel de publieke- als de commerciele sector.

Liep hier kortgeleden nog tegen aan toen een boekhoudkundig programma compleet dienst weigerde als deze niet als Administrator werd gestart op een Terminal Server. Het boekhoudprogramma draait nu lokaal, op een apart werkstation welke niet in het domein is opgenomen. Zelfs dat kan je zo configureren dat een applicatie op een werkstation welke niet in het domein zit alsnog binnen je Terminal omgeving beschikbaar is, als je dat zou willen. Volledig transparant voor de gebruiker en zonder de nadelige gevolgen van de gebruiker zelf alle rechten geven.
Een andere mogelijkheid zou zijn om bv dmv Process Monitor na te gaan waar het process op vast loopt (mbt rechten) en de desbetreffende rechten, al dan niet enkel wanneer de applicatie actief is, aan te passen. Maar iemand lokal admin maken terwijl je ook simpelweg doelgericht oa rechten op registersleutels aan kan passen is gewoon lui, onkunde en simpelweg vragen om problemen. Ofwel: 'Ik kan het niet, dus hier: je krijgt alle rechten van mij, red je ermee!''

[MAX3400]

Dat een applicatie onder een admin-account wil draaien, wil nog niet zeggen dat je, zoals de topic-starter, een user maar rechten gaat geven op regedit & program files. Dat ga je dus proberen te minimaliseren tot de strikt benodigde keys en strikt noodzakelijke files en/of je geeft "domain users" rechten op de betreffende reg-key zonder dat ze het weten.Kan me namelijk niet voorstellen dat een user-account full-admin rechten nodig heeft op de volledige directory van een applicatie; hoogstens op een paar ini-files of iets dergelijks.

Maar ja, dat is mijn opinie.

tenzij het onder citrix wel kan draaien

Ook hier gelden de beperkingen van de topicstarter dan; je kan een applicatie misschien 100% installeren op een Terminal Server en via Citrix aanbieden als Published App/Desktop, dan nog zal je de user rechten moeten geven op de keys/files uit de topicstart. Sterker nog, als je load-balanced moet je die user (of users) rechten geven op reg-key/file op elke Citrix-server of je moet het in een silo gaan bouwen.

[alt-92]

RolfLobker schreef op dinsdag 25 januari 2011 @ 22:52:
[...]
Maar iemand lokal admin maken terwijl je ook simpelweg doelgericht oa rechten op registersleutels aan kan passen is gewoon lui, onkunde en simpelweg vragen om problemen. Ofwel: 'Ik kan het niet, dus hier: je krijgt alle rechten van mij, red je ermee!''

Mwa, je kan er voor kiezen (maar dat zei ik ook al in het vorige topic over dit onderwerp van TS) om je userts local admin te geven.
Alleen zul je dan qua ondersteuning & supportdesk andere afspraken moeten maken

Anyways: Domain users op je hele registry én %programfiles% folders botweg alle rechten geven komt op hetzelfde neer als ze Localadmin geven.
Met als extra nadeel dat je zo je eigen versie van Windows gaat maken en wat betreft leveranciersondersteuning gelijk kan doen.

[Mental]

Een andere mogelijkheid zou zijn om bv dmv Process Monitor na te gaan waar het process op vast loopt (mbt rechten) en de desbetreffende rechten, al dan niet enkel wanneer de applicatie actief is, aan te passen. Maar iemand lokal admin maken terwijl je ook simpelweg doelgericht oa rechten op registersleutels aan kan passen is gewoon lui, onkunde en simpelweg vragen om problemen. Ofwel: 'Ik kan het niet, dus hier: je krijgt alle rechten van mij, red je ermee!''

Het is mijn werk om applicaties te migreren dus je mag enigzins aannemen dat ik dit dan ook doe, dit suggereren is een regelrechte belediging, bewust of onbewust
Maar als je oplossingen hebt om bijv. kerneldriver manipulatie en r/w op global objects te kunnen toestaan zonder een station dermate open te gooien dat het veiliger is om administrator rechten weg te geven let me know.

Verder, het citrix voorbeeld wat ik geef gaat meer over het architectuur verschil tussen windows xp/2003 en vista/2008 - 7/2008 r2.
De overgang naar een van de laatste 2 kan er voor zorgen dat een applicatie teveel rechten nodig heeft om te functioneren en dan is het wel fijn om een 2003 citrix omgeving te hebben die daar geen last van heeft.

Anyways: Domain users op je hele registry én %programfiles% folders botweg alle rechten geven komt op hetzelfde neer als ze Localadmin geven.

Bijna wel ja, maar zoals gezegd: je omzeilt UAC hiermee en dat is uberhaubt niet slim in een bedrijfsomgeving aangezien geautomatiseerde acties dan ook niet tegengehouden worden.

Het boekhoudprogramma draait nu lokaal, op een apart werkstation welke niet in het domein is opgenomen

Dat soort dingen zijn leuk als het om enkele users / 1 of 2 applicaties gaat.
Als het om meer dan 100 users gaat dan wordt dat al minder interessant; een open (lees: onbeheerde) werkplek met adminrechten komt in de praktijk meer voor.

[ Voor 22% gewijzigd door Mental op 25-01-2011 23:10 ]

[monta]

Ik weet dat veel mensen het er niet mee eens zijn maar je kunt nooit oordelen over een beslissing die iemand neemt als je de achtergrond niet kent.
Natuurlijk kun je alleen op bepaalde folders rechten geven en op bepaalde keys, maar rechten op program files geven is niet hetzelfde als local admin.
Een local admin kan via c$ naar andere systemen, daarnaast kan een local admin andere profilen zien en eventueel naar schrijven enz., een lokale admin kan instellingen wijzigen van de machine niet alleen voor een profiel.

Er zijn dus nogal wat verschillen tussen Local Admin maken en rechten geven op de registry. Van mij mag een gebruiker op zijn eigen systeem in de program files schrijven alsook in het registry...
Een lokale gebruiker mag echter niet bij andere profielen komen, of slechter bij andere systemen.
En als je nogal veel oude programma's hebt die echt niet werken zonder admin of je moet 100 x per dag een toestemmingsvenster wegklikken dan kies ik voor het andere.

[monta]

Om even terug te komen op de topicstart:

Het gaat niet echt goed met die registry rechten. Het volgende heb ik in de registry geplaatst:
In de key: computer configuration - security settings- regsitry de volgende keys toegevoegd:
Machine
Classes_root
Users

Voor alle keys zijn de rechten hetzelfde als volgt:
domein gebruikers: Full rights
gebruikers: leesrechten (dit zijn volgens mij de lokale gebruikers)
Administrators full rights.

Na het booten in de bepaalde OU waar de policy aanhangt starten bepaalde services niet meer zoals de Local Awareness Service. Na wat zoekwerk blijkt dat je op een bepaalde key de SERVICE rechten moet geven daarna kun je die services wel starten.
Dit heeft dus te maken met de rechten die ik gegeven heb en tevens ook gekozen voor replace current rights.

Wat gaat er verkeerd? ALs ik naar de standaard rechten van de registerkeys kijk staat er ook geen SERVICE bij die rechten heeft...

[Mental]

Replace current rights op een complete registry hive is sowieso iets wat je niet wilt, wat je al aangeeft is dat je service accounts hun rechten missen.
Toch even iets anders bedenken dus.

[Dysmael]

Mental schreef op dinsdag 25 januari 2011 @ 23:08:
[...]

Het is mijn werk om applicaties te migreren dus je mag enigzins aannemen dat ik dit dan ook doe, dit suggereren is een regelrechte belediging, bewust of onbewust

Was een algemene opmerking. Niet persoonlijk en ook niet beledigend bedoeld.

Mental schreef op dinsdag 25 januari 2011 @ 23:08:
[...]

Maar als je oplossingen hebt om bijv. kerneldriver manipulatie en r/w op global objects te kunnen toestaan zonder een station dermate open te gooien dat het veiliger is om administrator rechten weg te geven let me know.

Niet bepaald. Afgezien van doorspitten met de SDK (Debugging tools). Vraag me af of je het uberhaupt gaat oplossen ook al kan je zien wat de oorzaak is. Druk uitoefenen op leverancier om beter programmeerwerk te leveren lijkt me, hoewel dat ook vaak tegen dovemansoren is, een betere weg om te bewandelen.

[...]

Mental schreef op dinsdag 25 januari 2011 @ 23:08:
[...]

Dat soort dingen zijn leuk als het om enkele users / 1 of 2 applicaties gaat.
Als het om meer dan 100 users gaat dan wordt dat al minder interessant; een open (lees: onbeheerde) werkplek met adminrechten komt in de praktijk meer voor.

Betrof hier gelukkig één werkplek en één applicatie. Zou het echter 100 gebruikers betreffen dan zou je deze wellicht kunnen plaatsen op een aparte terminal server waar iedereen wel meer rechten heeft en alleen de applicatie zelf te publiseren. Gebruik je bv RES Workspace (Powerfuse) dan kan je daarin redelijk simpel applicaties die op een TS/Citrix omgeving draaien beschikbaar stellen voor iedereen op hun eigen werkplek. Ook als dat een andere TS/Citrix omgeving is. Zonder dat de gebruiker het merkt draait één applicatie dus compleet geisoleerd van de rest.

[alt-92]

monta schreef op woensdag 26 januari 2011 @ 11:37:
Wat gaat er verkeerd? ALs ik naar de standaard rechten van de registerkeys kijk staat er ook geen SERVICE bij die rechten heeft...

Daar had ik je dus ook voor gewaarschuwd Als je niet weet waar je naar moet kijken ga je met dit soort dingen dus ook de mist in.
Services en service-gerelateerde registry keys moet je dan ook gewoon van afblijven.

We blijven onszelf maar weer herhalen: breng eerst in kaart wáár je users die rechten nodig hebben.

[monta]

Ik ben er nu wel uit. Geef alleen op de HKLM\software de rechten, heb je volgens mij geen problemen met programma's.