Upgrading Remote Desktop Services deployments to Windows Server 2016 (Parte I de II )

Viernes, 16 de Diciembre de 2016 Sin comentarios

 

No somos muchos los que tuvimos y mantenemos la visión de apostar por una arquitectura robusta, escalable, en constante evolución y muy competitiva en el plano económico.

Hablo de los servicios RDS de Microsoft:
Remote Desktop Session Host, Remote Desktop Connection Bróker, Remote Desktop Gateway, Remote Desktop Web Access, Remote Desktop App, RD License Server y por supuesto Hyper-V.

¿Se admiten las actualizaciones de sistema operativo con los roles y las función de RDS instalado a Windows Server 2016?
Sí, pero con matices, veamos por qué:

Servidores de Remote Desktop Connection Bróker (En adelante RDCB)
Es obligatorio actualizar en primer lugar, los servidores de agente de conexión de RD o Bróker. Insisto, debe/n ser los primeros en actualizarse.
Primer matiz
Microsoft no soporta los servidores Windows Server 2012 R2 con el rol de RD Conexión Broker en una implementación mixta con servidores Windows Server 2016.
Sin embargo, al revés sí, una vez que los servidores de RDCB están ejecutando Windows Server 2016, el despliegue será funcional, aunque el resto de los servidores del despliegue todavía estén ejecutando Windows Server 2012 R2, como pueden ser tal vez los Host de Virtualización de RD, en definitiva, los Hyper-V.
Si hay una configuración activo/activo en el despliegue, se deben actualizar todos los servidores al mismo tiempo y durante el despliegue no estarán disponibles los servidores de RDCB.

Servidores de Remote Desktop License Server
Segundo matiz
Si vamos a actualizar los Host de sesión de escritorio remoto, normalmente las VMs, a Winsdows 2016, antes debemos actualizar el servidor de RD License Server
La CAL utilizada debe corresponder a la versión de Windows Server que se está conectando el dispositivo o usuario. Se puede utilizar CAL mayores para acceder a versiones más recientes de Windows Server, y podremos utilizar las CAL más nuevas para acceder a versiones anteriores de Windows Server.

La siguiente tabla muestra la compatibilidad de CAL en los RDSH y los Hosts de Virtualización de RD.

cals

Los servidores Remote Desktop Session Host (En adelante RDSH) 
Tercer matiz
Las actualizaciones para Windows Server 2016 son compatibles solamente si los RDSH son Windows Server 2012R2 y Windows Server 2016 TP5.
Además todas las aplicaciones instaladas en los RDSH, deben desinstalarse antes y volverlas a instalar después para evitar cualquier problema de compatibilidad de aplicación.

Cómo actualizar una Colección de sesiones de RDSH

  1. Identificar en la colección los servidores RDSH que vamos a actualizar.
  2. Impedir o evitar nuevas conexiones a estos servidores estableciendo a false la opción, Allow New Connections
  3. Desconectar todas las sesiones abiertas en los RDSH
  4. Quitar los RDSH de la colección.
  5. Actualizar los servidores a Windows Server 2016.
  6. Añadir los RDSH actualizados a sus Colecciones correspondientes.
  7. Modificar Allow New Connections en “true” para los RDSH actualizados de la colección.

Los servidores RD Web Access
Pueden actualizarse en cualquier momento. En el caso de RD Web con Windows Server 2012 y 2012 R2 trabajarán bien con implementaciones de Windows Server 2016. Sin embargo hay que tener en cuenta que la actualización puede restablecer propiedades del IIS (como los ficheros de configuración). Para no perder los cambios, es muy recomendable sacar unas pantallas o unas notas de las personalizaciones hechas al sitio Web de RD en IIS.

Los servidores RD Gateway (En adelante RDG)
También pueden actualizarse en cualquier momento. En el caso de RDG con Windows Server 2012 y 2012 R2 trabajarán bien con implementaciones de Windows Server 2016.
Sin embargo, Windows Server 2016 no incluye las políticas de protección de acceso de red (NAP). Éstas tienen que eliminarse antes de actualizar. Para administrar las directivas de NAP, abra la herramienta de servidor de directivas de red. Después de eliminarlos, haga clic en Actualizar la herramienta de configuración para continuar con el proceso de actualización.

Los servidores Remote Desktop Virtualization Host
Está opción estará disponible en la próxima entrada: Upgrading Remote Desktop Services deployments to Windows Server 2016 (Parte II de II )

Categories: Windows 2016 Tags:

NUMA en Hyper-V

Jueves, 15 de Diciembre de 2016 Sin comentarios

NUMA viene de “Non uniform Memory Access o Non Uniform Memory Architecture” y nació de la necesidad de incorporar funcionalidades en el hardware que permitieran un incremento mas lineal del rendimiento, a medida que los servidores cada vez tenían mas procesadores.

AVISO: Antes de seguir es necesario que te insista en que preocuparte por NUMA no es necesario salvo que quieras optimizar un sistema hasta las ultimas consecuencias y necesites hasta la ultima gota de rendimiento y aun en ese caso hay otras muchas cosas de las que preocuparse por optimizar antes que NUMA.

Una forma simple de entender NUMA es decir que en un servidor multiprocesador que pueda usar NUMA va a generar unos grupos llamados nodos, formados por uno o mas procesadores y una cantidad de memoria, normalmente los procesadores dentro de un nodo comparten físicamente un bus de sistema y un canal de entrada salida con el sistema.

Los diferentes nodos están conectados entre si por un bus de interconexión.

El sistema tratara de correr los hilos en los procesadores asociados a la memoria hasta donde el hilo trata de acceder.

Las APIs del sistema permiten además a las aplicaciones ser conscientes de NUMA lo que puede redundar en mejoras de rendimiento, la virtualización es una de las cargas que mas puede beneficiarse de NUMA por esta razón Microsoft invirtió en Hyper-V de cara a extraer lo máximo de NUMA.

Gracias a esta arquitectura los procesadores pueden usar la memoria dentro de su nodo NUMA de forma mucho mas rápida que la que esta en otros nodos, esto redunda en un mayor numero de ciclos de reloj disponibles para otras actividades lo que implica un mejor rendimiento del sistema, cuantas mas VMs tiene un servidor de Hyper-V mayores son los beneficios de NUMA.

En sistemas no NUMA todos los procesadores tienen el mismo derecho a acceder a los recursos de memoria e I/O cuantos mas procesadores tienen estos sistemas menos eficiente son en el uso rápido de los recursos.

Una maquina no NUMA funciona así:

image

Mientras que una NUMA organizara los recursos en nodos como he contado:

image

La inquietud por NUMA en la virtualización viene cuando una VM necesita recursos de mas de un nodo NUMA debido a que el uso de esos recursos será mas lento que si usa recursos locales a su nodo.

Preocuparse por NUMA no es algo común, muchos administradores no conocen de su existencia, no es algo que debamos hacer en el día a día en una instalación normal, sin embargo en ciertas situaciones entender NUMA puede ayudarnos a comprender por que un sistema no rinde como nos gustaría o como optimizar mejor un host de virtualización.

NUMA es lo suficientemente inteligente como para ser consciente de  por ejemplo agrupar los cores de un mismo procesador en vez de cores de diferentes procesadores.

En procesadores AMD crean un nodo por procesador mientras que en Intel puede variar.

Por ultimo decir, que los nodos NUMA puedes estar contenidos en grupos, cada grupo tiene un máximo de 64 procesadores lógicos (cores o hilos si usas hyperthreading) el numero máximo de grupos es 4 numerados del 0 al 3, en sistemas con menos de 64 procesadores lógicos veras un solo grupo NUMA con los nodos que sean necesarios.

Os voy a explicar NUMA para vuestro conocimiento de Hyper-V, ten en cuenta que en general la penalización de rendimiento por falta de afinamiento de NUMA es muy pequeña.

La optimización de NUMA es especialmente interesante y productiva cuando hablamos de hosts de Hyper-V muy estáticos que normalmente siempre tienen las mismas VMs. En sistemas mas dinámicos optimizar NUMA no es sencillo y en algunos casos no es posible.

Algunos servidores incluyen una alternativa a NUMA llamada SUMA si es tu caso no la actives, Hyper-V y Windows Server se benefician de NUMA, SUMA esta pensada para sistemas que no sean capaces de aprovechar estas capacidades.

Que vamos a ver

  • Como saber si mi servidor esta usando NUMA y que nodos tengo
  • ¿Por que me tiene que preocupar NUMA en un host de virtualización?
  • NUMA y la memoria dinámica
  • La afinidad de las VMs a nodos NUMA
  • ¿Puedo evitar que los recursos de una VM se extiendan a mas de un nodo NUMA?

Como saber si mi servidor esta usando NUMA y que nodos tengo

Una forma de ver los nodos NUMA que tienes y con que recursos cuentan son los contadores de Hyper-V con respecto a NUMA:

 ¿Por que me tiene que preocupar NUMA en un host de virtualización?

Cuando un hilo corre sobre un procesador que esta en el mismo nodo que la memoria a la que quiere acceder entonces el rendimiento es fantástico, cuando por el contrario esta situación no se da, el rendimiento es algo peor, no es el fin del mundo y la mayoría de los sistemas se enfrentan a esta condición a diario sin conocimiento de sus administradores.

Cuantificar esta penalización en un % es muy difícil dado el numero de factores que entran en juego, la cifra depende mucho del tipo de carga, podemos decir que una VM con muchos procesadores y con mucha RAM es mas susceptible de este problema y que en caso de darse, si la VM ejecuta cargas que hacen uso intensivo de operaciones de memoria o de operaciones SMP entonces la VM se vera aun mas afectada.

Los host de virtualización gestionan unas cargas muy dinámicas en cuanto a recursos, una VM puede usar memoria dinámica o en cualquier momento una VM con mas de un procesador puede verse afectada por la imposibilidad de encontrar tiempo libre de tantos procesadores como necesite dentro del mismo nodo NUMA.

En un sistema NUMA, por defecto cada VM tiene un nodo preferido, Hyper-V siempre trata de asignar memoria del mismo nodo a la VM.

Hyper-V establece este nodo preferido cada vez que  la VM arranca, como Hyper-V no puede predecir la carga que la VM tendrá es posible que con el tiempo esta VM requiera recursos que estén en otros nodos y esto conducirá a lo que denominamos fragmentación NUMA.

Desde el performance monitor puedes ver también en que nodo NUMA esta corriendo cada VM y en el contador “Remote physical pages” os dais cuenta de si se esta usando memoria de otros nodos.

NUMA y la memoria dinámica

Aunque NUMA afecta a la red y a los procesadores también, os voy a contar el ejemplo de la memoria dinámica por que es el mas fácil de entender:

Hyper-V siempre tratara de ubicar toda la memoria de una VM en un único nodo NUMA.

image

Pero si no es posible tendrá que usar memoria de varios nodos NUMA, esto puede pasar en el arranque de una VM, pero la probabilidad aumenta de que pase en ejecución cuando usas memoria dinámica, tu VM seguirá funcionando igual de bien, pero el rendimiento bajara un poquito.

image

Usar memoria dinámica aumenta las probabilidades de que una VM tenga que repartirse entre varios nodos NUMA lo normal será, insisto que esto no nos preocupe salvo en condiciones muy extremas.

La afinidad de las VMs a nodos NUMA

Es posible configurar que las maquinas virtuales tengan afinidad con un nodo NUMA, obviamente esto es algo que se debe de analizar cautelosamente debido a la cantidad de implicaciones que tiene en la gestión de los recursos. Cuando se cambia el nodo preferido para una VM, es necesario reiniciarla.

¿Puedo evitar que los recursos de una VM se extiendan a mas de un nodo NUMA?

En event viewer de los servidores hay eventos indicándote si en algún momento se ha tenido que usar recursos de otro nodo para servir por ejemplo la memoria pedida por una ampliación realizada a través de memoria dinámica. En Hyper-V, desde W2K8R2 tiene la posibilidad de evitar que una VM use recursos de mas de un nodo.

Activar esta opción tiene claras connotaciones como que por ejemplo se reducirá el numero de VMs que podremos correr en el host o se limitara la memoria RAM máxima que pueda tener una VM en función de la que este disponible en el nodo NUMA en la que corra.

hv

Cuando activamos éste parámetro desde el punto de vista de los recursos del host es como si dividieras tu servidor en servidores de virtualización mas pequeños

Categories: Sin categoría Tags:

Instalación de Exchange Server 2016 Parte II de II

Lunes, 30 de Noviembre de 2015 Sin comentarios

Ya hemos instalado Exchange Server 2016 sobre una arquitectura on-premise… ahora nos queda darle vida, para ello y utilizando una consola de Power-Shell de Exchange con privilegios de administrador, iremos enseñando a nuestro Exchange como moverse.

Estos son los pasos que yo he ejecutado en un DAG a cuyo servidor los he llamado HOST y HOST2 y al fqdn del dominio público, lo he llamado DOMINIO. Serán esos ítems y algún otro que iré explicando al crear el DAG los que tendréis que modificar para configurar vuestro Multirol Exchange Server 2016 en modo DAG:

Cambio de Service Connection Point (SCP) para clientes internos

Set-ClientAccessServer HOST -AutoDiscoverServiceInternalUri https://DOMINIO/Autodiscover/Autodiscover.xml

Cambio OWA y ECP a AuthIntegrada en lugar de Formularios

SetOwaVirtualDirectory “HOST\owa (Default Web Site)” -BasicAuthentication $false -FormsAuthentication $false -WindowsAuthentication $true

Ésta acción requiere un iisreset /noforce

SetEcpVirtualDirectory “HOST\ecp (Default Web Site)” -BasicAuthentication $false -FormsAuthentication $false -WindowsAuthentication $true

De nuevo ésta acción requiere un iisreset /noforce

Importaremos el Certificado Público y pasamos a habilitar su uso para IIS en HOST y en cualquier otro Exchange

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path C:\Certificados\MiCert.pfx -Encoding byte -ReadCount 0)) -Password:(Get-Credential).password

Enable-ExchangeCertificate -Thumbprint Un chorro de números de nuestro certificado -Services IIS

Configuración de InternalURL y ExternalURL para OWA, ECP, OAB, MAPI, ActiveSync, EWS

Set-OwaVirtualDirectory “HOST\owa (Default Web Site)” -InternalUrl https://DOMINIO/owa -ExternalUrl https://DOMINIO/owa
Set-EcpVirtualDirectory “HOST\ecp (Default Web Site)” -InternalUrl https://DOMINIO/ecp -ExternalUrl https://DOMINIO/ecp
Set-OabVirtualDirectory “HOST\oab (Default Web Site)” -InternalUrl https://DOMINIO/oab -ExternalUrl https://DOMINIO/oab
Set-MapiVirtualDirectory “HOST\mapi (Default Web Site)” -InternalUrl https://DOMINIO/mapi -ExternalUrl https://DOMINIO/mapi
Set-ActiveSyncVirtualDirectory “HOST\Microsoft-Server-ActiveSync (Default Web Site)” -InternalUrl https://DOMINIO/Microsoft-Server-ActiveSync -ExternalUrl https://correo.telyco.es/Microsoft-Server-ActiveSync
Set-WebServicesVirtualDirectory “HOST\ews (Default Web Site)” -InternalUrl https://DOMINIO/ews/exchange.asmx -ExternalUrl https://DOMINIO/ews/exchange.asmx

Configuración Outlook Anywhere

Set-OutlookAnywhere “HOST\Rpc (Default Web Site)” -ExternalHostname DOMINIO -InternalHostname DOMINIO -ExternalClientAuthenticationMethod Ntlm -InternalClientAuthenticationMethod Negotiate -SSLOffloading $False -ExternalClientsRequireSsl $True -InternalClientsRequireSsl $True

Configuración Clave

Set-ExchangeServer HOST -ProductKey “XXXXX-XXXXX-XXXXX-XXXXX-XXXXX”

Restart-Service MSExchangeIS

Creación del DAG, Adición de Nodos y configuración DAG

Para completar este paso necesitamos realizar antes algunos pasos previos en nuestra organización o dominio:

  • Acceso a un servidor, (File Cluster) al que he llamado HostName, para crear un Recurso Compartido, al que he llamado, “DAGHOST16_FSW”
  • Añadimos una entrada fqdn en el DNS de AD y le asignamos una IP del mimo ámbito o vlan en la que tengamos nuestro Exchange. A la que yo he llamado, DAGHOST16.

New-DatabaseAvailabilityGroup -Name DAGHOST16 -WitnessServer (HostName de mi File Share) -WitnessDirectory “H:\RECURSO COMPARTIDO\DAGHOST16_FSW” -DatabaseAvailabilityGroupIpAddresses (10.X.X.X)

Set-DatabaseAvailabilityGroup DAGHOST16 -NetworkCompression Enabled -NetworkEncryption Enabled -DatacenterActivationMode DagOnly

Add-DatabaseAvailabilityGroupServer DAGHOST16 -MailboxServer HOST

Creación, Configuración y Adición de copia de BBDD a la que he llamado ABOGADOS

New-MailboxDatabase -Name ABOGADOS -EdbFilePath E:\Mailbox\Abogados\Abogados.edb -LogFolderPath E:\Mailbox\Abogados\ -Server HOST

Restart-Service MSExchangeIS

Montamos la BD

Mount-Database ABOGADOS

Creamos una quota máxima de 2253 MB sobre los buzones que contendrá la BD Abogados

Set-MailboxDatabase ABOGADOS -ProhibitSendReceiveQuota 2253MB -IssueWarningQuota 1843MB -ProhibitSendQuota 2048MB

Solo si hemos montado un DAG, ejecutaremos el siguiente comando:

Add-MailboxDatabaseCopy ABOGADOS -MailboxServer HOST2

Mover buzones de arbitrajes y admin

New-MoveRequest “SystemMailbox{Otro chorro de números}” -TargetDatabase ABOGADOS
New-MoveRequest “Migration.Mas Numeros” -TargetDatabase ABOGADOS
New-MoveRequest “SystemMailbox{Mas Numeros}” -TargetDatabase ABOGADOS
New-MoveRequest Administrador -TargetDatabase ABOGADOS

Limpieza del BBDD creadas por la instalación de 2016

Remove-MailboxDatabase “Mailbox Database XXXXXXXXXX”

SÓLO SI INTEGRAMOS UC DE LYNC O SfB DE MICROSOFT COMO SOLUCIÓN DE UC

Configuración Lync

New-SettingOverride -Name OWAIMSettings -Server HOST,HOST2 -Component OWAServer -Section IMSettings -Parameters @(“IMServerName=FQDNdeLYNC”,”IMCertificateThumbprint=El de Lync”) -Reason “OWA IM Integration”

Set-OwaVirtualDirectory “HOST\owa (Default Web Site)” -InstantMessagingCertificateThumbprint Los numeritos que no te digo -InstantMessagingType Ocs -InstantMessagingServerName FQDN.de.Lync

Get-ExchangeDiagnosticInfo -Server HOST -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh

Restart-WebAppPool MSExchangeOWAAppPool

Configuración OOS-Exchange

Set-MailboxServer HOST -WacDiscoveryEndpoint https://oos.DOMINIO/hosting/discovery

Creación de subscripción en el servidor de Exchange con el rol de EDGE

New-EdgeSubscription -FileName “C:\Edge16.xml”

Adición de subscripción en HOST de Exchange

New-EdgeSubscription -FileData ([byte[]]$(Get-Content -Path “C:\Edge16.xml” -Encoding Byte -ReadCount 0)) -Site “MI SITE DE AD”

Certificado Wildcard

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path C:\star_DOMINIO.pfx -Encoding Byte -ReadCount 0)) -Password:(Get-Credential).password

Enable-ExchangeCertificate -Thumbprint XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX -Services IIS

Get-ExchangeCertificate

SÓLO SI INTEGRAMOS OWAC (Office Web App)

Configuración OOS

New-OfficeWebAppsFarm -InternalUrl “https://oos.DOMINIO” -ExternalUrl “https://oos.DOMINIO” -CertificateName “DOMINIO” -EditingEnabled:$True

Set-OfficeWebAppsFarm -OpenFromUrlEnabled

Categories: Exchange Server 2016 Tags:

Ransomware y nuestras acciones como primera línea de defensa

Lunes, 30 de Noviembre de 2015 Sin comentarios

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:


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)

 

Categories: Seguridad Tags:

Instalación de Exchange Server 2016 Parte I de II

Miércoles, 4 de Noviembre de 2015 Sin comentarios

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

Prepara AD

De la misma forma preparamos el Dominio:

Prepara Dominio

Sin olvidarnos de preparamos el Esquema:

Prepara Schema

Pasaremos por las siguientes ventanas al lanzar el setup:

Setup 01 Setup 02 Setup 03 Setup 04 Setup 05 Setup 06 Setup 07 Setup 08 Setup 09 Setup 10 Setup 11 Setup 12 Setup 13 Setup 14

Categories: Exchange Server 2016 Tags:

Troubleshooting Office Web App – Lync 2013 PowerPoint sharing issue: “There was a problem verifying the certificate from the server. Please contact your support team.”

Jueves, 24 de Septiembre de 2015 Sin comentarios
Recientemente y tras actualizar Office Web App desde Windows Update, la presentación de PowerPoint desde el cliente de Lync dejó de funcionar, con un escueto mensaje de error al verificar el certificado:
cer
Solución, desde el servidor de OWA, abrimos un Power Shell y ejecutamos:
  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
 Seguramente con esto no será suficiente, si los test han funcionado, el problema lo tenemos en nuestro navegador. Lo comprobemos en Opciones avanzadas de IE y desmarcamos,  Habilitar el modo protegido mejorado.
ie 
Cuando solo tenemos un equipo afectado, la solución es buena, pero cuando varios equipos están afectados la cosa cambia.
Al validar el certificado usando Certutil -URLFETCH -verify “mycert.cer” el resultado es el siguiente: 
casd
Os recomiendo leer atentamente el siguiente post para resolver el problema a nivel de dominio:
http://blogs.technet.com/b/lyncativity/archive/2012/12/06/troubleshooting-lync-2013-powerpoint-sharing-issue-there-was-a-problem-verifying-the-certificate-from-the-server-please-contact-your-support-team.aspx
Categories: Lync 2013 Tags:

Guest Clustering – Parte II de II

Viernes, 28 de Agosto de 2015 Sin comentarios

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.

Categories: Hyper-V Windows 2K12 Tags:

Guest Clustering o la redundante “High Availability” – Parte I de II

Jueves, 27 de Agosto de 2015 Sin comentarios

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.

 

Categories: Hyper-V Windows 2K12 Tags:

Actualización de Seguridad KB3002657

Viernes, 13 de Marzo de 2015 Sin comentarios

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

 

Categories: Directorio Activo Tags:

Guía de Migración de una CA Windows 2003 a Windows 2012R2

Jueves, 12 de Febrero de 2015 Sin comentarios

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:

Cert1

 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…
Cert2

En la siguiente pantalla hacemos click en Next.

cer3

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.

cert4

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

 

cert5

Para finalizar hacemos click en Finish.

cert6

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\

cert7

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.

cert8

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.

cert9

cert10

cert11

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

cert12

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).

cert13

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:

Registry location Configuration parameter
HKEY_LOCAL_MACHINE\system\currentcontrolset\services\certsvc\Configuration LDAPFlags
HKEY_LOCAL_MACHINE\system\currentcontrolset\services\certsvc\Configuration\CAname DSConfigDN

ForceTeletex

CRLEditFlags

CRLFlags

InterfaceFlags (required only if has been changed manually)

EnforceX500NameLengths

SubjectTemplate

ValidityPeriod

ValidityPeriodUnits

KRACertHash

KRACertCount

KRAFlags

CRLPublicationURLs

CRLPeriod

CRLPeriodUnits

CRLOverlapPeriod

CRLOverlapUnits

 

CRLDeltaPeriod

CRLDeltaPeriodUnits

CRLDeltaOverlapPeriod

CRLDeltaOverlapUnits

CACertPublicationURLs (check for custom entries with hard-coded host names or other data specific to the source CA)

CACertHash

HKEY_LOCAL_MACHINE\system\currentcontrolset\services\certsvc\Configuration\CAname\ExitModules\CertificateAuthority_MicrosoftDefault.Exit PublishCertFlags
HKEY_LOCAL_MACHINE\system\currentcontrolset\services\certsvc\Configuration\CAname\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy EnableRequestExtensionList

EnableEnrolleeRequestExtensionList

DisableExtensionList

SubjectAltName

SubjectAltName2

RequestDisposition

EditFlags

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..

Categories: Directorio Activo Tags: