none
Delega autorizzazioni reset password Account di dominio RRS feed

  • Domanda

  • Salve,

    ho dei probelmi nel propagare le autorizzazioni ad un utente di dominio su 2008-R2. 

    Una volta eseguito il wizard di "delega guidata di controllo"  da "utenti e computer di AD" mi ritrovo che nella scheda "Sicurezza" di alcuni utenti non compare l' utente al quale ho concesso i diritti a resettare la password.

    Vi è mai capitata una situazione simile? Qualcuno può aiutarmi?

    Grazie mille.

    Stefano

    lunedì 14 gennaio 2013 16:04

Risposte

Tutte le risposte

  • prova a verificare di non trovarti nel caso indicato qui

    http://certcities.com/editorial/columns/story.asp?EditorialsID=277


    Edoardo Benussi
    Microsoft MVP
    edo[at]mvps[dot]org

    martedì 15 gennaio 2013 07:48
    Moderatore
  • Grazie Edoardo.

    Ho controllato l' account, ma non fa parte di nessun gruppo builtin di dominio. Per fare una prova mi sono creato un nuovo account senza alterarne le appartenenze ai gruppi, e il risultato, delegando anche quest' ultimo sulla stessa OU, è lo stesso che se lo avessi fatto con quello che veramente necessita di delega, ossia, solo su alcuni (gli stessi utenti dell' altro) vengono riscritte le schede "sicurezza" per concedere i diritti di reset Password.

    martedì 15 gennaio 2013 13:37
  • riesci ad individuare qualcosa che accomuna gli oggetti di a.d. per i quali l'utente delegato non compare nella tab security ?

    ad esempio, gli account utente stanno nella medesima OU ? fanno parte di uno stesso gruppo ?


    Edoardo Benussi
    Microsoft MVP
    edo[at]mvps[dot]org

    mercoledì 16 gennaio 2013 11:05
    Moderatore
  • Invece gli utenti che non ricevono le autorizzazioni si trovano in qualche gruppo built-in? Mi sembra di capire che tu abbia fatto questa verifica solo sull'utente che stai delegando.

    A questo proposito assicurati inoltre, nelle proprietà degli oggetti utente problematici, che l'attributo Admin-Count sia impostato correttamente su 0:

    http://msdn.microsoft.com/it-it/library/windows/desktop/ms675212(v=vs.85).aspx

    Se si trova su 1 allora l'utente fa parte di un gruppo protetto e Active Directory non può modificare le autorizzazioni per la delega tramite ereditarietà.
    mercoledì 16 gennaio 2013 11:10
    Moderatore
  • Tutti gli utenti sono membri soltanto dei seguenti gruppi di protezione: "Domain Users" (di default) "UserData" (gruppo di protezione per folder redirection) e sono posizionati nella stessa OU, non quella di default "Users", ma una che ho creato manualmente quando creai il dominio: dominio.local>Domain Users>Contabilità qui risiedono tutti gli utenti con i quali ho problemi.

    Ho trovato che "Admincount" è settato su 1 per quelli che non ricevono delega! Mentre invece per quelli che la ricevono è su "<non impostato>".

    Ho impostato "admincount" su "0" e riapplicato la delega ma continuano a non prendersi le autorizzazioni, tant'è che nella scheda sicurezza degli utenti non ancora non compare l' account da delegare. Io non ho mai cambiato quel valore ma come può essere successo??

    mercoledì 16 gennaio 2013 12:36
  • Non puoi modificare l'attributo manualmente, comunque a mio parere è quello il problema e bisognerebbe capire perchè quegli account risultano protetti.

    Leggi attentamente questa pagina: http://technet.microsoft.com/en-us/magazine/2009.09.sdadminholder.aspx


    mercoledì 16 gennaio 2013 14:41
    Moderatore
  • Ho letto il link, ma non essendo abbastanza ferrato nell'argomento (oltre a non essere madrelingua Inglese :-( ) non sono riuscito ha capire bene cosa devo fare, ho anche paura di giocarci troppo e non vorrei causare problemi piu tragici! Al 95% è come dici te, devo modificare quel valore da 1 a 0, ti è mai capitato di modificarli? Devo seguire la guida  passo passo "How to Use the dsHeuristics Attribute to Exclude Groups from AdminSDHolder"?

    Grazie ancora

    mercoledì 16 gennaio 2013 15:47
  • La mia teoria è che gli account in questione in passato erano stati inseriti in gruppi protetti ma dopo la rimozione l'attributo era rimasto configurato per errore. In questo caso ti troveresti nel caso "Orphaned AdminSDHolder Objects" descritto nella pagina.

    In base alle mie ricerche l'unico articolo che descrive questo problema è questo: http://support.microsoft.com/?id=817433

    E' un pò vecchio (Aprile 2009) ma potrebbe essere applicabile anche a Windows Server 2008 R2. 

    mercoledì 16 gennaio 2013 16:27
    Moderatore
  • Quindi anche se l' hotfix risolve il problema su sistemi precedenti al 2008, posso comunque provare giusto?
    mercoledì 16 gennaio 2013 16:48
  • L'hotfix probabilmente non si installerà direttamente, però puoi provare i workaround.

    Comunque, se gli account non sono molti, secondo me potresti valutare direttamente la creazione di nuovi oggetti utente.

    mercoledì 16 gennaio 2013 16:55
    Moderatore
  • Stanotte proverò l' hotfix, purtroppo gli account sono 34, inoltre mi sono accorto che oltre alla OU "Contabilità", anche quelli che stanno sotto altre OU hanno buonaparte AdminCount su 1.
    mercoledì 16 gennaio 2013 17:15
  • Mi sono virtualizzato il server in modo da farci le prove. Ho provato l' hotfix ma non mi funziona, quindi procedo con il workaround.

    La guida dice:

    Per attivare l'ereditarietà per il contenitore adminSDHolder:
    1. Il pulsante destro del contenitore e quindi fare clic su proprietà.
    2. Scegliere la scheda protezione
    3. Fare clic su Avanzate.
    4. Fare clic per selezionare la casella di controllo Consenti le autorizzazioni ereditabili di propagare a questo oggetto e tutti gli oggetti figlio

    Dove posso trovare questa voce nel 2008 r2?

    venerdì 18 gennaio 2013 14:18
  • E' uguale alle versioni precedenti di Windows Server 2008 R2....bisogna aprire lo snap-in di Utenti e computer di Active Directory, fare click su Visualizza > Funzionalità avanzate, spostarsi in System > AdminSDHolder e fare click su Proprietà > scheda Sicurezza.
    venerdì 18 gennaio 2013 16:41
    Moderatore
  • Scusa mi sono spiegato male, non trovo la voce: consenti le autorizzazioni ereditabili di propagare a questo oggetto e tutti gli oggetti figlio.
    venerdì 18 gennaio 2013 17:57
  • Dovrebbe essere equivalente alla selezione della casella "Includi le autorizzazioni ereditabili del padre dell'oggetto" in quanto, quando selezionata, gli oggetti figlio erediteranno le autorizzazioni dall'oggetto padre. Quando invece è deselezionata le autorizzazioni applicate all'oggetto padre non verranno trasmesse agli oggetti figlio (questa è l'impostazione di default per questo elemento).

    venerdì 18 gennaio 2013 22:09
    Moderatore
  • Ho selezionato la casella, riavviato il server e atteso un pò sperando che le autorizzazioni venissero propagate, ma niente da fare, gli utenti continuano ad avere AdminCount su 1.
    sabato 19 gennaio 2013 18:41
  • ...ho provato anche "ripristina predefinite" sia dalla scheda "sicurezza" che "controllo", ma niente da fare.
    sabato 19 gennaio 2013 18:58
  • Una volta abilitata l'ereditarietà dovresti anche essere in grado di modificare manualmente l'attributo AdminCount, puoi anche provare ad utilizzare lo script fornito (che in pratica non fa altro che eseguire le due operazioni automaticamente per tutti gli utenti). Una volta che l'attributo sarà stato impostato su 0 e sarà stata abilitata l'ereditarietà per gli oggetti non dovresti avere più problemi in quanto alla prossima esecuzione del thread verrà bloccata nuovamente l'ereditarietà e verrà reimpostato l'attributo solo per gli utenti (oggetti) che si trovano effettivamente in gruppi protetti. Per questo motivo verifica attentamente che gli utenti non appartengano effettivamente a qualche gruppo protetto prima di eseguire l'operazione, altrimenti non si risolverà comunque il problema.

    sabato 19 gennaio 2013 20:29
    Moderatore
  • Abilitata eredità su AdminSDHolder.

    Impostato a 0 AdminCount per gli utenti che lo avevano a 1.

    Delegato utente per "Reimposta password" (direttamente dall' OU)

    Tutto come prima, alcuni utenti la prendono alcuni no. (gli stessi identici)

    Non so se ho capito bene quando mi dici "controlla che gli utenti non appartengano effettivamente a qualche gruppo protetto prima di eseguire l'operazione", intendi dire che devo controllare nella scheda "membro di" che l' account non faccia parte di qualche gruppo che blocca ereditarietà? Perchè tutti gli utenti sono membri delgli stessi gruppi, sia quelli che prendo la delega sia quelli che non la prendono.

    domenica 20 gennaio 2013 12:00
  • Si, intendevo dire di controllare bene i membri di gruppi protetti. A questo punto prova a fare così: crea un nuovo utente nell'OU (senza copiarlo da un account già esistente), attendi circa 60 minuti e poi verifica se AdminCount viene impostato su 1. Il mio dubbio è che gli account problematici siano quelli che hanno l'AdminCount a 0. Verifica anche che gli account che hai modificato manualmente abbiano AdminCount sempre a 0 e che non sia stato reimpostato a 1 dal sistema. 

    domenica 20 gennaio 2013 12:16
    Moderatore
  • Fatto.  Ho creato un nuovo utente e atteso 2 ore. Il nuovo utente si presenta come alcuni dei vecchi con AdminCount <non impostato>. Quelli che ho impostato manualmente a <0> sono rimasti come tali. Ho riprovato a riapplicare la delega ma non funziona ancora.

    domenica 20 gennaio 2013 17:59
  • OK, quindi il problema è effettivamente degli account....lo script dell'articolo hai provato ad eseguirlo?

    In alternativa potresti provare anche con PowerShell:

    http://www.ehloworld.com/1621

    domenica 20 gennaio 2013 18:38
    Moderatore
  • Lo script me lo ero lasciato per ultimo.

    A questo punto ho provato sia con script che con PowerShell, risultato: tutti gli account affetti dal problema ricevono la delega per il reset password, eccetto uno! Avendo fatto tutte le prove in virtuale, credi che a questo punto posso eseguire sia lo script che PS direttamente sul DC in produzione? Te lo chiedo perchè è la prima volta che mi capita e non vorrei creare casini su tutti gli utenti. 

    domenica 20 gennaio 2013 19:58
  • Considera che si tratta pur sempre di una modifica importante quindi è sempre meglio fare un backup del DC prima dell'operazione e lasciarlo da parte in caso di eventuali problemi: al limite con un ripristino autorevole dovresti riportare tutto com'è, basta però monitorare attentamenta la situazione nei prossimi giorni (se te ne accorgi troppo tardi potrebbe essere un problema, anche in relazione al numero di modifiche che vengono eseguite giornalmente su AD).

    domenica 20 gennaio 2013 22:44
    Moderatore
  • Grazie mille per l' aiuto, ad oggi le deleghe stanno funzionando e le modifiche apportate non hanno causato nessun problema in AD.

    giovedì 24 gennaio 2013 11:00
  • Grazie a te per il feedback.
    giovedì 24 gennaio 2013 11:31
    Moderatore
  • Un' ultima domanda.....è giusto che "Administrator" rimanga con AdminCount su 1?
    giovedì 24 gennaio 2013 11:56
  • Si, è normale ed è l'impostazione di default....Administrator deve rimanere protetto perchè è un account "critico" per il dominio.

    giovedì 24 gennaio 2013 12:49
    Moderatore
  • OK Grazie Fabrizio. Quindi è giusto anche che, essendo il mio account un membro di Domain Admins, sia impostato su 1?
    giovedì 24 gennaio 2013 13:03
  • Si, è corretto. Tutti gli account appartenenti a gruppi protetti hanno AdminCount su 1.
    giovedì 24 gennaio 2013 16:24
    Moderatore