Archivos mensuales: febrero 2011

Ocultar las «Desktop Actions» en Alfresco

En algunas empresas es necesario quitar las llamadas «desktop actions» o acciones de escritorio que se visualizan en los recursos compartidos cuando se activa el protocolo CIFS. Estas acciones son en algunas ocasiones muy útiles pero en otras, además de producir un mal conteo de ficheros en las carpetas, en muchas otras ocasiones lo único que pueden derivar es en la «contaminación» de las propias acciones por virus ya que son programas ejecutables.

Para eliminar/ocultar estas acciones se puede proceder como sigue:

Copiar el fichero:

${ALF_HOME}/tomcat/webapps/alfresco/WEB-INF/classes/alfresco/subsystems/fileServers/default/file-servers-context.xml

En:

${ALF_HOME}/tomcat/shared/classes/alfresco/extension/subsystems/fileServers/default/default

Y comentar las siguientes líneas:


—- file-servers-context.xml —-

[…]
  
<!–
  
      __Alfresco.url
  
–>
[…]
<!–
  
     
        
            alfresco/desktop/Alfresco.exe
        
     
  
  
     
        
           
               CheckInOut
           
           
               __CheckInOut.exe
           
        
        
           
               JavaScriptURL
           
           
               __ShowDetails.exe
           
           
               alfresco/desktop/showDetails.js
           
           
               anyFiles
           
           
               copyToTarget
           
        
–>
        
         <!–
           
            Echo __AlfrescoEcho.exe
            <property
            name=»name»> URL
            __AlfrescoURL.exe <bean
            class=»org.alfresco.filesys.repo.desk.CmdLineDesktopAction»>
            CmdLine __AlfrescoCmd.exe
           
            JavaScript
            __AlfrescoScript.exe
            alfresco/desktop/dumpRequest.js
            anyFiles, multiplePaths, allowNoParams
            confirm, copyToTarget
         –>
<!–
     
  
–>
[…]

—- file-servers-context.xml —-

${ALF_HOME} hace referencia al «path» o directorio donde está instalado Alfresco.

Bajar SVN de Alfresco con Subclipse a través de un proxy

En el artículo sobre la compilación de la versión Community de Alfresco bajada desde del SVN oficial:

Hay un caso en el que hay que configurar algo más; cuando estemos en un sitio donde haya un proxy por medio, habrá que configurar el SVN para que pueda salir a través de dicho proxy.

Para configurarlo hay que descomentar las líneas de proxy necesarias así como la autenticación utilizada, en mi caso he usado solamente 3 de dichas líneas. El fichero de configuración se llama «servers» y se encuentra en el perfil del usuario o dentro del directorio Subclipse respectivo.

Por ejemplo, en una máquina Windows XP podríamos encontrarlo en:

C:Documents and SettingsfegorApplication DataSubversion

En una máquina con Linux generalmente estará dentro del «home» del usuario, como:

/home/fegor/.subversion

 

Y las líneas principales para hacerlo funcionar:

http-proxy-exceptions = 127.0.0.1, *.intranet.fegor.com
http-proxy-host = proxyserver.fegor.com
http-proxy-port = 8080

Además, hay que tener en cuenta que es necesario bajarse un cliente de SVN en el caso de windows, como puede ser Slik o TortoiseSVN:

http://www.sliksvn.com/en/download/
http://tortoisesvn.net/downloads.html

Así mismo, subclipse utiliza JavaHL (JNI) por defecto, por tanto, si es una distribución Linux/Ubuntu tendrémos que cargar lal librerías correspondientes, como:

sudo apt-get install libsvn-java

Y poner la referencia (pe. -Djava.library.path=/usr/lib/jni) en eclipse.ini
 
Un ejemplo:
-showsplash
org.eclipse.platform
-framework
plugins/org.eclipse.osgi_3.4.0.v20080605-1900.jar
-vmargs
-Djava.library.path=/usr/lib/jni
-Dosgi.requiredJavaVersion=1.5
-Xms40m
-Xmx512m
-XX:MaxPermSize=256m


		

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