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
Mi amigo Toni de la Fuente ha modificado un componente en WebScript (repository) para visualizar todas las consolas de que disponemos en la versión Enterprise de Alfresco: http://blyx.com/2011/03/07/anade-mas-utilidades-de-administracion-en-alfresco-share/ y ha creado un proyecto en google code a partir de este en: http://code.google.com/p/alfresco-useful-admin-links/
