Relación de confianza

Aprovechando que mi vida estos dos últimos meses ha dado un pequeño giro y he vuelto a mi pasado de técnico con esas noches sin dormir, ese problema que nadie más ha tenido, que no existe en Google etc. y que los reyes me han traído un flamante equipo nuevo ya ahora estoy 100% movilizado. Vamos a ver si me animo y retomo el tema, aunque como ya avanzo me temo que será por poco tiempo. Desgraciadamente a mi vuelta a España me volveré a alejar de esta ilusión de mi relación con la tecnología.

Bueno, para la vuelta aunque tengo muchas cosas que contar ya que el proyecto que estamos llevando a cabo es bastante complejo os contaré como recuperar la relación de confianza entre un equipo (puede ser un equipo de un usuario o un servidor, no importa) y un dominio de Directorio Activo.

El punto es muy sencillo, cuando tenemos estos errores suele ser por que bien el equipo ha estado mucho tiempo desconectado del controlador, o por que el usuario ha hecho alguna barbaridad (o el técnico, que también). 

Como sabéis un equipo es un objeto dentro de directorio activo, al igual que puede ser un nombre de usuario (o más correctamente un usuario), y este como tal necesita servicios del directorio activo (oyes como me llamo, como se llama el dominio, dame una ip, etc.) y para mantener la seguridad el sistema lo que hace es que este objeto equipo, le asigna un nombre de usuario y contraseña, como a los usuarios. 

El nombre del equipo es sencillo, es como lo llamáis cuando instaláis WINDOWS, si no os acordáis podéis mirarlo en Mi PC (botón derecho, propiedades, y ahí está) o bien con un "ipconfig /ALL", os pego la imagen que queda más friki ;-)

Bien, en este caso ya tenemos el nombre del host, que es "AmSTablet", el primer paso será buscar el equipo en el directorio activo (esto ya para otro día), una vez que lo tenemos hacemos click sobre el objeto con el botón derecho del ratón, y tenemos una opción que dice restaurar contraseña. Hacemos click.

Con esto, el directorio activo ha "roto" la confianza definitivamente ya que ha cambiado la contraseña del objeto equipo, y el equipo no sabe cual es. Los siguientes pasos los realizaremos sobre el propio equipo. Para ello nos vamos a la pantalla de añadir/quitar equipo del dominio.

¡Atención! y esto es muy importante, aseguraros de conocer la contraseña de un usuario local del equipo con permisos de administración, o si la cosa no va bien tendréis auténticos problemas.

Bien, una vez con la pantalla de unir al dominio lo que vamos a hacer es justo lo contrario, elegiremos un grupo de trabajo, no importa el nombre, y nos pedirá las credenciales de un usuario de dominio para hacer ese trabajo (separarlo del dominio). No hará toda la parafernalia que ya conocemos, pero OJO, no reiniciemos el equipo aunque nos lo diga. Sin salir de la misma pantalla, volvemos a hacer el paso inverso, y unimos de nuevo el equipo al dominio. Esta vez si reiniciaremos el equipo.

Si todo ha ido bien, podremos comprobar en el visor de sucesos que el equipo ya tiene su relación de confianza, y todos esos mensajes feos, ha desaparecido.

Espero que os sirva. Disfrutar.

Saludos.

Esto se termina...

Hola a todos tras un año desconectado.

Ha sido un año de muchos cambios en mi vida tanto laboral como personal y he estado muy falto de tiempo y la verdad también de ganas. De hecho en varias ocasiones me he planteado seriamente cerrar el blog, y la verdad es que aun no he tomado una decisión sobre el destino final.

El origen de este blog era contar mi día a día como técnico de sistemas, que problemas me enfrentaba en mi trabajo diario y como los solucionábamos. Con el objeto de ayudar a otros que o bien por tiempo o por tener menos experiencia pudieran necesitarlo.

Pero desafortunadamente (para este blog) mi vida dio un cambio en Marzo del año pasado dejando de lado mi gran pasión por el mundo IT y reorientando mi actividad laboral más hacía el área comercial de proyectos en  una gran compañía. Si es cierto que requiere un importante componente técnico pero de ninguna manera del modo que tenía antes. Podemos decir que aquí leo algún articulo según la necesidad del cliente, rozamos la tecnología, y nos focalizamos en vender proyectos. Eso si, mucha metodología, comunicación con el cliente, seguimiento, etc. Un rollo en definitiva.

Bueno, al menos hasta final de año el blog permanecerá vivo y coleando así que si alguien quiere mantener algún articulo que lo copie, por que es posible que este blog muera con el año.

Gracias a todos los que alguna vez habéis enviado un comentario o agracedimiento. No sabéis lo que eso ha significado.

Gracias.

Configuración de una tarjeta de red en un Cluster Hyper-V

Anoche nos tocaba realizar una intervención de las teoricamente sencillas, pero que en nuestro mundo nunca son sencillas y al final se terminan complicando. Básicamente tenemos un cluster de Hyper-V con 4 máquinas virtuales en dos Hosts con Win2k8 R2 Enterprise. Cuando hicimos las pruebas en laboratorio todo fue perfecto y la máquina virtual con la que hicimos experimentos de caidas etc. funciono sin problemas.

La intervención en uno de los hosts implicaba apagarlo, para ello decidimos que moveríamos todas las máquinas virtuales al otro host y listo. Pues nada, a darle al botoncito del "Quick Migrate" todo fue bien, hasta que de repente una de las máquinas (la más improtante para variar) decidió que :

'Virtual Machine XXXX03' failed to start

Nada, a dar vueltas, nos hemos equivocado en el calculo de memoria, de cores, pero nada todo correcto, una vuelta por los visores de sucesos y nos encontramos con estos errores:


Ummmm, vaya, parece que algo en la red no va demasiado bien, revisamos los datos de tarjetas, de los switches, la visibilidad, etc. Aparentement todo correcto, una pequeña investigación nos llevo a ver que cuando tienes un cluster en Failover en Hyper-V las mismas herramientas que tienes en la MMC de Hyper-V las tienes en la caracteristica de Failover (vamos ya lo sabiamos pero siempre pensamos que eran identicas), pero una pequeña prueba (de las que mi profesor de matemáticas llamaba de idea feliz) hizo que al entrar en la configuración de la máquina virtual pero usando la herramienta de Cluster de repente la configuración de la red aparece como "Erronea", simplemente un cambio en la configruación de la red usando esta herramienta:


Una investigación por el Technet de Microsoft nos llevo a decubrir que es imperativo que la configuración de cualquier parametro de una máquina virtual que pertenezca a un cluster se debe llevar a cabo desde la herramienta de cluster no desde la MMC de Hyper-V u ocurrirán cosas como estas.

Estás advertido, disfruta.

Componentes de integración en máquinas CentOS 5 o superior

Hoy vamos a dar el pequeño detalle para la instalación de los componentes de integración de Hyper-V en las máquinas Linux basadas en CentOS 5.4 o superior. Lo primero que debemos hacer es actualizar nuestro kernel y librerías a las últimas versiones, para ello desde nuestra máquina virtual ya instalada y configurada (por supuesto con adaptador heredado, ya que el sintetico no funcionará) ejecutamos el siguiente comando:

yum update

Esto nos validará todas las actualizaciones, que aceptaremos, instalaremos, y reiniciamos la máquina con el último kernel disponible.
Ahora vamos a necesitar las últimas Herramientas de Integración de Hyper-V que a fecha de hoy las tienes aquí para descargar.

Bien, ejecutamos el ejectuable, valga la redundancia, y esto nos deja en un directorio una imagen .ISO que montaremos para la máquina virtual.

Para montar la imagen usaremos este comando:

mkdir /mnt/cdrom
mount /dev/cdrom /mnt/cdrom
cd /mnt/cdrom

Si no tenemos instaladas las herramientas de desarrollo en nuestro sistemas usaremos el repositorio de CentOS para hacerlo:

yum groupinstall "Development Tools"

Creamos el directorio donde instalaremos las herramientas y copiamos todos los archivos del CD-ROM a este directorio:

mkdir /opt/LinuxIC
cp -R /mnt/cdrom/* /opt/LinuxIC
umount /mnt/cdrom

ahora simplemente iremos a compilarlas:

cd /opt/LinuxIC
make
make install

Al ejecutar el make debemos fijarnos que no nos de error alguno, sino el make install no tendrá sentido. Con esto habríamos terminado. Si estamos utilizando la versión x64 de CentOS necesitamos un pasito más, para ello montamos el CD-ROM de CentoOS número 1, e instalamos el paquete "adjtime":

mount /dev/cdrom /mnt/cdrom
rpm –ivh /mnt/cdrom/Centos/adjtimex-1.20-2.1.x86_64.rpm

si no tenemos el CD-ROM podemos hacerlo con el comando yum:

yum install adjtimex.i386

Si queremos finalmente validar que todos los componentes de integración están funcionando, lo podemos comprobar con el siguiente comando:

/sbin/lsmod | grep vsc

Un último comentario, recordar que los dispositivos de red de los adaptadores sinteticos son denominados sethX, donde X es el número de interfaz, por ejemplo eth0 se convierte en seth0.

Hasta la próxima.