Uncategorized

MOSS 2007 – Plan for SSO operations

Managing the encryption key

La clave de cifrado se emplea como parte del proceso de cifrado para las credenciales que se usan con SSO. La clave ayuda a descifrar las credenciales cifradas que están almacenadas en la base de datos de SSO. La primera vez que se configuran el inicio de sesión único y las definiciones de aplicaciones de empresa en la página Administrar la configuración del servidor para inicio de sesión único de Administración central, la clave de cifrado se crea automáticamente. La administración de la clave de cifrado incluye la auditoría de la clave de cifrado y su regeneración.

Auditing the encryption key

Es posible habilitar la auditoría de los cambios que se realizan en la clave de cifrado. Si la clave se lee o se escribe, se registra un evento de seguridad en el registro de seguridad. El registro de seguridad puede verse mediante el Visor de eventos. La habilitación del registro implica:

· Modificar una clave de registro de SSO.

· Crear una directiva de equipo local en el Editor de objetos de directiva de grupo.

Regenerating the encryption key

Debido a que la clave de cifrado protege las credenciales de seguridad, se debe volver a generar de forma periódica; por ejemplo, cada 90 días. Además, se deberá volver a generar la clave si las credenciales de cuenta se ven comprometidas.

El proceso de cifrado es una operación de larga ejecución. Recomendamos que cambie la clave de cifrado durante períodos de poca actividad. El cifrado de la clave tiene el siguiente impacto en el entorno de SSO:

· Durante el proceso de cifrado, las operaciones de escritura (como la actualización de credenciales y el cambio de definiciones de aplicaciones de empresa) no están permitidas.

· Las operaciones de lectura, como la recuperación de credenciales, continúan funcionando de forma habitual.

Debe haber iniciado sesión en el servidor de clave de cifrado local para volver a cifrar la clave de cifrado. Además, debe ser un integrante de la cuenta de administrador de SSO.

Si se reinicia el servidor de clave de cifrado o se detiene el servicio de inicio de sesión único en el servidor de clave de cifrado durante el proceso de cifrado, es preciso comprobar si hay errores en el registro de eventos. Si el registro de eventos indica un error, debe reiniciar el proceso de cifrado. Si el proceso de cifrado se anula de alguna manera, deberá volver a ejecutarse. Si el proceso de cifrado se anula, vuelve a su estado original.

Cuando se crea una clave de cifrado, puede optar por cifrar las credenciales existentes con la nueva clave. Si no cifra las credenciales existentes con la nueva clave de cifrado, los usuarios deberán volver a escribir sus credenciales para las definiciones de aplicaciones de empresa individuales, y los administradores de definiciones de aplicaciones de empresa de grupo deberán volver a escribir las credenciales de grupo.

Al cifrar el almacén de credenciales del servicio de inicio de sesión único, los eventos se registran en el registro de eventos de la aplicación de Microsoft Windows Server 2003. Una vez que se inicia el cifrado, se puede supervisar el registro de eventos de la aplicación para comprobar que se haya cifrado el almacén de credenciales. El identificador de evento 1032 se agrega al registro de eventos de la aplicación cuando se inicia el cifrado. El identificador de evento 1033 se agrega cuando finaliza el cifrado. Si se producen errores durante el cifrado, se agrega un evento en el registro.

Al decidir las opciones de planeación para administrar la clave de cifrado, tenga en cuenta lo siguiente:

· ¿Con qué frecuencia piensa cifrar la clave de cifrado?

· ¿Las credenciales existentes deben cifrarse con la nueva clave de cifrado al mismo tiempo?

· ¿En qué otras circunstancias se cifrará la clave de cifrado?

Backing up the SSO environment

La copia de seguridad del entorno de SSO implica realizar una copia de seguridad de las siguientes dos entidades independientes:

· Clave de cifrado

· Base de datos de SSO

Se debe realizar una copia de seguridad de la clave de cifrado después de la configuración inicial de SSO y luego cada vez que se regenere la clave. No es necesario realizar una copia de seguridad de la clave de cifrado de forma periódica, a menos que este proceso esté vinculado al de la regeneración de la clave de cifrado. No es posible realizar una copia de seguridad de la clave de cifrado de forma remota. Es necesario ser integrante de la cuenta de administrador de SSO y haber iniciado sesión en el servidor de clave de cifrado local para realizar una copia de seguridad de la clave. La copia de seguridad de la clave de cifrado sólo puede realizarse en un medio de almacenamiento extraíble, no en un disco duro local. La copia de seguridad de la clave de cifrado se realiza desde la página Administrar la clave de cifrado de Administración central.

Se debe realizar una copia de seguridad de la base de datos de SSO después de su creación inicial y luego cada vez que se cifran las credenciales. Además, se pueden incluir las copias de seguridad de la base de datos de SSO con las copias de seguridad programadas para la base de datos de la granja de servidores. Las copias de seguridad programadas incluirán otros cambios en la base de datos de SSO, como nuevas definiciones de aplicaciones de empresa y actualización de las credenciales.

No se debe almacenar la copia de seguridad de la clave de cifrado en la misma ubicación de la copia de seguridad de la base de datos de SSO. Si un usuario obtiene una copia de la base de datos y de la clave, las credenciales almacenadas en la base de datos podrían verse comprometidas. Lo ideal es guardar la copia de seguridad de la clave de cifrado en un lugar seguro.

Al decidir las opciones de planeación para realizar copias de seguridad del entorno de SSO, tenga en cuenta lo siguiente:

· La frecuencia de realización de copias de seguridad de la clave de cifrado.

· El plan para realizar la copia de seguridad de la base de datos de SSO. El plan más eficaz consiste en incluir la base de datos de SSO junto con las copias de seguridad periódicas de la granja de servidores.

Restoring the SSO environment

Existen diversos escenarios que requieren la restauración del entorno de SSO. En algunos casos, se debe restaurar sólo la clave de cifrado o sólo la base de datos de SSO. En la siguiente tabla, se describen varios escenarios de restauración y se indica lo que es necesario restaurar.

Escenario

Lo que se debe restaurar

Transferencia de la función de servidor de clave de cifrado a otro servidor.

Clave de cifrado

Cambio de la cuenta de servicio de SSO.

Clave de cifrado

Restauración del servidor de base de datos con errores.

Base de datos de SSO

Migración de la granja de servidores de Office SharePoint Server 2007 a otro grupo de servidores.

Clave de cifrado y base de datos de SSO

Recuperación ante un desastre en toda la granja de servidores.

Clave de cifrado y base de datos de SSO

En el resto de esta sección, se detallan las tareas específicas de restauración del entorno de SSO, en función de cada escenario.

Para transferir la función de servidor con clave de cifrado a otro equipo servidor, siga estos pasos:

Move the encryption-key server role to a different server computer

1. Realice una copia de seguridad de la clave de cifrado.

2. Deshabilite el servicio de inicio de sesión único en todos los equipos de la granja de servidores.

3. Inicie sesión en el nuevo servidor de clave de cifrado.

4. Inicie el servicio de inicio de sesión único.

5. Establezca la configuración de SSO de la granja de servidores en el sitio de Administración central. Especifique la base de datos de SSO existente.

6. Restaure la clave de cifrado.

7. Inicie el servicio de inicio de sesión único en todos los servidores web de la granja de servidores.

Change the SSO service account

El identificador de seguridad (SID) de la cuenta de servicio de SSO se usa como parte de la fórmula para cifrar las credenciales de SSO. Por consiguiente, para cambiar la cuenta de servicio de SSO, debe volver a configurar el entorno de SSO. Realice los siguientes pasos para cambiar la cuenta de servicio de SSO:

Change the SSO service account

1. Realice una copia de seguridad de la clave de cifrado.

2. En todos los servidores de la granja de servidores que ejecuten el servicio de inicio de sesión único, vuelva a configurar el servicio con la nueva cuenta de servicio.

3. Cambie la configuración de SSO de la granja de servidores en el sitio de Administración central con la nueva cuenta de servicio de SSO. Especifique la base de datos de SSO existente.

4. Restaure la clave de cifrado.

5. Cifre las credenciales de la base de datos de SSO. Para cifrar las credenciales, se usa la clave de cifrado restaurada.

Restore only the SSO database server

Si se produce un error en el servidor que hospeda la base de datos de SSO, se deberá restaurar sólo la base de datos de SSO. Para ello, siga el mismo método que se usa para restaurar cualquier otra base de datos en el entorno de Office SharePoint Server 2007. Si restaura la base de datos de SSO en un servidor diferente, cambie la configuración de SSO de la granja de servidores con el nombre del nuevo servidor de base de datos.

Restore the entire SSO environment

Existen diversos escenarios que requieren la restauración de la clave de cifrado y de la base de datos de SSO. Siga estos pasos para restaurar todo el entorno de SSO:

Restore the entire SSO environment

1. Restaure la base de datos de SSO en el servidor de base de datos previsto.

2. Configure SSO siguiendo el mismo proceso de configuración de un nuevo entorno de SSO, excepto que deberá especificar el nombre del servidor y el nombre de base de datos de la base de datos de SSO existente.

3. Restaure la clave de cifrado en el nuevo entorno de SSO

Responding to an SSO security compromise

Un peligro para la seguridad puede incluir la pérdida de medios de copia de seguridad, la pérdida de contraseñas u otro evento que podría poner en peligro las credenciales almacenadas en la base de datos de SSO o los datos almacenados en las aplicaciones de empresa. Si se presenta un peligro para la seguridad que podría afectar el entorno de SSO, siga estos pasos:

Respond to a security compromise

1. Vuelva a generar la clave de cifrado.

2. Cifre las credenciales de la base de datos de SSO (se usa la nueva clave de cifrado).

3. Cambie las contraseñas de las aplicaciones de empresa que podrían verse comprometidas.

4. Sugiera a los usuarios que cambien sus contraseñas si éstas pudieran verse comprometidas.

Si el peligro para la seguridad es potencialmente grave, puede interrumpir el servicio de inicio de sesión único para detener inmediatamente el acceso a las credenciales almacenadas en la base de datos de SSO. Si debe interrumpir el servicio de inicio de sesión único, siga estos pasos para restaurar de forma segura el servicio en la granja de servidores de Office SharePoint Server 2007 existente:

Restore the Single Sign-On service to the existing server farm

1. Restaure el entorno de SSO en un servidor aislado.

2. Vuelva a generar la clave de cifrado.

3. Cifre las credenciales de la base de datos de SSO.

4. Realice una copia de seguridad del entorno de SSO.

5. Restaure el entorno de SSO en la granja de servidores de Office SharePoint Server 2007 existente.

Jonnathan De La Barra Bustinza

Microsoft Certified Technology Specialist Windows SharePoint Services 3.0 ConfiguringMCTS WSS 3.0 Configuring

Advertisements
Uncategorized

MOSS 2007 – Plan for single sign-on

La característica de inicio de sesión único (SSO) de Office SharePoint Server 2007 asigna credenciales de usuario a sistemas de datos back-end. SSO permite obtener acceso a datos desde servidores y servicios externos a Office SharePoint Server 2007. Desde Elementos web de Office SharePoint Server 2007, es posible ver, crear y cambiar estos datos. La característica de SSO garantiza que:

· Las credenciales de usuario se administran de forma segura.

· Se aplican los niveles de permisos de usuario que se configuran en el origen de datos externo.

· No se le pedirá a los usuarios que vuelvan a escribir sus credenciales al ver datos de orígenes de datos externos en Office SharePoint Server 2007.

· Office SharePoint Server 2007 pueda conectarse a varios sistemas de datos externos independientemente de la plataforma y los requisitos de autenticación.

SSO requiere el uso de credenciales de Windows para las cuentas de usuario. En entornos donde se usa el inicio de sesión web único para autenticar cuentas de usuario, SSO puede usarse sólo si el subproceso actual que invoca las interfaces de programación de aplicaciones (API) de SSO tiene una identidad de Windows asociada a él.

Common SSO scenarios

SSO se usa principalmente para escenarios de inteligencia empresarial. En Office SharePoint Server 2007, muchas características dependen de SSO, incluidas las siguientes:

· Catálogo de datos profesionales

· Excel Services

· InfoPath Forms Services

· Elementos web de datos profesionales

· Elemento web de KPI

· Elemento web de formulario de datos de Microsoft Office SharePoint Designer

· Búsqueda de datos profesionales

· Datos empresariales en listas

Además, se pueden incluir elementos web personalizados con conexión a orígenes de datos externos, incluidos aquellos que se basan en sistemas operativos distintos de Windows. Por ejemplo, puede establecer la conexión con las siguientes aplicaciones de empresa:

· SAP Business Information Warehouse

· Siebel eBusiness Applications

· Microsoft BizTalk Server

Office SharePoint Server SSO architecture

Microsoft Single Sign-On service

La característica de SSO de Office SharePoint Server 2007 usa el servicio de inicio de sesión único (SSOSrv) de Microsoft. En la siguiente ilustración, se muestra cómo se implementa el servicio de inicio de sesión único en una granja de servidores de Office SharePoint Server 2007.

SSO_MOSS2007

SSO encryption-key server

El primer equipo servidor en el que se habilita el servicio de inicio de sesión único se convierte en el servidor de clave de cifrado. El servidor de clave de cifrado genera y almacena la clave de cifrado. Esta clave se usa para cifrar y descifrar las credenciales almacenadas en la base de datos de SSO. El servidor de clave de cifrado debe ser un equipo servidor de aplicaciones, como un servidor de índices.

Single Sign-On service

Este servicio debe instalarse en todos los servidores web de la granja de servidores y, además, en los equipos que hospeden la función de servidor de aplicaciones de Excel Services. Si se usa una búsqueda en el Catálogo de datos profesionales, el servicio también deberá instalarse en el servidor de índices.

SSO database

Cuando se establece la configuración del servidor de SSO en el sitio de Administración central, Office SharePoint Server 2007 crea una base de datos de SSO en el servidor de base de datos que hospeda la base de datos de configuración. Si Microsoft SQL Server se encuentra instalado, la base de datos de SSO es una base de datos de SQL Server. De no ser así, el servicio de inicio de sesión único usa SQL Server 2005 Express Edition. La base de datos de SSO almacena las credenciales cifradas.

SSO tickets

En un entorno empresarial donde un usuario interactúa con diversos sistemas y aplicaciones, es muy probable que el entorno no mantenga el contexto de usuario a través de varios procesos, productos y equipos. Este contexto de usuario es fundamental para proporcionar funciones de inicio de sesión único, ya que es necesario comprobar quién inició la solicitud original. En escenarios donde varios servidores participan en el traspaso de credenciales desde el servidor de clave de cifrado hasta la aplicación de empresa, el servicio de inicio de sesión único proporciona un vale de SSO (no un vale Kerberos). Los servidores usan este vale para obtener las credenciales correspondientes al usuario que realizó la solicitud original.

Por ejemplo, un entorno de nóminas puede configurarse para tener acceso a datos en un sistema SAP a través de BizTalk Server. Si un elemento web se conecta al sistema SAP, las credenciales se distribuyen a través del equipo de servidor BizTalk Server. En un entorno de SSO, un elemento web envía un vale de SSO al servicio en el equipo de servidor BizTalk Server que se conecta con el sistema SAP. Si el usuario pertenece a una cuenta o cuenta de grupo que se ha especificado en la definición de aplicación de empresa, el servicio canjea el vale de SSO por credenciales para el sistema SAP. Para que el servicio del equipo de servidor BizTalk Server canjee los vales de SSO, la cuenta que usa el servicio debe agregarse al grupo de administradores de SSO.

El servicio de inicio de sesión único emite un vale cuando un usuario de Windows lo solicita o cuando una aplicación lo solicita en su nombre. El servicio de inicio de sesión único sólo puede emitir un vale para el usuario que realiza la solicitud (no es posible solicitar un vale para otros usuarios). Un vale contiene el nombre cifrado de usuario y de dominio correspondientes al usuario actual y la fecha de expiración del vale.

Una vez que la aplicación de empresa comprueba la identidad del solicitante original, canjea el vale para obtener las credenciales del usuario que inició la solicitud. De forma predeterminada, los vales expiran en dos minutos. Los administradores de SSO pueden modificar el tiempo de expiración de los vales. La validez del vale debe ser suficiente para abarcar el intervalo de tiempo desde que se emite hasta que se canjea.

SSO administration

La administración de SSO implica dos tipos de los administradores:

SSO administrators

Estos administradores establecen y configuran el SSO, administran las cuentas de SSO, realizan copias de seguridad de la clave de cifrado, y crean y cambian la clave de cifrado. Por motivos de seguridad, los administradores de SSO deben iniciar sesión en el servidor de clave de cifrado de forma local para establecer, configurar y administrar el SSO. Los administradores de SSO no pueden administrar la configuración del servidor de SSO desde un equipo servidor remoto.

Enterprise application definition administrators

Estos administradores crean y administran definiciones de aplicaciones de empresa, y actualizan las cuentas y credenciales que se usan para tener acceso a esas aplicaciones. Pueden administrar las definiciones de aplicaciones de empresa de forma remota.

Plan farm-level SSO settings

SSO encryption-key server

Determine qué equipo de la granja de servidores hospedará la función de servidor de clave de cifrado de SSO. La configuración recomendada es seleccionar un servidor de aplicaciones, como el servidor de índices, por las siguientes razones:

· Todos los servidores que ejecutan el servicio de inicio de sesión único deben tener la capacidad de comunicarse a través de la red con el servidor de clave de cifrado. Cuando se usa una granja de servidores con varios servidores web, algunas tecnologías de equilibrio de carga no permiten a los servidores web comunicarse entre sí.

· Los usuarios finales no tienen acceso directo a los servidores de aplicaciones y, por lo general, estos servidores están protegidos por niveles adicionales de seguridad. Por ejemplo, se suelen implementar protocolos de seguridad, como IPSec o SSL, para proteger la comunicación entre los servidores de una granja de servidores. Además, algunas topologías de granja implementan un enrutador o firewall adicional entre los servidores web y los servidores de aplicaciones.

El servicio de inicio de sesión único debe instalarse en cualquier servidor de aplicaciones que hospede la función de Excel Services. Si se usa una búsqueda en el Catálogo de datos profesionales, el servicio de inicio de sesión único también deberá instalarse en el servidor de índices. Estos requisitos permiten que cada uno de estos servidores sean una buena elección para la función de servidor de clave de cifrado.

SSO accounts

Hay cuatro cuentas diferentes que son necesarias para configurar, ejecutar y administrar el sistema de SSO:

· Cuenta de configuración de SSO.

· Cuenta de administrador de SSO.

· Cuenta de servicio de SSO.

· Cuenta de administrador de aplicación de empresa.

Uncategorized

Lo más nuevo de Windows 7 es… Windows XP

El problema de la compatibilidad con las aplicaciones desarrolladas para Windows XP ha sido una de las losas que siempre ha pesado sobre Windows Vista, sobre todo en entornos profesionales. Multitud de aplicaciones de contabilidad, control de stocks y otras herramientas importantes se quedaron sin funcionar en Vista y eso contribuyó a que muchas empresas optaran por no mover ficha cuando apareció el nuevo sistema.

caja-xp

Es bien sabido que Microsoft está aprendiendo valiosas lecciones con los problemas que le ha dado el todavía actual Windows, y la de la compatibilidad con Windows XP es una de las que no se puede permitir el lujo de no aprender. Nos consta que el equipo de programación de Windows 7 ha estado trabajando para aumetar el número de aplicaciones compatibles con Windows 7, pero los responsables deben haber constatado que el esfuerzo no ha sido suficiente, o quizás han recibido quejas de las empresas de software sobre el grado de compatibilidad con ciertas aplicaciones. Así que se han decidido por un brillante plan B.

¿Cuál es la mejor manera de asegurarse de que una aplicación desarrollada para Windows XP funcione en Windows 7? Nada más fácil, meter un Windows XP dentro de Windows 7. Así que los desarrolladores del nuevo sistema han incorporado el Windows XP Mode, un Windows XP instalado en una máquina virtual de Virtual PC de Microsoft.

vxp_01

En el blog del Windows Team han anunciado esta posibilidad que tanto Rafael Rivera de Within Windows como Paul Thurrott de Windows señalan como una de las sorpresas que se anunciaron para la RC de Windows 7. Ambos han estado probando durante cerca de un mes esta nueva herramienta. El anuncio se hace en paralelo con el lanzamiento de Virtual PC para Windows 7.

vxp_05

El XP mode se incorporará a las versiones Ultimate, Professional y Enterprise de Windows 7 e incluirá una licencia gratuita de Windows XP con service Pack 3. Se trata de una función que podremos descargar desde el sitio web de Microsoft por parte de todos lo usuarios de Windows 7.

vxp_10

Esta aplicación permite instalar directamete programas en el XP Mode sin necesidad de arrancar la máquina virtual. Una vez instaladas, esas aplicaciones de registrarán como si fueran aplicaciones nativas de Windows 7 que podremos ejecutar directamente en una ventana independiente. De esta forma la virtualización de Windows XP se hace de forma transparente. Hay que aclarar que una máquina virtual de Virtual PC no tendrá las mismas prestaciones que una aplicación nativa, pero si no se trata de software que haga un uso intensivo de gráficos y de otros elementos hardware, apenas notaremos una merma en el rendimiento, sobre todo si consideramos que las aplicaciones que suelen dar problemas, como hemos apuntado, son programas de contabilidad y similares.

vxp_17

Desde luego es una idea excelente  por muchas razones. La primera porque asegura una compatibilidad del 100% con Windows XP. La segunda porque se trata de una herramienta gratuita, para ciertas versiones de Windows 7. La tercera porque saca partido de un producto y una tecnología que es propiedad de Microsoft, Virtual PC. Siempre es una buena idea la de las sinergias, y si quedan en casa y se aprovecan recursos propios mucho mejor. Y finalmente porque puede resolver muchos problemas para las empresas y acabar con las objeciones de compatibilidad que pueda suscitar Windows 7.

Otro punto para Redmond.

Uncategorized

Windows 7 vs Vista, carrera a muerte

Ya sabemos que sacar al ruedo de los programas de prueba a una versión ya sea pre beta o beta de Windows 7 es poco significativo, que se trata de una versión pendiente de ajustar, con muchos elementos que pueden cambiar, controladores poco afinados, código sin depurar… Algunos recuerdan versiones pre-beta de XP y de Vista llenas de bugs y arrastrándose en máquinas potentes y por eso todos los responsables de Microsoft y entendidos de todos los colores advertían que era absurdo hacer pruebas.

desafio

Pero ¿qué pasa si esa versión preliminar, ese embrión de sistema operativo, ese código con muletas es puesto a prueba y supera a la versión anterior? Pues entonces sí que podemos decir que es significativo

Precisamente eso esa es la conclusión que se desprende de la prueba realizada por un colaborador de ZD-Net que ha publicado los resultados en su blog Hardware 2.0. En las marcas de salida se colocaban Windows Vista versión final, Windows Vista con Service Pack 1 y Windows 7 build 6956. A última hora cogió su puesto también el Windows XP con Service Pack 3.

La configuración de los equipos era idéntica (nada del otro mundo, por cierto, y eso es significativo):

– Phenom 9700 quad-core processor
– ATI Radeon 3850 graphics card with 256MB RAM
– ASUS M3A32-MVP Deluxe motherboard
– 2GB (2 x 1GB) Corsair Dominator CM2X1024-8500C5D RAM
– Western Digital Raptor 10,000RPM 150GB primary hard drive
– Western Digital Caviar 7,200RPM 500GB secondary hard drive

Aunque las diferencias en rendimiento no son espectaculares, los resultados hablan por si mismos:

Tiempo de arranque:

Una de las torturas que tienen que soportar los sufridos usuarios de Windows es el tiempo de arranque del sistema. Es la prueba quizás menos científica, pero significativa. Windows 7 no solo arranca más rápido que las dos versiones de Vista (significativamente la del service pack es más lenta) sino que incluso gana a Windows XP.

boot-time-windows-7

Pass Mark Performance Test 6:

Programa que prueba los distintos componentes del sistema, incluyendo CPU, discos y tarjetas gráficas. Aquí también gana Windows 7 con una diferencia espectacular si nos fijamos en la gráfica, aunque no tanto si nos fijamos en las cifras. Otra vez sigificativo el pobre resultado de Windows Vista SP1.

passmark-windows-7 PCMark Vantage:

Otro test en el que Windows 7 saca ventaja en esta prueba también. Se trata de pruebas con aplicaciones como edición de fotos, vídeo y otras tareas.

pcmark-windows-7 CINEBENCH R10:

Test que se basa en software de creación de animaciones en 3D. En este caso Windows 7 pincha frente a las dos versiones de Vista, aunque consigue superar al XP.

cinebench-r10

Para se mas precisos este análisis se hizo incluso antes de sacar la versión Beta  del Windows 7. Todo un resultado para un software que aún no estaba siquiera en su versión beta.

Uncategorized

Microsoft lanzado va por el “otro” Windows 7 – WM7

windows_theme_mobileMicrosoft puede presumir de ser líder insdiscutible en cuanto a sistemas operativos instalados en ordenadores personales, pero en cuanto a dispositivos móviles la cosa cambia. En este mercado Windows Mobile sobrevive por detrás de otros commo Apple, Blackberry o Nokia con Symbian recogiendo las migajas que el boom de los smartphones ha dejado a su paso, pero siempre desde la barrera. Actualmente Microsoft muestra las bondades de Windows Mobile 6.5, pero la apuesta clara es por su sucesor, Windows Mobile con la cifra mágica del 7. windowsmobile7

Con este sistema operativo Microsoft intentará recuperar terreno en el mercado de los sistemas operativos para dispositivos móviles que parece haberse asentado en un crecimiento sostenido a pesar de la crisis. Para ello ha reclutado nada menos que a 1.000 ingenieros para acelerar lo más posible el desarrollo del nuevo sistema con la esperanza de que tenga una repercusión parecida a su hermano Windows 7.

 

Según hemos podido leer en MuyComputer, windows_mobile_interface

Microsoft trabaja sin descanso en Windows Mobile 7 y prepara una gran ofensiva para recuperar cuota de mercado en el segmento móvil. El reciente lanzamiento de Windows Mobile 6.5, considerado como un sistema de transición, no es suficiente para recuperar terreno en un mercado de gran competencia, y Windows 7 Mobile en un proyecto clave en Microsoft.

Windows Mobile 7No es de extrañar por tanto que la compañía haya asignado un número tan impresionante de ingenieros y desarrolladores. La llegada del iPhone OS de Apple, el sistema de RIMM en las BlackBerry, la liberación del Symbian de Nokia y la salida del nuevo Palm Pre ha colocado a Microsoft en cuotas desconocidas en el segmento del móvil inteligente.

La llegada masiva de terminales con el Android de Google abundaría aún más en esta situación negativa por lo que la publicación de Windows Mobile 7 es de importancia estratégica para Microsoft.

WM7 contaría con una gran integración con las redes sociales, incluiría funciones de Windows 7 que ya hemos podido ver en el Zune 4.0 recientemente presentado, contaría con soporte para acelerómetro y brújula, soporte para RIL, GPS, Wi-Fi y USB, una versión especial del navegador Internet Explorer para móviles, un nuevo cliente para la suite ofimática Office 2010, soporte Flash y Silverlight y todas las tecnologías a disposición de la compañía. Una gran apuesta que espera poder ser presentada en el Professional Developers Conference de Los Ángeles en el mes de noviembre. Windows_Mobile_7_theme_by_brthtms

 

 

Uncategorized

SharePoint – NTLM vs Kerberos

En todas las instalaciones hay un punto crítico, esa pregunta que no tenemos muy clara  y que en ocasiones va acompañada de un texto recomendando una de las opciones, por si no sabemos muy bien qué es lo que estamos haciendo. MOSS no es una excepción.
La pregunta en cuestión llega cuando tenemos que decidir sobre la seguridad, la instalación de MOSS nos da a elegir entre sí usaremos NTLM ó Kerberos.
Como todos sabemos y Microsoft dice NTLM funciona para casi todo. De modo que suele ser la opción preferida de todos.  No hay que configurar nada y funciona.

Microsoft Windows Integrated Authentication supports the following two protocols that provide challenge/response authentication:

xa68twcb_impflow(en-us,VS_71)

NTLM

El protocolo NTLM es un protocolo seguro de que se basa en nombres de usuario y contraseñas cifradas, antes de enviar los nombres de usuario y contraseñas en la red. Se requiere autenticación NTLM en redes donde el servidor recibe solicitudes de los clientes que no admiten la autenticación de Kerberos.

Kerberos

Protocolo basado en tiquetes. Un usuario provee primero su nombre y clave al servidor de autenticación, el que genera un "tiquete" si las credenciales son aceptadas. El tiquete puede ser utilizado en la red para acceder recursos diferentes. Para usar este esquema, el cliente y el servidor deben tener una conexión de confianza con el servidor de dominio que mantiene el Key Distribution Center (KDC), y ambos deben estar conectados a un servicio de Directorio Activo (AD).

Kerberos por el contrario es un sistema de autentificación un poco más complejo, pero  también más seguro y más rápido (motivos por los cuales ya de por sí, debería ser la opción predilecta de todos).

Kerberos, es más rápido por que guarda en una cache (vales) la información del cliente después de que este se ha autentificado en el sistema, de modo que no tiene que estar comprobando las credenciales una y otra vez.
Otra de las características importantes de Kerberos es la Delegación, La delegación nos permite pasar las credenciales del cliente desde nuestro servidor front-end (SharePoint)  a nuestros servidores back-end (SQL Server etc..).
Cuando usamos NTLM, y deseamos acceder a recursos que están fuera de nuestro alcance, podemos suplantar al cliente (impersonate)  y usar la cuenta de suplantación para realizar las tareas necesarias.
¿Pero qué ocurre cuando tratamos de usar recursos que no están en la misma máquina que nuestro servidor web?, entonces la suplantación no es suficiente. Y se produce el efecto llamado Double-Hop

El double-hop mediante un token secundario se produce, por ejemplo, cuando el cliente del explorador se autentica a la página ASPX IIS utilizando la autenticación NTLM. En este ejemplo, el servidor IIS tiene una versión de hash de la contraseña como consecuencia del uso de NTLM. Si IIS gira en torno y pasa las credenciales a   Active Directory (AD), IIS está pasando una contraseña hash. AD no puede comprobar la contraseña y, en lugar de ello, se autentica mediante el LOGON NTAUTHORITY\ANONYMOUS.

Imaginemos que hemos realizado una solución para SharePoint que usa un servicio web o una conexión a un servidor SQL que se encuentra en una máquina distinta, y deseamos acceder usando la seguridad integrada (Integrated Security=SSPI) .

Al realizar la conexión nuestro servidor web debe ponerse en contacto con nuestro servidor SQL y este no es capaz de autentificar al usuario.
De modo que recibiremos un mensaje como:
Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’.

Como mencionaba anteriormente, esto es debido a que la suplantación no es válida, necesitamos algo más; Delegación.
Y esa delegación aunque cueste un poquito más configurarla es la que nos ofrece Kerberos.

Observación : Al instalar Windows SharePoint Services y optar por utilizar la autenticación de Kerberos, pero no configura la cuenta de dominio de que Windows SharePoint Services se está ejecutando como con un SPN (Service Principal Name), los usuarios no podrán iniciar sesión en el sitio de SharePoint. Aquellos usuarios que no son los administradores del equipo servidor recibirán múltiples mensajes de autenticación y recibirá el siguiente error:
HTTP Error 401.1 – Unauthorized: Access is denied due to invalid

Este escenario se produce en multitud de instalaciones de MOSS en donde usamos servicios de Excel, para recuperar datos de los servicios de análisis de SQL.

Un Post interesante sobre: NTLM con SharePoint:

La cual explica como se comporta el protocolo NTLM en su prueba de rendimiento (Latency).

la autorización es NTML. Yendo más adentro en el análisis, si intercepta los paquetes de comunicación entre el cliente y el servidor, vera que el handshake entre los dos ocurre más o menos de la siguiente forma:

1 – Cliente envía al servidor: GET (y otras cosas)
2 – Servidor devuelve al cliente: 401 Unauthorized, utilice NTLM
3 – Cliente envía al servidor: GET (otras cosas), Authorization: NTLM (mensaje 1)
4 – Servidor devuelve al cliente: 401 Unauthorized, utilice NTLM (mensaje 2)
5 – Cliente envía al servidor: GET (otras cosas), Authorization: NTLM (mensaje 3)
6 – Servidor devuelve al cliente: 200 Ok
Mensaje 1 contiene el nombre del host y el nombre del dominio NT del cliente
Mensaje 2 contiene el "desafío" ("Challenge") del servidor
Mensaje 3 contiene el nombre del usuario, del host, del dominio y dos "respuestas" al "desafío"

Y esto ocurre para cada elemento en la pagina que necesita autorización. O sea que se podrá imaginar, cada ida y venida, para cada elemento y todo multiplicado por 300 milisegundos de latencia, los tiempos de respuesta son de todo menos bonitos.

Es posible de evitar este fenómeno? Probablemente no, es algo que está enterrado profundamente en el protocolo del handshake. Lo único que se puede hacer es utilizar Kerberos.

Es algo de lo que tiene que preocuparse?

No, de ninguna manera si sus usuarios están al lado de los servidores de SharePoint en una intranet local;

SI, con toda seguridad si los usuarios están repartidos por todo el mundo y los servidores están regados por tres continentes. (Por así decirlo)

El problema de Kerberos es, por supuesto, que necesita tener un servidor para mantener las claves, pero eso se puede solucionar fácilmente.

Nota: La mayoría de las veces se puede utilizar NTLM; si no hay una necesidad especifica de usar Kerberos o si no puede configurar el Nombre de Servicio Principal (SPN), elija NTLM. Si utiliza Kerberos y no puede configurar el SPN, solamente los administradores del servidor podrán ser autenticados en SharePoint.