On the way to Virtualization

Hablar de consejos sobre proteger nuestra privacidad, no dejarnos engañar por estafas en línea y por e-mail o proteger nuestra reputación, son asuntos necesarios cuando nos sentamos frente a un dispositivo electrónico conectado a internet. Hace algún tiempo me hice eco en http://blogs.itpro.es/abueno/?s=jw de un didáctico video que la web jw.org publicó.

En ésta ocasión, el 30 de noviembre es la fecha elegida cada año para celebrar el Día Internacional de la Seguridad Informática (DISI), con la idea de que tanto los usuarios como las organizaciones estén conscientes de las amenazas de seguridad, aquí van algunas acciones como primera línea de defensa.

En consejos sobre seguridad y protección el primer punto que sufrimos muchos administradores y que yo alistaría figura el de, educar a los usuarios, y para ello el Centro de Seguridad y protección de Microsot: http://www.microsoft.com/security/online-privacy/phishing-scams.aspx nos ayuda a proteger nuestra privacidad del robo de identidad. Reconociendo que los usuarios son el primer factor de infecciones en una empresa, es esencial asegurar que los usuarios tengan el nivel adecuado de conocimientos para que NUNCA hagan clic en un archivo adjunto de correo electrónico o un enlace sospechoso, incluso si se trata de una fuente conocida.

Algunas versiones de virus, como “Ransomware” (del inglés ransom rescate y ware, software), son seguramente los invitados más invasivos y no deseados que siendo uno de los virus más detectados, paradójicamente es el virus con peor solución para los archivos infectados. Para los que no estén familiarizados con éste virus, Ransomware tiene a gala haberse hecho en su definición su hueco en la Wikipedia, como un tipo de programa informático malintencionado que restringe el acceso a determinadas partes o archivos del sistema infectado, y pide un rescate a cambio de quitar esta restricción. Este tipo de infección se propaga por correo electrónico, utilizando la máquina infectada como un relé, con el usuario infectado como emisor.

Si a esto le sumamos un adjunto, con un icono que nos resulta familiar (documento de Office, PDF, carpeta …) y decidimos hacer doble clic sobre él… la infección está garantizada. Algunos Ransomware utilizan esos iconos para engañar la vigilancia del usuario. Además, si un archivo adjunto de correo electrónico solicita la ejecución de una aplicación, los usuarios NUNCA deben aceptar la ejecución. Si un usuario tiene alguna duda, tiene que tomar el hábito de ponerse en contacto con el servicio de IT competente que seguramente le permitirá comprobar en un entorno aislado la validez de los datos adjuntos de su correo electrónico o si no es el caso siempre podemos comprobar la fuente desde enlaces como:

http://www.barracudacentral.org/lookups/lookup-reputation2

Si hemos sido infectados por un Ramsomware, será muy necesario que contemos con una solución de Backup-Restore. Debido a que la cave de descifrado de Ramsomware no es localizable, la mejor manera de obtener los archivos de nuevo será restaurar desde una copia de seguridad del sistema, como un Shadow Volume Copy o un System Restore. Lo mejor es poner en marcha un sistema de copia de seguridad fuera de línea, desconectado de la red para evitar que la copia de seguridad esté infectada por el Ransomware.

En este artículo se describe muy bien los principios:

http://www.backupassist.com/blog/support/cryptolocker-and-the-backup-impact/3

Actualizaciones. Es muy importante mantener el sistema operativo actualizado con las últimas actualizaciones de seguridad y para comprobar si todas sus máquinas han sido actualizadas para evitar un ataque con un problema de seguridad conocido, tanto de Microsoft como no Microsoft. Estadísticamente JAVA y Adobe representan el 90% de los vectores de intrusión.

Evite trabajar con un usuario con derechos locales de administración. Es muy recomendable no dejar que los usuarios pertenezcan al grupo administrador local de su máquina. De ésta forma se limitará su posibilidad de intrusión porque hay algunas acciones específicas que no se permitirán. Además, cualquier intrusión en su sesión tendrá el control de la máquina y pondría en peligro la integridad Directorio Activo si hablamos de un dominio.

Y algo difícil para muchos administradores.

Evitemos el uso de cuentas con derecho de Administración del Dominio.

El uso de las cuentas que son capaces de administrar el dominio deben reducirse al mínimo tiempo posible. Si una cuenta de dominio, con derechos de administración del dominio se ve comprometida, es fácil imaginar las consecuencias. No dudes en vestir a una lista de las cuentas que tienen el derecho de administrar el dominio y cambiar todas las contraseñas una vez que el ataque ha terminado.

Hay que prestar atención a los mecanismos de propagación.                                                                  

Un recurso compartido, el correo electrónico… ransomware puede utilizar diversas formas de difusión. Por eso, acciones como, limitar el uso de permisos de escritura y hacer cumplir la seguridad en el archivo adjunto de correo electrónico son de las recomendaciones catalogadas como, mejores prácticas para limitar las posibilidades de propagación.

Administrar macros en Office. Muchas infecciones son procedentes de documentos de Office recibidos por e-mail que contiene macros maliciosos. El manejo de gestión de las macros es una buena idea para evitar que los usuarios ejecutar macros sin pensarlo dos veces. En primer lugar, desactivar la ejecución automática de macros. Aquí os adjunto como hacerlo: https://support.office.com/en-ZA/Article/Enable-or-disable-macros-in-Office-documents-7b4fdd2e-174f-47e2-9611-9efe4f860b12#bm2Es

Éste es sin duda un primer paso para evitar ser infectado de forma automática una vez que se haya abierto el documento de Office que contiene la macro maliciosa. Sin embargo, no impide que el usuario de clic en «Activar» para ejecutar la macro una vez que se abre el documento. Por lo tanto, bien como administradores de un sistema o a título individual, debemos poner en su lugar una ubicación de confianza para las macros, es decir, un usuario sólo podrá ejecutar macros desde una ruta previamente configurada, de nuevo os adjunto un muy buen enlace para saber cómo hacerlo:

https://support.office.com/en-us/article/Add-remove-or-change-a-trusted-location-7ee1cdc2-483e-4cbb-bcb3-4e7c67147fb4?CorrelationId=cd218d92-02cf-427b-806c-59f6a7c22809&ui=en-US&rs=en-US&ad=US

El artículo podría parecer inútil, pero un usuario suele caer en la tentación de hacer clic en cada advertencia hasta que se ejecuta la macro. Esto evitará que un usuario ejecute una macro sin antes haber movido el archivo a una ubicación específica de confianza. Esto ayudará a reforzar la educación del usuario y por lo tanto el usuario puede pensar dos veces antes de ejecutar una macro contenida en un documento de Office que no se confía.

Activar la «Administración del filtrado de archivos», si ofrecemos recursos compartidos desde un entorno servidor de file share, este nos permite proteger los archivos y carpetas compartidas mediante la prevención, en función de las normas específicas definidas por usted mismo, la creación de archivos con la extensión mencionada y permite recibir una alerta si alguien trata de crear un archivo con un no permitidos extensión. Por ejemplo, es posible bloquear la creación de archivos con la extensión * .encrypted, *.hbbjfvd o cualquier otra extensión que utilice el virus para cifrar los datos. También podría impedir la creación de nada, excepto las extensiones que figuran en su lista blanca.

Los siguientes enlaces le ayudarán a configurar esta función:

• http://blogs.technet.com/b/josebda/archive/2008/08/20/the-basics-of-windows-server-2008-fsrm-file-server-resource-manager.aspx
• http://www.catalyticit.com.au/cryptolocker-file-screens/
• https://technet.microsoft.com/en-us/library/cc732074.aspx

Activar AppLocker (o SRP si aún calzas un Windows XP).

Es seguramente la protección más eficaz contra ransomware con el filtrado de URL y filtrado de archivo comprimido que contiene los ejecutables a nivel de proxy y el nivel de mensajería. Esta herramienta permite bloquear o autorizar la ejecución de programas específicos en función de varios criterios como colecciones (un conjunto de extensiones), versiones de archivos, firmas, rutas … y esto por los usuarios / grupos específicos de forma explícita.

Esos artículos deberían ayudarnos a configurarlo:

https://technet.microsoft.com/en-us/library/ee791885(v=ws.10).aspx

Casi perfecta, GPO App Locker:

http://community.spiceworks.com/how_to/59664-free-almost-perfect-malware-protection-with-gpo-app-locker

Detener cryptolocker y ransomware:

https://4sysops.com/archives/stopping-cryptolocker-and-other-ransomware/

Además, aquí están el cryptolocker y los malwares más utilizados con sus rutas y extensiones:

• %OSDRIVE%\Users\*\AppData\Local\Temp\*.tmp
• %OSDRIVE%\Users\*\AppData\*\*.tmp
• %temp%\*.tmp
• %OSDRIVE%\Users\*\AppData\Local\Temp\*.exe
• %OSDRIVE%\Users\*\AppData\*\*.exe
• %temp%\*.exe

El mayor inconveniente de esta herramienta es que podría bloquear aplicaciones legítimas para ejecutar.

Seguridad vs. Funcionalidad.

Sin embargo, es posible configurar reglas de excepción para evitar problemas de compatibilidad, en el siguiente enlace explica como hacerlo:

https://technet.microsoft.com/en-us/library/dd759051.aspx10

Office 365 Implementar Filtrado Fuerte.

Existe malware que utiliza la ejecución automática para instalarse y propagarse. Parece obvia la recomendación, configurar una regla de transporte en nuestro servicio de correo, tal vez Exchange Server para bloquear o marcar mensajes de correo electrónico con contenido ejecutable. El motor se basa en la lista de extensiones y de análisis de contenido para determinar si un archivo es un ejecutable o no.

Para mí lo más fácil es consultar enlaces que detallen el procedimiento y puedan ofrecerme información adicional, personalmente éste lo utilizo bastante:

http://blogs.msdn.com/b/tzink/archive/2014/04/08/blocking-executable-content-in-office-365-for-more-aggressive-anti-malware-protection.aspx

El artículo se basa en EOP (Exchange Online Protection), estos artículos traen información muy precisa sobre EOP:

• Información general del Intercambio Online Protection:
https://technet.microsoft.com/en-us/library/jj723119(v=exchg.150).aspx

• Las mejores prácticas para la configuración de EOP:
https://technet.microsoft.com/en-us/library/jj723164(v=exchg.150).aspx

• Configurar las políticas de Filtro:
https://technet.microsoft.com/en-us/library/jj200684(v=exchg.150).aspx

• Uso de reglas de transporte para inspeccionar archivos adjuntos de mensajes: http://blogs.technet.com/b/exchange/archive/2009/05/11/3407435.aspx

• Explicaciones genéricas disponibles aquí:
https://technet.microsoft.com/en-us/library/jj919236(v=exchg.150).aspx

Aplicar reglas de filtrado a nivel del rol de Edge o servidor de transporte de mensajería. Esto nos permitirá filtrar los archivos adjuntos de correo con anexos zip que contengan ejecutables.

Activar el filtrado de URL o activar el filtrado de URL en sus servidores proxy. Por ejemplo, en TMG:

https://technet.microsoft.com/en-us/magazine/ff472472.aspx)

Coexistencia

Si vamos a migrar un entorno on-premise a Exchange 2016 es importante conocer los casos en los que se admite la coexistencia de Exchange 2016 y versiones anteriores de Exchange.

• Exchange 2013 La actualización acumulativa 10 o superior en todos los servidores Exchange 2013 de la organización, incluyendo los servidores de transporte perimetral.
• Exchange 2010 Funciona con el paquete acumulativo de actualizaciones 11 para Exchange 2010 SP3 o superior en todos los servidores de Exchange 2010 de la organización, incluyendo los servidores de transporte perimetral.
• Exchange 2007 Directamente os digo, no funciona.

Curiosidades sobre el hardware para Exchange Server 2016

No vamos a detenernos en los pormenores de otros requisitos, pero sí me parece muy importante explicar la recomendación de máximos para Exchange 2016.

En muchos casos, con servidores de última generación, tendremos que reducir los cores desde el BIOS a 12 por CPU y tal vez quitarle unos cuantos DIMMs de memoria a los servidores, ya que no soporta más de 96 GB de memoria.

• Recommended Maximum CPU Core Count    24

• Recommended Maximum Memory                   96 GB

http://blogs.technet.com/b/exchange/archive/2015/06/19/ask-the-perf-guy-how-big-is-too-big.aspx

Sistema Operativo

No se admite la instalación de Exchange 2016 en un equipo que se ejecute en modo Windows Server Core. El equipo debe ejecutar la instalación completa de Windows Server. Si queremos instalar Exchange 2016 en un equipo que se ejecuta en modo Windows Server Core, debemos convertir el servidor a una instalación completa de Windows Server mediante la ejecución del comando Install-WindowsFeature Server-Gui-Mgmt-Infra, Server-Gui-Shell -Restart:

Mi recomendación se llama Windows 2012 R2 Standard

FEATURES

Install-WindowsFeature RSAT-ADDS, AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation

OTRAS CONSIDERACIONES

Se nos recomienda encarecidamente usar la versión más reciente de .NET Framework que es compatible con la versión de Exchange que está instalando. .NET Framewaor 4.5.2

Nivel Funcional del bosque de Active Directory debe ser Windows Server 2008 o superios

INSTALANDO

Y como una imagen vale más que mil palabras, aquí van unas pocas hasta completar nuestra instalación / migració

Preparación de Active Directory desde el path donde tengamos el setup de Exchange

De la misma forma preparamos el Dominio:

Sin olvidarnos de preparamos el Esquema:

Pasaremos por las siguientes ventanas al lanzar el setup:

1. Remove-OfficeWebAppsMachine
2. New-OfficeWebAppsFarm -InternalUrl «https://fqdn_server_owa» -ExternalUrl»https://fqdn_server_owa» -CertificateName «NombredelCertificado»  -EditingEnabled:$True
3. Set-OfficeWebAppsFarm -OpenFormUrl:$true 

Comprobamos con el siguiente test que funciona:

• https://fqdn_server_owa/op/generate.aspx

 

Terminamos diciendo en «Guest Clustering o la redundante HA» que al iniciar por primera vez nuestros nodos virtuales, el cluster no se iniciaría… lógico, aun nos quedan un par de cosas por construir.

1.- Desde el Administrador de Hyper-V, crea un conmutador virtual interno para cada anfitrión de hyper-v y por eso de ser rigurosos vamos a llamarlos igual, por ejemplo, Red Interna HB TestVM1 y en el otro anfitrión Red Interna HB TestVM2.

Aclaraciones: Éste conmutador interno solo se puede usar entre las máquinas virtuales que se ejecuten en el mismo anfitrión de hyper-v y entre las VM y el equipo físico. Un conmutador virtual interno no ofrece conectividad a una conexión de red física. Deberás habilitar el truncking entre los servidores físicos para que tengan comunicación por la vlan destinada al HB del guest cluster.

Su propósito va a ser dotar al guest cluster de un interfaz para la red de heart beat.

2.- A esta alturas ya puedes apagar tu cluster físico e iniciar el guest cluster. Cuando lo inicies, no olvides instalar los componentes de integración, después configura las redes del guest cluster, (el virtual swith dedicado a Gestión y el virtual swith interno dedicado a HB)

3.- Ves al administrador de discos, y pon en línea los discos de quorum, spool así como cualquier otro disco que contenga tu cluster y que ambos nodos virtuales deben poder ver y acceder.

4.- Abre el administrador de cluster. Dirigirte al apartado Discos y elimínalos. Tranquilo, la migración P2V fue tan exacta que se trajo hasta las viejas lun de los discos físicos que ya no tienes ni existen. Una vez que los elimines y si hemos hecho todo bien, podrás agregar nuevo almacenamiento al cluster, añade los discos virtuales y tus servicios de cluster deberán comenzar a funcionar.

Un par de pruebas; Balancea los recursos y servicios cluster entre los nodos virtuales… si funciona, vamos bien encaminados, finalmente apaga un nodo virtual y vuélvelo a iniciar, si arrancan sin errores, ya tienes un guest cluster con la redundante alta disponibilidad que un CSV te ofrece.

Si al reiniciar o apagar un nodo virtual del guest cluter no se inicia, revisa que los discos virtuales SCSI, estén compartidos y sean de tamaño fijo.

Hace poco quise migrar un servicio de impresión de alta disponibilidad de Windows 2008 R2 a Windows 2012 R2

El concepto, Cluster de Impresión, en alta disponibilidad, se anula en Windows 2012, porque el servicio de spool o cola de impresión deja de ser, ya no es un recurso cluster. Aun así, desde el punto de vista empresarial, continua existiendo la necesidad de disponer de un servicio HA para imprimir, máxime si una parte importante del core de tu negocio se basa en sacar facturas en formato papel impreso, por mucho que nos esforcemos por ser ecológicos.

Bueno, a grandes males, grandes soluciones. Desde la salida de Windows 2012 la impresión de HA, el Guest Clustering se convierte en la combinación de las tecnologías de cluster de conmutación por error de Microsoft y las tecnologías de Hyper-V para hacer de un servidor de impresión virtual de Windows Server 2012 un «HA».

Pero ATENCIÓN… puestos a rizar el rizo, encontré que mi viejo servicio de impresión Windows, usaba el servicio LPD, el cual permite que los equipos basados en UNIX u otros equipos que usen el servicio LPR, como gestor más inteligente de las colas de impresión, tipo PaperCut, puedan imprimir en las impresoras compartidas de Windows. Y ahora, ¿qué?

Tenemos dos opciones, o cambiamos el servicio LPD/LPR de la empresa, cosa poco probable o aplicamos de nuevo la misma máxima, a grandes males, grandes soluciones, de ahi el título de ésta entrada del blog, la redundante alta disponibilidad, Guest Clustering sobre un CSV de hyper-v.

Ésta fue mi fórmula;

P2V –> *.vhd –> *.vhdx –> CSV –> HDD (Fijo)

La explico.

Convierte tus nodos de cluster en nodos virtuales mediante P2V. Pero Ojo: P2V se descontinua en SCVMM 2012 R2. Para poder hacer un P2V con SCVMM necesitarás tener la versión 2012 y además tendrás que disponer y descubrir un servidor de hyper-v con el agente de 2012. Con eso, puedes comenzar con tu plan de migración de físico a virtual mediante P2V.

La migración habrá generado «n» discos virtuales vhd.

Si vas a migrar los nodos a un entorno de CSV con W2K12R2 es muy recomendable convertir los discos virtuales a vhdx Para ello desde Power Shell ejecuta los siguientes comandos:

PS C:\> Convert-VHD –Path c:\test\abbvhd.vhd –DestinationPath c:\test\abbvhdx.vhdx

Dependiendo del tamaño de los discos a convertir, ármate de paciencia y asegura el espacio en el disco físico para no quedarte sin él, ya que será aproximadamente un 5% mayor que el vhd.

Una vez convertido el disco lo movemos a nuestro recurso ClusterStorage del CSV y lo agregamos al cluster. Es muy posible que el resultado sea: una pequeña partición vhdx de arranque, una partición con el vhdx del sistema operativo y los discos compartidos del cluster incluido el de Quorum.

Antes de iniciar tu Cluster virtual necesitas lo siguiente:

1.- Configurar los discos que formarán tu Guest Clustering en el CSV de Hyper-V como discos SCSI

2.- Aunque se soportan discos de expansión dinámica es muy recomendable que los conviertas a discos de tamaño fijo.

3.- Comparte el disco vhdx para los recursos que formen el cluster (ej. disco de quorum y spool, además de cualquier otro que puedas tener), para ello:

3.1.- En la configuración de la máquina virtual, en Controlador SCSI, expande la unidad de disco que has creado.

3.2.- Haga clic en Características avanzadas

3.3.- En el panel de detalles, seleccione la casilla Habilitar uso compartido de discos duros virtuales

3.4.- Haga clic en Aplicar y, a continuación, haga clic en Aceptar. (Ni que decir tiene que la VM debe estar apagada cuando andes tocando el disco)

3.5.- Agrega el disco duro virtual a cada máquina virtual que vaya a usar el archivo .vhdx compartido. Al hacerlo, repite este procedimiento para habilitar el uso compartido de discos duros virtuales para cada máquina virtual que vaya a usar el disco.

Si prefieres hacer mediante consola de Power Shell, aquí tienes el comando para CSV:

Add-VMHardDiskDrive -VMName VM1 -Path C:\ClusterStorage\Volume1\Data1.vhdx -ShareVirtualDisk

El siguiente comando agrega un disco duro virtual compartido (Witness.vhdx) que está almacenado en un recurso compartido de archivos SMB (\\Server1\Share1) a una máquina virtual denominada VM2.

Add-VMHardDiskDrive -VMName VM2 -Path \\Server1\Share1\Witness.vhdx -ShareVirtualDisk

Ahora viene cuando tienes que apagar tu cluster físico, arrancar el Guest Clustering y descubrir que tu recién migrado y montado entorno virtual no funciona. Bueno, tranquilos, tiene su explicación que podréis leer en la siguiente entrada.

Microsoft ha detectado un elevado número de casos de soporte relacionados con problemas de autenticación NTLM tras la instalación del parche MS15-027. (KB30002657)

La recomendación pasa por probar extensivamente el parche antes de ponerlo en producción o considerar posponer la instalación del mismo hasta que el grupo de producto (el cual está activamente investigando este incidente) haya podido encontrar la causa raíz del problema y nos proporcione una solución al mismo.

Los síntomas que pueden aparecer son diversos e incluyen los siguientes:

1. Clientes Outlook no pueden conectar a servidores Exchange
2. Falla el autodiscover de Outlook
3. El transporte de correos puede verse impactado
4. Las sesiones RDP fallan
5. El acceso a carpetas compartidas falla
6. La autenticación NTLM falla con el mensaje 0xc000006d / STATUS_LOGON_FAILURE
7. Otros…

En el KB se describe parte del problema;

http://support.microsoft.com/kb/3002657

1. Introducción a la migracion:
El procedimiento de migración se basa en líneas generales en un backup de la base de datos y logs de las Autoridades de Certificación en la PKI Windows Server 2003 y una restauración de los mismos en una PKI nueva Windows Server 2012. También, se realiza una exportación de la configuración del servicio de certificados de las Autoridades de Certificación en la PKI Windows Server 2003 y una importación en la PKI Windows Server 2012.

Todo este procedimiento se basa en la siguiente documentación:

http://technet.microsoft.com/en-us/library/ee126102(v=ws.10).aspx
http://technet.microsoft.com/es-es/library/cc742515(v=ws.10).aspx
http://blogs.technet.com/b/xdot509/archive/2013/07/07/upgrading-your-pki-to-windows-server-2012-new-video.aspx
http://technet.microsoft.com/es-es/library/65bf928e-ea43-4849-94b4-79ea2e5b6a48#BKMK_BackupCAPolicy
http://technet.microsoft.com/es-es/library/dn486797.aspx

2. Preparando el entorno de origen.
Antes de empezar la migración se tienen que realizar dos pasos importantes:
 Ampliar el periodo de validez de las CRLs.
 Backup de las Autoridades de Certificación.

2.1. Ampliar el periodo de validez de las CRLs.
Antes de comenzar la migración de la CA, se recomienda ampliar el periodo de validez de la CRL más allá de la duración prevista de la migración. Esto es necesario para permitir la validación de certificados durante el proceso de migración.
Recomendamos por tanto realizar una publicación manual de la CRL para resetear el tiempo de validez de la misma, o bien asegurarnos de tener un intervalo de publicación (tanto base como delta) suficientemente largo.
Podéis encontrar más información sobre ambos aspectos en los siguientes artículos:
Manually publish the certificate revocation list
http://technet.microsoft.com/library/cc778151(WS.10).aspx
Schedule the publication of the certificate revocation list
http://technet.microsoft.com/library/cc781735(WS.10).aspx
Mostramos una captura de ejemplo de la ventana de configuración de los tiempos de publicación de la CRL:

 2.2. Backup de la CAs origen
El siguiente paso es hacer un backup de las CA origen abarcando desde el propio servidor hasta las plantillas de la CA. Para ello, podéis seguir los siguientes pasos:
2.2.1. Backup del servidor:
Realizar un backup del system state de la CA origen siguiendo los pasos descritos en el apartado “To Back Up the System State (Including Registry Settings)” del siguiente artículo:
How to use the backup feature to back up and restore data in Windows Server 2003
http://support.microsoft.com/kb/326216/en-us

2.2.2. Backup de la lista de plantillas
o Entrar con privilegios de administrador en la CA.
o Abrir un CMD.
o Ejecutar: certutil.exe –catemplates > catemplates.txt
o Comprobar que el fichero catemplates.txt contiene la lista de plantillas.

2.3. Backup del algoritmo de firma y CSP.
Durante la instalación de la CA en el servidor de destino, se puede especificar el algoritmo de firma y CSP utilizados por dicha CA, o aceptar la configuración por defecto. Si la CA origen no está usando la configuración por defecto, deberíamos llevar a cabo el siguiente procedimiento para guardar ambos datos:
o Entrar con privilegios de administrador en la CA.
o Abrir un CMD.
o Ejecutar: certutil.exe –getreg ca\csp\* > csp.txt
o Comprobar que el fichero csp.txt contiene los datos del CSP.

3. Migración de la CA.
A partir de ahora entramos en el procedimiento de la migración de los datos de la CA antigua a la nueva. Dentro del mismo hay diferentes pasos que iremos describiendo a continuación.

3.1. Backup de la base de datos de la CA y clave privada.
En este paso realizaremos un backup de diferentes datos de la CA, por lo que debemos decidir una localización donde guardarlos. Como ejemplo en esta guía supondremos la carpeta C:\backup\. Los pasos son:
 Entrar en la CA.
 Abrir la consola de Certification Authority.
 Botón derecho sobre el nombre de la CA, All Tasks, Back up CA…

 En la siguiente pantalla hacemos click en Next.

 En la siguiente ventana se seleccionamos los dos checkboxes siguientes:

o Private key and CA certificate.

o Certificate database and certificate database log.

Con estas dos opciones hacemos backup de la base de datos y los logs de la Autoridad Certificadora, de su certificado y clave privada. Además, indicamos la ruta donde alojaremos estos archivos, que en esta guía va a ser C:\backup\Cabackup.

Establecemos la contraseña para cifrar el certificado y la clave privada

Para finalizar hacemos click en Finish.

En la carpeta C:\backup\Cabackup se guardan los siguientes archivos:

 certbkxp.dat

 edb#####.log

 CAName.edb

 CAName.p12 file

3.2. Backup de CertSvc Configuration

El siguiente paso será realizar una exportación de la clave del registro donde se almacenan la configuración de la CA y guardarla en la carpeta C:\Backup\CAConfigBackup.

 Ir a la siguiente clave de registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\

 Click con botón derecho sobre Configuration, Save, e indicar la localización donde guardarlo, por ejemplo C:\Backup\CAConfigBackup.

3.3. Backup de CAPolicy.inf

Si la CA de origen utiliza un fichero CAPolicy.inf personalizado, debemos copiar este fichero a nuestra carpeta de backup. Normalmente este fichero está en %systemroot% (por defecto C:\Windows).

3.4. Eliminación del rol de Certificate Services de la CA origen.

Es importante quitar el rol de CA del servidor de origen después de completar el backup, y antes de instalar el mismo rol en el servidor destino. Las CAs Enterprise y Standalone que son miembros de un dominio,

guardan información de configuración en Directorio Activo. Quitando el rol de la CA eliminamos también esa configuración del directorio activo.

Para ello vamos al panel de control, añadir/eliminar componentes de Windows, quitamos Certificate Services y pulsamos Next.

3.5. Quitar el servidor del dominio.

Puesto que los nombres en dominios deben ser únicos, es necesario eliminar el servidor origen del dominio y borrar su cuenta de máquina de Directorio Activo antes de unir el servidor destino al dominio.

3.6. Copiado a servidor destino.

Ahora debemos copiar las carpetas en las que hayamos creado nuestros archivos de backup al servidor destino. Siguiendo el ejemplo en esta guía, sería lo contenido dentro de C:\Backup (carpetas CABackup y CAConfigBackup).

Como paso adicional, podemos apagar el servidor de origen.

3.7. Preparación del servidor destino

Si el fichero CAPolicy.inf ha sido personalizado en la CA origen, debemos copiar este fichero a la ruta C:\Windows (valor por defecto), antes de instalar el rol de AD CS en el servidor destino.

Instalamos el rol de AD CS en el servidor destino entrando en Server Manager, Roles, Add Roles.

 Seleccionamos Active Directory Certificate Services, pulsamos Next.

 En el paso Role Services, seleccionamos Certification Authortity, y hacemos click en Next.

 En Setup Type, especificar Enterprise or Standalone para hacerlo coincidir con la CA origen, y pulsar Next.

 En CA Type, elegir Root o Subordinate, de forma similar a la CA origen.

 En la siguiente pantalla del asistente debemos seleccionar la siguiente opción para poder usar el certificado y la clave privada que hicimos anteriormente durante el backup CA «Use existing private key» y «Select a certificate and use its associated private key«.

 En la lista de certificados, importar el certificado de la CA y pulsar Next.

 En el paso «Configure Certificate Database«, especificar la ruta a los ficheros de base de datos y logs de la CA anterior.

 Click Install.

3.8. Restaurar datos de la CA.

Una vez configurada la CA nueva tenemos que restaurar la base de datos de la CA Windows Server 2003. Para ello vamos a All Taks y hacemos click en Restore CA.

 A continuación se iniciará el Asistente de restauración de la base de datos de Autoridad Certificadora. Pulsamos Next.

En la siguiente pantalla, sólo seleccionamos el checkbox «Certificate database and certificate database log» y la ruta donde está almacenada los archivos de base de datos (carpeta CAbackup en esta guía).

 Finalizada la restauración hacemos click en Finish.

3.9. Restaurar datos de registro:

El siguiente paso será restaurar los valores de la clave de registro que exportamos previamente de la CA 2003. Antes de proceder a importar dichos valores, recomendamos hacer un backup de los existentes en el servidor 2012 R2, de la misma forma que hicimos la copia en la CA 2003. La clave de registro está en la siguiente ruta:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\ Configuration

No todos los parámetros del registro deben ser migrados sin realizar cambios desde la CA origen, y otros no deben ser migrados. Si son migrados, deben ser actualizados en el servidor de destino después de la migración puesto que algunos valores están asociados a la propia CA, mientras otros están asociados al dominio, máquina física, versión de Windows, y otros factores que pueden diferir.

La forma recomendada en este caso es editar el fichero antes de importarlo, cambiando o quitando los valores correspondientes. En la siguiente tabla se muestran los parámetros que deben ser transferidos de la CA antigua a la nueva:

Abrir el fichero .reg con un editor de texto.

Si el nombre de la CA destino es diferente de la de origen, buscar en el fichero el nombre de la CA origen. En cada aparición (ver nota posterior), asegurarnos de poner el nombre de la CA destino. Actualizar CAServerName si es necesario.
Importante: Si el nombre del servidor es encontrado como parte del nombre de la CA en Active dentro de Configuration, o en CommonName dentro de CAName, no se deben cambiar estos valores. El nombre de la CA no se debe cambiar en el proceso de migración. Eso significa que la CA de destino debe tener el nombre de la CA anterior, incluso si el nombre del servidor es parte del nombre de la antigua CA.

Comprobar si hay algunos valores que indiquen rutas locales (por ejemplo unidades o path). Si estos han cambiado, actualizarlos correspondientemente. Algunos de esos valores son: DBDirectory, DBLogDirectory, DBSystemDirectory, DBTempDirectory.
Las claves CACertPublicationURLs y CRLPublicationURLs, por defecto contienen path locales. Estos valores pueden ser actualizados posteriormente en la pestaña Extensions de la CA destino.
Una vez realizados los pasos anteriores, para importar el fichero .reg en la máquina de destino, abrir un cmd y ejecutar:
net stop certsvc
reg import
Los pasos anteriores relacionados con los cambios de los valores de registros se realizan con la idea de mantener las rutas de red que la CA anterior utilizaba para publicar CRLs y certificados. Si la CA de origen publicaba por defecto en directorio activo, después de completar el procedimiento anterior, debería existir una extensión con las opciones de publicación habilitadas y rutas LDAP que referencian al nombre de la CA origen, por ejemplo:
ldap:///CN=,CN=,CN=CDP,CN=Public Key Services,CN=Services,.
Dado que muchos administradores configuran extensiones que están personalizadas para su entorno, no se pueden proporcionar instrucciones específicas para estos temas. Recomendamos revisar con detalle las rutas y opciones de publicación asegurando que están configuradas según los requisitos de cada organización.
3.10. Importar plantillas de certificados.
Un paso adicional, únicamente para CA de tipo Enterprise, es importar las plantillas de certificados. Para ello se deben llevar a cabo los siguientes pasos:
o Iniciar sesión en la CA de destino con privilegios de administrador.
o Abrir un CMD.
o Escribir certutil -setcatemplates + y pulsar Enter. El parámetro debe ser sustituido por una lista de nombres de plantillas, separadas por comas. Ejemplo: certutil -setcatemplates +Administrator,User,DomainController
3.11. Comprobación de permisos:
Verificamos los permisos y volvemos añadir la cuenta de equipo, aunque esté agregada a los contenedores Configuration/Services/Public Key Services del ADSIedit como indica el punto Active Directory Permissions for the CA del siguiente artículo:
Performing the Upgrade or Migration
http://technet.microsoft.com/es-es/library/cc742388(v=ws.10).aspx
De esta manera evitamos que aunque la cuenta de equipo se llame igual tenga un SID que haga referencia a la cuenta de equipo de Windows Server 2003.
Desde un ADSI Edit, nos conectamos a la partición de configuración, y vamos a la ruta Services / Public Key Services
Enrollment Services: La cuenta de máquina de la CA tiene permisos de Read y Write para sí mismo en este contenedor.

AIA: Debe tener permisos “Full Control” el grupo “Cert Publishers” en este contenedor. La cuenta de equipo CA tiene que tener “Full Control” son sí misma en este contenedor.

CDP: Debe tener permisos “Full Control” el grupo “Cert Publishers” en este contenedor. La cuenta de equipo CA tiene que tener “Full Control” en cada objeto CRL.

Certification Authorities: Los miembros de los grupo Enterprise Admins y Domain Admins tienen permisos “Full Control” o permisos de Read and Write en este contenedor y la mayoría de los objetos que hay debajo de él. Las ACLs de las plantillas administrativas son configuradas interactivamente por el administrador de la CA.

KRA: La cuenta equipo CA tiene permiso “Full Control” para sí mismo en este contenedor.

OID: Los miembros de los grupo Enterprise Admins y Domain Admins tienen permisos “Full Control” o permisos de Read and Write en este contenedor y la mayoría de los objetos que hay debajo de él.

NTAuthCertificates: Los miembros de los grupo Enterprise Admins y Domain Admins tienen permisos “Full Control” o permisos de Read and Write en este contenedor.

Enrollment Services: Debe tener permisos “Full Control” el grupo “Cert Publishers” en este contenedor.
Arrancamos el servicio de la CA, por ejemplo desde la consola, botón derecho sobre el nombre de la CA, All Tasks, Start Service.

4. Comprobaciones
1. Verificamos las propiedades de la Autoridad Certificadora son correctas.
 Pestaña Extensiones. (CDP, AIA).
 Propiedades de Certificados Revocados.
 Certificados distribuidos, revocados, etc.
2. Verificar autoenrollment:
a. Entrar en un servidor miembro utilizando una cuenta con permisos de Autenroll, Enroll y Read en las plantillas asignadas a la CA de destino.
b. Hacer click en Start, Run.
c. Escribir certmgr.msc, y pulsar OK.
d. Botón derecho sobre Certificates, Current User, All Tasks, y elegir Automatically Enroll and Retrieve Certificates.
e. Next.
f. En “Request Certificates” deberían mostrarse una o más plantillas. Seleccionar la que se desee solicitar, y pulsar Enroll.
g. Finish.
h. En el contenedor Personal, Certificates, debería aparecer una lista de todos los certificados del usuario. Comprobar que está el solicitado anteriormente..

Microsoft ha liberado por primera vez en éste 2014, coincidiendo con las últimas versiones de Windows 8.1 y Windows Server 2012 R2, un cliente de Remote Desktop Services (RDP) para sistemas operativos no Microsoft, en particular para IOS, Mac OSX y Android.

El anuncio aquí:
•http://blogs.msdn.com/b/rds/archive/2013/10/21/microsoft-remote-desktop-apps-for-ios-mac-os-x-and-android-available-for-download.aspx

Y las apps pueden descargar desde las correspondientes stores:
•https://itunes.apple.com/us/app/microsoft-remote-desktop/id715768417
•https://play.google.com/store/apps/details?id=com.microsoft.rdc.Android (como veréis, muy similar en aspecto a la propia App “Modern UI” que se incluye en Windows 8.1 y Windows 8.1 RT)

Por tanto, queda únicamente por resolver el asunto del Linux.
En este ámbito existen varias soluciones que principalmente descansan en las implementaciones de rdesktop (como sería el caso de KRDC, Gnome –RDP) y FreeRDP (Remmina, Vinagre, etc.). Al final, estos desarrollos suelen estar desfasadas en una o dos versiones de protoólo con respecto a la ultima, y en ocasiones no incluyen todas las funcionalidades posibles (RemoteFX, RD Gateway… ese gran desconocido del que ya hablamos).
Dentro del mundo de soluciones completas de virtualización del escritorio o Thin/Zero Clients basados en diferentes sabores de Linux.

Dirigido a un público joven y a formadores y bajo el título, «Si usas las redes, no te enredes», el web site, jw.org, ha lanzado en formato de animación de pizarra, lo que me parece, ideología a parte, un interesante y bien realizado, dibujo animado de unos 4 minutos de duración, sobre una pizarra blanca que va cobrando vida, para representar diversas situaciones muy reales, que en cierta forma, expertos en seguridad informática y hacking ético, preconizan de forma más densa y ampliada.

Aquí os dejo el enlace que me parece digno de ver y escuchar nada menos que en 34 sorprendentes idiomas:

Si usas las redes, no te enredes

http://www.jw.org/finder?locale=es&docid=502014276&prefer=lang

Network Time Protocol (NTP) es uno de los protocolos de internet más viejos (1985) que siguen en uso.
Su propósito, sincronizar los relojes de los sistemas informáticos a través del enrutamiento de paquetes en redes con latencia variable. NTP utiliza UDP como su capa de transporte, usando el puerto 123 y está diseñado para resistir los efectos de la latencia variable.
En un entorno empresarial, es muy importante tener bien implementado el sincronismo horario.
Hablemos de NTP en el ldap de Directorio Activo de Microsoft.

Como sabemos, el sincronismo horario para toda la estructura de Active Directory y sus puesto cliente (en adelante Desktops y Servers), tienen que tener un correcto sincronismo horario. Para que esto funcione, los desktops sincronizan su hora local sobre el controlador de dominio, (en adelante DC) en el cual se han validado, (su logon server) al cual reportan.

Ahora bien, para asegurarnos de que esto funcione correctamente, tenemos que controlar nuestros DCs, para que entre ellos tengan tambien un correcto sincronismo, ¿cómo funciona esto?, basicamente, lo que hacen todos los DCs es contactar al DC con el rol de Primary DC (PDC) y tomar la hora del mismo, con lo que recae toda la responsabilidad sobre dicho DC.

¿Qué debemos configurar del lado de nuestro Active Directory? Lo primero, nuestro PDC con clave NTP y el o los DCs restantes con NT5DS, a su vez, el resto de los objetos computer del dominio (desktops o servers), tambien tienen que tener configurado NT5DS en dicha clave, todo esto, se puede hacer mediante la aplicación de la GPO: Computer Settings – Plantillas Administrativas – System – Time Service

HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/W32Time/Parameters
Key: Type con valor: NT5DS

Esta clave tiene que estar en todos los DCs menos en el PDC, ya que en el mismo en lugar de NT5DS tiene que figurar NTP y a su vez, en la key “NtpServer” se puede poner, el registro DNS o IP del server NTP de la empresa o muy preferiblemente algún NTP externo confiable, de esta forma, se hace que la estructura aplique un orden o un sincronismo horario a todo el bosque y/o dominio.

Con respecto al server NTP, se puede utilizar el de Microsoft (por darte un ejemplo) que es el default que aparece en la clave de registro NTPServer, si el dia de mañana habilitan un NTPServer o apuntamos a uno externo, se tiene que cambiar dicha clave de registro.

Por último, si hemos implementado los cambios de los que hemos hablado, se tiene que reiniciar el servicio Windows Time (W32Time). (net stop w32time – net start w32time)

Para ver el sincronismo horario de los Controladores de Dominio, podemos ejecutar el comando: w32tm /monitor

Personalmente diría que es muy recomendable cambiar la fuente externa del PDC, para que sincronice la hora desde otro site en internet en lugar de la que tenemos localmente.

Adjunto una útil url que utilizo para encontrar los servidores de hora NTP, importante de Stratum 2 y que hay disponibles: https://support.NTP.org/bin/View/Servers/StratumTwoTimeServers

Aplicado el cambio en el PDC ésta sería la configuración NTP:
El proveedor de hora NtpClient está recibiendo datos de hora válidos desde 93.189.33.204 (ntp.m|0x0|0.0.0.0:123-> 93.189.33.204). El nuevo servicio de hora comenzará a anunciarse como hora de origen.