martes, 28 de febrero de 2012

[Windows Server 2003R2] - Guía paso a paso de Administración de impresión


Administración de impresión para los sistemas operativos Microsoft® Windows Server™ 2003 R2.

¿Qué es Administración de impresión?

Administración de impresión es un complemento de Microsoft Management Console (MMC) que permite instalar, ver y administrar todas las impresoras de la organización desde cualquier equipo que ejecute Windows Server 2003 R2. Administración de impresión proporciona detalles actualizados al minuto sobre el estado de las impresoras y los servidores de impresión de la red. Puede utilizar Administración de impresión para establecer conexiones de impresora a un grupo de equipos cliente de forma simultánea. Administración de impresión facilita la búsqueda de impresoras con errores mediante filtros. Además, se pueden enviar notificaciones por correo electrónico o ejecutar secuencias de comandos cuando una impresora o un servidor de impresión precisen atención. En los modelos de impresora que facilitan una página Web, Administración de impresión tiene acceso a más datos como, por ejemplo, los niveles de tóner y papel, que puede administrar desde ubicaciones remotas en caso de ser necesario.

domingo, 26 de febrero de 2012

[CURSO] Preparación para el examen 101 de LPI: Hardware y arquitectura

Resumen:  En este tutorial, Ian Shields comienza a prepararlo para tomar el® Examen 101 (LPIC-1) de la Administración de Nivel Junior del Linux Professional Institute. Aquí, en el primero de los cinco tutoriales, Ian lo introduce en la configuración del hardware de su sistema con Linux™. Al finalizar este tutorial, usted sabrá cómo Linux configura el hardware que encuentra en una PC moderna y dónde deberá usted buscar la solución a cualquier problema.

martes, 21 de febrero de 2012

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


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.

Basicos: Configuración de DNS


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.

Basicos: Dominio Interno y Externo diferentes




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 articulohttp://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

Administración de redes

INDICE
  • Introducción
  • Agentes y consolas
  • Gestión de usuarios
  • Gestión del hardware
  • Gestión del software
  • Distribución de ficheros
  • Monitorización de la actividad de red
  • Planificación de procesos
  • Protección contra virus
  • Soporte de impresoras
  • Gestión del espacio de almacenamiento
  • Seguridad

lunes, 20 de febrero de 2012

Cómo funciona el servicio DNS - Parte 3 Integración con Active Directory


Luego de haber visto en la Parte 1 y Parte 2, el funcionamiento básico del servicio DNS, vamos a ver ahora, algo muy interesante como es la integración de DNS en (dentro de) Directorio Activo – Active Directory.
Una de los grandes cambios que comenzó Windows Server 2000 y que fue mejorado cada vez más con las nuevas versiones Windows 2003, Windows 2008 y Windows 2008-R2, es la posibilidad de integrar la zona en el Directorio Activo – Active Directory, vamos a ver algunas de las ventajas principales.

Cómo funciona el servicio DNS - Parte 2


DNSs Primarios, Secundarios y Master

Una de los primeros y aún vigente requerimientos en Internet es que hay que soportar tolerancia a fallas, y por lo tanto para resolver los nombres de un dominio hay que poner por lo menos dos servidores DNS, no importa si el Dominio es chico o va a recibir muy pocos pedidos de resolución
¿Se imaginan el trabajo de tener que mantener no sólo los registros creados y modificados manualmente en un servidor sino en por lo menos dos?
Bueno, esto se solucionó, hay un servidor que mantiene una base (la Zona) con privilegios de Lectura y Escritura, y periódicamente le transfiere los datos (transferencia de Zona) a uno o más servidores DNS. Estos últimos sólo tienen permiso de Lectura sobre la Zona.
De esta forma cualquiera tiene los datos para responder, pero los cambios se realizan sólo una vez.


Cómo funciona el servicio DNS - Parte 1

En una red con Windows y TCP/IP, cada máquina tiene en realidad dos nombres: uno llamado "Nombre NetBIOS" y otro llamado "Hostname". Estos nombres son asignados a los equipos durante la instalación, y son usados tanto por las aplicaciones como por los que usamos los equipos y recursos de la red.

En sistemas Pre-Windows 2000, el nombre que se le asigna a una máquina durante la instalación es el "Nombre NetBIOS", este tiene una longitud máxima de 16 caracteres, aunque sólo son utilizables 15, pues el dieciseisavo tiene uso reservado. Admite algunos símbolos (por ejemplo "_"). Pero si vamos a las propiedades de TCP/IP vemos que también tiene asignado un "hostname" que por omisión el sistema trata que sea igual al "Nombre NetBIOS".

A partir de Windows 2000, en cambio, el nombre asignado durante la instalación es el "hostname" que puede tener hasta 255 caracteres (Microsoft soporta hasta 24), pero que es mucho más restrictivo ya que sólo puede contener letras, números y el signo "-". En estos sistemas si miramos en el lugar donde se cambia el nombre, notaremos que también existe un "Nombre NetBIOS" pero que no lo podemos cambiar separadamente del "hostname".

De cualquier forma, y esto es importante, en una red TCP/IP siempre que nos referimos a un equipo usando alguno de estos nombres, el sistema necesita obtener qué dirección IP corresponde a dicho nombre. A este proceso se lo llama Resolución de Nombres.

Existen métodos para resolver "Nombre NetBIOS" y métodos diferentes para resolver "hostnames". Si no tiene muy claro el concepto es interesante que veaResolución de Nombres de Máquina (DNS, WINS, HOSTS, LMHOSTS, y etcéteras)

En esta nota trataré de ver con cierto nivel de detalle la resolución de "hostname" lo cual nos lleva indefectiblemente a cómo trabaja el servicio DNS.

¿Lo hacemos como un cuento para que sea más ameno? Winking smile Bien, si nadie dice nada lo haré así Smile. Había una vez… un grupo de gente muy estudiosa trabajando con las primeras redes TCP/IP que cuando necesitaban acceder a otro equipo lo identificaban directamente escribiendo la correspondiente dirección IP, y eso funcionaba perfectamente.

Si, funcionó perfectamente hasta que se fueron agregando más y más máquinas y ya era difícil recordar esos números (dirección IP) para cada uno de los equipos. A partir de eso se buscó algo que fuera más fácil de recordar: un "alias" o "apodo" para cada máquina ya que eso es mucho más fácil para que un humano lo recuerde. Y así nació el hostname

Luego en cada máquina se debía tener un archivo de texto que especificara qué dirección IP correspondía a cada alias (hostname). Esto es el archivo HOSTS. Este es un método muy eficiente para resolver nombres, pero tiene el inconveniente que hay que tenerlo y actualizarlo en cada máquina.

Mientras Internet, o en ese entonces Arpanet, eran pocos equipos y con muy poca variación esto fue una solución. Según se cuenta, en el MIT (Massachusetts Institute of Technology) se mantenía el archivo HOSTS central. Bastaba que cuando se agregaba o cambiaba un equipo se avisara, y que periódicamente uno se trajera una copia actualizada y la distribuyera entre sus equipos. Supongo que a esa altura la NASA debía tener como cinco computadoras Smile

Esto era muy bueno, pero a medida que siguió creciendo, se fue poniendo cada vez más difícil el mantenimiento del HOSTS central por su tamaño, y como si fuera poco comenzaron los problemas por la colisión de nombres, no podía haber dos máquinas con el mismo hostname.

Cómo se solucionó esto. La solución pasó por dos puntos fundamentales:

  • Descentralizar la administración
  • Armar una estructura jerárquica que solucionara las colisiones de nombres

Así nació DNS (Domain Name System o Domain Name Server)

En ese momento ya habían varias empresas comerciales incorporadas, como así también agencias gubernamentales, universidades, etc. Por lo tanto se convino en que cada una de ellas debía mantener un servidor de nombres (Name Server) que "resolviera" sus propios nombres.

Luego los clientes tenían configurado que cuando tuvieran que "resolver un nombre" le preguntaran a su servidor de nombres (Name Server). Mientras el administrador local se ocupara de mantener manualmente sus propios "mapeos de nombre" todo funcionaba perfectamente dentro de la propia organización . Esta base de datos donde se anotan los nombres y su correspondiente dirección IP, se llama ZONA.

Hasta acá todo bien, pero sólo se resuelve dentro de la propia organización, entonces ¿cómo se hace cuando se quiere acceder a un equipo que esté en otra empresa u organización? Bien, para resolver esto se dispuso poner un servidor de nombres que se encargara de resolver *solamente* los servidores de nombres de cada organización. Y estos últimos debían conocer a este "servidor de nombres padre".

Entonces funcionaría de esta forma, cuando un cliente tiene que resolver un nombre, se lo pregunta a su servidor de nombres, si éste lo puede resolver utilizando su propia ZONA, responde según se dice en forma Autoritaria o Autoritativa, pues tiene los datos localmente. Pero si no tuviera los datos localmente entonces le preguntará al "servidor de nombres padre" para saber qué servidor de nombres en particular le puede dar la respuesta.
Este "servidor de nombres padre" le indicará al "servidor de nombres local" a qué "servidor de nombres" debe preguntarle para obtener la respuesta final.

Así como está planteado hasta ahora, todo funcionaría, pero por variadas razones se hizo un poco más complejo, no mucho no asustarse. En lugar que todo el mundo tuviera un único "servidor padre" se agruparon por rubro. Es de decir el que resolvía los que eran nombres comerciales se agruparon en uno, los gubernamentales en otro, los educativos en otro, etc. etc. Arriba de todos estos, si había un "único padre".

Con un poco de imaginación vemos que estamos construyendo un árbol, o más precisamente las raíces de un árbol. Todos las organizaciones comerciales "colgando" de un servidor de nombres que "maneja los COMerciales", y otras organizaciones gubernamentales"colgando" del que "maneja los GOVernamentales", y educativas "colgando" del que "maneja los EDUcativos", etc. Y por arriba de todo, o sea el que conoce quienes son los que manejan a los COMerciales, GOVernamentales, EDUcativos, etc. hay un servidor de nombres que sabe quiénes son estos últimos.

Bueno, a esta altura paremos con los cuentos y vamos a cosas más reales. Cada "nudo" de este árbol invertido que estamos haciendo se llama Dominio de DNS o Dominio de Internet. Más adelante daremos una mejor definición.

En la parte inferior tenemos los dominios, por ejemplo: hp, microsoft, ibm, etc. que "cuelgan" del dominio "com"; nasa, whitehouse, etc. que "cuelgan" del "gov"; purdue, mit, etc. que "cuelgan" de "edu"; y podemos seguir con los diferentes grupos, que cada uno ya se imagina: org, net,mil y el que cada país tiene a este nivel (ar, es, mx, etc.)

Arriba de cada uno de esos dominios de primer nivel hay otro servidor de nombres que sólo conoce quienes son los servidores de com, gov, edu, etc.

Lo que tuvieron problemas es para designar el nombre de este dominio raíz, no hubo forma de ponerse de acuerdo, por lo que quedó sin nombre (un poco de humor). Es verdad se llama con el carácter nulo, pero como los humanos no lo podemos representar y no lo podemos ver se lo representa por un punto (.)

Como cada organización es responsable y debe mantener la resolución de nombres de su dominio, entonces cumplimos el primer objetivo que es distribuir el mantenimiento

Vamos ahora a ver cómo se evitan las colisiones de nombres.

Cada máquina (usemos la palabra host para ser más técnicos) necesita identificarse dentro de este árbol en una forma única (unívoca). Y esto se logra mediante el "camino" que va desde el propio host hasta el dominio raíz. Así por ejemplo un host que está en el sitio de hp y tiene hostname "server1" se identifica como: "server1.hp.com." (si, con punto al final) y otro que también se llame server1 pero que esté en el MIT, se llamará "server1.mit.edu. ".

Este nombre que identifica unívocamente cada host en el árbol se llama FQDN (Fully Qualified Domain Name) que todos los usamos cuando escribimos un URL de Internet, aunque no sepamos que esa parte se llame así.

Aunque nadie pone el punto final de un FQDN, todas las aplicaciones lo dan por descartado y funcionan bien. Más, cuando más adelante veamos el contenido de una Zona, veremos que el sistema agrega el "." aunque no lo escribiéramos.

Llegó el momento de poner las cosas en su lugar y ver cómo funciona esto. Vamos a suponer que en este momento se pone todo en funcionamiento, o sea que no hay ninguna información almacenada en memoria de ningún equipo, solamentelo que tenga en su propia zona.

Cada servidor de una organización conoce solamente los nombres de su propia organización, y la dirección IP del (los en realidad) servidores del dominio raíz.
El (los) servidor del domino raíz conoce sólo los DNS que tiene justo "abajo", o sea primer nivel (.com, .edu, .mil, .ar, .mx, etc.)
Y los servidores de primer nivel sólo conocen a los DNS de cada organización.

En la situación anterior, un usuario en, supongamos, hp quiere acceder aserver1.microsoft.com. Por lo tanto en el equipo cliente un componente software llamado Resolver se encarga de preguntar al DNS que tenga configurado para que le diga qué dirección IP tiene dicho host. Los Resolvers suelen ser de mal carácter (humor) así que la pregunta es algo así como: "dime que IP tiene server1.microsoft.com o dime que no sabes, no acepto referencias o medias respuestas) A esto tipo de pregunta se la llama Recursive Query, exige respuesta concreta por sí o por no.

Como el servidor DNS de hp no tiene localmente en su propia zona nada de microsoft.com sale a buscar al único DNS externo que conoce, el DNS del dominio raíz. Las preguntas que hacen los servidores DNS a otros DNS generalmente son de tipo Iterative Query (Dime lo más que puedas, acepto referencias).Este le va a responder con una referencia, que es lo más que puede; algo así como "preguntale al servidor de com", por lo tanto el servidor DNS de hp ahora le pregunta al de "com" quien le dirá que pregunte al de microsoft que finalmente dará la respuesta solicitada, al servidor DNS de hp, que devolverá el dato correspondiente al cliente que originó todo, y que finalmente podrá hacer la conexión correspondiente.

Cada pregunta que hizo el servidor DNS para resolver el pedido del cliente, recibió conjuntamente con la respuesta, un parámetro denominado TTL (Time To Live) que corresponde a cuánto tiempo puede tener la información en memoria y considerarla válida (cachear que le decimos)

Dentro del tiempo de los TTLs, si otro cliente repite la pregunta, el DNS devolverá la información correcta sin necesidad de ir a buscar afuera. O inclusive si le preguntaran por serve1.microsoft.com podría preguntar directamente al DNS de microsoft.com. O inclusive si le preguntaran por server.ibm.com no comenzaría por el raíz, sino directamente por el DNS de com.

Esto ya está demasiado largo, así que quedará para otra nota, un poco más de DNS, específicamente los temas de zonas primarias y secundarias, tipos de registros SOA, NS, A, etc. y supongo que para una tercera parte, la integración de DNS con Active Directory.


sábado, 18 de febrero de 2012

[Truco] Activar / Desactivar cuenta de Administrador en XP

Activar la cuenta Administrador en Windows XP / Vista:

Abrimos una ventana de linea de comandos (CMD) con privilegios de administrador.

Una vez abierta la ventana de comandos, ejecutar el siguiente:

net user administrador /active:yes

Para desactivar la cuenta ejecutar los siguiente:

net user administrador /active:no

sábado, 11 de febrero de 2012

[Appliance] Redmine + Apache + Phusion Passenger + Ruby Enterprise usando Ubuntu JeOS

En posts anteriores se ha visto cómo optimizar una máquina de VMware en menos de 5 minutos, cómo instalar Ubuntu JeOS (que no trae entorno gráfico) y manejarlo con Webmin, asi como las opciones más importantes a tocar para que no haga falta tocar el sistema.

viernes, 10 de febrero de 2012

Como modificar claves y valores del registro usando la línea de comandos y archivos batch.

Mediante la línea de comandos es posible modificar, editar y cambiar cualquier valor o clave del registro de Windows sin tener que utilizar la herramienta Regedit. Aunque el método más fácil y practico es crear un archivo REG para agregarlo al registro, existe siempre la alternativa de la línea de comandos, que en ocasiones es el método ideal o el único posible, por ejemplo en casos que no hay acceso a Regedit o para crear aplicaciones ejecutables o archivos batch en las que la función que deseamos ejecutar requiere la modificación de un valor en el registro.

domingo, 5 de febrero de 2012

MIKROTIK: Filtro de contenido con OpenDNS

Antes que nada, tengo que reconocer que a RouterOS le falta mucho en lo que a filtro de contenido se refiere. Si bien incorpora Web Proxy, el cual lo podemos usar para filtrar contenido no deseado, siempre se nos va a escapar algún sitio web, dado que no filtra por el contenido del sitio solicitado, sino por la URL del mismo.