martes, 18 de agosto de 2009

Validación integrada en Terminal Server 2008

Hola.

A continuación os voy a detallar los pasos a seguir para conseguir que la validación de usuario en una conexión de Terminal Server en Windows Server 2008, esté integrada con el inicio de sesión del equipo en el que se encuentra el usuario.

En primer lugar, damos por supuesto que la conexión de terminal server, está asegurada gracias a contar con un certificado ssl en la propia conexión, para eso, solo tenemos que ir a la consola de Remote App y en el pasode “Configuración de firma digital” asegurarnos que tenemos un certificado emitido a nombre del propio servidor y emitido por una entidad certificadora de confianza para todo el dominio.

En mi caso voy a utilizar un certificado autofirmado por el propio servidor y desplegado como certificado de confianza a través de políticas de A.D.

ts1

1. Herramientas Administrativas – Administración de directivas de grupo

ts2

2. Crear una nueva política asociada o bien a la raiz del dominio o bien a la ou en la que incluiremos los equipos que ha de aplicarse la misma.

3. En la propia directiva, hay que ir a: Configuración de equipo – Plantillas administrativas – Sistema – Delegación de credenciales – Permitir delegación de credenciales predeterminadas.

ts3

3. Una vez ahí, tenéis que detallar contra que servidores de terminal vais a permitir el envio de credenciales, podéis utilizar asteriscos y han de ser siempre precedidos por “TERMSRV/” los lo que son factibles las combinaciones siguientes:

TERMSRV/*.dominio.local

TERMSRV/*

TERMSRV/servidorts.dominio.local

ts4

Como véis, son los usuarios los que tienen que enviar la credencia, por lo que también podéis evitar hacerlo de forma centralizada con A.D. y realizarlo de forma individualizado lanzando la consola “gpedit.msc”.

Saludos.

jueves, 13 de agosto de 2009

Hypervisor Footprint Debate Part 1: Microsoft Hyper-V Server 2008 & VMware ESXi 3.5

 

Fud y más Fud es lo que se ve últimamente en el mundo de la virtualización, eso está bien, cuando la gente se pone nerviosa es que la competencia está trabajando bien…

http://blogs.technet.com/virtualization/archive/2009/08/12/hypervisor-footprint-debate-part-1-microsoft-hyper-v-server-2008-vmware-esxi-3-5.aspx

El origen del lío (el Fud origen del lío)

image_thumb4

Contestaciones

------

If you really want to focus on the disk footprint that matters, the amount of software that could be directly exposed to VM attack, the Hyper-V hypervisor and virtualization stack combined is about 20 MB, ~19.4 MB for the virtualization stack and ~600k for the hypervisor.

---------

Comparison #1: Microsoft Hyper-V Server 2008 & VMware ESXi 3.5

Disk Footprint & Patch Count. Here's what we found:

  • Microsoft Hyper-V Server 2008: 26 patches, totaling 82 MB
  • VMware ESXi 3.5: 18 patches, totaling over 3.7 GB.

Yes, I said over 3.7 GB. To put it another way,

-------

Because VMware releases a whole new ESXi image every time they release a patch. Furthermore, because VMware releases a whole new ESXi image every time they release a patch it also means that every ESXi patch requires a reboot.

At this point, a VMware salesman, may concede the point that every ESXi server has to be rebooted for every patch, but they will then state that they have VMotion (Live Migration), so it doesn't affect their uptime.

Except when their own patches cause days of downtime and render VMotion impotent.

Reliability/Availability. With VMware ESXi 3.5 Update 2, it included a serious flaw which resulted in two days of downtime for their customers including the loss of VMotion

--------

After VMware released Update 2, which affected both ESXi & ESX, they rushed to get a fix out the door and did so in a few days. One interesting thing I noticed was that in the span of a few days, the patch grew 17 MB.

17 MB in a few days????

image_thumb41

Bing & Google

Hola.

Quería haceros llegar este link, hace tiempo que lo uso y me ha venido bastante bien.

http://bing-vs-google.com/

Captura

Saludos.

viernes, 7 de agosto de 2009

Mejor contraseña en blanco que "1234"

Y bueno, la verdad es que es un tanto sorprendente la siguiente información, pero pensándolo bien, si tienes seguridad física, recuerda que por ejemplo no tienes posibilidad de conectarte remotamente a un servidor 2003 o 2008 o Vista / Windows 7, si el usuario con permiso de conexión remota, tiene contraseña en blanco.

----------------------------------------------------------------------------------------
http://www.microsoft.com/protect/yourself/password/create.mspx

“Avoid using online storage. If malicious users find these passwords stored online or on a networked computer, they have access to all your information.”

(So SKYDRIVE = BAD)
The "blank password" option
A blank password (no password at all) on your account is more secure than a weak password such as "1234". Criminals can easily guess a simplistic password, but on computers using Windows XP, an account without a password cannot be accessed remotely by means such as a network or the Internet. (This option is not available for Microsoft Windows 2000, Windows Me, or earlier versions) You can choose to use a blank password on your computer account if these criteria are met:
• You only have one computer or you have several computers but you do not need to access information on one computer from another one
• The computer is physically secure (you trust everyone who has physical access to the computer)
The use of a blank password is not always a good idea. (DUH!) For example, a laptop computer that you take with you is probably not physically secure, so on those you should have a strong password.

http://www.microsoft.com/protect/yourself/password/create.mspx

lunes, 3 de agosto de 2009

Cambiar almacenamiento en Cluster 2003

Más sencillo que ampliar la garantía de una cabina es la sustitución de la misma y debido al alarmante aumento en las ventas de las mismas, incentivado en gran parte por el auge de la virtualización, nos vamos a ver cada vez más enfrascados en líos de estos:

http://msmvps.com/blogs/clusterhelp/archive/2005/08/05/61741.aspx