none
Abilitare l'installazione di un'applicazione al gruppo Users RRS feed

  • Domanda

  • Ciao a tutti.

    Scrivo qui, anche se la questione non è strettamente legata al dominio, sebbene in questa realtà i pc siano in join con un dominio. Il problema è che l'introduzione del dominio ha finalmente reso gli utenti Users e non più Administrators, e, come si sa, questo fatto diventa motivo di discussione continua tra IT e utenti.

    C'è effettivamente un'applicazione che vorremmo far gestire completamente agli utenti: si tratta di Dike, il software per la firma digitale di Infocert. Il problema principale è che questo software viene aggiornato molto spesso, ma l'utente del gruppo Users non ha i privilegi per aggiornarlo. Abbiamo fatto un po' di conti e abbiamo concluso che correre in giro su tutti i client a mettere password amministrative non appena Dike ha bisogno di un aggiornamento, è oggettivamente complicato. E inoltre dà un senso di "pezzotto", ovvero di qualcosa di arrangiato. Abbiamo pensato anche a fare un calendario per cui ogni mese si fa un giro e si va ad aggiornare Dike, il problema è che quando l'utente vede l'alert che sono presenti aggiornamenti, vuole applicarli subito perché teme che poi quello che firma digitalmente non sia legale. Ed è una discussione infinita.

    Ho provato personalmente con Process Monitor a capire dove Dike ha bisogno di privilegi amministrativi per potersi aggiornare e credo che tutto sia bloccato dall'accesso a determinate chiavi di registro, quelle dove vengono gestiti i certificati.

    Non mi sono avventurato ad "aprire" l'accesso a quelle sezioni del registro agli utenti del gruppo Users, perché mi sembrava una porcata pazzesca.

    C'è qualche soluzione più elegante? Tipo dire a Windows 7: -Questa applicazione ha poteri amministrativi anche quando la lancia un utente capra-?

    Grazie in anticipo, come sempre

    giaconet

    giovedì 6 ottobre 2011 14:41

Risposte

  • Se è vera la condizione precedente e cioè che a ogni aggiornamento corrisponde una nuove versione dell.exe scaricabile dal sito tu non dovrai fare altro che scaricare la nuova versione dal sito, estrarre l'MSI dalla temp e aggiungerlo alla policy di deploy precedentemente creata, in questo modo al riavvio o al logon successivo i client su cui e' abilitata la policy riceveranno l'aggiornamento.

     

    Devi fare solo due verifiche che l'msi si installi correttamente e che l'aggiornamento funzioni correttamente prima di inserirlo in produzione 

     

    Altre vie percorribili sono:

    l'utilizzo di Runas con password criptata http://www.robotronic.de/runasspcEn.html ne esistono diversi oltre a questo linkato.

     

    Ciao


    lunedì 10 ottobre 2011 14:48

Tutte le risposte

  • Non mi sono avventurato ad "aprire" l'accesso a quelle sezioni del registro agli utenti del gruppo Users, perché mi sembrava una porcata pazzesca.

    C'è qualche soluzione più elegante? Tipo dire a Windows 7: -Questa applicazione ha poteri amministrativi anche quando la lancia un utente capra-?

     


    ho percorso, non per Dike ma per altro, la strada numero 1 (visto che la numero 2 non può essere percorsa) e ti posso dire che non la ritengo una "porcata" anche perchè dare un permesso in scrittura su una chiave di registro (il ramo più limitato possibile) non fa capire al normale utente di aver acquisito i poteri di un semi-dio. dopo averglieli concessi si sentirà esattamente come prima senza riuscire a capire che in realtà qualcosa è cambiato.

    ciao.


    Edoardo Benussi
    Microsoft MVP - Management Infrastructure
    edo[at]mvps[dot]org
    giovedì 6 ottobre 2011 15:50
    Moderatore
  • Ciao,

     

    Potresti utilizzare l'MSI del programma per creare una policy di deploy oppure creare un wrapper MSI che lanci l'exe utilizzando gli switch silent ed aggiornarlo sempre tramite policy

     

    Non conosco il programma ma se l'aggiornamento avviene ogni volta tramite un eseguibile nuovo la soluzione qua sopra e' percorribile e ti permette di gestire tutto da policy, se invece il programma ha un sistema di update interno che non sempre corrisponde a un rilascio di un nuovo eseguibile non è una soluzione percorribile

     

     

    Ciao

    lunedì 10 ottobre 2011 09:28
  • Purtroppo non c'è un'MSI. L'applicazione è un'exe. Dike.exe. E lancia una shell con l'applicazione icSwUpdate.exe quando trova degli aggiornamenti da fare.

    Adesso sto facendo test per capire quanti "oggetti" sono realmente interessati in questo aggiornamento...

    Grazie

    giaconet

    lunedì 10 ottobre 2011 09:47
  • se il programma e' questo https://www.firma.infocert.it/software/DiKe 5.2.0.exe quando lanci l'eseguibile estrae un file .msi come nello screen in una cartella temporanea che puo essere poi utilizzato per creare una gpo di deploy

    se ogni aggiornamento corrisponde a un nuovo eseguibile scaricabile dal sito non dovresti avere grossi problemi.

    Ripeto sto cercando di aiutarti nonostante non conosca il programma e magari hai gia provato a seguire questa strada, scusami nel caso fosse cosi :)

     

    lunedì 10 ottobre 2011 09:57
  • Bella mossa.

    Devo verificare un attimo (sperando ci siano al più presto aggiornamenti da fare :-D).

    Magari mi prendo un vecchio file di installazione, così sicuramente si deve aggiornare. Mi viene un dubbio però: una volta fatta la policy, se il pacchetto scaricato dall'agent di update si chiama Dike 5.2.x.msi, è game over, giusto?

     

    Grazie, anyway

    giaconet

    lunedì 10 ottobre 2011 13:50
  • Se è vera la condizione precedente e cioè che a ogni aggiornamento corrisponde una nuove versione dell.exe scaricabile dal sito tu non dovrai fare altro che scaricare la nuova versione dal sito, estrarre l'MSI dalla temp e aggiungerlo alla policy di deploy precedentemente creata, in questo modo al riavvio o al logon successivo i client su cui e' abilitata la policy riceveranno l'aggiornamento.

     

    Devi fare solo due verifiche che l'msi si installi correttamente e che l'aggiornamento funzioni correttamente prima di inserirlo in produzione 

     

    Altre vie percorribili sono:

    l'utilizzo di Runas con password criptata http://www.robotronic.de/runasspcEn.html ne esistono diversi oltre a questo linkato.

     

    Ciao


    lunedì 10 ottobre 2011 14:48
  • Bellissimo anche questo del runas! Io ci avevo già pensato, usando un utente specifico, ma avevo il problema della password.

    Ci provo!!

    Grazie

    giaconet

    lunedì 10 ottobre 2011 15:37
  • E' passato qualche anno è vero, ma ti posso dire come abbiamo risolto noi.
    Semplicemente abbassando il livello dell'UAC.
    venerdì 13 giugno 2014 07:40
  • Cerco di rianimare questo vecchio thread anche perchè come amministrazione pubblica siamo quasi costretti ad usare il software DIKE.

    Per installare Dike sui ns. pc anche noi abbiamo estratto l'MSI dall'exe come già comunicato in questo thread ed inserito in una GPO.

    Analizzando le operazioni di Dike durante gli update con Procmon e altri tools ci siamo accorti che per l'aggiornamento dell' dike.exe altri componenti (attraverso internetUpdate.exe) basta dare diritti di scrittura all'utente sulla directory dell programma stesso. Per queste procedure non serve alterare o manipulare l'UAC.

    Per quanto riguarda l'update di altri processi attraverso icSwUpdate.exe, come per esempio scrittura nella registry nel seguente HIVE: HKLM\Software\Microsoft\SystemCertificates\ROOT\Certificates per Certificati, abbiamo concesso diritti di scrittura agli utenti.

    L'exe icSwUpdate.exe putroppo necessita dell'UAC e fino ad oggi non siamo stati in grado di modificare questa exe nel modo da non dover manipolare l'UAC stessa. (Funziona l'implementazione tramite RUNASPC, ma il problema che emerge da questa soluzione è che dopo l'update dei vari componenti, l'utente riesce ad avviare Dike con diritti di amministratore, soluzione quindi non applicabile per noi)...

    Anche la soluzione INVOKER del Microsoft ACT non funziona. L'UAC non si riesce a bypassare per icSwUpdate.exe.

    Se qualcuno di voi nell'frattempo è riuscito a risolvere il problema senza abbassare L'UAC e senza soluzioni come RUNASSPC, fatemi sapere!

    Grazie e saluti,
    benno


    • Modificato benomaniaz mercoledì 1 aprile 2015 09:41
    mercoledì 1 aprile 2015 09:40
  • Ora c'è lo stesso problema con Skype
    giovedì 22 marzo 2018 15:59