Archivos de etiquetas: SSO

Buenas prácticas en Alfresco ECM

Verión: 1 – Revisión: 0 – Publicación: 4/10/2011 – Última modificación: 4-oct-2011

Introducción
La instalación de Alfresco ECM requiere de una requisitos previos así como unas acciones posteriores para que el sistema comience a funcionar correctamente y se mantenga «sano» surante todo el tiempo que esté gestionando la documentación y registros. Este artículo pretende ser solamente un compendio de consejos y buenas prácticas y por tanto se irá modificando y ampliando en la medida de lo posible.

El ciclo de instalación, configuración y mantenimiento de Alfresco ECM comprende las siguientes fases:

Fase de preparación
1.    Diseñar tanto la arquitectura física como la arquitectura lógica antes de comenzar la instalación, si bien pueden usarse diagramas mixtos, es preferible realizar estos diseños por separado lo que nos dará también la posibilidad de generar lo sentregables para los distintos departamentos (comunicaciones y hardware, sistemas, etc.)
2.    Utilizar arquitecturas de 64 bits preferentemente, tanto a nivel de Hardware como Software (Sistema Operativo, Máquina Virtual de Java, etc.). Esto es muy importante en la medida en que en sistemas de 32 bits. se limita a nivel de direccionamiento de memoria principalemente.
3.    Usar procesadores de doble núcleo como mínimo y procesadores de 2,5GHz. en adelante.
4.    Usar la matriz de compatibilidad establecida por Alfresco para la instalación de todos los componentes: http://www.alfresco.com/services/subscription/supported-platforms/
5.    Adecuar la instalación a la arquitectura planteada y verificar la disponibilidad de recursos (NAS/SAN, SGDB,…) y que estos están disponibles, que son montados en el inicio de la máquina o al menos antes de arranque de Alfresco ECM.

Ejemplos (en Linux/Unix/MacOS X):
   Comprobar las unidades montadas para verificar su existencia: mount
   Verificar la correcta escritura: touch prueba

Comprobar que el servidor de la SGDB está funcionando: ping servidorsgdb
6.    Verificar la disponibilidad de los puertos que son necesarios para la instalación. Algunos puertos importantes para Alfresco son los siguientes:

  • a.    FTP: TCP 21 (se recomienda desconectar)
  • b.    SMTP: TCP 25
  • c.    SMB / NetBT: UDP 137,138, TCP 139,445 (para determinados entornos no es aconsejable)
  • d.    IMAP: TCP 143
  • e.    SharePoint Protocol: TCP 7070
  • f.    Tomcat Administration: TCP 8005
  • g.    HTTP: TCP 8080 (Tomcat, JBoss,…) / 9080 (para WebSphere) /…
  • h.    RMI: TCP 50500

Ejemplos (en Linux/Unix/MacOS X):
   Comprobar la existencia del puerto SMTP: telnet servidoralfresco 25
   Otra forma de comprobar que el puerto está abierto: nmap -P0 -p T:21,25,110,8080 servidoralfresco
   Puertos abiertos en el mismo servidor: netstat -putan

7.    Verificar la correcta comunicación tanto a nivel de fiabilidad como de estabilidad, verificar la latencia y rapidez de las transferencias:

  • a.    Conexión con el SGBD.
  • b.    I/O del disco que almacena los índices de Lucene.
  • c.    I/O del disco que almacena el repositorio.
  • d.    Conectividad entre los nodos (clúster).
  • e.    Conectividad con servidor NTP.

 Ejemplos (en Linux/Unix/MacOS X):
   Comprobar la transferencias a discos locales cada 2 segundos: iostat -w 2
   Visualizar las estadísticas de red cada 2 segundos: netstat -s -p tcp -w 2

8.    Comprobar la configuración con el SGDB con un DBA certificado así como la configuración del sistema de almacenamiento del repositorio con un experto certificado en el sistema de archivo usado (GFS, OCFS, VxFS, etc.). Es muy aconsejable que tanto la SGBD como el lugar donde se aloja el repositorio se conecten mediante “fibre channel” para evitar excesivas latencias y lentitud en las transacciones.
9.    Usar Alfresco Environment Validation Tool (Alfresco EVT) para validar el entorno (http://code.google.com/p/alfresco-environment-validation/)

Fase de instalación
1.    Crear una plantilla estándar adecuada al tipo de instalación y entorno con “checks” de control de las tareas. Es importante que los técnicos que instalen los sistemas, rellenen correctamente estas hojas e indiquen todas las incidencias que encuentran.

2.    Verificar los parámetros para la instalación, espacio disponible en discos, memoria RAM de los equipos y memoria Heap/Stack/Perm a usar para la JVM según el fabricante soportado (SUN, ORACLE, etc.), descriptores posibles, máximas conexiones del servidor de aplicaciones así como de firewalls y proxies puestos delante de Alfresco ECM.

Recomendaciones básicas de memoria para producción:
– Heap (-Xmx): 4G
– Pila (-Xss): 256k
– Perm (-XX:MaxPermSize): 256m

Ejemplos (en Linux/Unix/MacOS X):
   Kernel: uname -a
   Datos del sistema: cat /proc/cpuinfo
   Verificar memoria: free
   Procesos java arrancados: jps -v
   Procesos java arrancados: ps -fea | grep java

3.    Utilizar las recomendaciones de Alfresco para la ubicación de los archivos:

  • a.    ${TOMCAT_HOME}/shared/classes/extension/alfresco
  • b.    ${WEBSPHERE_HOME}/lib/alfresco
  • c.    ${JBOSS_HOME}/conf/alfresco

4.    NO incluir nunca ficheros de configuración en el despliegue de Alfresco ECM excepto por parte de módulos.
5.    Usar SIEMPRE módulos (mmt) para la instalación de nuevas funcionalidades, personalizaciones y configuraciones de Alfresco ECM.
6.    Usar las recomendaciones de Alfresco para la creación de ficheros de propiedades y XML y el uso de las normas estándar para la lectura de ficheros de configuración de Spring Framework.
7.    Puede utilizarse NFS con SAN para entornos clúster de repositorio compartido (solo a partir de la versión 3.4 según Alfresco) aunque es recomendable la utilización de sistemas de ficheros de clúster/concurrencia como GFS, OCFS, VxFS, etc.
8.    Los índices de Apache-Lucene deben ir siempre en el sistema local o en su defecto en NAS. A partir de la versión 4 de Alfresco ECM podrá utilizarse Solr.
9.    Es preferible tener en el “extension” una copia de log4j.properties como custom-log4j.properties para gestionar la salida de información de los logs.
10.    Aunque no es parte de Alfresco ECM, hay que medir cuidadosamente los aplicativos que interactúan con este respecto a seguridad:

  • a.    Uso de SSL (HTTPS) para asegurar canales de comunicación. Si es posible, también entre los propios elementos de Alfresco ECM, como Alfresco Share y el repositorio.
  • b.    Configuración de sistemas de autenticación externa mediante CAS, AD-Kerberos, NTLM, etc. y usar Single Sign On (SSO) en la medida de lo posible.
  • c.    Usar puertos por encima del 1024 y usuario “no root” en las instalaciones en sistemas Linux/Unix.

11.    No es recomendable balancear los protocolos TCP como CIFS/SMB, FTP y NFS que Alfresco ECM ofrece como servicios debido a problemas de bloqueos en JLan hasta aviso de Alfresco ECM y por lo menos hasta la versión actual (3.4.x). Sí es posible balancear HTTP/HTTPS y WebDAV. Una posible arquitectura siguiendo esta recomendación sería la siguiente:

12.    NO USAR JAMÁS EL USUARIO ROOT, crear un usuario tomcat, alfresco, jboss, etc. con los privilegios apropiados (acordarse de que en máquinas con Linux/Unix/MacOS X no pueden usarse puertos por debajo del 1024 por defecto).
13.    Es muy aconsejable que siempre se realicen 3 tipos de instalación, una para la parte de desarrollo y personalización, otra para preproducción o “Quality Service” que sirva para realizar pruebas antes de desplegar en producción, y una tercera instalación para producción. El entorno de desarrollo puede ser “no cluster” siempre y cuando no dependa dicho desarrollo de elementos própios de este. El entorno de preproducción y producción deben ser totalmente idénticos excepto en el tema de arquitectura hardware, es decir, puede ser un entorno con máquinas virtuales en preproducción y con máquinas físicas o virtuales con mayor asignación de recursos en producción. Así mismo, la carga de datos entre preproducción y producción tiene que ser lo más parecida posible, siempre al menos de un 50% de carga entre uno y otro para no tener problemas posteriores en cuanto a límites.

Fase de configuración y tuning
1.    Comprobar que la configuración de la codificación tanto en el SO, la SGDB, sistema de ficheros y JVM están en UTF-8. Ejemplos:

  • a.    En JVM de SUN y JRockit de IBM: -Dfile.encoding=UTF8
  • b.    En MySQL (my.cnf): default-character-set=utf8
  • c.    En Oracle, debe realizarlo un DBA.

2.    Usar autenticación con Single Sign On (SSO) en lo posible a través de AD-Kerberos o CAS siendo CAS el recomendable actualmente.
3.    Establecer los parámetros de monitorización en el arranque (JMX)
Ejemplo:
   Para monitorizar con jconsole: jconsole service:jmx:rmi:///jndi/rmi://servidoralfresco:50500/alfresco/jmxrmi
 
4.    Verificar parámetros de configuración y optimización del SGBD siempre a través de personal DBA certificado. Por ejemplo:

  • a.    MySQL: ANALYZE   
  • b.    PostgreSQL: VACUUM y ANALYZE
  • c.    Oracle: Dependiente de la versión, debe realizarse por un DBA.
  • d.    MS-SQL Server: ALTER INDEX REBUILD, UPDATE STATISTICS
  • e.    DB2: REORGCHK, RUNSTATS

5.    Utilizar los parámetros de optimización aconsejados por Alfresco:

  • a.    Ajustar pool de conexiones de Alfresco, se recomiendan 225 en adelante para el uso de protocolo CIFS/SMB. En WebSphere, Tomcat, Jboss, etc. Se pueden gestionar las conexiones a través de JNDI. En este caso, hay que tener en cuenta si el que controla los parámetros de conexiones máximas, mínimas, tiempos de espera para cierre de conexiones, etc. es Alfresco ECM o el mismo servidor de aplicaciones. Por ejemplo para WebSphere se pueden modificar los valores correspondientes desde la Consola de administración, en Recursos->JDBC->Orígenes de datos->(origen)->Propiedades de la agrupación de conexiones.

   db.pool.max=275

  • b.    Deshabilitar el uso de máximo de conexiones abiertas, es decir, no espera un tiempo en los que la conexión no responde para cerrarla. Igual que en el punto anterior, hay que modificarlo en la consola de administración de WebSphere o ficheros necesarios en otros servidores de aplicaciones.

   db.pool.idle=-1

  • c.    Esteblecer un tamaño de consultas (registros) mayor al establecido por defecto (10 registros).

   hibernate.jdbc.fetch_size=150

  • d.    Desactivar la parte de almacenamiento de transacción atómica para los índices y las transacciones de indexación «atómicas», SOLO EN EL CASO DE IMPORTACIONES Y SUBIDAS MASIVAS DE DOCUMENTOS.

   lucene.maxAtomicTransformationTime=0
   index.tracking.disableInTransactionIndexing=true

  • e.    Si no se van a usar “quotas” de espacio, se aconseja desconectarlas ya que suponen tiempo de cálculo.

   system.usages.enables=false

  • f.    Usar JodConverter en lugar de la integración directa con OpenOffice.org deshabilitando esta última ya que si no Alfresco levantará dos instancias de OpenOffice.org. También es aconsejable usar un servidor independiente para realizar todas las conversiones.

   ooo.enabled=false
   jodconverter.enabled=true

  • g.    En clúster usar JGroups con conexiones TCP (para controlar mejor las conexiones).
  • h.    En clúster usar el “tracking” cada 5 segundos.

   index.tracking.cronExpression=0/5 * * * * ?

  • i.    En sistemas con muchos documentos y consultas Apache-Lucene muy genéricas, el resultado puede contener muchas filas y tardar mucho tiempo. Para evitar que salgan menos filas de las solicitadas hay que adaptar los parámetros system.acl.maxPermissionCheckTimeMillis y system.acl.maxPermissionChecks, pe. Para la salida de hasta 30000 filas cuya consulta dura menos de 5 minutos sería:

   system.acl.maxPermissionCheckTimeMillis=300000
   system.acl.maxPermissionChecks=30000

  • j.    Si es necesario indexar todo el contenido del documento y este tiene más de 10000 términos, hay que ajustar el valor lucene.indexer.maxFieldLength para que indexe todo el contenido. Por ejemplo, para que indexe contenidos con hasta 150000 palabras:

   lucene.indexer.maxFieldLength=150000

  • k.    Configurar correctamente y verificar su acceso a las utilidades utilizadas por Alfresco ECM:

   ImageMagick 
   Pdf2swf
   OpenOffice.org

  • l.    Realizar pruebas de carga y estrés antes de la puesta a producción mediante herramientas especializadas, p.e. JMeter.
  • m.    Adaptar valores de EHCache a los nodos, usuarios, permisos (ACLs), tickets de autenticación, etc. para que no se llene.

Desarrollo y personalización
Extensión del modelo de datos
1.    Usar la indexación por tokens en los casos necesarios, p.e. para metadatos que usan caminos, códigos o palabras sin significado semántico es mejor usar solamente la indexación por cadenas (strings).

Por ejemplo, si se tiene un metadato llamado “sección” que almacena una sección en particular como valor único, se podría definir como:


        d:text
       
        true
        false
        false
       
 

2.    Utilizar ficheros independientes por modelo de datos así como de prefijos para clarificar los desarrollos.
3.    NO usar nunca los modelos de ejemplo que vienen en Alfresco ECM.
4.    Es preferible usar Aspectos a Tipos e intentar crear tipos básicos heredados de los que Alfresco ECM incluye por defecto.
5.    Usar solamente los metadatos que van a ser usados en búsquedas en el gestor documental directamente y que tengan relevancia dentro de la gestión documental.
6.    Usar restricciones donde hagan falta (CONSTRAINTS) y reutilizarlas.
7.    Evitar en la medida de lo posible muchas asociaciones (ASSOCIATIONS), ya que Alfresco ECM no es un sistema relacional.
8.    No cambiar el modelo original de Alfresco ECM bajo ningún concepto.
9.    No eliminar modelos y aspectos si no se tiene total seguridad de que no han sido usados nunca.
10.    Evitar complejidades innecesarias en los modelos así como excesiva profundidad en la estructura.
11.    El modelo de datos dedicado a permisos y roles no puede ser movido del lugar del despliegue actualmente y hay que ser muy cauto a la hora de crear nuevos roles.
12.    Se aconseja no modificar los roles actuales.

Interoperabilidad
1.    Usar CMIS a través de RESTful principalmente (versión 3.4 en adelante) o en su defecto WebServices a través de SOAP para mantener la interoperabilidad, escalabilidad y estandarización.
2.    Comunicarse a través de aplicaciones mediante tecnologías SOA. Capas intermedias de middelware, buses de integración, fachadas de servicios y sistemas centralizados de control.
3.    Usar las AFC (Alfresco Foundation Classes) solo en casos muy específicos.
4.    Si es necesario personalizar/desarrollar directamente en Alfresco ECM, es preferible realizarlo a través de WebScripts, Reglas/Acciones y Workflows en lugar de desarrollar directamente clases Java.
5.    Es desaconsejado el uso de JCR ya que está obsoleto.

WebScripts/JavaScripts – Surf
1.    Incluir los ficheros de scripts en los lugares adecuados del extensión en lugar del despliegue o en su defecto crear un módulo de Alfresco ECM para instalarse de forma limpia usando el mmt (Module Management Tool) de Alfresco ECM.
2.    Usar librerías comunes mediante “includes” y reutilizar código.
3.    Realizar depuraciones mediante el depurador incluido en Alfresco ECM.
4.    Evitar mucha recursividad al recorrer nodos ya que puede llenar la memoria de pila, o bien, ampliar el espacio de esta en la configuración.
5.    Dirigir los desarrollos hacia la plataforma Spring-Surf.

WebServices
1.    Evitar la transferencia de grandes ficheros mediante mensajes SOAP. Usar para ello el Servlet que incorpora Alfresco ECM.
2.    Minimizar las transferencias de información en tareas reiterativas. Por ejemplo, es preferible la llamada a un WebScript que devuelva en formato JSON/Atom/Text la lista de usuarios que realizar N llamadas desde el WebService cliente.

Búsquedas y consultas
1.    Adecuar los motores de búsqueda de Alfresco ECM al tipo de consulta y resultado requerido XPath/Lucene/CMIS-SQL.
2.    Es recomendable ir hacia consultas vía CMIS (cmis-strict) para estandarizar lo máximo posible.
3.    Intentar optimizar las consultas Lucene/CMIS para que devuelva pocos resultados.

Autenticación y seguridad
1.    Usar alf_ticket como método de mantener sesiones autenticadas en lugar de el uso de autenticaciones usuario/contraseña contínuas, así como JSESSIONID para el caso de mantener rutas en balanceadores. Se recomienda legar el uso de autenticaciones a Alfresco ECM y sistemas dedicados a esta tarea como CAS, AD-Kerberos, etc.
2.    Almacenar los datos “sensibles” de forma “ofuscada” o encriptada.

Mantenimiento
1.    Monitorizar la JVM, Servidor de Aplicaciones y la instancia de Alfresco ECM mediante Jconsole/VisualVM, IBM WebSphere Console, etc.
2.    Realizar seguimientos de tráfico entre los componentes de Alfresco ECM (WebClients y Repositorio, Alfresco y SGBD, etc.) para detectar grandes cargas, tráfico alto y cuellos de botella usando comandos como ntop, iostat, netstat, etc.
3.    Reindexar todo cuando se hayan cambiado valores de configuración de Apache-Lucene así como si se detecta corrupción en los índices. Esto es muy importante para mantener estable el sistema. Se puede usar la consola de chequeo de índices de Alfresco ECM para reindexar por fechas, transacciones, etc. Por ejemplo: http://servidoralfresco:8080/alfresco/service/enterprise/admin/indexcheck
4.    Estudiar las salidas (logs) constantemente prestando especial atención a mensajes de aviso (Warnings) y errores (Errors) y filtrando convenientemente:

Ejemplo:
Salida controlada de errores de log en un WebSphere: tail -2000f /opt/WebSphere/AppServer70/profiles/AppSrv01/logs/alfresco/SystemOut.log | grep » E «

5.    Utilizar herramientas como NAGIOS/ICINGA para monitorizar puertos, memoria, CPU, etc.
6.    Usar sistemas de mensajes SMS y alertas de seguimiento en los sistemas en producción.

Bibliografía
Documentos y libros
Título: Alfresco Day Zero Configuration Guide.pdf
Autor: Peter Monks

Título: Administering_an_Alfresco_Enterprise_3_4_0_Production_Environment.pdf
Autor: Alfresco

Título: Escalabilidad y tuning.pdf
Autor: Toni de la Fuente

Título: Scale your Alfresco Solutions. Architecture, Design and Tuning Best Practices
Autor: Gabriele Columbro

Titulo: Alfresco Developer Guide
Autor: Jeff Potts

Blogs:
http://www.blyx.com
http://www.fegor.com
http://ecmarchitect.com/

Webs:
http://docs.alfresco.com
http://www.juntadeandalucia.es/xwiki/bin/view/MADEJA/ArqSIAlfresco

SSO con Active Directory Kerberos en Win2k3 para Alfresco 3.4 en CentOS 5.5

El escenario propuesto es el siguiente:

Servidor de Alfresco:
Linux: CentOS 5.5 (i686)
Alfresco: 3.4.0 Enterprise
Tomcat: 6.0.29
MySQL: 5.0.77 (i686)
JVM (Sun): 1.6.0_22-b04 (32 bits)

SAMBA: 3.0.33
Nombre de la máquina: alfpru

Servidor PDC (Primario del dominio):
Windows: 2003 Server SP1
Nivel funcional: Windows Server 2003
Active Directory: in2pruebas
Nombre de la máquina: winsrv

Primero hay que preparar el Active Directory para Kerberos, y sobre todo para que funcione la aplicación share de Alfresco.

Si se tiene alguna duda se puede consultar la siguiente dirección: http://wiki.alfresco.com/wiki/Alfresco_Authentication_Subsystems#Kerberos

Se crean en Active Directory dos usuarios:

Nombre: Alfresco HTTP
Usuario: alfrescohttp
Passwd: laquesea

Nombre: Alfresco CIFS
Usuario: alfrescocifs
Passwd: laquesea

En ambos, después de la contraseña, se desmarca la casilla de «El usuario debe cambiar la contraseña en el siguiente inicio de sesión», y se marcan las casillas «La contraseña nunca caduca» y «No pedir la autenticación Kerberos previa». Así mismo, si estuviera marcada, hay que desmarcar la casilla «Usar tipos de cifrado DES para esta cuenta». Estas casillas se encuentran en las propiedades del usuario dentro de «Usuarios y equipos de Active Directory», en la pestaña «Cuenta».

Bien, ahora hay que usar un comando que está dentro del Kit de Recursos de Windows 2003 Server, dentro de «Utilidades de soporte». Este comando se llama ktpass.exe y es el que genera las tablas de claves para poder identificar el servicio.

Aquí es donde me he encontrado problemas, las mayores dificultades para configurar Alfresco con AD-Kerberos está en la generación de estos ficheros, ya que existen varias versiones de la utilidad ktpass.exe. En mi caso tengo dos comandos ktpass.exe, uno del 24/03/2005 y otro del 17/02/2007. Finalmente he creado los ficheros con la última versión.

Los comandos son:

ktpass -princ cifs/alfpru.in2pruebas@IN2PRUEBAS -pass elquesea -mapuser IN2PRUEBASalfrescocifs -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out c:tempalfrescocifs.keytab

ktpass -princ HTTP/alfpru.in2pruebas@IN2PRUEBAS -pass elquesea -mapuser IN2PRUEBASalfrescohttp -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out c:tempalfrescohttp.keytab

Luego hay que crearlos como servicios dentro del Active Directory como sigue:
setspn -a cifs/alfpru alfrescocifs
setspn -a cifs/alfpru.in2pruebas alfrescocifs

setspn -a HTTP/alfpru alfrescohttp
setspn -a HTTP/alfpru.in2pruebas alfrescohttp

Y se copian los ficheros (alfrescocifs.keytab y alfrescohttp.keytab) creados en la máquina Linux en, por ejemplo, /etc/alfresco.

Ahora, en la máquina Linux:

Seguidamente vamos a unir la máquina Linux al dominio de Windows 2003 (PDC) ya que si no, sería imposible establecer una «confianza» para realizar la autenticación para que los administradores de Windows tengan constancia de esta máquina, además este proceso también modifica el DNS de Windows 2003 Server para tener acceso vía TCP/IP aunque como bien me ha señalado iblanco no es necesario este paso para realizar simplemente la autenticación con Active Directory Kerberos.

Para ello se usa SAMBA, se instala:

yum install samba

…se configura el fichero /etc/samba/smb.conf como:

[global]
    workgroup = in2pruebas
    server string = Samba Server Version %v
    password server = in2pruebas
    realm = IN2PRUEBAS
    security = ads
    idmap uid = 10000-20000
    idmap gid = 10000-20000
    winbind separator = +
    template shell = /bin/false
    winbind use default domain = false
    winbind offline logon = false
    security = ADS

…se arranca:

service smb start

…se utiliza el comando «net» para unir la máquina al dominio de la seguiente forma:

net ads join –S winsrv.in2pruebas –n alfpru –U Administrador

…y ya se puede parar el servicio de SAMBA:
service smb stop

(Nota: Hay que repasar el fichero /etc/hosts y que las IPs apunten a los host y dominio correspondiente)

Se configura el fichero /etc/krb5.conf como:
[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log
[libdefaults]
 default_realm = IN2PRUEBAS
 default_tkt_enctypes = rc4-hmac
 default_tgs_enctypes = rc4-hmac
 dns_lookup_realm = false
 dns_lookup_kdc = true
[realms]
 IN2PRUEBAS = {
  kdc = winsrv.in2pruebas:88
  admin_server = winwrv.in2pruebas
 }
[domain_realm]
 .winsrv.in2pruebas = IN2PRUEBAS
 winsrv.in2pruebas  = IN2PRUEBAS
[appdefaults]
  forward=true
  forwardable=true
  proxiable=true

Dentro de la máquina virtual (JVM de Sun), concretamente en la parte de la JRE y en una ruta parecida a la siguiente: /usr/java/jre/lib/security existen dos ficheros que hay que configurar. El primero es java.login.config y se configurará como sigue:
Alfresco {
    com.sun.security.auth.module.Krb5LoginModule sufficient;
};
AlfrescoCIFS {
    com.sun.security.auth.module.Krb5LoginModule required
    storeKey=true
    useKeyTab=true
    keyTab=»/etc/alfresco/alfrescocifs.keytab»
    principal=»cifs/alfpru.in2pruebas»;
};
AlfrescoHTTP {
    com.sun.security.auth.module.Krb5LoginModule required
    storeKey=true
    useKeyTab=true
    keyTab=»/etc/alfresco/alfrescohttp.keytab»
    principal=»HTTP/alfpru.in2pruebas»;
};
ShareHTTP {
    com.sun.security.auth.module.Krb5LoginModule required
    storeKey=true
    useKeyTab=true
    keyTab=»/etc/alfresco/alfrescohttp.keytab»
    principal=»HTTP/alfpru.in2pruebas»;
};
com.sun.net.ssl.client {
    com.sun.security.auth.module.Krb5LoginModule sufficient;
};
other {
    com.sun.security.auth.module.Krb5LoginModule sufficient;
};

Y el fichero java.security también hay que editarlo para indicarle donde está el fichero de configuración anterior, en la línea siguiente:

login.config.url.1=file:/usr/java/jre/lib/security/java.login.config

Como se observa, en el fichero java.login.config se establecen a su vez los directorios donde se encuentran los ficheros keytab.

Para la instalación de Alfresco se ha utilizado el fichero alfresco-enterprise-3.4.0.zip, se descomprime y se copian los directorios que hay dentro de web-server de forma recursiva dentro del servidor de aplicaciones que ya tengamos instalado.
Por ejemplo:

cd /opt
make alfinst
cd alfinst
unzip /home/fegor/Downloads/alfresco-enterprise-3.4.0.zip
cp -rf webserver/conf /opt/alfresco_340/tomcat
cp -rf webserver/lib /opt/alfresco_340/tomcat
cp -rf webserver/shared /opt/alfresco_340/tomcat
cp -rf webserver/webapps /opt/alfresco_340/tomcat

Se crea la base de datos:

mysql -u root -p

CREATE DATABASE alfresco340;
GRANT ALL ON alfresco340.* to ‘alfresco’@’localhost’ identified by ‘alfresco’;
FLUSH PRIVILEGES;
EXIT

Se realiza la configuración global o general de Alfresco en el fichero alfresco-global.properties:

dir.root=/opt/alfresco_340/repositorio
db.name=alfresco340
db.username=alfresco
db.password=alfresco
db.host=localhost
db.port=3306
db.driver=org.gjt.mm.mysql.Driver
db.url=jdbc:mysql://${db.host}:${db.port}/${db.name}
authentication.chain=kerberos:kerberos

 Lo primero es comentar la línea «authentication.chain» y arrancar la instancia de Alfresco para comprobar su funcionamiento y su despliegue. Una vez desplegado ya podemos usar el subsistema «Authentication» para poder establecer la configuración de Kerberos.

Hay que copiar desde webapps/alfresco/WEB-INF/classes/alfresco/subsystems/Authentication/kerberos a shared/classes/alfresco/extension/subsystems/Authentication/kerberos/, quedando finalmente como: shared/classes/alfresco/extension/subsystems/Authentication/kerberos/kerberos y dentro habrá cuatro ficheros que son:
kerberos-authentication-context.xml
kerberos-authentication.properties
kerberos-filter-context.xml
kerberos-filter.properties

De estos, los ficheros con extensión «properties» son los que hay que configurar como sigue:

El fichero kerberos-authentication.properties:

kerberos.authentication.realm=IN2PRUEBAS
kerberos.authentication.user.configEntryName=Alfresco
kerberos.authentication.defaultAdministratorUserNames=Administrador
kerberos.authentication.cifs.configEntryName=AlfrescoCIFS
kerberos.authentication.cifs.password=laquesea
kerberos.authentication.authenticateCIFS=true

El fichero kerberos-filter.properties:
kerberos.authentication.http.configEntryName=AlfrescoHTTP
kerberos.authentication.http.password=laquesea
kerberos.authentication.sso.enabled=true
kerberos.authentication.browser.ticketLogons=true

Ahora, para tener acceso a CIFS vía Kerberos hay que copiar también la rama webapps/alfresco/WEB-INF/classes/alfresco/subsystems/fileServers/default a shared/classes/alfresco/extension/subsystems/fileServers/default/default (igualmente debe haber dos niveles de directorio llamados default), y se modifica el fichero file-servers.properties como sigue:
filesystem.name=alfpru
filesystem.acl.global.defaultAccessLevel=
cifs.enabled=true
cifs.serverName=alfpru
cifs.domain=in2pruebas
cifs.broadcast=255.255.255.255
cifs.bindto=
cifs.ipv6.enabled=false
cifs.hostannounce=true
cifs.disableNIO=false
cifs.disableNativeCode=false
cifs.sessionTimeout=900
cifs.urlfile.prefix=http://alfpru
cifs.tcpipSMB.port=445
cifs.netBIOSSMB.sessionPort=139
cifs.netBIOSSMB.namePort=137
cifs.netBIOSSMB.datagramPort=138
cifs.WINS.autoDetectEnabled=false
cifs.WINS.primary=1.2.3.4
cifs.WINS.secondary=5.6.7.8


Además recomiendo desconectar tanto FTP como NFS dentro del mismo fichero como:

ftp.enabled=false
nfs.enabled=false

Ya solo queda la configuración de la parte «share», esta se encuentra en: shared/classes/alfresco/extension/web-extension en el fichero share-config-custom.xml.sample, hay que renombrar este fichero como share-config-custom.xml y configurar la sección «KerberosDisabled», eliminando la palabra Disabled y descomentando el bloque que viene a continuación con la condición «Remote». Ambos bloques se configuran como sigue:
  
  
  
     
         <!–
            Password for HTTP service account.
            The account name *must* be built from the HTTP server name, in the format :
               HTTP/@
            (NB this is because the web browser requests an ST for the
            HTTP/ principal in the current realm, so if we’re to decode
            that ST, it has to match.)
         –>
         Poli1970
         <!–
            Kerberos realm and KDC address.
         –>
         IN2PRUEBAS
         <!–
            Service Principal Name to use on the repository tier.
            This must be like: HTTP/host.name@REALM
         –>
         HTTP/alfpru.in2pruebas@IN2PRUEBAS
         <!–
            JAAS login configuration entry name.
         –>
         ShareHTTP
     
  

   <!–
        Overriding endpoints to reference an Alfresco server with external SSO enabled
        NOTE: If utilising a load balancer between web-tier and repository cluster, the «sticky
              sessions» feature of your load balancer must be used.
        NOTE: If alfresco server location is not localhost:8080 then also combine changes from the
              «example port config» section below.
        *Optional* keystore contains SSL client certificate + trusted CAs.
        Used to authenticate share to an external SSO system such as CAS
        Remove the keystore section if not required i.e. for NTLM.
       
        NOTE: For Kerberos SSO rename the «KerberosDisabled» condition above to «Kerberos»
   –>
  
     
        
             alfresco/web-extension/alfresco-system.p12
             pkcs12
             alfresco-system
        
        
        
            alfrescoCookie
            Alfresco Connector
            Connects to an Alfresco instance using cookie-based authentication
            org.springframework.extensions.webscripts.connector.AlfrescoConnector
        
        
        
            alfresco
            Alfresco – user access
            Access to Alfresco Repository WebScripts that require user authentication
            alfrescoCookie
            http://localhost:8080/alfresco/wcs
            user
            true
        
     
  

Una parte importante para poder realizar SSO Kerberos con Alfresco Share, es que hay que darle al usuario alfrescohttp la posibilidad de obtener la delegación de permisos por parte del otro servicio, en este caso, Alfresco (repositorio). Esto se obtiene dentro de Usuarios y equipos de Active Directory, en la rama Users y encima del usuario «Alfresco HTTP» pulsamos botón derecho y propiedades.

Aquí, en la pestaña «Delegación» hay que activar «Confiar en este usuario para la delegación a cualquier servicio (solo Kerberos)».

Si esta pestaña no está visible habrá que «elevar el nivel funcional del dominio…». Esto se consigue en la raíz del dominio (en nuestro caso in2pruebas de «Usuarios y equipos de Active Directory», se pulsa botón derecho del ratón y se selecciona «Elevar el nivel funcional del dominio»). Se encuentra más información en: http://technet.microsoft.com/en-us/library/cc757194%28WS.10%29.aspx

Para poder depurar correctamente, recomiendo usar las siguientes líneas en los ficheros log4j.properties:

log4j.logger.org.alfresco.repo.security=debug
log4j.logger.org.alfresco.web.app.servlet.KerberosAuthenticationFilter=debug
log4j.logger.org.alfresco.web.site.servlet.SSOAuthenticationFilter=debug
log4j.logger.org.alfresco.web.app.servlet.WebScriptsSSOAuthenticationFilter=debug

Al igual, también se puede activar la depuración de Kerberos a nivel de la JVM añadiendo los parámetros a la línea que ya se tenga de JAVA_OPTS como:
export JAVA_OPTS=»${JAVA_OPTS} -Dsun.security.krb5.debug=true -Dsun.security.jgss.debug=true»

Bien, ahora vamos a la parte cliente, el Windows XP que estemos usando, el Linux o el mismo Windows 2003 Server que puede servir para probar al final si todo funciona correctamente desde el navegador Internet Explorer o Firefox.

En el caso de Internet Explorer hay que indicarle en Herramientas->Opciones de Internet->Seguridad->Intranet Local la URL a la que vamos a acceder para que funcione el SSO. En este caso se ha incluido http://alfpru.in2pruebas que es el servidor donde está instalado Alfresco. Además en Herramientas->Opciones de Internet->Seguridad->Nivel Personalizado hay que comprobar que está seleccionada la opción «Inicio de sesión automático sólo en la zona de Intranet» en «Autenticación de Usuario».

Si no tenémos infraestructura suficiente usando DNS para resolución de nombres, podemos usar el fichero hosts de C:WindowsSystem32driversetc e incluir la línea «IP host host.dominio», por ejemplo:
192.168.1.12   alfpru   alfpru.in2pruebas

Para el caso de Firefox, hay que poner en este (en el campo URL) about:config y confirmar que deseamos entrar en la configuración. Buscamos las siguientes opciones y le damos los valores  aquí señalados o los que correspondan según la configuración de dominio del Active Directory:
network.negotiate-auth.delegation-uris = http://alfpru.in2pruebas:8080/share
network.negotiate-auth.trusted-uris = http://alfpru.in2pruebas:8080/alfresco
network.negotiate-auth.using-native-gsslib = false

(Nota: Actualmente en la versión 3.4.0, el SSO en Alfresco no funciona con Firefox en Linux; tampoco Alfresco Share con máquinas JVM de IBM).

Ya solo queda realizar los ajustes que se necesiten, poner los nombres correctos según la configuración de cada uno y probar su funcionamiento. 

Más información de como configurar este escenario en:
http://wiki.alfresco.com/wiki/Alfresco_Authentication_Subsystems#Kerberos
http://www.bdat.com/documentos/samba/html/domain-member.html
http://technet.microsoft.com/en-us/library/cc757194%28WS.10%29.aspx