Page 1


Ediciones ENI

Exchange Server 2010 Diseño de la infraestructura, implementación y administración Colección Recursos Informáticos

Extracto del Libro


Capítulo 6

A. Introducción La administración de los servidores de la organización se realiza mediante la consola MMC, pero también en PowerShell. En el capítulo dedicado a PowerShell, descubrirá que algunas funciones disponibles en línea de comandos, no están disponibles en modo gráfico. El nodo configuración del servidor permite gestionar los roles de los servidores siguientes: - Los servidores de buzones de mensajes, que almacenan las bases de datos. - Los servidores de accesos de cliente, que proporcionan un acceso para los clientes ActiveSync, los clientes OWA e incluso el cliente Outlook Anywhere. - Los servidores de transporte Hub, que gestionan el conjunto de flujos de mensajería electrónica en el seno de la organización. - Los servidores de Mensajería Unificada, que gestionan el conjunto de mensajes de voz y los faxes de la organización. En esta sección va a estudiar cómo administrar y gestionar sus servidores de manera cotidiana. Principalmente aprenderá cómo crear filtros de búsqueda para sus servidores y cómo familiarizarse rápidamente con estas nuevas interfaces de administración.

B. Administración de los servidores de buzones de mensajes Primer servidor de la lista, el servidor de buzones de mensajes, sustituye al servidor principal de las versiones anteriores a 2007 (también llamado servidor back). El servidor de buzones de mensajes funciona de la siguiente manera: - Accede a la información de los usuarios a través de Active Directory. - Recupera toda la información relativa a los destinatarios y sobre todo, la información de la configuración Exchange 2010 de su organización. El servidor de transporte Hub ubica los mensajes en el buzón de mensajes apropiado. El servidor de accesos de cliente envía las consultas de los clientes al servidor de buzones de mensajes y después, reenvía los datos del servidor de buzones de mensajes a los clientes. Los clientes Outlook que se encuentran en la red interna, pueden acceder directamente al servidor de buzones de mensajes para enviar y recuperar los mensajes. Los clientes Outlook situados fuera de la organización, pueden acceder a un servidor de buzones de mensajes mediante una llamada de procedimiento remoto RPC en HTTP (Outlook Anywhere).

324

Exchange Server 2010


Administración de los servidores

ã Editions ENI - All rights reserved

El servidor de buzones de mensajes (servidor de BALS), almacena la información de las bases de datos de los buzones de mensajes de la organización. Como en las versiones anteriores, va a encontrar las siguientes nociones: grupos de almacenamiento, bases de información y carpetas públicas; pero sobre todo va a descubrir los modos de recuperación de las bases de datos y cómo establecer rápidamente una política de recuperación eficaz y fiable en caso de accidente. Los servidores de buzones de mensajes no transfieren los mensajes entre ellos, sino que pasan obligatoriamente por un servidor de transporte Hub que se encarga de esta función. El servidor de buzones de mensajes se gestiona mediante la Consola de administración de Exchange.

Diseño de la infraestructura, implementación y administración

325


Capítulo 6

Haciendo un clic derecho en el servidor de buzones de mensajes, en la sección Resultados, puede acceder a las propiedades del servidor. Allí encontrará, entre otras, información relativa al servidor, su versión, la edición, los roles presentes, el ID de producto y la fecha de instalación. En la pestaña Configuración del sistema, encontrará los servidores controladores de dominio y los catálogos globales a los que hace referencia para su funcionamiento. La tercera pestaña le permite especificar el plan de gestión de los registros de mensajería electrónica.

326

Exchange Server 2010


Administración de los servidores

ã Editions ENI - All rights reserved

Siempre mediante la consola MMC, en la sección Resultados, encontrará un botón de filtro en la parte superior izquierda de la consola, que le permite realizar consultas precisas en los servidores presentes en la organización.

Diseño de la infraestructura, implementación y administración

327


Capítulo 6

1. Las bases de datos Las bases de información pierden su nombre a partir Exchange 2007 y pasan a llamarse, a partir de ese momento, bases de datos. Por defecto, estas bases se almacenan en el servidor Exchange en la siguiente ruta: Instalación Exchange\Mailbox\NombreBase\NombreBase.edb.

Las bases de datos ya no son miembros de grupos de almacenamiento como sucedía antes de Exchange 2010. Las bases de datos se categorizan en dos tipos: las bases de buzones de mensajes y las bases de carpetas públicas. Las dos se almacenan en los servidores de buzones de mensajes.

328

Exchange Server 2010


Administración de los servidores

ã Editions ENI - All rights reserved

Entre las novedades relativas a los servidores de buzones de mensajes, recuerde las siguientes: - El archivo de base de datos de transmisión (.stm) se elimina a partir de Exchange 2007. Ahora sólo tiene un único archivo que es *.edb. - Se utilizan nombres para los archivos de log más largos. De esta manera, cada grupo de almacenamiento puede generar dos millones de archivos de log, antes de que se vuelva a iniciar la regeneración de los archivos de log que no sean necesarios. - El tamaño de archivo del log de transacciones (Res1.log y Res2.log) se reduce de 5 MB a 1 MB (a partir de Exchange 2007). - Por último, recuerde que cada base de datos reside en una ubicación de almacenamiento de tipo NAS o SAN. De hecho, este tipo de configuración es la que se recomienda. Como ha podido comprobar, para las versiones anteriores de Exchange, Microsoft recomienda la segmentación de los grupos de almacenamiento con las bases de datos, pero también con los archivos binarios del programa. La arquitectura siguiente le permite aprovechar al máximo el almacenamiento de los datos. - Las bases de datos ya no se gestionan desde el servidor de buzones de mensajes, sino directamente desde la organización. Preferentemente, sitúe los archivos binarios en una partición separada de la que contenga los diferentes grupos de almacenamiento y bases de datos asociadas. Si puede, mejor opte por una solución de Raid 1 para el sistema operativo. Si es posible, sitúe los archivos de transacciones de los grupos de almacenamiento en una partición separada, que disponga de un espacio en disco en consecuencia. En efecto, la generación de los logs producidos por el servidor Exchange es tan importante, que debe prever suficientes recursos en sus discos. Microsoft aconseja situar estos grupos de almacenamiento en una configuración Raid 0. Sitúe los archivos de las bases de datos en una partición separada de las dos anteriores. Prevea también otra ubicación para el almacenamiento de las bases de datos en replicación continua. Siempre puede situar estas copias en el Raid 0, que contiene los logs de transacciones de los grupos de almacenamiento. Opte, en la medida de lo posible, por una configuración en Raid 5 para optimizar los accesos a disco, así como el conjunto de lecturas/escrituras en sus bases de datos.

Diseño de la infraestructura, implementación y administración

329


Ediciones ENI

Windows PowerShell (versiones 1 y 2)

Gu铆a de referencia para la administraci贸n del sistema Colecci贸n Expert IT

Extracto del Libro


293

Capítulo 5

La seguridad

1. La seguridad: ¿Para quién? ¿Por qué? La llegada de las redes locales y de Internet ha cambiado muchas cosas en la forma de proteger su PC. No basta con atar su disco duro al radiador y cerrar la puerta de la oficina por la noche para que no le roben o pirateen los datos. Ahora, proteger su puesto de trabajo se ha convertido en algo esencial para evitar intrusos o malversaciones. Pero ahora, ¿contra quién protegerse? Pues bien, contra todo lo que se mueve… e incluso contra lo que no se mueve. En efecto, ya sea contra programas malévolos, usuarios mal intencionados o incluso usuarios sin experiencia, todos pueden ser considerados como una amenaza. Es por ello que necesita bloquear su sistema estableciendo normas de seguridad, aplicando y asegurando que los demás lo hacen.

2. Los riesgos ligados al scripting Observará rápidamente en qué se basa la fuerza del scripting, aunque también podrá ver su fragilidad. La facilidad con la que se pueden hacer las cosas, haciendo sencillamente un clic en un script, o ejecutándolo desde una ventana de comando, puede crearle una situación embarazosa si no tiene cuidado.


Windows PowerShell (v. 1 y 2)

294

Guía de referencia para la administración del sistema Supongamos un script de logon que desde el inicio de la sesión la bloquea inmediatamente. Esto puede ser divertido entre amigos, pero en una empresa, dudamos que esté muy bien visto. Aún más grave, un script procedente de una persona con malas intenciones o muy poco experimentada en PowerShell (en este caso, le recomendamos comprarle un ejemplar de este libro…) puede perfectamente bloquearle las cuentas de usuario en Active Directory, formatearle un disco, hacer que tenga que reiniciar sin cesar. En fin, lo ha entendido, un script puede hacerlo todo. Porque, aunque actualmente se hacen llegar alertas al usuario para prevenir de la ejecución de un script, no son capaces de determinar de antemano si un script es perjudicial para el buen funcionamiento del sistema. Los riesgos relacionados con el scripting se reducen a una cuestión de compromiso: o bien decide impedir cualquier ejecución de scripts, y por lo tanto asume que deberá pasarse la vida haciendo y rehaciendo tareas básicas que suelen ser ingratas, o bien decide abrir su sistema al scripting, tomando las precauciones adecuadas. Pero no se desmoralice ya que incluso si la ejecución de los scripts le expone a algunos problemas de seguridad, PowerShell está dotado de nuevos conceptos que facilitan considerablemente este aspecto del scripting.

3. Optimizar la seguridad PowerShell

Como podrá entender, la seguridad es algo muy importante, sobre todo en el ámbito del scripting. Es por ello que los creadores de PowerShell incluyeron dos normas de seguridades por defecto. Los archivos ps1 asociados al bloc de notas La extensión «.ps1» de los scripts PowerShell, está por defecto asociada al editor de texto bloc de notas (o Notepad). Este procedimiento permite evitar lanzar scripts potencialmente peligrosos por una mala manipulación. El bloc de notas es ciertamente un editor un poco clásico, pero tiene la doble ventaja de ser inofensivo y no bloquear la ejecución de un script cuando éste está abierto con el editor.

n Observación Este tipo de seguridad no está establecido con los scripts VBS cuya apertura está directamente relacionada al Windows Script Host. ¡Aquéllos que nunca hayan hecho doble clic en un script VBS al querer editarlo que tiren la primera piedra!

© Editions ENI - Reproducción prohibida

3.1 La seguridad PowerShell por defecto


La seguridad Capítulo 5 Una política de ejecución limitada La segunda barrera de seguridad es la aplicación de políticas de ejecución «restricted» por defecto (véase las políticas de ejecución). Esta estrategia es la más restrictiva. Es decir que bloquea sistemáticamente la ejecución de cualquier script. Solamente se ejecutaran los comandos escritos en el shell. Para remediar este bloqueo del script, PowerShell requiere que el usuario cambie el modo de ejecución con el comando Set-ExecutionPolicy <modo de ejecución>.

n Observación Tal vez comprende ahora porqué el despliegue de PowerShell en sus máquinas no constituye un aumento de los riesgos, en la medida en que se respeten determinadas normas.

3.2 Las políticas de ejecución PowerShell integra un concepto de seguridad que se ha denomina políticas de ejecución (execution policies) para evitar que un script no autorizado pueda ejecutarse sin el conocimiento del usuario. Existen cuatro configuraciones posibles: Restricted, RemoteSigned, AllSigned y unrestricted. Cada una de ellas corresponde a un nivel de autorización de ejecución de un script en particular y que podríamos tener la necesidad de cambiar en función de la estrategia que desea aplicar.

3.2.1 Las diferentes políticas de ejecución Restricted: ésta es la política más restrictiva, y es también la política por defecto. No permite la ejecución de script, sólo permite las instrucciones de línea de comandos, es decir únicamente en el shell. Esta política puede considerarse como la más radical, dado que protege la ejecución involuntaria de archivos «.ps1». Durante un intento de ejecución de script con esta política, un mensaje de este tipo se muestra en la consola: No se puede cargar el archivo C:\script.ps1, porque en el sistema está deshabilitada la ejecución de scripts.

Como esta política se define por defecto durante la instalación de PowerShell, habrá que cambiarla para la ejecución de su primer script.

295


Windows PowerShell (v. 1 y 2) Guía de referencia para la administración del sistema AllSigned: es la política que permite la ejecución de script más «segura». Autoriza únicamente la ejecución de scripts firmados. Un script firmado es un script que contiene una firma digital como la que se muestra en la figura siguiente.

Ejemplo de script firmado

Con la política AllSigned, la ejecución de scripts firmados necesita que se esté en posesión de los certificados correspondientes (véase el apartado acerca de la firma de los scripts). RemoteSigned: esta política es similar a la AllSigned con la diferencia de que sólo los scripts con un origen distinto al local requieren de una firma. Por consiguiente, esto significa que todos los scripts creados localmente podrán ejecutarse sin ser firmados. Si intenta ejecutar un script procedente de Internet sin que éste esté firmado, se mostrará en consola el mensaje siguiente. No se puede cargar el archivo C:\script.ps1. El archivo C:\script.ps1 no está firmado digitalmente. El script no se ejecutará en el sistema.

© Editions ENI - Reproducción prohibida

296


La seguridad Capítulo 5

n Observación Se preguntará seguramente cómo hace PowerShell para saber que nuestro script procede de Internet. Respuesta: gracias a las «Alternate Data Strings» que están implementadas en forma de flujos ocultos desde aplicaciones de comunicación como Microsoft Outlook, Internet Explorer, Outlook Express y Windows Messenger (véase el apartado relativo a los Alternate Data Streams).

Unrestricted: es la política menos vinculante, y por lo tanto la menos segura. Con ella, todo script, poco importa su origen, puede ejecutarse sin solicitud de firma. Es pues la estrategia donde el riesgo de ejecutar scripts potencialmente peligrosos es más elevado. Esta estrategia muestra un aviso cuando se intenta ejecutar un script descargado de Internet. PS > .\script.ps1 Advertencia de seguridad Ejecute sólo los scripts de confianza. Los archivos procedentes de Internet pueden ser útiles, pero algunos archivos podrían dañar su equipo. ¿Desea ejecutar C:\MiScript.ps1? [N] No ejecutar [Z] Ejecutar una vez [U] Suspender [?] Ayuda (el valor predeterminado es "N":

PowerShell v2 aporta dos políticas de ejecución suplementarias: Bypass: no bloquea nada y no se muestra ningún mensaje de advertencia. Undefined: no existe una política de ejecución definida en el ámbito actual. Si todas las políticas de ejecución de todos los ámbitos son de tipo Undefined entonces la política efectiva aplicada será la política Restricted.

3.2.2 Los ámbitos de las políticas de ejecución Esta parte sólo se aplica a PowerShell v2. PowerShell v2 aporta un nivel de granularidad que PowerShell v1 no tenia en la gestión de las políticas de ejecución. PowerShell v1 sólo controlaba la política de ejecución del ordenador, dicho de otra forma, PowerShell v1 únicamente estaba dotado del ámbito LocalMachine. Además del ámbito LocalMachine, PowerShell v2 aporta los dos nuevos ámbitos siguientes: Process, y CurrentUser. Si se desea, es posible asignar una política de ejecución a cada ámbito.

297


Windows PowerShell (v. 1 y 2)

298

Guía de referencia para la administración del sistema La prioridad en la aplicación de las políticas es la siguiente: - Ámbito Process: la política de ejecución únicamente afecta a la sesión en curso (procesos Windows PowerShell). El valor asociado al ámbito Process se almacenada únicamente en memoria; por lo que no se conserva al cerrar la sesión PowerShell. - Ámbito CurrentUser: la política de ejecución aplicada al ámbito CurrentUser sólo afecta al usuario actual. El tipo de política se almacena de forma permanente en la parte del registro HKEY_CURRENT_USER. - Ámbito LocalMachine: la política de ejecución aplicada al ámbito LocalMachine afecta a todos los usuarios de la máquina. El tipo de política se almacena de forma permanente en la parte del registro HKEY_LOCAL_MACHINE. La política con una prioridad 1 es más prioritaria que la de una prioridad 3. Por consiguiente, si el ámbito LocalMachine es más restrictivo que el ámbito Process, la política que se aplicará será al menos la política del ámbito Process. A menos que ésta sea de tipo Undefined en cuyo caso PowerShell aplicará la política del ámbito CurrentUser, y después intentará aplicar la política LocalMachine. Remarcar que el ámbito LocalMachine es el predeterminado cuando se aplica una política de ejecución sin precisar un ámbito concreto.

3.2.3 Identificar la política de ejecución actual La política de ejecución en curso se obtiene con el commandlet Get-ExecutionPolicy. Ejemplo:

Con PowerShell v1, no se plantea la cuestión de saber cuál es el ámbito asociado al modo devuelto por este comando. En efecto, PowerShell v1 únicamente gestiona el ámbito LocalMachine. Con PowerShell v2, nos beneficiamos del switch -List. Gracias a él vamos saber qué políticas se aplican a nuestros ámbitos. Por ejemplo: PS > Get-ExecutionPolicy -List Scope ExecutionPolicy ----- --------------MachinePolicy Undefined UserPolicy Undefined Process Undefined

© Editions ENI - Reproducción prohibida

PS > Get-ExecutionPolicy Restricted

1_9782746065963  

Extracto del Libro Diseño de la infraestructura, implementación y administración Colección Recursos Informáticos Ediciones ENI

Read more
Read more
Similar to
Popular now
Just for you