Cómo restablecer contraseña olvidada de VM en Azure

Bien, en esta ocasión veremos una forma rápida y sencilla para restablecer la contraseña olvidada de una máquina virtual en Azure, es más común de lo que parece olvidar una contraseña de alguna máquina en Azure, y el problema radica en que si olvidamos la contraseña de qué otra forma podemos ingresar, ya que el único acceso que tenemos normalmente es por RDP, veremos como restablecerla desde el portal de vista previa, ya que el portal clásico no ofrece esta opción.

Existe otra forma de restablecer la contraseña y es mediante el agente de máquina virtual (VMAccess), que viene seleccionado por defecto al crear una máquina virtual (ver imagen), pero esta opción la explicaré en otro artículo, empezaré con esta ya que resulta más rápida y sencilla.

Una vez ingresamos al portal de azure (manage.windowsazure.com), hacemos clic en elnombre del usuario de la suscripción, en la parte superior derecha de la pantalla, del menú que se despliega seleccionamos la opción Cambiar al portal de vista previa de Azure

Se abrirá una nueva página con el portal de vista previa, de las opciones de la izquierda seleccionamos Máquinas virtuales (clásico), ya que la máquina fue creada desde el portal clásico.

Aparecerá la lista de máquinas que tengamos desplegadas, en mi caso solamente tengo una llamada SRV01.

seleccionamos la máquina para que nos aparezcan todas las acciones que podemos realizar sobre la misma, y en la parte de Configuración podemos observar la opción Restablecimiento de contraseña

Ahora simplemente proporcionamos los datos para restablecer la cuenta administrador integrada, no importa si no recordamos el nombre, simplemente si especificamos otro distinto será renombrada la cuenta, en mi caso la cuenta se llama cherrada ahora la llamaré nuevoadmin y le pondré una nueva contraseña.

Ahora, intentaré el ingreso por RDP con los nuevos datos.

Vemos que efectivamente me ha aceptado las nuevas credenciales de administrador local.

El inicio en mi VM ha sido exitoso, ahora si revisamos la consola de Usuarios y Grupos locales podemos observar la cuenta de administrador integrada ya renombrada.

Bueno amigos, esto es todo, espero esta información les sea de utilidad. Hasta la próxima!

Azure Active Directory y sus diferencias con Windows Active Directory

Para muchas personas no es clara la diferencia que existe entre Azure Active Directory y Windows Active Directory.

A primera vista se puede pensar que Azure Active Directory es el mismo Active Directory que conocemos en el mundo on-premise con la diferencia de que se encuentra en la "nube", es decir; en Microsoft Azure, pero esto en realidad no es así, y precisamente ese es el objetivo de este artículo, comprender las diferencias que existen entre los dos, iniciemos explicando lo que es el Active Directory on-premise que ya conocemos.

Windows Active Directory 

Generalmente se encuentra aislado del resto del mundo.

Si se requiere comunicación con el mundo externo se hace necesario abrir una gran cantidad de puertos para lograrlo, y posiblemente nos enfrentemos a conflictos de DNS de Internet y nuestra zona interna.

Azure Active Directory

Azure Active Directory (AAD), es un servicio basado en la web de gran escala para la administración de identidad y acceso, éste servicio se encuentra alojado en los centros de datos de Microsoft, y nos permite gestionar todo lo relacionado con identidades, acceso a aplicaciones, auditoria, reportes, autenticación multifactor, y regularmente se agregan nuevas características y posibilidades.

Aunque su nombre es similar al Active Directory que ya conocemos, AAD NO son instancias de Windows Server Active Directory en controladores de dominio ubicados en los centros de datos de Azure, Aunque tiene algunas similitudes tales como:

• Usuarios
• Grupos
• Contenido que se replica

Pero carece de otras cosas típicas de Windows Active Directory (AD), como:

• Unidades Organizativas (OUs)
• Sitios
• Unión de equipos al dominio (aunque Windows 10 permite usar una cuente en Azure para autenticarse, similar a como se hace hoy en día con las cuentas Microsoft.)
• GPOs

¿Porqué necesitamos Azure Active Directory?

Hoy en día con la explosión de la nube las cosas han cambiado, los modelos a los cuales veníamos acostumbrados se han quedado atrás y ya se consideran obsoletos, me explico un poco mejor.

Las aplicaciones in-house cada vez pierden más sentido, el mantenimiento se hace más complejo, si se hacen cambios en la aplicación, se hacía necesaria la actualización de la misma, generalmente mediante paquetes que entrega el proveedor de la misma, y en algunos casos eran enviados incluso en CDROM.

El día de hoy, muchos proveedores de aplicaciones están migrando sus servicios a la nube, para ofrecer sus productos de software como servicio (SaaS), con esto el proveedor hace los cambios que requiera la aplicación en un solo lugar, y de inmediato todos sus clientes disfrutarán del cambio de manera automática.

Veamos un ejemplo de la utilidad de AAD.

Un proveedor de una aplicación corporativa que funciona en la intranet, y en un momento dado el proveedor decide llevar su aplicación a la nube, en ese momento requiere que cada usuario de la aplicación tenga un juego de credenciales (user/password) para poder ingresar a su aplicación recién alojada en la nube.

La siguiente imagen muestra el escenario antes de que el proveedor migrará su aplicación a la nube, con el fin de ofrecer el servicio de la misma a otras empresas, ya "montado" el proveedor en al nube, pronto la aplicación on-premise que utiliza autenticación contra un AD local dejará de ser mantenida por el mismo.

                                                                 Aplicación on-premise

Una vez la aplicación fue llevada a la nube el usuario no podrá utilizar sus credenciales de red, es decir; no podrá autenticarse contra AD, en su lugar deberá tener un juego de credenciales que se almacenará probablemente en una base de datos en los servidores alojados en la nube donde se aloja ahora la aplicación, tal como se muestra en la siguiente imagen:

                                                              Aplicación en la nube (SaaS)

Lo anterior obliga a que el usuario tenga que memorizar otro juego de credenciales diferentes a las de red para ingresar a la aplicación, y lo mismo tendrá que hacer no solo con esta aplicación sino con cualquier otra que aplicación externa que el usuario necesite.

Ahora el proveedor de la aplicación toma la sabia y excelente decisión de integrar su aplicación con AAD

¿Porqué es una buena decisión?, porque el usuario podrá autenticarse en la aplicación en la nube pero utilizando las mismas credenciales de red. Con esto si el usuario se retira de la compañía, el administrador simplemente deshabilita el usuario en Active Directory local, y este cambio se replicará hacia AAD, lo cual impide que el usuario siga ingresando a la aplicación, se tendrá un manejo centralizado de las identidades y para todas las aplicaciones sin importar que la aplicación se encuentre fuera de la red corporativa.

Aplicación integrada con Azure Active Directory (AAD)

Como se puede apreciar en la imagen anterior, el usuario inicia sesión en la aplicación utilizando las mismas credenciales de la red corporativa, gracias a que dichas credenciales están siendo sincronizadas desde el AD local hacia AAD. ¿ahora tiene más sentido? en lugar de estar administrando identidades separadas para cada aplicación o servicio, se administran todas desde una sola ubicación, con esto los beneficios son grandes:

• El proveedor de la aplicación administra y actualiza la misma, adiciona mejoras, etc.
• Las credenciales son las mismas de red y son administradas por TI en Active Directory local
• Las aplicaciones están disponibles desde cualquier dispositivo (Smartphone, Tablet, PC)

En el portal de Azure, podemos encontrar cientos de aplicaciones que se integran con AAD listas para usar.

¿Se puede interactuar con AAD como se hace con AD mediante LDAP?

No es posible, LDAP no está expuesto externamente, pero para consultar, leer y escribir en AAD, se puede hacer uso del módulo de PowerShell para Azure Active Directory o utilizar la interface Graph-API basada en REST

Al tratarse AAD de un servicio web la forma de consultar cambia, mientras una típica consulta LDAP en Active Directory luce como la siguiente:

(&(objectCategory=person)(objectClass=user)(cn=Cesar Herrada)

La misma consulta en AAD utilizando Graph luce así:

GET https://graph.windows.net/azurecloud.la/Users?$filter=displayName eq 'Cesar Herrada'&api-version=2013-04-05

¿Se puede tener una réplica de Active Directory local en Azure?

No es posible tener una réplica más allá de lo que mencionamos anteriormente, es decir; la sincronización de usuarios, contraseñas y grupos.

Lo que SI podemos tener es una réplica de un controlador de dominio on-premise en Azure el cual se encuentra conectado al centro de datos local a través de una conexión VPN, en este caso Azure lo podemos ver como un sitio más de Active Directory, como si se tratase de un sitio externo, por ejemplo para escenarios de recuperación de desastres.

Del mismo modo, podemos tener una instancia de máquina virtual (VM) en Azure, y le instalamos los servicios de dominio de Active Directory para convertirla en un controlador de dominio, en este caso no tenemos conexión alguna con el sitio on-premise. Este escenario es ideal para temas de desarrollo y prueba de aplicaciones.

En resumen, tenemos las siguientes posibilidades:

Sincronización de contraseñas

Permite la sincronización de usuarios y sus contraseñas a AAD

Sincronización de Identidades con federación

Con identidad federada se requieren los servicios de federación de Active Directory, para la autenticación, la aplicación en la nube enviará la solicitud al servidor de federación, quién emitirá un token para el usuario si las credenciales son validas.

Conexión entre red local y red de Azure

En este caso tenemos la red local de nuestro centro de datos conectada a la red de Azure donde se encuentra un controlador de dominio, esto se hace a través de una VPN

Directorio independiente en Azure

En este escenario no existe conexión alguna entre el directorio local y AAD, se trata simplemente de un controlador de dominio aislado montado sobre una instancia de máquina virtual en Azure, el cual provee autenticación a cualquier aplicación en la nube que lo requiera.

¿Cómo se administra Azure Active Directory?

Algo muy común que podemos preguntarnos es cómo se administra AAD, se puede utilizar la clásica consola Equipos y Usuarios de Active Directory, la respuesta es no, la administración de los usuarios se hace desde la sección Active Directory del portal de Azure, y claramente también se puede hacer desde PowerShell utilizando el módulo destinado para ello, a continuación se muestra la administración hecha desde el portal de Azure.

E incorpora algunas  herramientas para administrar los usuarios

Pero claramente, muchas cosas se pueden seguir manejando de manera local y serán replicadas a la nube, por ejemplo el cambio de una contraseña, creación de un usuario, cambio de una descripción, pueden ser trabajados localmente en Active Directory y luego serán sincronizados.

¿Azure Active Directory maneja Kerberos, NTLM y otros protocolos?

AAD es un servicio basado en la web que admite múltiples dispositivos, múltiples plataformas, por lo cual no se basa en los mismos protocolos con los que estamos familiarizados en el mundo on-premise, en su lugar se usan protocolos basados en la web tales como: SAML 2.0, WS-Federation, OAuth, OpenID, REST Graph, entre otros.

Básicamente podemos concluir que Azure Active Directory es un servicio orientado específicamente al tema de autenticación de aplicaciones basadas en la nube, mientras que Windows Active Directory, es orientado especialmente al mundo on-premise, ya que además de el manejo de identidad y acceso permite la administración centralizada de cambios y configuraciones en una red basada en Windows.

Espero con este artículo haber aclarado algunas de las diferencias que existen entre el Active Directory local y el de la nube, y claramente también se pretende resaltar las características de AAD y entender que se trata de una pieza clave si queremos llevar o desarrollar nuestras aplicaciones en la nube.

Restaurar carpeta compartida NETLOGON

En un controlador de dominio con Windows Server 2012 R2, al ingresar por ruta UNC no aparece el recurso compartido Netlogon, únicamente se puede apreciar la carpeta Sysvol , tal como se muestra en la siguiente imagen.

Bien, para restaurar el recurso compartido Netlogon, se deben realizar las siguientes tareas.

1. Abrir el editor del registro (regedit.exe) y expandir la siguiente rama:

   HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

Ubicar la llave SysvolReady podemos apreciar que su valor se encuentra establecido en 1

Edite el valor y cámbielo por 0 y luego clic en OK

Lo editamos nuevamente, y dejamos el valor otra vez en 1 y hacemos clic en OK

Después de este cambio, cerramos el editor del registro y volvemos a revisar los recursos compartidos en el controlador de dominio.

Como se puede apreciar, el recursos compartido Netlogon se ha vuelto a crear.

Y esto es todo amigos!

Fuente: https://support.microsoft.com/es-es/kb/947022

Automatización: Programar encendido y apagado de máquinas virtuales en Azure

En este artículo veremos como utilizar la potente herramienta de automatización que incorpora Microsoft Azure, la cual utilizaremos para apagar y encender todas las máquinas virtuales en una suscripción de Azure, el apagar todas las máquinas sin ir una por una y hacerlo a determinadas horas, resulta especialmente útil en escenarios donde deseamos ahorrar créditos y no queremos que nuestras máquinas queden encendidas durante largas jornadas de tiempo consumiendo de nuestra tarjeta y máxime si las máquinas no están haciendo nada, así que veamos como automatizar la tediosa tarea de apagar las máquinas, y de paso también veremos como automatizar el encendido.

Lo primero que debemos hacer es crear una cuenta de organización del tipo @algo.onmicrosoft.com, esta cuenta debe tener permisos de co-administrador

En este caso cree una cuenta llamada auto cuyo nombre de usuario es auto@cesarherrada.onmicrosoft.com, La vamos a necesitar más adelante.

Ahora seleccionamos la característica Automatización del panel de la izquierda en el portal.

Nos indica  que no existe ninguna cuenta de automatización, entonces hacemos clic en Crear una cuenta de automatización

Indicamos el nombre de la cuenta y la región donde deseamos crearla.

Una vez creada, ingresamos a la misma y veremos varias opciones en el menú de la parte superior, seleccionamos Activos

En las opciones de la parte inferior del portal hacemos clic en Agregar Configuración

En Agregar Configuración seleccionamos la opción Agregar Credenciales 

Esto nos permitirá crear y almacenar las credenciales que utilizaremos para ejecutar los flujos de PowerShell que se encargan de encender y apagar las máquinas (recordemos que la cuenta a utilizar fue lo primero que creamos).

En Tipo de Credenciales seleccionamos Credenciales de Windows PowerShell del cuadro desplegable

Y en el cuadro Nombre ponemos el nombre que llevará este activo y a el cual debemos referirnos más adelante, en este caso lo he llamado Azurecloud

En el siguiente paso es donde debemos especificar la cuenta que hemos creado al inicio y su respectiva contraseña.

Al finalizar, veremos que el nuevo activo ha sido creado satisfactoriamente.

Ahora, volvemos a la página principal de automatización, y veremos que como parte de la introducción a esta característica tenemos la posibilidad de importar runbooks desde una galería, estos runbooks son como los scripts o flujos de trabajo de PowerShell que hacen posible la automatización.

Presten especial atención a la lista de la izquierda, existe una gran variedad de categorías para explorar, en nuestro caso vamos a seleccionar la categoría VM Lifecycle Management y de la lista de runbooks trabajaremos con los dos que se encuentran encerrados con rojo, se trata de los runbooks para programar el encendido y apagado de máquinas virtuales, voy a empezar con el de apagado, el que tiene la palabra "stopping"

Al seleccionarlo, nos mostrará la definición del runbook, es decir, el código de PowerShell básicamente.

Ahora nos solicita un nombre, dejaré el nombre por defecto Stop-AllAzureVM, en Cuenta de Automatización seleccionar la recién creada, luego la suscripción y región deseadas.

Finalizamos, y veremos en la barra de notificaciones el siguiente mensaje:

En el mensaje podemos hacer clic en el botón Editar Runbook para configurarlo

Vamos a la opción Autor donde encontraremos otras dos opciones Publicado y Borrador, todos los runbooks permanecen en estado de borrador hasta que no los revisemos, ajustemos y una vez ajustados e incluso probados podemos publicarlos para que sean puestos en producción, así que por ahora haremos clic en Borrador

En el borrador debemos cambiar dos partes y ajustarlas a nuestros datos, estas son Name y SubscriptionName, específicamente las líneas 32 y 39 donde debemos poner el nombre del activo que creamos con las credenciales y el nombre de la suscripción.

Ya editado, podemos probarlo antes de publicarlo, para ello hacemos clic en prueba en laparte inferior.

Se debe producir la siguiente salida indicando que la operación fue exitosa.

Nota importante: Mientras realizaba las pruebas del runbook estaba obteniendo el siguiente mensaje de error:

Error: Select-AzureSubscription : The subscription name VISUAL STUDIO PREMIUM CON MSDN doesn't exist.

Claramente, la suscripción existe, escribí el nombre tal como lo noté en la parte superior de portal donde aparecen los créditos disponibles.

Si observan en la edición del runbook esta es la suscripción que indique, así que decidí conectarme desde PowerShell y verificar la información, pensé que tal vez era por no ser la suscripción actual.

Y como se puede observar, la suscripción es la adecuada y además es la suscripción por defecto, lo único que noté diferente es la forma en que escribí, en el runbook tengo todo el texto en mayúsculas, tal como aparece en el estado del crédito, sin embargo podemos ver que el resultado del cmdlet Get-AzureSubscription no lo muestra todo en mayúscula, así que decidí hacer la prueba y cambiar esto en el código.

También pude haber observado este nombre sin necesidad de PowerShell, simplemente es el mismo que aparece junto a las VMs

A continuación el código modificado.

Después de este cambio, la prueba funcionó correctamente.

Bien, de este modo ha quedado listo el primer runbook para apagar las máquinas, ahora vamos a configurar el de inicio, omitiré los pasos ya que es exactamente igual al de apagado, solo mostraré la pantalla final.

Al finalizar, veremos los dos runbooks creados.

Antes de poder realizar la programación, debemos publicar los runbooks, encontramos la opción en la parte inferior.

Vemos que ahora tenemos el código en la opción Publicado

Una vez publicado, en cada uno de los runbooks vamos a la opción Programar y hacemos clic en Vincular a una programación nueva

Debemos hacerlo por cada runbook.

Vamos con el de encendido, ponemos el nombre que llevará la programación.

Y configuramos la programación, en este caso la dejé diaria a las 7:00 am y con repetición todos los días.

Este será el resultado

Ahora hacemos lo mismo con el runbook de apagado

También diariamente pero a las 18:00

El resultado

En el tab Runbooks podemos ver los dos recién creados y columnas donde se indica el estado de los trabajos, la última vez que se ejecutó  y la cantidad de trabajos ejecutados.

A continuación pongo dos días después de haber creado las tareas de automatización, se observa la cantidad de trabajos que se ha realizado, si fue exitoso y la fecha y hora en que se ejecutó, la cual corresponde claramente a la programación que definimos previamente.

De esta forma hemos terminado de automatizar el encendido y apagado de todas las máquinas virtuales de una suscripción de Azure.

Espero esta información sea de utilidad. Hasta la próxima!