No se pueden otorgar permisos de "envío como" en Exchange 2010

Estoy tratando de otorgar permisos de 'enviar como' a un usuario en Exchange 2010. Aquí está el comando Powershell que estoy ejecutando:

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

Powershell devuelve este error:

La operación de Active Directory falló en DC.OurDomain.pri. Este error no es recuperable. Información adicional: acceso denegado. Respuesta del directorio activo: 00000005: SecErr: DSID-031521D0, problema 4003 (INSUFF_ACCESS_RIGHTS), datos 0 + CategoryInfo: WriteError: (0: Int32) [Add-ADPermission], ADOperationException + FullyQualifiedErrorId: EDBB94A3, Microsoft.Exchange. AddADPermission

He probado varias alternativas al comando Powershell, es decir. usando -Identity, etc., pero eso y el asistente de EMC devuelven el mismo error.

No estoy seguro de si "INSUFF_ACCESS_RIGHTS" se refiere a mí, ¿quién ejecuta el comando o al usuario al que le doy los derechos de envío?

He estado siguiendo la página web "Administrar Enviar como permisos para un buzón" de Microsoft Technet aquí: http://technet.microsoft.com/en-us/library/bb676368.aspx

Entonces agregué los dos permisos que necesita para hacer esto:

Gestión de la organización

Gestión de destinatarios

Pero eso no está ayudando. ¿Algunas ideas?

Actualizar

Si hago lo siguiente:

• abra "Usuarios y equipos de AD" con la vista "Funciones avanzadas"
• Ir a las propiedades de Usuario1
• Presiona "Avanzado" en la pestaña Seguridad
• Seleccione "Agregar"
• ingrese en "Usuario2" y seleccione "Enviar como" Permitir

Eso funciona, si cierro ADUaC y lo abro nuevamente y vuelvo a verificar esos nuevos permisos, todavía están allí. Si regreso unos 10 minutos más tarde, esos permisos ya no están: el usuario2 no aparece en absoluto en los permisos de seguridad del usuario1.

No creo que haya visto este tipo de comportamiento AD antes.

Finalmente he arreglado esto.

Curiosamente, Send-As es un permiso de AD, no un permiso de intercambio como podría haber esperado.

De todos modos, estos son los pasos:

Haga que el buzón de destino sea "compartible" con este comando en Powershell en su servidor de Exchange:

Set-Mailbox user1 -type:shared

Si obtiene este error (igual que en mi primera publicación):

Deberá encontrar ese usuario en AD e ir a las propiedades >> Seguridad >> Avanzado:

Es necesario para ACTIVAR la opción "Incluir todos los permisos heredables de un objeto primario de este objeto":

Una vez hecho esto, debería poder completar el script para compartir carpetas.

Luego, de hecho, otorgue los derechos con este comando:

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

Espero que ayude a otros que tienen el mismo problema.

Kieran

Los mensajes de acceso denegado generalmente provienen de la cuenta que ejecuta la sesión de PowerShell que no tiene suficiente permiso. Recibo esto todo el tiempo cuando inicio el Shell de administración de Exchange en lugar de ejecutarlo como mi cuenta de usuario administrativo.

Después de su actualización, lo que sospecho que puede estar sucediendo es que el Usuario1 es parte de un grupo protegido (Operadores de impresión), por lo que Exchange no le permite otorgar Enviar como en el Usuario2 porque sabe que solo se eliminará en la próxima hora. Parece que confirmó esa teoría al agregar manualmente Enviar como usando ADUC y ver que se elimina poco tiempo después.

En el controlador de dominio que ejecuta la función FSMO del emulador PDC, cada hora se ejecuta algo llamado subproceso adminSDHolder. Lo que esto hace es tomar todas las cuentas que están (o alguna vez han estado, incluso si se han eliminado posteriormente) en grupos protegidos (Administradores de empresas, Administradores de dominio, Operadores de cuentas, Operadores de impresión, por nombrar algunos de los más comunes) y elimina todos permisos otorgados en los objetos y los reemplaza con ciertos permisos definidos explícitamente. La idea es que una cuenta delegada no puede causar estragos y despojar a un administrador de dominio de sus privilegios.

No estoy completamente convencido de que su solución de otorgar permiso explícitamente va a funcionar y no se restablecerá cada hora, pero me he equivocado antes, así que si lo hace, ¡genial! Sin embargo, si el usuario no necesita estar en el grupo Operadores de impresión, le recomiendo que modifique su cuenta con ADSI Edit y establezca la propiedad adminCount en cero. Luego, habilite los permisos heredables en el objeto de usuario y restablezca los permisos predeterminados. Una vez que haya hecho eso, intente su cmdlet de Exchange nuevamente y con un poco de suerte funcionará (obviamente, dé suficiente tiempo para que se produzca la replicación de AD).

No creo que pueda modificar su cmdlet para adaptarse a esto; como dije, imagino (aunque no estoy seguro) que no le permitirá hacerlo porque Exchange sabe que el permiso solo se eliminará poco después y está tratando de salvar la confusión de su parte. En circunstancias "normales" (es decir, un usuario estándar), el cmdlet debería funcionar sin problemas porque todo el hilo adminSDHolder ni siquiera entra en juego.

¿Ha visto este KB: acceso denegado cuando intenta otorgar al usuario "enviar como" o "recibir como" permiso para un grupo de distribución en Exchange Server 2010 o Exchange Server 2013

Porque

De forma predeterminada, Exchange Trusted Subsystem no tiene el permiso "modificar permisos". Esto hace que el cmdlet Add-ADPermission falle con un error de acceso denegado.

Resolución

Para solucionar este problema, agregue el permiso "modificar permisos" para el Subsistema de confianza de Exchange a la unidad organizativa (OU) que contiene el Grupo de distribución siguiendo estos pasos:

1. Abra Usuarios y equipos de Active Directory.
2. Haga clic en Ver y luego en Funciones avanzadas.
3. Haga clic con el botón derecho en la unidad organizativa que contiene las listas de distribución y luego haga clic en Propiedades.
4. En la pestaña Seguridad, haga clic en Avanzado.
5. En la pestaña Permisos, haga clic en Agregar.
6. En el cuadro Introducir nombre del objeto para seleccionar, escriba Exchange subsistema de confianza y luego haga clic en Aceptar.
7. En la pestaña Objeto, seleccione Este objeto y todos los objetos descendientes en la lista Aplicar en, busque Modificar permisos en la lista Permisos y luego configúrelo en Permitir.
8. Haga clic en Aceptar.

Encontró esta 'herencia no habilitada' en la cuenta de un usuario, al intentar configurar la migración a o365. No se pudieron importar las propiedades de Exchange. Escribió esta pequeña rutina para habilitar la casilla de verificación 'permisos heredables'.

$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”;
}

Las soluciones anteriores no resolvieron mi problema, pero esta sí: http://support.risualblogs.com/blog/2012/02/07/the-user-has-insufficient-access-rights-error-when-trying- configurar-enviar-como-permisos-en-un-buzón-en-intercambio-2010 /

La cuenta de usuario de AD particular en la que estaba tratando de configurar los permisos Enviar como no tenía permisos heredables marcados en AD.