Configuración de bases de datos de Exchange
No tiene autorización para ver este contenido. Para acceder a todos los videos y recursos del sitio inicie sesión como miembro VIP o complete el registro haciendo clic aquí.
Configuración de acceso de clientes y certificado
No tiene autorización para ver este contenido. Para acceder a todos los videos y recursos del sitio inicie sesión como miembro VIP o complete el registro haciendo clic aquí.
Sobre los tipos de certificados…
Para asegurar el acceso a los servicios de Exchange podemos utilizar 3 tipos de certificados:
- Certificado Auto firmado. Al instalar Exchange 2013 se genera automáticamente un certificado auto firmado (self signed) habilitado para IIS, POP, IMAP y SMTP. Este certificado incluye los nombres de host y FQDN del servidor, ej: servidor1, servidor1.dominio.local
- Certificado interno. Este certificado es emitido por una CA interna. Esta CA podría estar integrada con Active Directory (tipo de CA Enterprise) o puede ser “Stand alone”, es decir no integrada.
- Certificado público o externo. Este tipo de certificado es el que en general se recomienda para cualquier servicio expuesto hacia internet. Para obtener un certificado público es necesario una entidad certificadora externa como Godaddy, Digicert o Comodo entre otras.
Veamos las características más relevantes de cada caso.
Certificado auto firmado
El certificado auto firmado habilita a que de forma predeterminada los servicios de Exchange sean accedidos de forma segura.
Este certificado cumple con la función básica pero presenta los siguientes inconvenientes:
- Los clientes no confían en el certificado. Este certificado fue emitido por el propio servidor y la evaluación sobre que es o no confiable se basa en si la entidad que emitió el certificado se encuentra dentro de las raíces emisoras de confianza del cliente.
- Dependiendo del tipo de acceso, los clientes en algunos casos podrían aceptar las advertencias y acceder al servicio mientras que en otros esto no sería posible.
En organizaciones sin requerimientos específicos de acceso desde Internet, el administrador podría optar por distribuir la llave pública del certificado y si bien no sería la mejor opción podría ser suficiente para el acceso interno.
Certificado interno
El certificado interno en primera instancia implica contar con una CA (Certificate Authority) o instalarla para este propósito.
Utilizar un certificado emitido por una CA interna puede tener varias ventajas, al menos frente al certificado auto firmado:
- Es posible emitir un certificado con nombres específicos, por ejemplo “mail.dominio.com”, “mail.dominio.local”, etc.
- Dependiendo de si la CA se encuentra integrada con Active Directory, los clientes unidos al dominio confiarían de forma predeterminada.
Acá el tema es que pasa con el acceso externo? Específicamente que sucedería al acceder al correo desde un dispositivo móvil o un equipo no unido al dominio?
En este caso los usuarios van a encontrarse con errores de certificados.
Para corregir la situación sería necesario acceder al equipo e instalar la raíz emisora de confianza (CA interna). Como alternativa se le puede indicar al usuario (si tiene los permisos necesarios) y esto podría funcionar en una infraestructura chica pero no resultaría escalable. En el caso puntual de dispositivos móviles dependiendo de la versión podría presentar la opción de que el usuario acepte confiar directamente en la CA.
Existe la posibilidad de crear múltiples sitios web y de este modo poder utilizar más de un certificado; en este caso un certificado interno incluyendo el nombre del servidor y otro utilizando el nombre público por ejemplo webmail.dominio.com (emitido por una CA externa).
En internet se pueden encontrar tutoriales explicando el proceso pero en general esta no es una práctica recomendada ya que implica mayor complejidad, configuración, mantenimiento e igualmente requiere un certificado público.
Certificado Público o externo
Dentro de los certificados públicos, existen varios tipos, el que usualmente se requiere para Exchange es el de tipo SAN (Subject Alternative Names) o UCC (Unified Communications Certificate), dependiendo el proveedor el nombre exacto. Este tipo de certificado nos permite utilizar múltiples nombres. Adicionalmente están los certificados de tipo wildcard (*), estos habilitan a utilizar cualquier nombre dentro de un dominio específico (subdominios).
El certificado público a diferencia del auto firmado y del interno tiene un costo directo al momento de la compra y en función al tipo, cantidad de nombres y tiempo el precio.
El certificado público es ideal ya que entre otras cosas puede ser utilizado interna como externamente. Este certificado sería confiable en clientes internos, externos, dispositivos móviles, etc de forma predeterminada.
A tener en consideración que actualmente no es posible incluir nombres internos en certificados públicos y si bien no se consideraba una buena práctica era algo relativamente común de encontrar. Dada esta situación y considerando que en la configuración de Exchange debemos definir URLs internas y externas, es necesario un mecanismo que habilite a configurar los servicios con nombres válidos y que estos puedan ser utilizados desde la red interna e Internet.
Para cumplir con este requerimiento podemos utilizar Split DNS o PinPoint DNS. Este tipo de configuración nos permite utilizar los mismos nombres interna y externamente resolviendo a una IP privada o pública dependiendo desde donde consulta el cliente.
Conclusión de tipo de certificado
El certificado auto firmado nos habilita a contar con una instalación segura de forma predeterminada, sin embargo el hecho de que no sea confiable y solo incluya los nombres internos del servidor no lo hacen un candidato ideal para producción.
El certificado interno puede ser una buena opción si no accedemos desde internet o no se considera problemático que los usuarios reciban advertencias sobre seguridad. Claramente esto no es recomendado.
El certificado público cumple con las prácticas recomendadas por Microsoft:
- Es confiable
- No incluiría el nombre de los servidores
- Mediante split DNS podemos minimizar la cantidad de nombres
Dentro de los certificados públicos se recomienda de tipo SAN/UCC. Los certificados de tipo wildcard implican un riesgo muchas veces innecesario ya que habilitan a asegurar cualquier subdominio, de cualquier modo es muy utilizado y si ya existe uno en la organización, de cumplir con los requerimientos de diseño puede ser una opción viable.
Prácticas recomendadas
A continuación las prácticas recomendadas más relevantes a nivel de certificados:
- Adquirir un certificado de una entidad certificadora (CA) externa. De las recomendadas para Exchange encontramos Godaddy, Digicert y Comodo entre otras.
- Utilizar certificados con atributo de SAN. Esto nos permite utilizar un nombre principal en el certificado por ejemplo mail.aprendiendoexchange.com y agregar otros en el campo de SAN como por ejemplo autodiscover.aprendiendoexchange.com, etc.
- Si dentro del asistente de solicitud de certificado se sugieren nombres internos para el certificado es porque probablemente algún servicio no este correctamente configurado, en este caso editar los nombres a incluir y verificar qué servicio está utilizando un nombre incorrecto (en general el FQDN del servidor).
- Minimizar la cantidad de nombres a utilizar en el certificado. Para esto podemos utilizar un Split DNS. La idea acá sería utilizar un espacio de nombre unificado.
- Utilizar el mismo certificado en todos los servidores con el rol de CAS. Se realiza el procedimiento de solicitud, procesamiento, etc en uno de los servidores y posteriormente se exporta junto a su llave privada y se importa en el resto de los servidores
Errores típicos de configuración
A continuación algunos errores típicos a nivel de configuración:
- Dejar los servicios con las URLs internas predeterminadas. Esto implica que utilizan el nombre de servidor en lugar de un nombre común como por ejemplo webmail.contoso.com.
- Incluir el nombre netbios y FQDN de cada servidor Exchange en el certificado. Esto no debería ser necesario, tendríamos que incluir únicamente los nombres asociados a los distintos servicios en uso.
- Configuración de Autodiscover. Dependiendo del mecanismo seleccionado de autodiscover si es necesario afectar los certificados en uso cuando agregamos un nuevo dominio o no. Por ejemplo si utilizamos registros SRV no es necesario modificar el certificado, pero si deseamos que usuarios de un nuevo dominio utilicen “autodiscover.nuevodominio.com”, si lo es.
Recurso complementario recomendado:
Autodiscover externo y registros SRV …
Sin dudas la forma más sencilla de configurar el autodiscover externo es incluyendo el registro Autodiscover en el certificado y creando un registro A «autodiscover» en la zona externa DNS apuntando a la IP en la que se encuentre publicado el servidor de acceso de clientes.
Si bien este sería un escenario ideal, en producción no siempre es posible. Pensemos por ejemplo el caso donde se cuente con un certificado con un único nombre «mail.empresa.com». En este caso si un cliente accede al servidor con el nombre «autodiscover.empresa.com» esto va a dar error de certificado porque el nombre no coincide. El administrador podría evaluar cambiar el certificado por uno que incluya múltiples nombres (SAN) e incluir el registro «autodiscover.empresa.com» pero si esto no es posible habría que ir por alguna alternativa. Una de las más populares es mediante registros SRV en DNS. En este caso se podría generar un registro SRV en la zona DNS externa apuntando a «mail.empresa.com».
Ahora supongamos el escenario de una empresa que tiene 10 dominios de correo, en este caso en principio habría que incluir en el certificado 10 veces el registro autodiscover, 1 por cada dominio externo que tengamos.
Al paso de un tiempo se agrega un nuevo dominio de correo, qué hacemos?
Una opción es solicitar un nuevo certificado e incluir nuevamente todos los registros para Autodiscover, instalar en todos los servidores, etc.
La realidad es que dependiendo del tipo de organización esto puede ser viable pero una alternativa sería la creación de un registro SRV en la zona externa del nuevo dominio de correo, este registro apuntaría a uno de los nombres existentes en el certificado, por ejemplo «autodiscover.dominioprincipal.com».
Si por ejemplo quisiera solicitarle al proveedor de la zona externa la creación de un registro SRV para la zona de un nuevo dominio de correo podría enviarle la siguiente tabla:
Nota: En target reemplazar «dominio.com» por el dominio que corresponda
Si es tan sencillo usar registros SRV por qué alguien optaría por pagar por nombres adicionales en el certificado creando un registro «autodiscover» por cada dominio?
El tema está en que usando registros SRV el cliente recibe ocasionalmente alertas (por ejemplo cuando se crea el perfil) indicando que esta siendo redireccionado, por fuera de esto el usuario puede aceptar la redirección y marcar la opción para que no se le vuelva a consultar. En adición a esto, pueden existir casos específicos de dispositivos móviles que no se comporten correctamente con registros SRV.
En definitiva, usar registros SRV nos habilita a simplificar la cantidad de nombres que incluimos en el certificado, dependiendo de los requerimientos evaluar si es la opción más conveniente.
Configuración de transporte de correo
No tiene autorización para ver este contenido. Para acceder a todos los videos y recursos del sitio inicie sesión como miembro VIP o complete el registro haciendo clic aquí.
Sobre la creación de un nuevo dominio de correo en Exchange…
Para que Exchange acepte correo de un nuevo dominio, este debe ser definido en la organización. Si bien tenemos varios tipos de dominios aceptados, el más común es el de tipo “Autoritativo”, esto significa que nuestra organización es la encargada de la entrega a este dominio de correo teniendo la “última palabra” por decirlo de algún modo, es decir que si un destinatario no existe en la organización es porque efectivamente no existe.
Otro tipo de dominios aceptados son los de internal relay y de external relay, pero estos los utilizamos para casos puntuales como por ejemplo cuando compartimos el mismo espacio de nombre SMTP en un escenario de coexistencia que abarque múltiples organizaciones de correo entre otros.
En el caso puntual del curso, iniciamos con el dominio de correo aprendiendoexchange.local. Este es el predeterminado y coincide con el nombre del dominio raiz del bosque de Active Directory.
En esta lección uno de los requerimientos es crear un nuevo dominio de correo «aprendiendoexchange.com» ya que si instalamos Exchange seguramente tengamos la intención de intercambiar correo con otras organizaciones por lo que deberíamos utilizar un dominio público.
Para esto creamos un nuevo dominio aceptado autoritativo.
A grandes rasgos para configurar un nuevo dominio de correo debemos realizar las siguientes actividades:
- Crear un nuevo dominio aceptado en Exchange
- Configurar el o los registros MX en las zonas DNS externas
- Asignar direcciones de correo que utilicen el nuevo dominio
El caso del punto 3 lo vamos a ver más adelante. En esta instancia lo importante es entender para qué debemos crear el dominio aceptado.
Recurso complementario recomendado:
Sobre la prueba EICAR…
Como vemos en esta lección la prueba EICAR nos permite validar si un antivirus esta funcionando correctamente, para esto debemos copiar la siguiente cadena de texto:
Esta cadena la podemos copiar desde el siguiente sitio:http://www.eicar.org/
Una vez copiado el texto lo podemos pegar en el bloc de notas y guardar el archivo como EICAR.txt o con el nombre que queramos.
A tener en cuenta que para poder realizar la prueba, el equipo donde guardemos el archivo debe tener el antivirus deshabilitado, en caso contrario lo va a detectar como virus y seguramente lo elimine.
Acceso de clientes y rol de Edge con Exchange 2016
No tiene autorización para ver este contenido. Para acceder a todos los videos y recursos del sitio inicie sesión como miembro VIP o complete el registro haciendo clic aquí.
ReFS y Exchange …
Como se menciona en el curso, el sistema de archivos recomendado para la ubicación de datos en Exchange 2016 es ReFS (incluso para 2013).
La particularidad con este sistema de archivos es que debemos estar seguros de usarlo con la característica de chequeo de integridad deshabilitada.
La recomendación para mayor control es usar Powershell.
Tenemos varias opciones para lograr este requerimiento, en mi opinión la forma más sencilla es la siguiente:
- Desde el administrador de discos crear un nuevo volumen y seleccionar ReFS como sistema de archivos
- Especificar la letra de unidad y no formatear el volumen
- Abrir Powershell como administrador y ejecutar:
Format-Volume -DriveLetter R -FileSystem ReFS -AllocationUnitSize 65536 -SetIntegrityStreams $false
Nota: Reemplazar «R» con la letra de unidad que corresponda
Por último, tener en cuenta que este sistema de archivos es solo para bases de datos y logs.
En el caso de sistema operativo y binarios de Exchange debemos seguir usando NTFS.
Es necesario usar ReFS?
No es necesario pero es el sistema de archivos recomendado para bases y logs.
Esto se encuentra especificado en la arquitectura preferida para Exchange 2016 pero la realidad es que en la mayoría de las instalaciones el hecho de usar NTFS o ReFS no tendría un impacto significativo.
Lo más importante es que independientemente del sistema de archivos que utilicemos hagamos el formato de la unidad en 64k.
