Imansible dare autorizzazioni di invio come in Exchange 2010

Sto cercando di assegnare le autorizzazioni 'send-as' a un utente in Exchange 2010. Ecco il command Powershell in esecuzione:

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

Powershell restituisce questo errore:

L'operazione di Active Directory non è rioutput su DC.OurDomain.pri. Questo errore non è ripristinabile. Ulteriori informazioni: L'accesso è negato. Risposta della directory triggers: 00000005: SecErr: DSID-031521D0, problema 4003 (INSUFF_ACCESS_RIGHTS), dati 0 + CategoriaInfo: WriteError: (0: Int32) [Add-ADPermission], ADOperationException + FullyQualifiedErrorId: EDBB94A3, Microsoft.Exchange.Management.RecipientTasks. AddADPermission

Ho provato diverse alternative al command Powershell – vale a dire. utilizzando -Identity ecc, ma che e la procedura guidata EMC restituiscono lo stesso errore.

Non sono sicuro se il "INSUFF_ACCESS_RIGHTS" mi riferisce a chi esegue il command o l'utente che sto a dare i diritti di invio come?

Ho seguito il sito web di Microsoft Technet "Gestisci invio come autorizzazioni per una cassetta postale" : http://technet.microsoft.com/en-us/library/bb676368.aspx

Così hanno aggiunto le due autorizzazioni necessarie per farlo:

Gestione dell'organizzazione

Gestione dei destinatari

Ma questo non sta aiutando. Qualche idea?

Aggiornare

Se faccio quanto segue:

  • aprire "Utenti e computer AD" con la vista "Caratteristiche avanzate"
  • Vai alle properties; di User1
  • Colpire "Avanzate" nella scheda Protezione
  • Seleziona "Aggiungi"
  • entrare in "User2" e select "Invia come" Consenti

Che funziona, se chiudo ADUaC e l'apro di nuovo e riesaminerò quelle nuove autorizzazioni che sono ancora lì. Se return circa 10 minuti più tardi tali autorizzazioni sono ormai scomparse – user2 non si presenta nelle autorizzazioni di protezione di user1 a tutti.

Non credo di aver mai visto questo tipo di comportmento AD prima.

  • Posso configurare OWA (2010) per informare un utente quando il suo account è bloccato?
  • Recupero del file OST senza profilo
  • Exchange 2007: configuration di esportzione?
  • Condividi i calendari di Exchange / Outlook tra due domini diversi
  • Gli errori di MS Exchange da risolvere per l'installazione sul server win 2012
  • Exchange 2013 ECP non è in grado di accedere
  • Exchange 2010 CAS (OWA) in ambiente Exchange 2007
  • Assicurare le cassette postali di Exchange da Admins Nosy
  • 5 Solutions collect form web for “Imansible dare autorizzazioni di invio come in Exchange 2010”

    Ho finalmente risolto questo.

    È interessante notare che Send-As è un'authorization AD – non un permesso di scambio come si potrebbe prevedere.

    Comunque, questi sono i passi:

    Rendere la cassetta postale di destinazione "condivisibile" utilizzando questo command in Powershell sul server di Exchange:

     Set-Mailbox user1 -type:shared 

    Se ottieni questo errore (come nel mio primo post): Fallimento AD

    Dovrai trovare l'utente in AD e andare alle properties; >> Sicurezza >> Avanzate:

    Proprietà AD

    È necessario abilitare l'opzione "Includi le autorizzazioni ereditabili dal genitore di questo object":

    immettere qui la descrizione dell'immagine

    Una volta che è fatto si dovrebbe essere in grado di completare lo script di condivisione di cartelle.

    Quindi effettivamente concedere i diritti utilizzando questo command:

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

    Spero che aiuta gli altri che hanno lo stesso problema.

    Kieran

    I messaggi di negazione di accesso vengono di solito dall'account che esegue la session di PowerShell non avendo abbastanza autorizzazioni. Ho tutto questo tempo quando lancio la shell di gestione di Exchange invece di eseguire l'esecuzione come mio account amministrativo.

    A seguito dell'aggiornamento, ciò che sospetto possa succedere è che User1 fa parte di un gruppo protetto (operatori di printing) in modo che Exchange non ti consente di concedere la trasmissione come in User2 perché sa che verrà eliminata solo nell'ora successiva. Sembra che tu abbia confermato questa teoria manualmente aggiungendo Send As con ADUC e vedendolo tolto poco tempo dopo.

    Sul controller di dominio che esegue il ruolo di FSMO Emulator PDC, each ora viene denominato il thread adminSDHolder. Ciò che fa è che tutti i conti che sono (o sono stati, anche se successivamente rimossi) in gruppi protetti (Admins aziendali, amministratori di dominio, operatori di account, operatori di printing per citarne alcuni dei più comuni) e rimuove tutti le autorizzazioni concesse sugli oggetti e le sostituisce con determinate autorizzazioni esplicitamente definite. L'idea è che un account delegato non sia in grado di distruggere e strappare un amministratore di dominio dei propri privilegi.

    Non sono del tutto convinto che il tuo fix di esplicito concessione del permesso sta andando a lavorare e non verrà ripristinato each ora, ma ho sbagliato prima – quindi se lo fa, è fantastico! Se tuttavia l'utente non deve essere presente nel gruppo Operatori printing, ti consiglierei di modificare il proprio account utilizzando ADSI Edit e impostare la properties; adminCount su zero. Quindi abilitare le autorizzazioni ereditabili sull'object utente e reimpostare le autorizzazioni predefinite. Una volta che hai fatto questo, provare nuovamente il cmdlet di Exchange e con un po 'di fortuna functionrà (ovviamente dare abbastanza tempo per la replica di AD).

    Non credo che sarai in grado di modificare il tuo cmdlet per accomodarvi per questo – come ho detto, immagino (non certo però) che non ti permetterà di farlo perché lo scambio sa che l'authorization sta per essere rimossa poco dopo e sta cercando di salvare la tua confusione da parte tua. In circostanze "normali" (cioè un utente standard) il cmdlet dovrebbe funzionare senza problemi perché l'integer thread di adminSDholder non è nemless entrato in gioco.

    Avete visto questo KB: Accesso negato quando si tenta di autorizzare l'utente "send-as" o "come ricevere come" per un gruppo di distribuzione in Exchange Server 2010 o Exchange Server 2013

    Causa

    Per impostazione predefinita, il sottosistema Trusted Subsystem non è concesso l'authorization "modifica autorizzazioni". In questo modo il cmdlet Add-ADPermission non è riuscito con un errore di Access denied.

    Risoluzione

    Per aggirare questo problema, aggiungere l'authorization "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 e quindi scegliere Caratteristiche avanzate.
    3. Fare clic con il button destro del mouse sull'OU che contiene gli elenchi di distribuzione e quindi scegliere Proprietà.
    4. Nella scheda Protezione, fare clic su Avanzate.
    5. Nella scheda Autorizzazioni, fare clic su Aggiungi.
    6. Nella casella Inserisci nome object per select, digitare sottosistema attendibile di Exchange e quindi scegliere OK.
    7. Nella scheda Oggetto, select Questo object e tutti gli oggetti discendenti nell'elenco Applica in, individuare Modifica autorizzazioni nell'elenco Autorizzazioni e quindi impostarlo su Consenti.
    8. Fare clic su OK.

    Ha riscontrato questa "inheritance; non abilitata" nell'account di un utente, mentre tentava di impostare la migrazione su o365. Imansible importre le properties; di Exchange. Ha scritto questa piccola routine per consentire 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 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 /

    Il particolare account utente AD che stavo cercando di impostare Send as perms on non ha avuto autorizzazioni ereditarie controllate in AD.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.