miércoles, 22 de abril de 2015

Tenga cuidado al invocar el objeto SPSite de incluir la zona

SharePoint desde su versión 2007 cuenta con un modelo de objetos para acceder los recursos y servicios de SharePoint vía programación a través de las soluciones de granja y recientemente en 2013 bajo el modelo de Aplicaciones o Apps.

La clase SPSite representa la colección de sitios dentro de una aplicación web de SharePoint.  Los constructores para instanciar en memoria SPSite son 6 el más utlizado es SPSite(string) donde definimos la dirección URL que deseamos invocar.

Para que necesitamos SPSite, pues bueno para programar en SharePoint debemos de respetar las jerarquías y cualquier objeto dentro de un sitio debemos de accederlo a través de su colección de sitios SPSite y luego de su sitio o subsitio con SPWeb.  Echemos un vistazo en la siguiente gráfica de la jerarquía de objetos en SharePoint.

Donde obtenemos vía programación la URL actual de la aplicación.  Pues es a través de la clase SPConext y sus propiedades Current.Web.URL, esta línea de código completa se lee así: SPContext.Current.Web.URL.

Si combinamos las dos clases para instanciar en memoria la clase SPSite se leería de la siguiente forma en C#:

SPSite miSitio = new SPSite(SPContet.Current.Web.URL);

y la forma correcta es utilizando using de la siguiente forma para que podamos eliminar efectivamente de memoria dicho objeto ya que SharePoint tiene aún dependencia de los servicios COM+ de Windows.  Vea las mejores practicas para utilizar los objetos de SharePoint en https://msdn.microsoft.com/en-us/library/aa973248(v=office.12).aspx

using(SPSite miSitio = new SPSite(SPConext.Current.Web.URL) {

//tu codigo…

}

Otra forma de instanciar en memoria este objeto es a través de su Guid o ID.  De la misma forma que obtenemos la URL Actual así obtenemos el Guid de la colección de sitios con la siguiente línea de comando en C#:

SPContext.Current.Site.ID

El código completo sería de la siguiente forma:

using(SPSite miSitio = new SPSite(SPConext.Current.Site.ID) {

//tu codigo…

}

Pero si la solución que estamos ejecutando esta corriendo sobre HTTPS y no es la zona predeterminada ambos código son dispararán error.   Que podemos hacer?… Pues utilizar el constructor donde podemos definir la zona actual con la siguiente línea de código para obtener la zona:

SPContext.Current.Site.Zone

Entonces el código completo combinando nuestros hallazgos sería el siguiente:

SPSite miSitioId = SPContext.Current.Site.ID;

var miZona = SPContext.Current.Site.Zone;

using(SPSite miSitio = new SPSite(miSitioId, miZona) {

//tu codigo…

}

 

 

y una aplicación típica de código para listar por ejemplo los elementos de una lista se vería de la siguiente forma:

SPSite miSitioId = SPContext.Current.Site.ID;

var miZona = SPContext.Current.Site.Zone;

using(SPSite miSitio = new SPSite(miSitioId, miZona) {

using (SPWeb miWeb = miSitio.OpenWeb()) {

SPList miLista = miWeb.Lists["Tasks"];

SPListItemCollection collItem = miLista.GetItems("Title", "Status");

foreach(SPListItem oItem in collItem) {

Response.Write(SPEncode.HtmlEncode(oItem["Title"].ToString()) + " :: " + SPEncode.HtmlEncode(oItem["Status"].ToString()) + "<BR>");

}

}

}

 

Espero haberles ayudado.

SharePoint4Fun!,

Juan Manuel Herrera Ocheita

miércoles, 1 de abril de 2015

Por qué es mejor ejecutar SharePonit en Azure que en su infraestructura local

 

Debido a la diversidad y efectividad de servicios disponibles en Microsoft ejecutar SharePoint Foundation o Server en Azure es estratégicamente mejor por lo siguientes aspectos:

1) Reducción del Costo Total de Propiedad:  Es mucho mas barato pagar una renta reducida al mes, que pagar energía, aire acondicionado, mantenimiento, soporte del equipo y especialización para mantener la infraestructura funcionando.

2) Disponibilidad de Servicios:  Fácilmente podemos habilitar servicios de Backup, Data Recovery, Alta Disponibilidad con un mínimo de esfuerzo y de forma inmediata, esto se traduce en reducciones de riesgo, costos operativos y de implementación. Y ante todo velocidad de respuesta efectiva.  No necesitamos cintas, los medios están almacenados geográficamente separados y los servicios son fáciles de implementar y los costos son relativos al consumo que hagamos de estos servicios.

image

3) Inversión paulatina:  No necesitamos realizar grandes inversiones tecnológicas por el contrario el gasto se va incrementando con el uso y los servicios que se van habilitando.  Por ejemplo las primeras dos semanas se configura la vpn, se crea el DC que se replicará localmente y se inicia la configuración de la granja las siguientes dos semanas.  Luego se puede migrar el contenido una o dos semanas, una vez tengamos el ambiente arriba podemos iniciar el proceso de habilitar el servicio de Backup de Azure.  Por lo que el primer mes consumimos una factura por lo que usamos y configuramos y el siguiente mes la del servicio de Backup un incremento mucho menor que se va sumando.  Luego en el futuro se desea habilitar servicios de alta disponibilidad se incrementará en cuanto a la maquinas virtuales adicionales que se agreguen en su momento.

image

4) Aprovechamiento de la economía a escala:  Esta es la razón por la que Azure es competitiva y una oferta económica viable para las empresas.  Grandes inversiones de infraestructura y desarrollo de software que permite que las empresas de todo tamaño puedan adquirir servicios tecnológicos a bajo costos sin preocuparse por mantener vivo el andamiaje tecnológico ya que es un servicio, el proveedor Microsoft se encarga del resto.

5) Pagas por lo que usas:  Esto es también importante, no tienen una fuerte inversión tecnológica que no usas, al contario tienes un entendimiento más claro como estas utilizando la tecnología y cuanto realmente te esta costando, con lo cual puedes hacer ajustes hacia abajo o hacia arriba según las necesidades.  Si tienes picos de carga de trabajo como fin de mes y quincena para tu portal de SharePoint por ejemplo y quieres mejorar el servicio puedes indicar a la infraestructura que se duplique procesamiento, memoria y luego regresar a la configuración anterior, esto lo puedes hacer manual o de forma automática.  Puedes probar un vez y el otro no y no tuviste que pagar una inversión alta de algo que no estabas tan seguro si valía la pena, por ejemplo.

image

6) Proteges la inversión y garantizas la continuidad del negocio: Hablar de Alta disponibilidad en el pasado era un reto técnico y una fuerte inversión que para muchas empresas era prohibitivo.  Con Availability Set en Azure esto es muy simple de configurar y solo te cobran por la máquina virtual en ejecución y no por toda la configuración física y lógica que esta atrás para disponer de alta disponibilidad.   Por diseño los centros de datos están configurados en Clusters y Azure dispone de Failover Host Clustering y Failover Guest Clustering para las Maquinas virtuales.

image

7) Mitigación de la reducción perdida de información: Hoy en día muchas aplicaciones de negocios no tienen ni siquiera un plan de recuperación y tampoco saben en cuanto tiempo ni que cantidad de información puedan perder, esto es una preocupación hoy en día que gracias a Azure disponemos de respuestas efectivas y concretas al tema a bajos costos.  Es tiempo de hacer un plan detallado de como vamos a recuperarlo y con que disponemos incluyamos Azure para este objetivo primordial y de alta prioridad para garantizar la menor perdida de información posible.

image

8) Disponible para todos desde cualquier dispositivo:  Para habilitar una extranet del portal de SharePoint en Internet, tenemos que pensar en un dominio público, una dirección IP Pública, un certificado SSL de terceros, firewall, una DMZ, NAT, Extender la aplicación Web en SharePoint, por lo que contar con esta infraestructura lista para usarse en SharePoint es algo que se agradece y mejora la velocidad con que entregamos una plataforma disponible para cualquier dispositivo desde cualquier lugar con acceso a la red de Internet.

image

image

9) Minimiza los tiempos de implementación:  Azure desde las galerias de imágenes que provisionan el sistema operativo o la aplicación como SharePoint o SQL Server permite que en menos de 5 minutos tengamos una VM disponible para finalizar de configurar.  Esto nos ahorra entre 3 a 5 horas de implementación.

image

image

Con el Nuevo Portal de Azure existe una nueva opción “Granja SharePoint” que permite crear una granja preconfigurada de 3 VMs o en alta disponibilidad de 9 VMs esta opción reduce drasticamente tiempo de instalación y configuración inicial ideal para ambientes de desarrollo y pruebas de concepto.

image

Luego de creada la granja aproximadamente 15 minutos.

image

En este articulo vimos 9 razones porque una granja en SharePoint es más mejor en Azure que en nuestras instalaciones de la red interna.  Reduciremos los costos de propiedad total, aseguraremos la inversión y muy probablemente estaremos listos para escalar, expandir los servicios de IT a través de Azure y estaremos apoyando de forma ágil y efectiva al negocio.

Hasta la próxima!, Azure&SharePoint4Fun!

Juan Manuel Herrera Ocheita

martes, 24 de febrero de 2015

Alternativas para autenticarse por Windows desde una granja de SharePoint migrada en Azure

Hay muchas aclaraciones que hacer con este tema, pero seré lo más conciso posible yendo al grano y resolviendo algunos mitos o malas concepciones sobre el tema.

Primero lo primero, definir el requerimiento del cliente.  Mover  la granja de SharePoint hacia la nube de permitiendo a los usuarios de la red interna o intranet autenticarse con sus mismas credenciales de su red interna en la instancia de Azure.

En este escenario hay un componente que define las opciones que tenemos disponibles y las que no.  A continuación las opciones disponibles en Azure hoy 14 de Febrero del 2015.  Ya que Azure evoluciona tan rápido que mejor hago referencia a la fecha en como estaban las cosas en ese momento.   Para las tres opciones es necesario establecer una VPN sitio a sitio entre Azure y la red interna del cliente.  Esto nos permite ver la red interna del cliente desde las Virtuales de Azure y viceversa como que si estuviésemos en la misma ubicación geográfica.  Entonces los servidores se configuran como el resto de servidores de la red interna, y perteneciendo al dominio o bosque al que se le indique en la configuración.  Las cuentas de servicio utilizadas en la instalación son del dominio de la intranet así que gracias al tunel privado de la VPN las dos redes son una misma red.  En Azure se crearon dos Virtuales una con SQL Server y otra con SharePoint Foundation 2013.  Se montó la base de datos de contenido de la granja local al ambiente creado en Azure.

Explicado eso enumeramos las 3 opciones posibles de configuración:

1) La autenticación de Windows sucede en el DC de la intranet a través de la VPN, si por alguna razón la VPN se interrumpe, los usuarios no podrán autenticarse a los servidores que están en Azure ni desde la red interna ni desde Azure.   https://msdn.microsoft.com/en-us/library/azure/dn636917.aspx

Resultado de imagen para vpn connection azure

2) Se adiciona otra virtual donde se configura el rol de Controlador de Dominio y se utiliza el AD Directory Service para definir un sitio en Azure basado en el rango de IPS definidas en la VPN sitio a sitio.  Esto permite que los usuarios se autentiquen con el DC configurado en Azure y en caso se pierda la conexión de la VPN los usuarios que accedan desde internet puedan autenticarse al SharePoint que esta en Azure, no así los de la intranet si utilizan el descubrimiento del DNS local sino el público con un enlace de Internet.  Esto da una mayor independencia de acceso con algunos inconvenientes. http://azure.microsoft.com/en-us/documentation/articles/virtual-networks-install-replica-active-directory-domain-controller/

https://msdn.microsoft.com/library/azure/jj156090.aspx

3) Se implementa AD FS o Active Directory Federation Service en azure, para ello se requiere como mínimo para menos de 1,000 usuarios tres servidores virtuales adicionales uno para AD FS y otro para AD FS Proxy o WAP (Web Application Proxy) y otro para DirSync.  Si son más de 1,000 usuarios se recomienda redundancia en los servidores AD FS, es decir para dar un total de 5 servidores.  Para esta ultima configuración se recomienda que el o los DC´s corran por lo menos sobre Windows 2008 R2 y utilizar el asistente de configuración el Azure AD Connect que aunque este en Preview, facilita la configuración de estos servidores.   Esta última opción es una solución Single Sign On real, que permite autenticar a los usuarios tanto de la red interna como la nube aunque la VPN falle.  Solo fallará si el enlace a internet no esta disponible desde donde se este accediendo.

https://technet.microsoft.com/en-us/library/hh831502.aspx

https://connect.microsoft.com/site1164/Downloads/DownloadDetails.aspx?DownloadID=53949

https://technet.microsoft.com/en-us/library/dn296436.aspx

http://simon-may.com/adfs-dirsync-waad-resources/

El escenario no disponible para resolver este problema es el siguiente:

Configurar un servidor virtual en Azure para sincronizar el directorio Activo local al Directorio de Azure.  Este escenario no funcionará ya que el contenido migrado tiene los permisos asignados a los usuarios de la red interna que están registrados en SharePoint con el formato tradicional de usuario de red [dominio]/[nombre usuario] y los usuarios del Directorio de Azure son reconocidos con el siguiente formato [Proveedor Azure]:[Nombre de Usuario en formato upn].  Además los usuarios de red utilizan el siguiente prefijo en el formato i:0#.w y los usuarios autenicados por el Directorio de Azure con el siguiente prefijo: i:0e.t .  (Dando a entender que el primero es Windows y el segundo externo). Este escenario esta pensado para usuarios externos que deseamos exponer información que vamos a compartir con ellos, por ejemplo proveedores, clientes o socios de negocios.

https://msdn.microsoft.com/en-us/library/azure/dn441214.aspx

https://technet.microsoft.com/en-us/library/dn635311.aspx

 

Que escenario escoger es dependiendo que tan crítico es la información almacenada en SharePoint y que tanto se desea invertir para mantener la disponibilidad del servicio todo el tiempo para los usuarios de la red de la organización para acceder dicho servicio tanto desde la red interna como del internet.

En este artículo vimos 3 escenarios para acceder la plataforma de SharePoint desde la nube pero autenticándonos con  los usuarios de la red interna lo que podemos catalogar como un ambiente híbrido. 

Les recomiendo revisen el siguiente artículo:

Planning for SharePoint 2013 on Azure Infrastructure Services

The SharePoint Server Farm feature

Hasta la próxima!,

Juan Manuel Herrera Ocheita

jueves, 19 de febrero de 2015

Cómo sincronizar los usuario y contraseñas locales con Azure AD para una instancia nueva de SharePoint 2013

El escenario es el siguiente:

Se desea crear una instancia nueva de una granja de SharePoint 2013 en la nube de Azure para reducir los costos de operación e inversión, el cliente solicita que los usuarios de su red interna puedan autenticarse con sus mismas credenciales en y con la mínima configuración posible.

Cuales son los requerimientos básicos entonces para este escenario:

1) Contar con una suscripción en Azure

2) Contar con una Directorio Activo Local

3) Realizar una Conexión VPN Sitio a Sitio desde el portal de Azuren

4) Una Virtual con Windows Server y AD DirSync para sincronizar los usuarios de la red interna con el Directorio Activo de Azure

5) Dos Virtuales conectadas al dominio local por medio de la VPN para SQL Server y SharePoint 2015

6) Configurar la Aplicación Web en SharePoint para utilizar el Directorio Activo de Azure como proveedor de autenticación

NOTA: Este escenario es valido si no se esta migrando contenido de SharePoint de la red interna a la nube de Azure, ya que a nivel de permisos en SharePoint el usuario de Windows la red interna se registra de otra forma distinta a la del proveedor de Azure.  El formato tradicional de usuario de red en SharePoint se registra de la siguiente forma: [dominio]/[nombre usuario] (Ej: midominio\elusuario) y los usuarios del Directorio de Azure son reconocidos con el siguiente formato [Proveedor Azure]:[Nombre de Usuario en formato upn] (Ej.: [Proveedor Azure]miusuario@midominio.com).  Además los usuarios de red utilizan el siguiente prefijo en el formato i:0#.w y los usuarios autenticados por el Directorio de Azure con el siguiente prefijo: i:0e.t .  (Dando a entender que el primero es Windows y el segundo externo).

Que beneficios nos provee Azure como plataforma.  Pues son muchos pero entre los que más se agradece son los siguientes:

1) Azure solo cobra por uso, es decir si tengo reservado un espacio de almacenamiento no me cobra por ello solo el  que ocupo.  No me cobra por la VM mientras este apagado por ejemplo.  O la VPN solo cuando este trasfiriendo paquetes de un lado a otro.

2) Se cuenta con IP públicas por cada máquina virtual y nombres públicos accesibles desde el internet

3) Una vez familiarizado con el portal y sus opciones, es relativamente fácil la configuración del ambiente y la seguridad, como por ejemplo habilitar o deshabilitar el acceso a las virtuales por Escritorio Remoto, HTTP, IMAP, etc.

4) Contar con Servicio de Directorio Activo disponible de forma inmediata, para utilizar como proveedor de autenticación en una granja de SharePoint.

Resumen del procedimiento

1) Adquirir una suscripción en Azure http://azure.microsoft.com/en-us/pricing/free-trial/

image

2) Establecer una VPN sitio a sitio https://msdn.microsoft.com/es-es/library/azure/dn636917.aspx

Topología de red

La idea fundamental de la VPN este establecer un tunel privado en Internet para conectar las dos redes (local/nube).   Para ellos es necesario de lado del cliente contar con un Equipo de enrutamiento de Red o Router. Es necesario para configurarlo asignar IPs de lado de Azure que no colisionen con el rango de IPs de la red interna y que el rango asignado de ambos lados sea el mismo.  Es muy importante en esta configuración manejar la misma máscara supongamos que en el ejemplo de arriba estamos usando al configuración 192.168.1.0/24 eso define una máscara de IP por lo que de lado de Azure debemos manejar la misma máscara es decir 192.168.2.0/24.  El rango de IP locales configuradas deberán contener las IPS donde están los servidores DC y DNS ya que más tarde se utilizaran para conectar las virtuales a ese dominio.  Para configurar la VPN Ambos tienen que conocer las puertas de enlaces, rangos de IPs y la llave Pre-Shared, y la información de ambas fases.  Por ejemplo: 

Puerta de enlace intranet es en el ejemplo de arriba 192.168.1.11 y de lado de Azure es  192.168.2.11.

Fase I

authentication:  pre-share

encryption: aes-256

hashing: hash sha

Key group: Deffi

lifetime: 28800

Fase II – Configuración IPSEC

esp-aes-256 esp-sha-hmac

lifetime seconds 3600

lifetime kilobytes 102400000

La información de las fases es extraída del script generado para los dispositivos como CISCO en el siguiente enlace:

image

Si es exitosa veras una imagen similar a la de abajo.

image

3) Establecer un grupo de afinidad geográfico para asociar máquinas virtuales.  Esto es importante para reducir el tiempo de retraso por la ubicación geográfica y para que las maquines se puedan ver entre ellas.

image

4) Una Virtual con Windows Server y AD DirSync para sincronizar los usuarios de la red interna con el Directorio Activo de Azure

Importante en este procedimiento es crear una cuenta de servicio en Azure AD y asignarle el permiso de Global Admin. Eso lo hacemos en la edición del perfil del usuario dentro del Active Directory de Azure como se muestra en la imagen de abajo.

image

Directory sync with password sync scenario

Para revisar los prerrequisitos de Azure Dir Sync el siguiente enlace:

https://msdn.microsoft.com/en-us/library/azure/jj151831.aspx?f=255&MSPPError=-2147217396

 

5) Crear las máquinas virtuales  http://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-tutorial/

image

Para crear las máquinas virtuales tenemos dos opciones de la galeria de Azure o bien de una imagen que hayamos subido.   En mi caso fue de una imagen que subimos ya que el cliente tenía su licencia de Windows.  Para ello fue necesario crear la virtual en Hyper-V instalar el sistema operativo del cliente y ejecutar la utileria sysprep para poder subir el archivo vhd, el resto del software lo podemos descargar vía suscripción desde el internet disponible en Azure luego de leventar la virtual.  El procedimiento para subir la vitual es la siguiente:

http://azure.microsoft.com/en-us/documentation/articles/virtual-machines-create-upload-vhd-windows-server/

6) Configurar la Aplicación Web en SharePoint para utilizar el Directorio Activo de Azure como proveedor de autenticación

Users authenticated with Azure Active Directory

Para realizar esta configuración los dejo con tres enlaces que los ayudarán.  Lean los detenidamente y que no se les pase ningún detalle.  Mucho ojo con los FQDN y URL que deberán indicar ya que allí pueden tener problemas, puede eliminar y crear de nuevo las reglas de grupo el Proveedor de Identidad WS-Federation o el certificado, sin problema, solo asegúrense de hacerlo bien.

Oficial de Microsoft:

https://technet.microsoft.com/en-us/library/dn635311(v=office.15).aspx

Artículo de Fuse Collaboraton services

http://www.fusecollaboration.com/fuseblog/Lists/Posts/Post.aspx?List=178d823a-3196-48e8-bb8f-743bfee59281&ID=74&Web=8df942bb-1ca5-4306-9004-53a7757edbb8

Y de Patterns & practices

https://msdn.microsoft.com/en-us/practices/dn635311(v=office.14)

En este artículo vimos como configurar un pequeña granja de SharePoint pero en la nube de Azure, una tendencia cada vez más común dentro de las organizaciones.

Hasta la próxima,

Juan Manuel Herrera Ocheita

domingo, 8 de febrero de 2015

SharePoint Server 2016 para el segundo semestre de este año

El anuncio a dejado una esperanza para mejora y sorpresa al mismo tiempo.  Ya que InfoPath continua vigente para esta próxima versión y será totalmente soportado en  SPO o SharePoint Online.

Dos aspectos sobresalientes del anuncio son prometen más poder a la comunidad de desarrolladores que es de 3 millones de personas.   A través de las APIs ya disponibles y otras nuevas que serán presentadas.  El modelo de Apps continua contrario a lo que algunos piensan.

Y el tema Ambientes híbridos que es la mejor forma de acoger la idea de la nube y del software como servicio.

 

Main graphic - new - 020215

También parece ser que las características de seguridad mejoraran finalmente esperemos un tablero que facilite la seguridad y revisión de los permisos para apoyar la administración de SharePoint.  Esperemos ver asistentes de configuración como las nuevas herramientas de Azure que ayudan la instalación de escenarios más rápida y fácilmente, como lo es AAD Connect http://connect.microsoft.com/site1164/program8612.

Quieres leer más al respecto aquí enlaces:

http://blogs.office.com/2015/02/02/evolution-sharepoint/

http://redmondmag.com/blogs/the-schwartz-report/2015/02/on-premises-sharepoint-2016.aspx

Hasta la próxima!,

 

Juan Manuel Herrera Ocheita

viernes, 30 de enero de 2015

Error OMS_6118 al intentar crear una suscripción en Azure para virtualizar SharePoint

El proyecto es tener una granja de SharePoint en Azure en un ambiente hibrido donde los usuarios de la red interna se puede autenticar en el portal de SharePoint con sus cuentas de Windows.

El problema que tuvimos fue que los créditos de Azure se compraron por licenciamiento Open y la cuenta registrada en Azure al momento de adicionar la suscripción daba el siguiente error:

Sorry, we could not complete the operation. Please try again later or reload the web page [OMS_6118]

La clave de la solución me la dio el sugiente comentario en el foro:

“I was having the same issue, tried about 20 times with no luck. But first time I checked the "Microsoft can contact me for marketing purposes" checkbox, I got my subscription created.”http://answers.flyppdevportal.com/categories/azure/azurebilling.aspx?ID=5ff93290-f7b0-4b2f-9b03-097e17dfc6c4

Al parecer el problema esta con la cuenta que estamos utilizando para agregar la suscripción en Azure.  Las cuentas de empresas se deben de registrar en el sistema de identidades de Microsoft como lo es live.com, y este a su vez se asocia a Azure.

La solución:

Sabiendo de antemano esto, ingrese a www.live.com y me autentique con la cuenta y sorpresa me dio la bienvenida (es decir el usuario nunca había ingresado a live.com a revisar su perfil). 

image

Valide el tema de aceptar correos y lo volví a guardar.   Regrese a Azure e intente de nuevo el mismo procedimiento y adivinen que paso… funcionó! Guiño

image

Eso es todo a partir de ello pudimos empezar a trabajar con la creación de la VPN para comunicar el ambiente local (On Premises) y de la Nube o sea Azure.

Así que SharePonit vive en Azure también en un ambiente híbrido con muchas posibilidades para crecimiento y escalabilidad.

Hasta la próxima!,

Juan Manuel Herrera Ocheita

jueves, 15 de enero de 2015

Los roles de la autenticación por formularios pareciera no funcionar en SharePoint 2013

 

La autenticación por formularios en SharePoint existe desde la versión 2007 y es la respuesta de Microsoft para proveer otra forma de autenticación que no sea a través del Directorio Activo.  Este método de autenticación a evolucionado con las versiones más recientes de SharePoint y se ha convertido en una implementación más de la autenticación basada en reclamos permitiendo al administrador de IT o consultor de SharePoint personalizar el método de autenticación elegido de forma muy flexible.

En este artículo resolveremos el acertijo porque no funciona el rol de FBA dentro de un grupo de SharePoint y cual es la aplicación correcta.

En la imagen de abajo muestra el flujo de autenticación de una implementación por formularios.  Fundamentalmente el usuario navega a la URL del sitio de SharePoint y al momento de autenticarse es redirigido a una página aspx donde le solicita el usuario y la contraseña esta solicitud es trasladada al servicio en SharePoint para autenticar los usuarios el cual es conocido como Security Token Service o STS este valida el tipo de autenticación que en este caso es Autenticación basada en Reclamos y en una implementación de Formularios el cual conoce que su proveedor de membresía es una base de datos en SQL Server y allí valida que exista el usuario, que sea valida su contraseña y luego si es válida pasa al proceso de autorización sino lo es es rechazada la solicitud.

Forms-based authentication process

La implementación del repositorio de credenciales en la autenticación por formularios es a través de una implementación de base de datos denominada ASP.NET membership and role providers.  Dentro del esquema de base de datos se almacena los usuarios y los roles y la combinación de ambos. 

Expanded aspnetdb_claim node

Podemos concluir que los Roles es una forma de agrupar los usuarios dentro de esta implementación. 

EXEC aspnet_Roles_CreateRole 'MyAppName', 'Employee'
EXEC aspnet_Roles_CreateRole 'MyAppName', 'TeamManager'
EXEC aspnet_Roles_CreateRole 'MyAppName', 'CEO'

EXEC aspnet_UsersInRoles_AddUsersToRoles 'MyAppName', 'bob', 'Employee', 8
EXEC aspnet_UsersInRoles_AddUsersToRoles 'MyAppName', 'mary', 'TeamManager', 8
EXEC aspnet_UsersInRoles_AddUsersToRoles 'MyAppName', 'jack', 'CEO', 8
EXEC aspnet_UsersInRoles_AddUsersToRoles 'MyAppName', 'jack', 'Admin', 8

Por tanto los Roles a diferencia de los usuarios deben de aplicarse directamente a los permisos del sitio y no a otro grupo de SharePoint.  En ocasiones hemos aplicado a grupos de SharePoint y SharePoint no logra descubrir los permisos del usuario, en cambio por el otro lado si ha funcionado.


SharePoint4Fun!,


Juan Manuel Herrera Ocheita