Impossibile concedere le autorizzazioni "Invia come" in Exchange 2010

Sto cercando di concedere le autorizzazioni "Invia come" a un utente in Exchange 2010. Ecco il comando Powershell che sto eseguendo:

Add-ADPermission "User1" -User "Ourdomain\User2" -Extendedrights "Send As"

Powershell restituisce questo errore:

Operazione di Active Directory non riuscita su DC.OurDomain.pri. Questo errore non è recuperabile. Ulteriori informazioni: accesso negato. Risposta di Active Directory: 00000005: SecErr: DSID-031521D0, problema 4003 (INSUFF_ACCESS_RIGHTS), dati 0 + CategoryInfo: WriteError: (0: Int32) [Add-ADPermission], ADOperationException + FullyQualifiedErrorId: EDBB94A3, Microsoft.Exchange.Man AddADPermission

Ho provato diverse alternative al comando Powershell - ad es. utilizzando -Identity ecc., ma questo e la procedura guidata EMC restituiscono tutti lo stesso errore.

Non sono sicuro che "INSUFF_ACCESS_RIGHTS" si riferisca a me che sta eseguendo il comando o all'utente a cui sto dando i diritti di invio?

Ho seguito la pagina Web "Gestisci le autorizzazioni come una cassetta postale" di Microsoft Technet qui: http://technet.microsoft.com/en-us/library/bb676368.aspx

Quindi ho aggiunto le due autorizzazioni necessarie per fare questo:

Gestione dell'organizzazione

Gestione dei destinatari

Ma questo non aiuta. Qualche idea?

Aggiornare

Se faccio quanto segue:

• apri "Utenti e computer AD" con la vista "Funzioni avanzate"
• Vai alle proprietà di User1
• Premi "Avanzate" nella scheda Sicurezza
• Seleziona "Aggiungi"
• inserire "Utente2" e selezionare "Invia come" Consenti

Funziona, se chiudo ADUaC e lo riapro e ricontrollo quelle nuove autorizzazioni sono ancora lì. Se ritorno circa 10 minuti dopo, tali autorizzazioni non sono più disponibili - user2 non viene visualizzato nelle autorizzazioni di sicurezza di user1.

Non pensare di aver mai visto questo tipo di comportamento AD prima.

Ho finalmente risolto questo problema.

È interessante notare che Send-As è un'autorizzazione AD, non un'autorizzazione di scambio come ci si potrebbe aspettare.

Ad ogni modo, questi sono i passaggi:

Rendi "condivisibile" la cassetta postale di destinazione usando questo comando in Powershell sul tuo Exchange Server:

Set-Mailbox user1 -type:shared

Se ricevi questo errore (come nel mio primo post):

Dovrai trovare quell'utente in AD e andare alle proprietà >> Sicurezza >> Avanzate:

È necessario ABILITARE l'opzione "Includi autorizzazioni ereditabili dal genitore di questo oggetto":

Una volta fatto ciò, dovresti essere in grado di completare lo script di condivisione delle cartelle.

Quindi concedi effettivamente i diritti usando questo comando:

Add-ADPermission user1 -User Ourdomain\User2 -ExtendedRights "Send As"

Spero che aiuti gli altri che hanno lo stesso problema.

Kieran

I messaggi di accesso negato di solito provengono dall'account che esegue la sessione di PowerShell senza autorizzazioni sufficienti. Lo ottengo sempre quando lancio Exchange Management Shell invece di eseguirlo come il mio account utente amministrativo.

A seguito del tuo aggiornamento, ciò che sospetto possa accadere è che Utente1 fa parte di un gruppo protetto (Operatori di stampa), quindi Exchange non ti consente di concedere Invia come su Utente2 perché sa che verrà rimosso solo nell'ora successiva. Sembra che tu abbia confermato tale teoria aggiungendo manualmente Invia come usando ADUC e vedendolo rimosso poco tempo dopo.

Sul controller di dominio che esegue il ruolo FSMO dell'emulatore PDC, ogni ora viene eseguito qualcosa chiamato thread adminSDHolder. Ciò che fa è prendere tutti gli account che sono (o sono mai stati, anche se successivamente sono stati rimossi) in gruppi protetti (Enterprise Admins, Domain Admins, Account Operators, Print Operators per citarne alcuni tra quelli più comuni) e rimuove tutti autorizzazioni concesse sugli oggetti e le sostituisce con determinate autorizzazioni esplicitamente definite. L'idea è che un account delegato non è in grado di rovinare e spogliare un amministratore di dominio dei suoi privilegi.

Non sono del tutto convinto che la tua soluzione di concessione esplicita dell'autorizzazione funzionerà e non verrà ripristinata ogni ora, ma ho sbagliato prima, quindi se lo fa, fantastico! Se tuttavia l'utente non deve appartenere al gruppo Print Operators, ti consiglio di modificare il suo account utilizzando ADSI Edit e di impostare la proprietà adminCount su zero. Quindi abilitare le autorizzazioni ereditabili sull'oggetto utente e ripristinare le autorizzazioni predefinite. Una volta che lo hai fatto, prova di nuovo il cmdlet di Exchange e con un po 'di fortuna funzionerà (ovviamente dai abbastanza tempo perché si verifichi la replica di Active Directory).

Non credo che sarai in grado di modificare il tuo cmdlet per adattarlo a questo - come ho detto, immagino (non certo però) che non ti permetterà di farlo perché Exchange sa che l'autorizzazione verrà rimossa poco dopo e sta cercando di salvare la confusione da parte tua. In circostanze "normali" (ovvero un utente standard) il cmdlet dovrebbe funzionare senza problemi poiché l'intero thread adminSDHolder non entra in gioco.

Hai visto questo KB: accesso negato quando provi a concedere all'utente l'autorizzazione "invia come" o "ricevi come" per un gruppo di distribuzione in Exchange Server 2010 o Exchange Server 2013

Causa

Per impostazione predefinita, al sottosistema attendibile di Exchange non viene concessa l'autorizzazione "modifica autorizzazioni". Ciò causa l'esito negativo del cmdlet Add-ADPermission con un errore Accesso negato.

Risoluzione

Per aggirare questo problema, aggiungere l'autorizzazione "modifica autorizzazioni" per il sottosistema attendibile di Exchange all'unità organizzativa (OU) che contiene il gruppo di distribuzione attenendosi alla seguente procedura:

1. Apri Utenti e computer di Active Directory.
2. Fare clic su Visualizza, quindi su Funzionalità avanzate.
3. Fare clic con il pulsante destro del mouse sull'unità organizzativa che contiene gli elenchi di distribuzione, quindi fare clic su Proprietà.
4. Nella scheda Sicurezza, fai clic su Avanzate.
5. Nella scheda Autorizzazioni, fai clic su Aggiungi.
6. Nella casella Immettere il nome dell'oggetto da selezionare, digitare Exchange sottosistema attendibile e quindi fare clic su OK.
7. Nella scheda Oggetto, selezionare Questo oggetto e tutti gli oggetti discendenti nell'elenco Applica a, individuare Modifica autorizzazioni nell'elenco Autorizzazioni, quindi impostarlo su Consenti.
8. Clicca OK.

Si è riscontrata questa "eredità non abilitata" sull'account di un utente, durante il tentativo di configurare la migrazione a o365. Impossibile importare le proprietà di Exchange. Ha scritto questa piccola routine per abilitare la casella di controllo "autorizzazioni ereditabili".

$user = Get-ADuser -Filter "(displayname -eq "Joe Cool")
$ou = [ADSI](“LDAP://” + $user)
$sec = $ou.psbase.objectSecurity
If ($sec.get_AreAccessRulesProtected()) {
   $isProtected = $false ## allows inheritance
   $preserveInheritance = $true ## preserver inhreited rules
   $sec.SetAccessRuleProtection($isProtected, $preserveInheritance)
   $ou.psbase.commitchanges()
   Write-Host “$user is now inherting permissions”;
}

Le soluzioni di cui sopra non hanno risolto il mio problema, ma questo ha fatto: http://support.risualblogs.com/blog/2012/02/07/the-user-has-insufficient-access-rights-error-when-trying- to-set-send-as-permessi-on-a-mailbox-in-cambio-2010 /

L'account utente AD specifico su cui stavo cercando di impostare i permessi Invia come non aveva le autorizzazioni ereditabili verificate in AD.