UAC Probleem

[Verwijderd]

Beste Tweakers,

Momenteel is UAC enabled voor domain computers zodat normale domain users geen rotzooi op hun PC kunnen installeren. Dit is voor een domein met ongeveer 25 workstations. Elke domain computer moet ongeveer 2x per week manueel een update uitvoeren van hun CRM pakket.

Door de UAC beperkingen kunnen ze dit niet uitvoeren. Ik zoek dus naar een mogelijkheid om voor deze specifieke applicatie UAC te disablen.

Volgens google bestaan hier heel wat exotische oplossingen voor. Ik lees ondermeer door het aanmaken van een scheduled task shortcut (http://www.sevenforums.co...ut-uac-prompt-create.html) of door het downloaden van Microsoft Application Compatibility Toolkit. (http://cybernetnews.com/h...rompt-for-an-application/)

Nu lijken mij deze oplossingen iets te vergezocht om gewoon een simpele update van een CRM pakket te kunnen doorvoeren. Ik ben eigenlijk op zoek naar een GPO oplossing voor dit probleem om alle PC's tegelijk te kunnen instellen. Helaas vind ik hiervan geen voorbeelden.

Iemand die raad/tips heeft voor deze issue?

[CMD-Snake]

UAC kan niet selectief per applicatie werken. Wel per user.

Wel bijzonder dat je CRM pakket twee maal per week een update moet krijgen.

Je zou kunnen overwegen om als je de patch voor je CRM in MSI vorm krijgt om deze middels een GPO te pushen naar als je PC's. Dan installeert de GPO de patch en heeft de gebruiker geen admin rechten nodig. Als het een .exe is zou je ook nog deze kunnen pushen middels een login script of logoff script.

[Verwijderd]

CMD-Snake schreef op vrijdag 16 mei 2014 @ 06:59:
UAC kan niet selectief per applicatie werken. Wel per user.

Wel bijzonder dat je CRM pakket twee maal per week een update moet krijgen.

Je zou kunnen overwegen om als je de patch voor je CRM in MSI vorm krijgt om deze middels een GPO te pushen naar als je PC's. Dan installeert de GPO de patch en heeft de gebruiker geen admin rechten nodig. Als het een .exe is zou je ook nog deze kunnen pushen middels een login script of logoff script.

Er wordt gewoon een .exe uitgevoerd die lokaal op iedere PC staat. Bij het uitvoeren hiervan wordt een ftp-connectie opgezet die de nieuwste versie zal downloaden en daarna de huidige versie overschrijven.
Kan dus wel een goed idee zijn om dit via GPO te doen, enorm bedankt voor de tip!

[Glashelder]

Dit uitvoeren met behulp van een login script gaat niet werken omdat die draaien onder de rechten van de gebruiker.

Uitvoeren als startup script werkt wel, maar dan moet je wel de computeraccounts van je domein leesrechten geven op de share waar je de EXE neerzet (domain computers).

[Verwijderd]

Ik had nu als eenvoudige oplossing om domain users full control te geven op de .exe die lokaal op elke PC staat. Zijn niet zoveel PC's ook uiteindelijk.

Toen ik dan de .exe ging uitvoeren, werden de domain credentials niet aanvaard door UAC hoewel toch domain users full control hebben op de .exe

[Verwijderd]

Als je pakket structureel bijgewerkt wordt kan je het beste om een MSI vragen. Die rollen via AD heel erg prettig uit zonder gedoe. Kan me bijna niet voorstellen dat je de enige klant bent die met dit probleem zit?
Deze manier van updates werkt onverstandig IT beleid in de had zoals users voorzien van lokale administrator rechten.

[Glashelder]

Verwijderd schreef op maandag 19 mei 2014 @ 12:25:
Ik had nu als eenvoudige oplossing om domain users full control te geven op de .exe die lokaal op elke PC staat. Zijn niet zoveel PC's ook uiteindelijk.

Toen ik dan de .exe ging uitvoeren, werden de domain credentials niet aanvaard door UAC hoewel toch domain users full control hebben op de .exe

Je krijgt die UAC prompt omdat je gebruikers blijkbaar geen lokale administrator rechten hebben. Hadden ze dat wel, dan krijg je alsnog een UAC prompt maar dit keer alleen met een vraag of je het uitvoeren van het bestand wel of niet wilt toestaan.

Naar mijn mening kan je het beste (indien je geen MSI kunt krijgen) even uitzoeken of deze .EXE zichzelf stil kan installeren. Dit kan je dan met een startup script regelen.

Houd er wel rekening mee dat een startup script altijd bij het opstarten wordt uitgevoerd. Je moet dus even kijken of deze .EXE niet bij elke herstart dan een update gaat doen

[Verwijderd]

Verwijderd schreef op maandag 19 mei 2014 @ 12:30:
Als je pakket structureel bijgewerkt wordt kan je het beste om een MSI vragen. Die rollen via AD heel erg prettig uit zonder gedoe. Kan me bijna niet voorstellen dat je de enige klant bent die met dit probleem zit?
Deze manier van updates werkt onverstandig IT beleid in de had zoals users voorzien van lokale administrator rechten.

Als ik uitsluitend op die exe instel dat domain users hierop rechten hebben? Is toch nog een groot verschil dan direct de domain user lokale admin maken.

[alt-92]

Ook dat zal je dan niet helpen.
Wat is trouwens de naam van die .exe ?
Een aantal rereserveerde namen triggeren hoe dan ook UAC.

[Verwijderd]

alt-92 schreef op dinsdag 20 mei 2014 @ 20:47:
Ook dat zal je dan niet helpen.
Wat is trouwens de naam van die .exe ?
Een aantal rereserveerde namen triggeren hoe dan ook UAC.

Waarom niet?
Dan kunnen de gebruikers met hun eigen gebruikersnaam authenticeren via UAC.

[Glashelder]

Omdat UAC niet getriggerd wordt als je geen rechten hebt om een bepaald bestand niet te lezen. UAC komt pas tevoorschijn als je programma acties wilt uitvoeren waar het user account niet toe gerechtigd is*. Waren ze dat wel, dan krijg je alleen een vraag om toestemming.

Maar blijkbaar wil je het niet begrijpen

*Als local admin krijg je de UAC prompt ook, omdat UAC ervoor zorgt dat je effectief zonder administrator rechten werkt, totdat je de toestemming aan UAC geeft om die rechten tijdelijk wel te geven

Waarom denk je dat UAC je probleem veroorzaakt?

[Verwijderd]

Glashelder schreef op donderdag 22 mei 2014 @ 08:58:
Omdat UAC niet getriggerd wordt als je geen rechten hebt om een bepaald bestand niet te lezen. UAC komt pas tevoorschijn als je programma acties wilt uitvoeren waar het user account niet toe gerechtigd is*. Waren ze dat wel, dan krijg je alleen een vraag om toestemming.

Maar blijkbaar wil je het niet begrijpen

*Als local admin krijg je de UAC prompt ook, omdat UAC ervoor zorgt dat je effectief zonder administrator rechten werkt, totdat je de toestemming aan UAC geeft om die rechten tijdelijk wel te geven

Waarom denk je dat UAC je probleem veroorzaakt?

"Waren ze dat wel, dan krijg je alleen een vraag om toestemming."

Sorry maar ik begrijp het inderdaad nog steeds niet. Volgens uw uitleg wordt UAC pas getriggerd als je iets wil uitvoeren waar je GEEN rechten toe hebt. Als ik die user full control op die .exe geef. Dan heeft hij toch WEL rechten om die .exe uit te voeren?

[marquis]

Wel op de .exe maar nog steeds geen rechten om iets lokaal op de pc te mogen installeren. Anders zouden ze ook .exe vanaf internet kunnen instaleren. Daar grijpt de UAC in.

[ Voor 7% gewijzigd door marquis op 22-05-2014 12:32 ]

[Glashelder]

Precies. Dat je het recht hebt om een bestand te lezen of uitvoeren betekent nog niet dat dat bestand dan OOK het recht heeft om alles maar te mogen doen op die PC.

Je hebt bestandspermissies (1) en rechten op je lokale systeem (2). Deel 1 heb je nu afgedekt, alleen deel 2 niet. Waarschijnlijk probeert jouw .EXE te schrijven naar bijv. C:\Program Files en dat mag een normale user niet.

Dus dit probleem kan je op twee manieren oplossen. Oplossing één is het geven van lokale administrator rechten aan je gebruikers (zéér onverstandig). Oplossing twee is een opstartscript (géén log-in script, want die draait als de lokale user en heeft dus weer geen rechten) of een MSI die je via een GPO laat uitrollen. Die draaien beide onder het machineaccount en die heeft wel genoeg rechten.

[Verwijderd]

Glashelder schreef op donderdag 22 mei 2014 @ 13:04:
Precies. Dat je het recht hebt om een bestand te lezen of uitvoeren betekent nog niet dat dat bestand dan OOK het recht heeft om alles maar te mogen doen op die PC.

Je hebt bestandspermissies (1) en rechten op je lokale systeem (2). Deel 1 heb je nu afgedekt, alleen deel 2 niet. Waarschijnlijk probeert jouw .EXE te schrijven naar bijv. C:\Program Files en dat mag een normale user niet.

Dus dit probleem kan je op twee manieren oplossen. Oplossing één is het geven van lokale administrator rechten aan je gebruikers (zéér onverstandig). Oplossing twee is een opstartscript (géén log-in script, want die draait als de lokale user en heeft dus weer geen rechten) of een MSI die je via een GPO laat uitrollen. Die draaien beide onder het machineaccount en die heeft wel genoeg rechten.

Ok, erg dank voor het geduld & de duidelijke uitleg.
Kleine vraag: heeft de computeraccount heeft automatisch volledige rechten op het lokale systeem en het bestand zelf? Dus in principe definiër ik in startup script dat die .exe moet uitgevoerd worden.

Om verder te gaan op mijn vorig (slecht) idee. Nu de bestandspermissies goed staan, stel dat ik de rechten op mijn systeem dan ook nog eens aanpas? Ben ik er dan? Of is dit te kort door de bocht? Ik weet perfect naar welk pad de .exe schrijft. Als ik op die directory de user dan rechten toegeef, heb ik én deel 1 én deel 2 afgedekt.

[marquis]

Om verder te gaan op mijn vorig (slecht) idee. Nu de bestandspermissies goed staan, stel dat ik de rechten op mijn systeem dan ook nog eens aanpas? Ben ik er dan? Of is dit te kort door de bocht? Ik weet perfect naar welk pad de .exe schrijft. Als ik op die directory de user dan rechten toegeef, heb ik én deel 1 én deel 2 afgedekt.

Nee, het moet waarschijnlijk ook in het register schrijven. Dus kan je .exe wel de bestanden neerzetten maar niet het register beschrijven. Ik zou, zoals "glashelder"al schrijft, via de GPO laten lopen. Dat is (volgens mijn mening) de standaard route en werkt ook het beste.

[Glashelder]

Agree met marquis. Het is ook gewoon best practice om installaties te doen met een account wat daar gewoon altijd de juiste rechten voor heeft. Misschien dat het anders nu goed gaat, maar in de toekomst weer niet.

Houd er overigens rekening mee dat áls je gebruikt gaat maken van een startup script dat je huidige bestandspermissies niet meer toereikend zijn. Je zult dan computers accounts toegang moeten gaan verlenen (Domain Computers, is net zoals Domain Users gewoon een groep).