Be Geek My Friend : Windows Server

Windows Server Virtualization.

Daniel Matey — Fri, 28 Sep 2007 08:35:00 GMT

Como ya sabreis, hace unos dias aparecio la RC0 de Windows Server 2008, que por primera vez hace publica una versión beta de "Viridian" o Windows Server Virtualization.

Para poder instalar la virtualización es necesario seguir una serie de pasos y tener el sistema operativo W2008 instalado en x64 en una maquina con soporte para virtualización asistida por hardware, lo cual me ha hecho montar un lio en casa alucinante para poder montarlo.

Para mas información sobre los prerequisitos y la forma de instalar y activar la virtualización, podes leer el siguiente post del blog de David Cervigon.

http://blogs.technet.com/davidcervigon/archive/2007/09/25/como-instalar-windows-server-virtualization-en-la-rc0-de-windows-server-2008.aspx

Mas información sobre la instalación y otros aspectos relacionados:

http://www.microsoft.com/windowsserver2008/virtualization/install.mspx

Podeis descargar la RC0 de Windows Server 2008 de:

http://www.microsoft.com/downloads/details.aspx?FamilyId=0818D425-CD47-4279-BE8D-24ABA14530A3&displaylang=en

Y finalmente una screencast para que veais el producto en acción:

mms://wm.microsoft.com/ms/inetpub/keithcombs/ws2008/WSvTour.wmv

Guias paso a paso de Longhorn Beta 3

Daniel Matey — Sun, 29 Apr 2007 13:48:00 GMT

Installing, Configuring, and Troubleshooting the Microsoft Online Responder.doc	939 KB	Download"); // --> Download
Step-by-Step Guide for Configuring a Two-Node File Server Failover Cluster in Windows Server Longhorn.doc	579 KB	Download"); // --> Download
Step-by-Step Guide for Configuring a Two-Node Print Server Failover Cluster in Windows Server Longhorn.doc	581 KB	Download"); // --> Download
What's New in Failover Clusters.doc	354 KB	Download"); // --> Download
Windows Server Code Name Longhorn Beta 3 Active Directory Certificate Services Step-By-Step Guide.doc	480 KB	Download"); // --> Download
Windows Server Longhorn Beta 3 Terminal Services RemoteApp Step-By-Step Guide.doc	634 KB	Download"); // --> Download
Windows Server Longhorn Beta 3 Windows Deployment Services Step-by-Step Guide.doc	582 KB	Download"); // --> Download

http://www.microsoft.com/downloads/details.aspx?FamilyID=518d870c-fa3e-4f6a-97f5-acaf31de6dce&DisplayLang=en

Mas sobre easy print

Daniel Matey — Sat, 28 Apr 2007 13:28:00 GMT

Me esta encantando la beta 3 de longhorn y ver cómo me ayudara a mejorar mis infraestructuras, reducir problemas y mejorar el servicio a los usuarios.

En el mundo de las aplicaciones remotas ya sean sostenidas por Terminal Services o por Citrix la impresión siempre ha sido un problema.

En citrix han existido soluciones parciales como el driver universal y en Terminal Services tenemos el failback printer driver y los mapeos entre drivers, pero ninguna de estas aproximaciones ni otras que existen en el mercado resuelven completamente los problemas existentes, Citrix ha anunciado nuevas mejoras en ese aspecto y Microsoft por su parte nos sorprende con una nueva funcionalidad en Longhorn Beta 3, llamada Easy Print.

Easy Print permitira que se mapeen las impresoras en las sesiones de terminal usando un driver universal, la diferencia esta en que cuando el usuario seleccione las propiedades de impresión las vera en su propio PC y no en el entorno del Terminal, el driver redirigira todas las selecciones a la sesion de terminal donde el documento se formateara con xps y se mandara comprimido al puesto, donde se imprimirá con el driver instalado en el propio puesto.

Esto se traduce en soporte para todas las impresoras, poder usar todas las opciones de los drivers, ausencia de problemas con los drivers de 64bits y mejor rendimiento de la impresión, si añadimos todo esto a las otras muchas ventajas de Longhorn como servidor de terminales (ts gateway, aplicaciones sin entorno, asignación de aplicaciones, webpart para acceso a las aplicaciones asignadas, mejoras de rendimiento, validación integrada, etc, etc) sabremos seguro que la apuesta por Longhorn es sinónimo de éxito en este tipo de soluciones.

El equipo de desarrollo de terminal ha publicado un artículo muy interesante sobre el tema.

http://blogs.msdn.com/ts/archive/2007/04/26/introducing-terminal-services-easy-print-part-1.aspx

Longhorn Server Beta 3

Daniel Matey — Thu, 26 Apr 2007 06:37:00 GMT

Hace dias aparecio por la MSDN una versión Escrow de la Beta 3, ahora ya disponemos de la build real de la beta 3.

Windows Server "Longhorn" Web
x86 - English | x64 - English

Windows Server "Longhorn" Std/Ent/Data
x86 - English | Mirror 1 | Mirror 2
x64 - English | Mirror 1 | Mirror 2

Espero tener algo de tiempo para publicar aqui algun articulo sobre el tema.

Longhorn Beta 3!!!!!!

Daniel Matey — Wed, 11 Apr 2007 06:37:00 GMT

Se me hace la boca agua, este fin de semana sera grande.

Las 10 razones para montar el SP2 de Windows

Daniel Matey — Sun, 01 Apr 2007 16:19:00 GMT

Top 10 Reasons to Install Windows Server 2003 SP2

Security Updates/Hotfixes

Windows Server 2003 SP2 will get all of your Windows Server 2003 and Windows XP Professional x64 Editions up to date with the latest Security Bulletin updates and Hotfixes, ensuring the highest level of security, reliability, stability, manageability, supportability and compatibility.

Deploy your operating systems more effectively

Building upon our previous deployment solutions, Windows Deployment Services (WDS) offers customers a complete ‘out of the box’ provisioning solution. WDS provides organizations with manageable image store, remote booting, PXE boot support, and more; all in a greatly improved management interface. WDS also uses the new file-based Windows Imaging Format (WIM) which facilitates deployments on Windows Vista and Windows Server “Longhorn”.

Improved networking performance

Windows Server SP2 offers solutions to network traffic challenges in an era of the multi-Gigabit Ethernet. Increases to CPU resources required to handle high network traffic can potentially inhibit scaling and effectively reduce the performance gains that are possible with increased link speeds. Windows Server 2003 SP2 Scalable Networking Pack (SNP), introduces technologies that helps organizations cost-effectively scale network-based applications to meet growing demands. The Scalable Networking pack Increases network and application performance by freeing up CPU cycles and more efficiently using processor resources. More information on the Scalable Networking Pack can be found at www.microsoft.com/snp

Improved manageability for IPsec

Server and Domain Isolation are key security benefits offered on Microsoft Networks. By using Active Directory, domain memberships and group policies, Server and Domain Isolation allows companies to logically segment their networks. This means that you can restrict non-domain computers which aren’t managed at a corporate level (lab computers, guests or other unsecure systems) from communicating with non- domain members. Service Pack 2 improves Server and Domain Isolation by reducing the IPsec filter set that needs to be managed from potentially hundreds of filters to as few as 2 filters. More information on Server and Domain Isolation can be found at www.microsoft.com/sdisolation.

Utility improvements

Making common tasks easier, SP2 introduces customer-driven improvements to the Domain Controller Diagnostics tool (DCDIAG) and MS Configuration (MSCONFIG) tool. SP2 also has an updated Access Control List (ICACLS) program to allow for greater flexibility when backing up Access Control Lists.

Management tools made easier

SP2 includes the Microsoft Management Console 3.0 (MMC 3.0). MMC provides a framework that unifies and simplifies day-to-day system management tasks on Windows by providing common navigation, menus, toolbars, and workflow across diverse tools. MMC tools (called snap-ins) can be used to administer networks, computers, services, applications and other system components. MMC does not perform administrative functions, but hosts a variety of Windows and non-Microsoft snap-ins that do.

Single install experience

It patches both the R2 and non-R2 versions of Windows Server 2003. This reduces the amount of patch management for an organization.

Support for additional languages

Service Pack 2 will be released in 9 additional localized languages for Windows Server 2003 x64 Editions including: German, French, Korean, Chinese Traditional, Chinese Simplified, Spanish, Italian, Russian and, Portuguese (Brazilian).

Performance improvements

Service Pack 2 offers performance improvements for Windows Server 2003 running as a Virtual Server guest under high Advanced Processor Interrupt Controller (APIC) rates. It also improves SQL Server performance under intensive workloads. Both of these improvements lead to more efficient data processing.

Manage new wireless settings without the hassle

SP2 provides the ability to manage the WPA2 protocol for wireless networks. This supports and simplifies the process of discovering and connecting to wireless networks in your home or on the road.

Todo llega pequeño Padawan: el editor de atributos del AD en Longhorn.

Daniel Matey — Thu, 22 Mar 2007 06:05:00 GMT

Pues si, finalmente despues de mucho tiempo, Microsoft ha escuchado a sus usuarios y ha incorporado a la consola de "Site and Services" y a la de "Users and Computers" un nuevo tab a los objetos desde la que se pueden editar sus atributos en el AD.

Hasta ahora para realizar esta función habia que usar extensiones personalizadas de la consola que son muy dificiles de hacer, scripts conectados o no con Display specifiers, el adsiedit.msc o programas propios o de terceros.

Por si fuera poco, las fechas aparecen ahora en formato humano y no en el endemoniado formato tipico del AD.

Para poder ver este tab es necesario poner la consola en "advanced view"

El video que querias ver: Longhorn Server Virtualization

Daniel Matey — Fri, 02 Mar 2007 16:30:00 GMT

Video: Longhorn - Windows Server Virtualization

Documentación tecnica sobre el IAG 2007 (Intelligent Application Gateway )

Daniel Matey — Wed, 07 Feb 2007 07:57:00 GMT

•	Intelligent Application Gateway User Guide (Download) This guide provides in-depth information about IAG's functionality and how to use its various components and options. It includes step-by-step instructions on how to configure, maintain, monitor, and control IAG servers.

•	Intelligent Application Gateway Advanced Configuration (Download) This guide provides details on advanced configuration and capabilities of IAG, including security management tools, customizing web pages, access control, session settings, and more.

•	Intelligent Application Gateway Application Aware Settings (Download) This guide provides application aware instructions and information for applications supported by IAG, including application-specific instructions and, where applicable, configuration instructions.

•	Intelligent Application Gateway Software Ver 3.7 Release Notes (Download) This document provides a list of known issues with the release of software version 3.7 and information about multi-platform application support.

•	Intelligent Application Gateway 2007 System Requirements This page describes the system requirements for IAG 2007, as well as supported client software and client system requirements.

Microsoft Cluster Configuration Validation Wizard

Daniel Matey — Wed, 07 Feb 2007 07:54:00 GMT

Con esta utilidad se puede saber si un grupo de servidores cumple con los requisitos para montar un cluster, solo hay que instalarlo en una de las maquinas,

http://www.microsoft.com/downloads/details.aspx?FamilyID=bf9eb3a7-fb91-4691-9c16-553604265c31&DisplayLang=en

Articulo sobre Longhorn Core en PCWorld

Daniel Matey — Fri, 02 Feb 2007 06:21:00 GMT

Para los que estéis interesados en el tema de Longhorn Core, este mes he tenido el privilegio de publicar un artículo sobre este aspecto de Longhorn en la revista PCWorld.

Además la revista incluye otros muchos artículos interesantes.

Si hay que editar el Esquema se edita, pero editarlo para nada..... (Editando el esquema y creando un Display-Specifier)

Daniel Matey — Mon, 29 Jan 2007 05:59:00 GMT

Crea y edita tus propiedades personalizadas en el Directorio Activo.

En este artículo aprenderás cosas acerca del esquema y de algunos aspectos del funcionamiento interno del AD, crearemos una nueva propiedad para los usuarios y aprenderemos como extender la administración para poder utilizarla.

Introducción

Cada objeto que almacenamos en el directorio activo ya sea por ejemplo un usuario o un ordenador tiene una serie de propiedades que son las que nos permiten a nosotros y al Directorio Activo almacenar información relativa al objeto en cuestión, como por ejemplo los grupos a los que pertenece un usuario, la fecha en la que expira la cuenta o en que servidor de Exchange tiene su buzón un usuario.

Las propiedades que tiene un objeto están definidas en la “Clase”, a las propiedades se las llama atributos.

Cuando creamos un nuevo usuario en el Directorio Activo, en realidad estamos creando una instancia de la clase “User”, la clase contiene información relativa a todos los atributos que son necesarios para guardar toda la información de un usuarios en el AD, como la contraseña, el nombre, etc, la clase también define que atributos son obligatorios y cuáles no.

Las clases pueden heredar unas de otras, por ejemplo aunque nos parezca increíble, la clase “Computer” que es la que define a los objetos de los ordenadores que estén en el AD hereda de la clase “User”, cuando una clase hereda automáticamente contiene los mismos atributos y con la misma configuración que la clase de la que hereda, además se pueden añadir nuevos atributos.

Toda la información sobre las clases y los atributos se encuentra en el esquema que está almacenado en una partición especial del directorio activo.

Esta partición se replica a todos los controladores de dominio, pero solo puede ser modificada por el controlador de dominio que sostiene el rol de Maestro de esquema o Schema Master.

Para poder modificar el esquema es necesario pertenecer al grupo de usuarios Enterprise Admins o Schema Admins.

Modificar el esquema es una operación muy seria y delicada, antes de realizar una modificación en el esquema hay que probarla bien en un entorno de pruebas, yo recomiendo siempre hacer estos cambios con un script ya que podemos ejecutar el mismo script en una maquina de desarrollo y luego en producción si todo va bien.

Los cambios que hagamos en el esquema no se pueden borrar del todo, aunque es posible deshabilitar clases o borrar atributos.

Encuentro muy práctico realizar las pruebas con una maquina virtual, ya que se puede configurar esta para que no guarde los cambios cuando se reinicia, de forma que si tienes que repetir algo no tengas que hacer un DC de nuevo o copiar otra máquina virtual.

Explorando el Esquema.

Para poder ver la definición de las clases necesitamos acceder a la consola de administración del esquema, para hacer esto tenemos que registrar la DLL “schmmgmt.dll”.

Imagen 1, registrando la DLL.

Imagen 2, Mensaje de confirmación del registro de la DLL.

Una vez registrada la DLL lo siguiente será ejecutar la consola, para ello accederemos a la MMC y añadiremos la consola de

Imagen 3, Ejecutando la MMC.

Imagen 4, Añadiendo la consola.

Imagen 5, Añadiendo la consola.

Imagen 6, Añadiendo la consola.

Imagen 7, Atributos y clases.

Imagen 8, Clases.

Imagen 9, Atributos.

Imagen 10, Definición de la clase User (Ficha General).

Veis que la clase tiene un atributo llamado OID, por simplificar diré que este OID es un número único que se usa para identificar las clases, este número se genera con una utilidad llamada oidgen que podéis encontrar en el resource kit de Windows 2000.

Imagen 11, Definición de la clase User (atributos)

En el tab de Attributes podéis ver todas las propiedades que tiene la clase User.

En el Tab de Relationships veréis que clases pueden contener instancias de este objeto.

Imagen 12, Definición de la clase User (atributos).

Imagen 13, Propiedades de un atributo.

A parte del OID del que ya hemos hablado en explicación sobre las clases y que funciona igual en los atributos, nos podemos encontrar con alguna información muy interesante, tal como el tipo de atributo que es este caso es “Unicode String”, cadena de caracteres Unicode y el largo mínimo y máximo que puede tener.

Como sabéis el catalogo global no contiene todos los atributos de los objetos, solo contiene los atributos más usados, a este grupo de atributos se le llama PAS (partial attribute set), el catalogo global contiene estos atributos pero de todos los dominios, por esa razón en las empresas en las que hay varios dominios, es común que se realicen búsquedas sobre los GC, si queremos que un atributo especifico este replicado en los GC, tendremos que activar el check “Replicate tis attribute to the Global Catalog”

Hay que ser conservador a la hora de añadir atributos a la PAS pues si añadimos muchos afectaremos a la replicación, aunque esta consideración solo tiene sentido si tenemos grandes volúmenes de usuarios y también hay que analizar la capacidad de las líneas de comunicaciones, el numero de cambios que se hagan al día, las ventanas de replicación, etc.

Alguno de los otros checks como por ejemplo el de búsquedas ANR nos permiten modificar la forma en la que se indexara este atributo en las diferentes tipos de búsquedas.

¿Quién es el Schema Master?

Podemos saber quién es el schema master de varias maneras.

La primera es desde la consola de administración del esquema.

Imagen 14, Averiguando quien es el Schema Master.

Imagen 15, Viendo el Schema Master.

Fijaros que desde aquí también es posible especificar que servidor es el schama master, pudiéndolo cambiar en cualquier momento.

También podemos modificar quien es el Schema Master desde el comando NTDSutil.

Imagen 16, NTDSutil.

Modificando el esquema del AD.

Como ejemplo vamos a añadir una nueva propiedad a la clase user, esta nueva propiedad la usaremos para almacenar el Nº del documento nacional de identidad del usuario.

Es importante que antes de modificar el esquema para añadir un atributo a una clase, investiguéis bien la clase por si hay algún atributo que os valga, por ejemplo los objetos de tipo user tienen un atributo denominado EmployeeID que vale para poner el numero de empleado en recursos humanos de la empresa, si no usáis este campo para esa función, os puede valer para guardar el DNI.

El primer paso será generar un OID valido con la herramienta OIDGen del Resource Kit, en nuestro caso será: 1.2.840.113556.1.4.7000.233.28688.28684.8.416449.1243815.479696.960415

Imagen 17, Creando el nuevo atributo.

Imagen 18, Aviso.

Imagen 19, Creando el atributo.

Los atributos marcados como multivalue son en realidad Arrays unidimensionales, por ejemplo el campo de direcciones de correo de un usuario es multivalue.

Imagen 20, Atributo DNI ya creado.

El paso siguiente será modificar la clase User para que contenga este atributo.

Imagen 21, Añadiendo el DNI a la clase User.

Imagen 22, Añadiendo el DNI a la clase User.

Imagen 23, Añadiendo el DNI a la clase User.

Comprobando que hemos añadido la propiedad correctamente.

Desgraciadamente cuando añadimos un atributo a una clase, este atributo no está disponible desde la administración común de estos objetos.

Por lo tanto aunque hemos añadido el DNI a la clase user, si editamos un usuario desde la consola de usuarios y computadoras, no veremos dicho atributo, al final de este artículo os mostrare una sencilla solución a este problema.

Lo que sí es posible es usar la consola de edición del Directorio Activo (adsiedit.msc) para ver y editar las propiedades de un usuario, para poder usar esta consola tendréis que instalar las support tools de Windows 2003.

Yo siempre recomiendo que las support tools y el resource kit vayan instaladas en todos los servidores, pero eso es parte de otro artículo que algún día hare, podeis bajar las support tools de:

http://www.microsoft.com/downloads/details.aspx?familyid=6EC50B78-8BE1-4E81-B3BE-4E7AC4F0912D&displaylang=en

Imagen 24, Añadiremos la consola como hemos aprendido antes.

Imagen 25, Conectándonos al AD desde el ADSI Edit.

Imagen 26, Conectándonos al AD desde el ADSI Edit.

Imagen 27, Refrescando el cache del esquema tras conectarnos.

Imagen 28, Viendo las propiedades de un usuario.

Imagen 29, Editando el DNI del usuario.

Imagen 30, Editando el DNI del usuario.

El secreto de los Display Specifiers.

Bien, por supuesto, este proceso de edición no es demasiado rápido y no sería muy práctico que los operadores tuvieran que usar ADSIEdit para mantener el directorio por esa razón, vamos a usar un pequeño truco del Directorio Activo para facilitar el proceso de edición.

Vamos a modificar el menú contextual del objeto user dentro de la consola de usuarios y computadoras para que incluya una opción que nos permita editar el DNI del usuario.

El primer paso será crear un script que nos permita editar el DNI.

Si tuviéramos más atributos o quisiéramos poner combos para elegir los valores o un interfaz más rico podríamos usar un script HTA.

Los scripts HTA son scripts normales VBS pero que exponen un interfaz Windows, este interfaz se diseña usando HTML, otro día pondré un articulo enseñando como se haría este mismo script pero con PowerShell, pero es más complicado porque en vez de usar HTML hay que poner los controles a mano usando el espacio de nombres de Windows Forms de .Net.

El script que usaremos será muy sencillo:

‘***************************************************************************************

On Error resume next

Dim oemployeeID

Dim oUser

Dim temp

Set StrArgs = Wscript.Arguments

Set oUser = GetObject(StrArgs(0))

temp = InputBox("DNI: " & oUser.DNI & vbCRLF & vbCRLF & "Si quieres introducir un nuevo DNI o modificar el existente, introduce el nuevo número en la caja de texto.")

if temp <> "" then oUser.Put "DNI",temp

oUser.SetInfo

Set oUser = Nothing

Set StrArgs = Nothing

Set temp = Nothing

WScript.Quit

‘***************************************************************************************

En este ejemplo guardare el script con el nombre DS_DNI.vbs en una carpeta llamada c:\scripts.

El siguiente paso será conectarnos con AdsiEdit pero esta vez en vez de a la partición de Dominio nos conectaremos a la partición de configuración.

Imagen 31, Conectando AdsiEdit a la partición de configuración.

Una vez conectados a la partición de configuración veremos una unidad organizativa llamada “Display Specifiers”, entraremos en ella y veremos una OU por cada idioma, tenemos que modificar los Display Specifiers del idioma en el que este la consola de Usuarios y Computadoras que vallamos a usar, como normalmente todos instalamos los sistemas en ingles, usare la 409 que es la de este idioma.

Dentro de la OU 409 editaremos las propiedades del objeto User-Display

Imagen 32, Editando el objeto User-Display.

El objeto User-Display controla los menús contextuales y otras comportamientos gráficos de las instancias de la clase User a lo largo de todo Windows, la propiedad “adminContextMenu” se encarga del menú contextual de administración que es el que nos aparece en la cosa de usuarios y computadaros.

Tendremos que editar esa propiedad “adminContextMenu“y añadir una nueva línea que apunte a nuestro script.

Imagen 33, Editando la propiedad “adminContextMenu“.

Cada línea tiene que tener un numero identificador, luego pondremos el nombre que queremos que salga en el menú precedido de “&” y finalmente la ruta del script.

Imagen 34, Viendo el menú contextual de cualquier usuario.

Imagen 35, Script corriendo tras pulsar en DNI.

Imagen 36, Script corriendo por segunda vez.

Conclusión

En este articulo habéis visto como extender el schema y crear un Display Specifier para ayudaros a resolver una necesidad de administración, algo tan simple como guardar el DNI de los usuarios es un aspecto clave dentro de toda administración evolucionada.

Pensar que un usuario del que no sabéis su DNI no es nadie, es solo un nombre, mientras que con el DNI es posible una integración con el sistema de nominas, lo cual tras varias iteraciones de automatización puede llegar a sinergias tan importantes como las bajas y altas automáticas o el control de errores, pero eso otro artículo.

Entender la autenticación en Remote Desktop 6.0

Daniel Matey — Tue, 23 Jan 2007 05:46:00 GMT

Como sabéis al usar el cliente 6.0 de Remote Desktop normalmente pide validación antes de entrar en el servidor, pero algunas veces se comporta de otra manera.

En este artículo nos explican ese comportamiento:

Vista Remote Desktop Connection Authentication FAQ

El cliente 6.0 está incluido en vista y se puede descargar para XP, os lo recomiendo por que soluciona algunos problemas de impresión.

El cliente también jugara un papel importante en Longhorn ya que es imprescindible para el uso de nuevos funcionalidades como el tsgateway o las aplicaciones remotas.

Para los que queráis saber más sobre Terminal Services en Longhorn podéis leer mi artículo:

http://geeks.ms/blogs/dmatey/archive/2007/01/16/terminal-services-en-longhorn.aspx

Básicos: Cosas que siempre quisiste saber sobre el correo electrónico y nunca te atreviste a preguntar (Parte 1).

Daniel Matey — Sat, 20 Jan 2007 19:23:00 GMT

La serie Básicos.

Esta serie de artículos nace de la necesidad de tener una referencia que poder usar para dar una respuesta sencilla a las preguntas básicas que frecuentemente aparecen en los foros.

Introducción

Desgraciadamente con frecuencia, las pequeñas y medianas empresas se enfrentan al reto de querer disponer de su propia infraestructura de correo sin tener los conocimientos adecuados, cuando finalmente han conseguido desplegar este servicio, se encuentran con los problemas relativos al relay, el spam y los virus.

Por ultimo las pequeñas operaciones del día a día, también suponen un problema si no se cuenta con la formación adecuada.

En este artículo espero que puedas encontrar las respuestas a algunas de tus preguntas, para las demás, yo y otros MVP y colaboradores de la comunidad te esperamos en los foros de la technet.

El funcionamiento del correo a alto nivel.

Para poder entender como logran los servidores de correo de otros dominios dar con los nuestros es necesario que entandáis el concepto de los registros MX (Mail Exchangers o intercambiadores de correo)

¿Para qué sirven los MX?

Los registros MX son un tipo especial de registro en la zona DNS de un dominio, estos registros identifican que servidores se encargan del correo de ese dominio.

Los registros MX no especifican una IP, si no que en realidad hacen referencia a otro registro, será ese registro el que este asociado a una IP publica en internet, esta IP será la del servidor de correo o router/firewall que lo publique en Internet.

Dado que el registro en la zona DNS apuntara a una IP, es imprescindible que este IP sea fija.

El correo de entrada desde otros dominios nos llega por el puerto 25 que es el del protocolo SMTP (Simple Mail Transfer Protocol o Protocolo Simple de Transferencia de Correo), por lo tanto necesitareis publicar o redirigir este puerto en vuestros firewalls o routers hacia el servidor que desempeñe esa función dentro de vuestra red.

Cuando un servidor de un dominio cualquiera quiere enviar correo a un usuario de nuestro dominio, lo primero que tratara de hacer es averiguar la IP de un servidor de correo de ese dominio, para eso se conectara al DNS y le solicitara los registros MX del dominio en cuestión.

El registro MX solo es válido para el dominio que lo contiene, esto significa que si tienes varios dominios, cada uno tendrá que tener su propio MX.

Un solo servidor con una sola IP puede ser el MX de tantos dominios como quieras, pero tendrás que configurar en tu servidor de correo que acepte los correos que entren de esos dominios.

Un dominio puede tener más de un MX, a cada MX se le asocia un peso o prioridad que es simplemente un numero, los servidores de correo siempre trataran de conectarse a los MX con menor peso, si no lo logran se conectaran al siguiente.

En empresas grandes es habitual que se coloquen varios MX y que los servidores que respondan a esas IPS se encuentren en diferentes puntos geográficos y con líneas de diferentes proveedores de comunicaciones, de esta forma las empresas se garantizan que en caso de que un servidor tuviera problemas de cualquier tipo, otro servidor recibiría el correo.

Muchos proveedores de correo, ofrecen como servicio poner sus servidores de correo como MX secundarios de forma que si tu servidor tiene problemas ellos recibirán el correo por ti, cuando tu servidor se recupere ellos te reenviaran todo el correo que hayan almacenado.

En el siguiente diagrama vemos gráficamente el funcionamiento de lo explicado hasta ahora.

Cuando el servidor de correo de la empresa A quiere mandar un correo a la empresa B sucede lo siguiente:

1) El servidor de correo trata de conectarse con el servidor DNS que tenga configurado en la tarjeta de red del servidor de correo o en la configuración de Exchange, para esto necesitara que el firewall o router le dejen salir por el puerto 53 de TCP y UDP, una vez que se ha conectado pregunta al servidor DNS por los MX de la zona de la empresa B.

2) El servidor DNS responde con los datos de los MX

3) El servidor de correo de la empresa A trata de conectarse a la IP del MX por el puerto 25 TCP, el firewall de la empresa A tiene que dejar salir ese tráfico y el de la empresa B tiene que estar publicando el puerto 25 del servidor de correo en la IP publica a la que se haga referencia en el DNS.

¿Cómo crear un MX si no lo tengo y que necesito para poder crearlo?

Una vez que ya has registrado un domino, el siguiente paso es crear los registros MX.

Cuando registras un dominio suele haber dos opciones.

Opción 1) Dejar que la empresa que te vende el dominio se encargue de los DNS; en esta modalidad no tienes que montar un DNS, la empresa en la que has registrado el dominio se encarga de proporcionarte uno, normalmente tendrán una página web en la que podrás gestionar los registros en la zona del dominio que has registrado, así que este caso solo tendrás que entrar en esa página con el usuario y contraseña que te han dado e introducir un nuevo registro MX con la IP que tengas.

Imagen 1, ejemplo de pagina web de administración de los MX de una zona.

Opción 2) Tener tus propios DNS; una vez que has registrado un dominio, es posible indicarle que quieres que los servidores DNS encargados de ese dominio sean los tuyos, usualmente no recomiendo que se haga esto, ya que aunque aporta más flexibilidad es una gran responsabilidad, si los servidores DNS fallan, nadie podrá acceder a ningún servicio prestado en el mismo.

Dentro de las zonas DNS es posible tener un servidor primario y varios servidores secundarios, los secundarios replican la información del primario por si este dejara de funcionar, es posible tener el primario a nuestro cargo en nuestros servidores y que el secundario lo tenga el proveedor o que este en otros servidores nuestros.

Los servidores DNS de una zona se especifican con registros de tipo NS.

Si nosotros tenemos el DNS es importante que nunca lo pongamos en un servidor unido al dominio de Windows, especialmente si es un DC, los DC contienen información muy valiosa en términos de seguridad, dado que los servidores DNS han de exponer su puerto 53 (TCP y UDP) en internet son siempre un punto inicial para un ataque, por esta razón es recomendable que los DNS que tengamos en Internet estén completamente aislados de la red interna.

Veamos ahora como configuraríamos el registro MX en un servidor DNS de Windows 2003 Server en caso de tener en un servidor nuestro la zona del DNS.

Imagen 2, creación del registro A que representa al servidor de correo.

Imagen 3, Creación del registro A y asociación a la IP publica en Internet.

Imagen 4, Creación del registro MX.

Imagen 5, Creación del registro MX asociándolo al registro de tipo A creado anteriormente.

¿Cómo saber cuál es mi MX o mis servidores DNS?

Hay dos formas de realizar estas averiguaciones.

Opción 1) La forma fácil; podemos usar alguna pagina como http://www.dnsstuff.com desde la cual podemos sacar un informe de nuestra zona DNS

Imagen 6, Pidiendo a dnsstuff.com un informe sobre la zona DNS de Microsoft.com

7, Servidores NS (servidores DNS) mostrados en el informe de dnsstuff.com.

Imagen 8, Servidores MX mostrados en el informe de dnsstuff.com

Opción 2) La difícil; Yo prefiero esta opción la razón es que la puedo ejecutar desde mi propio servidor de correo y esto me ayuda cuando tengo problemas al enviar correo a otros dominios, ejecutando este proceso desde un servidor de correo, podréis averiguar si es capaz de encontrar los MX de otros dominios.

Usaremos el comando nslookup para conectarnos al DNS, el servidor DNS usado por un servidor de tipo Exchange tiene que poder ser capaz de responder a preguntas sobre zonas en internet, pero también tiene que ser capaz de permitirle ser miembro del directorio activo, una de las posibles soluciones a este problema la podéis encontrar en este otro artículo: http://geeks.ms/blogs/dmatey/archive/2007/01/16/basicos-configuraci-n-de-dns.aspx

Imagen 9, entrando en nslookup y preguntando por los registros NS de Microsoft.com

Imagen 10, preguntando por los servidores MX de Microsoft.com

Como veis la información obtenida es la misma, pero nos garantizamos que es exactamente como nuestro servidor la ve.

Es posible conectarnos a servidores DNS específicos usando el comando “server IP” desde el comando nslookup y cambiando IP por la IP del servidor dns al que nos queramos conectar.

¿Cómo probar el servidor de correo que escucha en un MX?

Una vez que sabemos cuál es el registro MX de una zona, podemos probarlo simplemente haciendo telnet al puerto 25 de ese servidor concreto, si no obtenemos respuesta de ninguno de los MX del dominio significara que no podremos enviar correo a ese dominio, si lo intentamos hacer contra un servidor nuestro, es importante no hacerlo desde el mismo servidor.

De esta forma podemos saber si otros servidores se pueden conectar contra el nuestro.

Para probarlo contra un servidor de Microsoft ejecutaremos el siguiente comando.

Imagen 11, conectando a un servidor MX de Microsoft.com

Imagen 12, Recibimiento del MX de Microsoft.com.

Si os fijáis veréis que aunque hemos hecho un telnet a maila.microsoft.com nos ha recibido un servidor llamado mail04, esto se debe a que en las empresas grandes es común que se usen balanceos de carga de varios servidores para responder a cada MX, especialmente al de mas bajo peso que será el que más correo reciba.

Precauciones antes de poner un servidor en internet.

Como habéis visto una vez que publiquemos nuestro correo en internet, cualquiera podrá conectarse al puerto 25 de nuestro servidor, en este puerto escuchara nuestro sistema de correo, por ejemplo Exchange, si Exchange tuviera algún fallo de seguridad un atacante con los conocimientos adecuados podría intentar hacerse con el control del servidor.

Este problema es común a todos los servidores de correo ya sean Linux, Windows, Solaris, etc.

Por esta razón es siempre muy importante mantener actualizado nuestro servidor y tratar de exponer lo menos posible el servidor al exterior, si montamos y publicamos mas servicios en el mismo servidor estaremos multiplicando exponencialmente el riesgo.

A la hora de defender nuestra red, es clave pensar detenidamente donde pondremos nuestro servidor o servidores SMTP.

En medianas y grandes empresas es usual que si se usa Exchange 2003, se disponga de servidores denominados Front-End, dichos servidores se encargan del acceso de los usuarios a su correo por Web, POP3, Imap y también prestan los servicios de SMTP.

Mucha gente sostiene que estos servidores Front-End al estar expuestos a Internet se tienen que situar en la DMZ o zona desmilitarizada.

La DMZ es una red que se suele configurar entre Internet y la red local.

Podemos encontrar infinitos modelos de DMZ, los más comunes serian.

Imagen 13, Diferentes configuraciones de DMZ.

En el caso de las empresas más pequeñas, nos podemos encontrar que no hay firewall, en ese caso simplemente contaremos con el router para poder filtrar los puertos abiertos, algunos routers cuentan con bocas especiales para crear una DMZ.

Yo sostengo que no se deben poner los servidores de Front-End de Exchange en la DMZ, mis argumentos se basan en que Exchange requiere ser miembro del dominio y trabajar estrechamente con los controladores de dominio, por esta razón es necesario abrir demasiados puertos en los firewalls perimetrales, además parte de este tráfico a permitir es de tipo RPC, los protocolos de tipo RPC requieren de un rango dinámico de puertos para funcionar, es cierto que es posible cambiar este comportamiento reduciendo el rango de puertos dinámicos, aun así, creo que si alguien lograra conquistar un Front-End en la DMZ podría usar estos puertos abiertos y el hecho de que el servidor sea miembro del dominio, para lograr penetrar en la red interna.

Bajo mi forma de ver este problema creo que hay dos posibles variantes de diseños, los expresare bajo el modelo de back to back simple aunque obviamente se puede extrapolar a cualquier configuración de firewalls que cuente con una DMZ.

Variante 1.

Imagen 14, variante 1 del emplazamiento del SMTP dentro de una arquitectura de correo.

En esta variante, confiamos en el filtro de aplicación SMTP de los firewalls y usamos IPSEC para garantizar que si alguien consiguiera el control del Front-End no lograría salir de ese grupo y reglas, a esta configuración se la llama server isolation.

Variante 2

Imagen 15, variante 2 del emplazamiento del SMTP dentro de una arquitectura de correo.

En esta variante colocamos en la DMZ un servidor SMTP con el antivirus y el Antispam, este servidor no forma parte del dominio y simplemente filtra todo el correo entrante y lo reenvía hacia el Front-End, este será el servidor del que publicaremos su puerto 25 en internet, aun asi usaremos IPSEC, dado que también será necesario publicar en internet los puertos del correo por web (OWA) y siempre existe el riesgo de un ataque.

Este servidor no tiene por qué tener Exchange, se puede usar el servidor SMTP de Windows 2003.

En Exchange 2007 existe un tipo especial de rol de servidor de Exchange denominado Edge Services, estos servidores están pensados para hacer lo mismo que expreso en esta variante de diseño, podéis leer mas sobre este rol en mi artículo sobre el diseño de arquitecturas con Exchange 2007 en: http://geeks.ms/blogs/dmatey/archive/2007/01/16/ejemplo-de-dise-o-de-arquitectura-de-mensajeria-con-exchange-2007.aspx

Insisto en la importancia de mantener actualizados todos los servidores de la solución, para ello lo mejor es contar con servidores de actualización del tipo de WSUS, también recomiendo usar MBSA (http://www.microsoft.com/technet/security/tools/mbsahome.mspx)y Exchange Best Practice Analyzer (http://www.microsoft.com/exchange/downloads/2003/exbpa/default.asp)

Exchange cuenta con un producto gratuito denominado IMF que esta incluido dentro de Exchange y que nos ayudara a reducir el Spam.

Como sistema de Antivirus recomiendo usar ForeFront de Microsoft que es uno de los pocos antivirus de correo que permite usar varios motores de detección simultáneos garantizándonos así que tendremos la máxima protección.

El problema del Relay.

¿Qué es el relay?

El relay consiste en reenviar correo de un servidor a otro, de por si no es malo, pero sin embargo si lo es y mucho cuando ni el dominio origen ni el destino es nuestro.

Todos somos víctimas del SPAM o correo no deseado, hemos visto que podemos utilizar herramientas como IMF para evitar que nos entre SPAM, pero desgraciadamente el problema va mas allá, las personas que se dedican a hacer SPAM suelen usar servidores vulnerables al Relay para enviar estos miles de correos, estos servidores se ven atacados por miles de correos que consumen sus recursos y ancho de banda.

El problema puede ser aun peor, ya que para evitar el SPAM muchas organizaciones indican a sus servidores de correo que validen en unas listas conocidas como listas negras si los servidores que les intentan mandar correo están en dichas listas o no.

De tal forma que si por alguna razón nuestro servidor ha hecho relay y alguna lista negra lo ha detectado y listado, es posible que otros servidores de correo rechacen nuestros envíos pensando que son SPAM.

¿Cómo saber si hago relay?

Hay páginas en Internet que pueden hacernos un test de relay probando varias técnicas, en esta que os pongo de ejemplo y que podeis encontrar en: http://www.abuse.net/relay.html , podeis considerar que no haceis relay si pasais las 8 primeras pruebas con éxito.

Imagen 16, pagina para hacer un test de relay.

Una forma fácil y rápida de comprobar si hacemos relay o no, es conectarnos desde otro punto a nuestro servidor de correo por telnet al puerto 25.

Imagen 17, conexión al SMTP de un servidor de correo de Microsoft.

Imagen 18, intento de hacer relay.

Como podemos ver si tratamos de usar el servidor de correo de Microsoft para hacer relay ósea enviar un correo de alguien que no es de Microsoft a alguien que no es de Microsoft, el servidor no responderá con un “unable to relay” indicándonos que no podremos hacer esto en su servidor.

Microsoft al igual que otras empresas usan una técnica denominada tarpit que hace que una vez que el servidor de correo detecta un intento de relay empieza cada vez a responder mas lento al atacante, de esta forma los que intentan hacer el spam dejan de intentarlo ya que no les resulta productivo, podéis leer mas sobre esta técnica en: http://support.microsoft.com/kb/842851

¿Cómo evitar hacer relay con Exchange 2003?

Editaremos las propiedades del servidor SMTP de Exchange que tengamos publicado.

Imagen 19, editando el servidor SMTP publicado.

Imagen 20, configurando el relay en el servidor SMTP.

Imagen 21, configurando el relay en el servidor SMTP.

Una vez hecho esto, probar vosotros mismos con el telnet a hacer relay.

Si por alguna razón necesitáis hacer relay desde el interior de vuestra red, es posible añadir estos servidores a las excepciones mostradas en la imagen 21, aunque yo prefiero crear otro servidor virtual de SMTP desde la consola de Exchange.

¿Cómo saber en qué listas negras estoy metido?

Si creéis que estáis metidos en alguna lista negra, hay paginas en internet que os pueden ayudar a interrogar varias listas negras.

Imagen 22, viendo si Microsoft.com está en alguna lista negra desde dnsstuff.com

Imagen 23, resultados del informe.

Si buscáis en google por “relay blacklist database” encontrareis otros sitios donde poder consultar estas bases de datos.

¿Qué hacer si estoy en una lista negra?

Esta pregunta no tiene fácil respuesta, lo primero es aseguraros de que no hacéis relay o si lo hacéis corregirlo, luego tendréis que buscar la web de la lista negra en la que estáis listados y tratar de poneros en contacto con ellos para que os quiten, en algunos casos es rellenando un formulario en la web, en otros casos solicitan “donativos” para quitaros o simplemente no aceptan solicitudes de quitar de las listas, afortunadamente cada vez es menor las empresas que usan estas listas, ya que en algunos casos se están convirtiendo en fuentes de problemas, falsos positivos y estafas.

Conclusiones

Espero que este articulo os haya servido para aprender un poco más sobre el funcionamiento del correo electrónico, en siguientes artículos de la serie básicos tratare el tema del IMF, y las operaciones del día a día con Exchange tales como listas de distribución, usuarios, desvíos de correo, etc.

Instalando Longhorn y haciendo un DC (a lo rapido )

Daniel Matey — Fri, 19 Jan 2007 12:34:00 GMT

Terminal Services en Longhorn

Daniel Matey — Tue, 16 Jan 2007 20:36:00 GMT

Sin duda una de las cosas que mas me apasiona de Longhorn son los servicios de terminales, creo que las mejoras en el protocolo RDP y otras nuevas capacidades vienen a mejorar uno de los aspectos de Windows que mas aportan a las infraestructuras informáticas de las grandes empresas.

La verdad es que cuando te enfrentas a granjas de decenas de servidores de terminales con miles de usuarios concurrentes toda nueva funcionalidad o mejora es mas que interesante :-D.

Vamos al Grano…

Una de las cosas mas interesantes que podemos ver es el uso por Terminal de aplicaciones de forma que aparentemente corran en el PC, esto se debe a que el usuario para entrar solo tiene que ejecutar un icono en el escritorio o en el menú de inicio, ambos iconos los podemos configurar de forma centralizada, como veremos luego.

Una vez ejecutado el icono, el usuario no vera el interfaz de Terminal si no la aplicación corriendo en su propia ventana, de hecho los cuadros de dialogo que la aplicación despliegue flotaran sobre esta pudiéndolos mover fuera de la ventana.

Icono de Notepad en terminal

Otra de las ventajas es que podemos asociar extensiones de archivos a aplicaciones de Terminal de forma que cuando se ejecuten, se arrancara la aplicación por Terminal y se abrirá el archivo.

Podemos generar paquetes de instalación MSI o archivos RDP desde las herramientas del servidor y luego desplegarlas por GPO o por otros medios, estos paquetes configuraran todas las opciones en el puesto y crearan los iconos si así lo deseamos.

En Windows 2000 y 2003 existía un cliente de Terminal en Activex con el cual se podía acceder desde una Web a una sesión RDP, este cliente activex seguía usando el puerto RDP de toda la vida no http, con lo cual se solucionaba poco, también usando este Activex se podían embeber aplicaciones RDP dentro de portales como Sharepoint.

En Longhorn han ido un poco mas lejos, ahora cuando creas una aplicación remota puedes publicarla en “TS Web Access” esto es una pagina web, totalmente configurable y personalizable que además incluye una web part que podemos poner en Sharepoint.

Solo aparecerán los iconos de las aplicaciones que tengamos asignadas al usuario ya sea por grupos de Windows o por GPO, las aplicaciones pueden correr en su propia ventana.

Pero esta funcionalidad, al igual que antes sigue usando el puerto rdp con lo cual tenemos que abrir dicho puerto en nuestros firewalls, ademas si en el escenario que tuviéramos necesitarmos acceder desde Internet, tendríamos que o bien dejar el RDP abierto o acceder por VPN.

En Longhorn podemos usar una característica llamada TS Gateway para acceder a Terminal por http, los servidores que hagan de gateway estarán publicados en la red de la que vengan los clientes y “trasformaran” el http en RDP y al contrario.

Para usar esta característica necesitaremos el ultimo cliente de Terminal, por ejemplo el que viene con Windows Vista.

Los gateways son balanceables por NLB pueden exponer granjas de servidores de terminales y ser publicados fácilmente con ISA o con otros firewalls, permiten la validación por smarcard, password y también pueden usar certificados de servidor.

Hay diversas opciones para los logs de los Gateways y también podemos usar NAP para garantizar que los puestos cumplan con nuestras políticas de seguridad antes de acceder al Terminal.

Otra de las grandes noticias es la posibilidad de usar licencias por usuario, de forma que cuando el mismo usuario acceda desde varios ordenadores o dispositivos solo use una licencia.

Ahora podemos administrar varios servidores juntos formando una granja esto facilita algunas operaciones de configuración, también es mas fácil la configuración del session directory que nos permitirá que los usuarios se reconecten al servidor de la granja en el que ya tenían una sesión abierta, en caso de que la pierdan, esto es especialmente util, para garantizar que un usuario solo tenga una sesión en toda la granja.

La seguridad esta presente en todos los sitios, mejor encriptación y mas opciones.

La limitación de los recursos que se mapean es mas granular, tanto en el servidor como en el cliente.

Por ultimo una nueva opción del cliente la /span que nos permite expandir el escritorio remoto a varios monitores.

Basicos: Dominio Interno y Externo diferentes.

Daniel Matey — Tue, 16 Jan 2007 13:00:00 GMT

Serie "Básicos"

Este sitio Web está dedicado a la arquitectura informática y por lo tanto sus artículos son de nivel medio/alto, pero debido a mi colaboración en foros como la TechNet es común que me encuentre con algunas dudas "básicas".

La serie básicos pretende ayudar a los administradores noveles a solucionar situaciones que aunque sencillas pueden representar un problema para ellos.

Introducción

A la hora de decidir cual será el nombre DNS del primer dominio y por lo tanto del bosque que creamos, hay que tomar una elección:

1) Llamar al dominio del directorio activo igual que nuestro dominio externo.

2) Usar un nombre de domino diferente para nuestro directorio activo.

Todas las buenas prácticas apuntan a que es mejor usar la 2ª opción si por ejemplo nuestro dominio externo es Empresa.Com usaremos algo como Empresa.Local para nuestro dominio interno.

En este articulo "básico" analizaremos los problemas más comunes que se encuentra un administrador novel al enfrentarse a cualquiera de las dos decisiones.

Dominio Externo igual que dominio Interno.

En este caso el problema más frecuente es que si por ejemplo se tiene una web publica del tipo http://www.empresa.com/ los usuarios internos de la red no pueden navegar por ella.

La razón es que los puestos tienen configurado como DNS al controlador de dominio que considera la zona empresa.com como local y además se cree completamente autoritativo para ese dominio, por lo cual cuando no sabe resolver algo en esa zona considera que es por que no existe.

Este mismo problema con la web se puede extrapolar a cualquier tipo de servicio como servidores de correo, etc.

Solucionarlo pasa por conseguir que los servidores DNS internos sean capaces de resolver esos recursos públicos.

Conseguir esto es tan sencillo como crear los registros adecuados en la zona DNS empresa.com de nuestros DNS.

Figura, 1. Creando un registro DNS para http://www.empresa.com/ (1)

Figura, 2. Creando un registro DNS para http://www.empresa.com/ (2)

Si usas un servidor Proxy para salir a Internet, tendrás que configurar los navegadores para que soliciten al proxy las direcciones locales y el proxy para que sea capaz de prestar esas páginas web.

Lo segundo depende del tipo de proxy que uses pero lo primero se configura en Internet Explorer.

Figura, 3. Configurando Internet Explorer para que no se salte el proxy en las direcciones locales.

La casilla de no usar proxy para direcciones locales tiene que estar desmarcada.

Domino Interno diferente del dominio Externo.

En este caso, los problemas son:

1)- Al montar exchange este no permite que entren los correos dirigidos al dominio externo Empresa.Com.

2)- Dudas a la hora de publicar servicios o pedir certificados.

Lo primero que tienes que pensar es que este escenario es el mas comun, ademas piensa tambien en la cantidad de proveedores de servicios que prestan servicios de correo electronico a cientos de empresas diferentes o en los grupos de empresas que tienen muchos dominios DNS.

Para conseguir que Exchange acepte el correo electronico del dominio Empresa.Com, lo primero que te tienes que asegurar es que tienes los registros MX creados dentro de la zona publica de tu servidor DNS publico y que apuntan a las IPs publicas en las cuales tengas publicado el puerto 25 de tu servidor exchange.

Una vez que tengas comprobado esto y que desde internet se puede acceder al puerto 25 de tu servidor Exchange en la IP publica de tus MX, ya puedes configurar Exchange para que acepte los correos del dominio Empresa.com y asigne a los usurios una dirección SMTP del domino Empresa.Local.

Para hacer esto es necesario que crees una politica de recipientes desde la consola de Exchange "system manager"

Figura, 4. Creando una política de recipientes en Exchange (1).

Figura, 5. Creando una política de recipientes en Exchange (2)

Figura, 6. Creando una política de recipientes en Exchange (3)

Figura, 7. Creando una política de recipientes en Exchange (4)

En address pondremos nuestro dominio externo en nuestro caso Empresa.Com precedido de una @.

Es importante marcar la casilla "Esta organización de Exchange es la responsable de todo el correo de esta dirección"

Figura, 8. Creando una política de recipientes en Exchange (5)

La dirección que marquemos como primaria será la que se use para responder los correos.

En la mayoría de los casos recomiendo dejar la dirección smtp de @Empresa.local, pero es opcional.

Después de guardar los cambios y esperar un poco, la RUS que es el servicio encargado de asignar las direcciones de correo según lo indicado en las políticas de recipientes se encargara de asignar una dirección con el domino que hayamos indicado.

Respecto a las dudas relativas a la publicación de servicios en internet, tienes que tener en cuenta.

Siempre que publiques algo lo harás sobre una IP Publica y configuraras el DNS público para que resuelva el nombre que quieras en dicha IP.

Una vez que publiques en tu firewall el recurso que quieras en esa IP, los usuarios externos lo encontraran sin problemas sea cual sea el dominio interno.

Si algún recurso publicado exige validación, hay que validarse indicando el nombre del dominio interno.

A la hora de pedir certificados hay que pedirlos con el nombre del dominio externo.

Si publicas algo en ISA especifica el nombre que tendrá el recurso en internet con el dominio externo.

Si los DNS externos será también tuyos en vez de un proveedor de servicios internet tendrás que crear un split DNS, este articulo te ayudara: http://www.isaserver.org/tutorials/You_Need_to_Create_a_Split_DNS.html

Si tienes que publicar varios sitios web sobre una sola ip publica tendrás que usar encabezamientos para que el IIS sepa a que sitio web quiere ir un usuario según el nombre del sitio.

Esto se puede hacer durante la creación del sitio web:

Figura, 9. Configurando un nuevo sitio web para que pueda funcionar en la misma IP que otros (1).

Figura, 10. Configurando un nuevo sitio web para que pueda funcionar en la misma IP que otros (2).

Figura, 11. Configurando un nuevo sitio web para que pueda funcionar en la misma IP que otros (3).

El resto de la configuración será normal.

Si por el contrario queremos modificar un sitio ya existente, lo haremos modificando las propiedades del sitio:

Figura, 12. Modificando un sitio web para que pueda funcionar en la misma IP que otros (1).

Figura, 13. Modificando un sitio web para que pueda funcionar en la misma IP que otros (2).

Referencias:

Para tener mas información sobre como funciona el DNS dentro de una empresa puedes leer el articulo http://geeks.ms/blogs/dmatey/archive/2007/01/16/basicos-configuraci-n-de-dns.aspx

Para información sobre por que es mejor usar diferentes nombres y una visión mas general del DNS: http://www.microsoft.com/latam/technet/articulos/200110/art03/default.asp

Basicos: Configuración de DNS

Daniel Matey — Tue, 16 Jan 2007 12:55:00 GMT

Con este articulo empiezo una nueva serie de artículos denominados Básicos.

Como todos sabéis, este sitio web está dedicado a la arquitectura informática tanto de infraestructuras como de soluciones y por lo tanto suelo tratar temas de nivel medio/alto.

Desde hace un tiempo colaboro en los foros de la TechNet de Microsoft, donde veo que continuamente aparecen preguntas de carácter básico.

Los artículos de esta serie "básicos" están orientados a responder a esas preguntas sencillas que aunque ya están mas que respondidas por la documentación de Microsoft, algunos administradores siguen sin saber aplicar y requieren de una explicación más sencilla.

Introducción:

Cuando Windows 2000 salió al mercado, el directorio activo fue la mayor novedad y la funcionalidad con mayores repercusiones, desde el principio me di cuenta de que el DNS seria uno de los mayores focos de problemas, dado que la mayoría de los administradores de Windows no habían tenido ninguna relación con este servicio que fuera mas lejos que la resolución de nombres en internet.

En este articulo hablaremos de cómo hay que configurar el DNS en una empresa usando Windows 2003.

Primeros pasos:

Cuando hacemos DCPromo se configura automáticamente un servidor DNS en el mismo servidor en el que hemos lanzado el DCPromo, es común que muchos técnicos instalen a mano el servicio de DNS desde quitar y añadir programas del panel de control antes de lanzar el DCPromo.

En ese caso el DCPromo configurara el servicio para funcionar con el directorio activo.

En posteriores controladores de dominio, siempre deberos de ser nosotros los que instalemos el servicio de DNS, antes de lanzar el dcpromo.

Normalmente las empresas tendrán dos necesidades con respecto al DNS interno:

· Que sea capaz de resolver direcciones de internet para que los usuarios puedan navegar y el correo electrónico funcionar correctamente.

· Que permita el buen funcionamiento del directorio activo y resuelva correctamente los nombres y dominios internos.

El error mas común en las pequeñas empresas es poner como DNS de los puestos a un servidor DNS de internet para que pueda navegar.

Cuando se configura un puesto o un servidor de esta manera, no pasa demasiado tiempo antes de que empiecen a aparecer los problemas, GPOs que no se aplican, puestos que tardan en arrancar, recursos de red que desaparecen, etc.

Para que un puesto funcione bien, todos los DNS que use, tienen que ser controladores de dominio.

¿Qué controladores de dominio se deben usar como DNS?, el primario será el controlador de dominio (DC) más cercano que tenga el puesto, el secundario el siguiente aunque este en otra oficina, de esa forma si un DC deja de funcionar el puesto trabajara con normalidad usando otro DNS de otro DC.

¿por que los puestos y los servidores dependen tanto de los DCs para todo lo relacionado con el directorio activo?, en Windows NT, los puestos y servidores encontraban a los PDC y BDC usando broadcast netbios, esto era un problema por muchas razones que no vienen al caso, con el fin de solucionar este problema, Microsoft acertadamente decidió que los DCs y GCs se localizaran a través del DNS.

Cuando un DC arranca su servicio de Netlogon escribe en el DNS una serie de registros que ayudaran a que los puestos lo localicen y sepan que servicios presta, por esta razón estos registros se denominan "locators"

Puedes ver dichos registros entrando en la consola del DNS y luego en la zona de tu dominio:

Figura, 1. Uno de los registros locator de un servidor DC.

Por lo tanto ya conocemos la regla básica del buen funcionamiento del DNS, todas las maquinas tendrán como DNS a los controladores de dominio de su red.

¿Qué DNS tienen que tener configurados los controladores de dominio?, por regla general todo DC se tendrá a sí mismo como DNS primario y al DC más cercano como secundario.

En otros casos se pueden poner como secundarios otros DCs de otros sites, pero esa es una configuración más avanzada que no es el objetivo de este articulo.

Hemos visto que el DCPromo es capaz de configurar nuestro servidor DNS, pero desgraciadamente no realiza el procedimiento completo.

NSlookup es una herramienta de línea de comandos que nos permite interrogar a los servidores DNS, si la ejecutamos se conectara automáticamente al DNS primario que tengamos configurado en la maquina en la que lo corramos.

Figura, 2. Nslookup.

NSlookup nos dice que no puede encontrar el nombre para el servidor con la IP 192.168.0.11, que en nuestro caso es la IP de nuestro DC.

¿Por qué no puedo encontrar el nombre para la IP de mi DC?, cuando DCPromo configura el DNS lo hace para que podamos averiguar que IP tiene un nombre, esto se llama forward resolution, pero para averiguar el nombre que tiene una IP hay que lanzar una reverse resolution.

Para solucionar este problema tendremos que crear una zona de resolución inversa en el servidor de DNS, esta zona de resolución inversa es válida solo para una subred, tendremos que crear una zona por cada subred que tengamos.

En este articulo estamos usando la subred 192.168.0.0 con mascara 255.255.255.0, vamos a crear la zona de resolución inversa para esta red.

Figura, 3. Creando zona de resolución inversa (1)

Figura, 4. Creando zona de resolución inversa (2)

Figura, 5. Creando zona de resolución inversa (3), eligiendo el tipo de zona y si se almacenara en el AD.

Figura, 6. Creando zona de resolución inversa (4), especificando a que servidores se replicara dentro del Forest.

Figura, 7. Creando zona de resolución inversa (5), indicando la subred de la que se hará cargo la zona.

Figura, 8. Creando zona de resolución inversa (6), especificando si la zona permitirá actualizaciones automáticas de los DHCP y puestos.

Figura, 9. Creando zona de resolución inversa (7), finalizando.

Figura, 10. Creando zona de resolución inversa (8), zona ya creada y con el registro del DC introducido.

¿Cómo se crea un registro PTR?, los PTR son los registros de las zonas de resolución inversa, pulsa sobre la zona con el botón derecho, selecciona "nuevo registro PTR" y rellena el formulario indicando la parte de la IP que no está contenida en la máscara y el nombre completo del servidor al que hará referencia el registro PTR.

Figura, 11. Creación de un registro PTR.

Figura 12. Probando de nuevo con nslookup.

Como podemos ver en la figura 12, el nslookup ya funciona correctamente, gracias a la zona de resolución inversa ya es posible encontrar nombres a partir de IPs, esto tan simple, nos ahorrara múltiples problemas en el futuro.

¿Que pasa con Internet?

Si has configurado todo como te hemos indicado hasta ahora, tu dominio funcionara bien a nivel de DNS, pero tus puestos y servidores no podrán resolver nombres de internet, si tratamos de por ejemplo hacer un ping a http://www.google.com/, no obtendremos respuesta.

Figura , 13. Ping fallido a http://www.google.com/

Para resolver esta situación necesitamos que al menos uno de nuestros DNS sea capaz de resolver direcciones de internet, esto se consigue gracias a los reenviadores o forwarders.

Es importante que comprendamos que los forwarders se configuran para cada servidor DNS, esto significa que :

1) Podemos configurar forwarders en todos nuestros servidores DNS hacia unos controladores de domino concretos que tengan los forwarders hacia internet.

2) Podemos configurar todos nuestros servidores DNS para que tengan como DNS secundarios en las tarjetas de red a los servidores DNS con los forwarders activados (esta solución hace que la resolución sea mas lenta)

3)También podemos configurar forwarders en todos los servidores DNS de nuestra empresa.

La elección es vuestra, aunque a mí me gusta más la opción de configurar forwarders en todos los servidores DNS hacia dos Controladores de dominio concretos que sean los que tengan los forwarders para resolver en internet.

En las empresas pequeñas es común encontrar un solo DC que además sea el único DNS, con lo cual solo hay que configurar un servidor con forwarders.

¿Que dns de internet uso para los reenviadores?, la costumbre es usar los DNS de tu proveedor de internet, otra solución es ver que servidores DNS son mas rápidos y usarlos como reenviadores, ya que esta velocidad puede mejorar el rendimiento de tus consultas en internet.

Puedes ver la lista de DNS de los ISP en http://www.adslzone.net/dns.html o http://www.34t.com/box-docs.asp?doc=886

¿Cómo funcionan los reenviadores?, para contestar a esta pregunta veamos el siguiente diagrama.

Diagrama, 1. Funcionamiento de los reenviadores

Vemos en el diagrama que si un puesto pide resolver una dirección como por ejemplo http://www.google.com/, pasara lo siguiente:

1- El puesto se lo pide al servidor DNS que tenga configurado como primario en la tarjeta de red, ya hemos aprendido que este servidor tiene que ser un DC del dominio en el que este el puesto.

2-El servidor ve que no tiene ninguna zona google.com y por lo tanto usa el reenviador que tenemos configurado para solicitar al servidor DNS que hayamos indicado que le resuelva el registro http://www.google.com/.

3-El servidor DNS de internet resuelve http://www.google.com/ y responde a la solicitud de nuestro DC.

4-El DC cachea la respuesta para poderla responder directamente si algún puesto se la hace de nuevo.

5-El DC responde al puesto con la dirección de http://www.google.com/.

Estupendo, eso es lo que quiero!!!!! ¿Cómo configuro el reenviador?

Es muy sencillo, antes que nada te tienes que asegurar de que tu controlador de dominio sabe llegar a internet y que tu router y tu firewall le están dejando usar el puerto 53 de salida para que pueda acceder al los servidores DNS en internet.

Puedes ver si todo esto se cumple, es tan fácil como usar nslookup para probarlo.

En nuestro caso vamos a probar con un DNS de telefónica (80.58.0.33)

Figura, 14. Probando si el DC puede usar un DNS de internet con NSlookup.

Para conectarnos con un servidor DNS tenemos que usar el comando server dentro de nslookup indicando la ip del servidor.

Después podemos escribir directamente el nombre que queremos resolver.

Si esto no funciona, significa que alguna de las siguientes cosas está fallando:

1) El servidor no sabe cómo llegar a internet, tienes que indicar a tu servidor que use como puerta de enlace predeterminada al dispositivo de tu red que de acceso a internet como por ejemplo un router o un firewall.

2) Tu firewall no está dejando que el servidor salga por el puerto 53 de TCP y de UDP, tienes que configurar una regla en tu firewall que deje salir al DC por el puerto 53 de TCP y UDP.

Para configurar el reenviador o forwarder sigue estos pasos:

Figura, 15. Configurando el reenviador (1)

Figura, 16. Configurando el reenviador (2)

Puedes meter tantos servidores DNS como quieras, también puedes configurar reenviadores para dominios específicos, esta solución se emplea por ejemplo cuando se crean relaciones de confianza o hay varios forest dentro de la misma empresa.

Ahora que ya tenemos configurados los forwarders, nuestro DC ya podrá resolver nombres de internet.

Figura, 17. Probando el forwarder con NSlookup.

Una cosa muy interesante de la que hemos hablado es la cache, la cache permite que los servidores DNS guarden las resoluciones que ya se han hecho y en caso de que se le pida de nuevo a un servidor DNS una consulta que tenga en la cache, el servidor la devolverá directamente de la cache, esto acelera el acceso a internet y es muy interesante para los proxys y los servidores de correo.

Puedes ver la cache haciendo lo siguiente.

Figura, 18. Viendo la cache (1)

Figura, 19. Viendo la cache (2)

¿Entonces como funcionara el DNS si tengo varias oficinas?, si tienes varias oficinas, se pueden dar los siguientes casos:

1) La oficina es pequeña y no cuenta con un DC propio, por lo tanto los puestos tendrás configurados como DNS los DCs de la central y funcionaran como has visto hasta ahora.

2) La oficina tiene bastantes usuarios y cuenta un DC propio, en ese caso, el DC de la delegación se tendrá así mismo como DNS primario y como secundario al de la central, que cuenta con el forwarder, el funcionamiento sería el siguiente:

Diagrama, 2. Resolución en un escenario con DC en delegación.

1- El puesto se lo pide al servidor DNS que tenga configurado como primario en la tarjeta de red, ya hemos aprendido que este servidor tiene que ser un DC del dominio en el que este el puesto, en este caso además es el DC que esta en su delegación.

2-El servidor ve que no tiene ninguna zona google.com y por lo tanto usa el DNS que tiene como secundario para realizar la solicitud al DC en la central, también se puede configurar un forwarder en este servidor para que use al de la central.

3-El servidor DNS de de la central usa su forwarder para hacer la solicitud

4- El DNS de internet resuelve http://www.google.com/ y responde a la solicitud de nuestro DC en la central.

5- El DNS de la central cachea la resolución.

6- El DNS de la central responde al DNS de la delegación con los datos de la resolución.

7-El DC cachea la respuesta para poderla responder directamente si algún puesto se la hace de nuevo.

8-El DC responde al puesto con la dirección de http://www.google.com/.