none
Permisos de Send as RRS feed

  • Pregunta

  • Buenos días: Mi entorno es DC 2003 y Exchange 2003 Sp2.

    Detectamos que por default el grupo Domain Admin tiene permisos de Send As en todos los buzones y listas de distibucion.

    Estaria necesitando quitar estos permisos, podrian indicarme cual es la mejor practica para realizar esta tarea sin tener un impacto en el servicio.

    Saludos y gracias


    Adrian Rodriguez -
    lunes, 3 de octubre de 2011 14:06

Respuestas

  • Why can domain administrators spoof mailbox-enabled user accounts in their domain?

    Active Directory includes a base set of permissions that can be applied against objects within the directory. In particular, Active Directory includes the Send As extended permission. By default, the Administrators group, the Domain Admins group, the Enterprise Admins group, and the Account Operators group have Send As permissions for all users. The Administrators group permissions and the Enterprise Admins group permissions are inherited from the domain level. The Account Operators group and the Domain Admins group receive explicit permissions that are based on the definition of the user object that is in the Active Directory schema.

    You may consider implementing a Deny "Send As" access control entry (ACE) against administrators for user objects in the domain. If you decide to implement a Deny "Send As" ACE against administrators for user objects in the domain, consider the following:

    • An explicit Allow ACE will override an inherited Deny (in other words, explicit ACEs are applied before inherited ACEs).
    • Members of the Domain Admins group are able to remove the Deny ACE and/or add an explicit Allow ACE.
    • The addition of a Deny ACE may have additional consequences in your environment. For more information, see Where to Apply Permissions.

    If implementing a Deny "Send As" ACE against administrators for user objects in the domain puts your messaging environment at risk, you should implement one or more of the following:

    • Limit the number of domain administrators in the domain by delegating specific tasks. For more information, see “Best Practices for Delegating Active Directory Administration” (http://go.microsoft.com/fwlink/?LinkId=31309).
    • Use auditing to monitor the account logon events for those accounts that are members of the Domain Admins group.

    Why do members of the Enterprise Admins group and root Domain Admins group have full control in the Exchange organization?

    In Exchange 2000 Server and later versions, data about the Exchange organization is not stored in a separate directory. Exchange stores organizational data in Active Directory in the Configuration naming context. The forest administrators (members of either Enterprise Admins group or root Domain Admins group) control all aspects of the directory, and, in essence, own the data stored in the directory. Forest administrators must control the directory because a single configuration change could adversely affect the entire forest. The Configuration naming context, and, by inheritance, the Exchange organization stored within the Configuration naming context, have the following permissions:

    • Enterprise Admins – Full Control
    • Root Domain Admins – Read, Write, Create All Child Objects, Special Permissions 

    In addition to the inherited permissions, Exchange Setup adds a Deny ACE for “Send As” and “Receive As” against the Enterprise Admins group and root Domain Admins group; this prevents those administrators from accessing and spoofing mailboxes within the forest. For more information, see Permissions Granted During Exchange Setup.

    You cannot remove inheritance from the Exchange organization node within the configuration naming context. If the messaging administrators do not trust the forest administrators, the messaging team should consider isolating Exchange within its own forest. For more information about deployment options, see the Exchange Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=47569).

    If you cannot put the Exchange organization in a separate forest, it is recommended that you perform one or more of the following tasks:

    • Limit the number of enterprise administrators and domain administrators in the root domain by delegating specific tasks. For more information, see “Best Practices for Delegating Active Directory Administration” (http://go.microsoft.com/fwlink/?LinkId=31309).
    • Use auditing to monitor the account logon events for those accounts that are members of any privileged groups, including the Enterprise Admins group and the root Domain Admins group.
    • Use auditing to monitor changes that occur within the CN=<Exchange Org>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<root domain> portion of the directory.

    Dario Woitasen | MCITP: Enterprise Messaging Administrator 2007/2010 | MCTS: Microsoft Lync Server 2010, Configuring
    jueves, 6 de octubre de 2011 9:15

Todas las respuestas

  • Why can domain administrators spoof mailbox-enabled user accounts in their domain?

    Active Directory includes a base set of permissions that can be applied against objects within the directory. In particular, Active Directory includes the Send As extended permission. By default, the Administrators group, the Domain Admins group, the Enterprise Admins group, and the Account Operators group have Send As permissions for all users. The Administrators group permissions and the Enterprise Admins group permissions are inherited from the domain level. The Account Operators group and the Domain Admins group receive explicit permissions that are based on the definition of the user object that is in the Active Directory schema.

    You may consider implementing a Deny "Send As" access control entry (ACE) against administrators for user objects in the domain. If you decide to implement a Deny "Send As" ACE against administrators for user objects in the domain, consider the following:

    • An explicit Allow ACE will override an inherited Deny (in other words, explicit ACEs are applied before inherited ACEs).
    • Members of the Domain Admins group are able to remove the Deny ACE and/or add an explicit Allow ACE.
    • The addition of a Deny ACE may have additional consequences in your environment. For more information, see Where to Apply Permissions.

    If implementing a Deny "Send As" ACE against administrators for user objects in the domain puts your messaging environment at risk, you should implement one or more of the following:

    • Limit the number of domain administrators in the domain by delegating specific tasks. For more information, see “Best Practices for Delegating Active Directory Administration” (http://go.microsoft.com/fwlink/?LinkId=31309).
    • Use auditing to monitor the account logon events for those accounts that are members of the Domain Admins group.

    Why do members of the Enterprise Admins group and root Domain Admins group have full control in the Exchange organization?

    In Exchange 2000 Server and later versions, data about the Exchange organization is not stored in a separate directory. Exchange stores organizational data in Active Directory in the Configuration naming context. The forest administrators (members of either Enterprise Admins group or root Domain Admins group) control all aspects of the directory, and, in essence, own the data stored in the directory. Forest administrators must control the directory because a single configuration change could adversely affect the entire forest. The Configuration naming context, and, by inheritance, the Exchange organization stored within the Configuration naming context, have the following permissions:

    • Enterprise Admins – Full Control
    • Root Domain Admins – Read, Write, Create All Child Objects, Special Permissions 

    In addition to the inherited permissions, Exchange Setup adds a Deny ACE for “Send As” and “Receive As” against the Enterprise Admins group and root Domain Admins group; this prevents those administrators from accessing and spoofing mailboxes within the forest. For more information, see Permissions Granted During Exchange Setup.

    You cannot remove inheritance from the Exchange organization node within the configuration naming context. If the messaging administrators do not trust the forest administrators, the messaging team should consider isolating Exchange within its own forest. For more information about deployment options, see the Exchange Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=47569).

    If you cannot put the Exchange organization in a separate forest, it is recommended that you perform one or more of the following tasks:

    • Limit the number of enterprise administrators and domain administrators in the root domain by delegating specific tasks. For more information, see “Best Practices for Delegating Active Directory Administration” (http://go.microsoft.com/fwlink/?LinkId=31309).
    • Use auditing to monitor the account logon events for those accounts that are members of any privileged groups, including the Enterprise Admins group and the root Domain Admins group.
    • Use auditing to monitor changes that occur within the CN=<Exchange Org>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<root domain> portion of the directory.

    Dario Woitasen | MCITP: Enterprise Messaging Administrator 2007/2010 | MCTS: Microsoft Lync Server 2010, Configuring
    jueves, 6 de octubre de 2011 9:15
  • Dario, muchas gracias por la respuesta.

    Por lo que veo no es recomendable, asi que veremos como solucionamos este inconveniente.

    Saludos


    Adrian Rodriguez -
    jueves, 6 de octubre de 2011 20:36