Tag: Avanzado

Certificados y recibos parametrización

Es posible configurar el acceso a los documentos de recibos de nómina y certificados de varias formas:

Publicación de los documentos a través en un servidor SFTP

Dentro del archivo BoldWebCfg podremos configurar los siguientes parámetros:

 * <SFtpHost> </SFtpHost> --> especificamos la dirección IP del servidor donde se encuentran los documentos
  * <SFtpPort> </SFtpPort> --> añadimos el puerto del servidor
  * <SFtpUser> </SFtpUser> --> credenciales de usuario
  * <SFtpPass> </SFtpPass> --> credenciales contraseña
  * <SFtpWorkingDir> </SFtpWorkingDir> --> ruta que se encuentran los documentos

Para que aparezcan las nóminas hay que introducir el parámetro ‘Payroll’ dentro de la etiqueta ‘Features’ para que se puedan visualizar, en el archivo BoldWebCfg

Con las variables MaxDaysShowNomina, SFtpNoCheckWorkerCodeFiles y PSSJDMode, configuraremos los diferentes tipos de documentos que queremos visualizar como son las nóminas(RS_1) ; pagas(RS_2);objetivos y atrasos(RS_8).

Usando el conector con Nóminas Labor (Navision)

Es necesario incluir el tag:

<NominasWebServiceLabor>Yes</NominasWebServiceLabor>

Usando el conector con Nóminas Integrho

<NominasWebServiceIntegrho>Yes</NominasWebServiceIntegrho>

Configuración de contadores

ATENCIÓN: El siguiente contenido es de uso avanzado y su utilización puede ocasionar daños irreparables en la configuración del sistema

Abrir Maestro/Formularios. Crear nuevo y rellenar

Instalación servidor BOLDApp

Requerimientos técnicos

Para poder utilizar la APP se necesita acceso público a través de un puerto seguro (443 ó 8183 normalmente, para HTTPS) a un servidor donde instalaremos el módulo GPSNODE. Este servidor ha de tener acceso a la base de datos de BOLD (puerto 1433) y al servidor de datos de BOLD (puerto 80). Normalmente este servidor sigue una estructura DMZ para que la seguridad de la red no se vea comprometida, aunque no es imprescindible, siendo posible que el servidor de base de datos y lógico de BOLD sean el mismo.

Para que la comunicación con este servidor siga el protocolo HTTPS es imprescindible contar con un certificado válido (no autofirmado) que valide el acceso a ese servidor a través de la dirección pública determinada.

Requerimientos para la parametrización visual (formato logo)

  • Logos grandes dentro de la APP: Se ven en la pantalla de login, y en el logo superior en el menú. Deben ser 2 ficheros, un PNG 774×306 y un PNG 540×213
  • Color base de fondo para la aplicación (en RGB), por ejemplo: “#E1BEE7”
  • Color primario para botones y otros componentes: “#922744”

Instalaciones on premise: limitacion de los webservices disponibles

Para poder usar la App móvil es necesario publicar el acceso a la aplicación en Internet (si los móviles no tiene posibilidad de usar una vpn).

En el caso de instalaciones on premise donde se vaya a utilizar también la app es posible limitar la publicación en internet a sólo unos pocos webservices, para mayor seguridad. Consultar con el área técnica acerca de esta posibilidad.

Configuración de datos personales

ATENCIÓN: El siguiente contenido es de uso avanzado y su utilización puede ocasionar daños irreparables en la configuración del sistema

Para modificar los datos personales visibles en la App hay que acceder en el archivo : PersonalData_schema_custom.json que está junto al fichero BoldWebConfig.xml

Si el archivo no está, hay que crearlo. A continuación un ejemplo de este fichero para que sirva de orientación:

{
	"header": [{
			"title": "Nombre",
			"value": "FullName"
		}, {
			"title": "DNI",
			"value": "DNI"
		}, {
			"title": "Categoria profesional",
			"value": "Object(W_ContractWorkerForDate(ID, Today()), \"ContractWorker\").ProfessionalCategory.Name"
		}, {
			"title": "Fecha de nacimiento",
			"value": "LeftStr(SystemProps.BirthDate,10)"
		}
	],
	"cards": [{
			"cardName": "Contacto",
			"values": [{
					"title": "Telefono1",
					"value": "SystemProps.Phone1"
				}, {
					"title": "Telefono2",
					"value": "SystemProps.Phone2"
				}, {
					"title": "Telefono3",
					"value": "SystemProps.Phone3"
				}
			]
		}, {
			"cardName": "Direccion",
			"values": [{
					"title": "Dirección",
					"value": "SystemProps.Adress"
				}
			]
		}, {
			"cardName": "Datos profesionales",
			"values": [{
					"title": "Categoria profesional",
					"value": "Object(W_ContractWorkerForDate(ID, Today()), \"ContractWorker\").ProfessionalCategory.Description"
				}
			]
		}
	]
}

Configuración con LDAP

ATENCIÓN: El siguiente contenido es de uso avanzado y su utilización puede ocasionar daños irreparables en la configuración del sistema

En este artículo se explican las capacidades de integración de los diferentes módulos con la autenticación LDAP

Requisitos para configurar acceso por LDAP

Antes de iniciar la configuración del LDAP / Directorio Activo, los informáticos de la empresa nos deberán proporcionar lo siguiente:

  1. Dirección del servidor de LDAP (ej.: ldap://ldapservername.com).
  2. Credenciales de acceso, usuario o usuaria y password con permisos de lectura sobre todo el árbol de usuarios/as a autenticar.
  3. Directorio raíz a partir del cual se encuentran las personas usuarias.
  4. Campo del usuario o usuaria de LDAP por el cual podremos identificar a la persona empleada de Workplanner (DNI/código empleado/a).
  5. Nombre del campo LDAP donde se encuentra el Mail de usuaria o usuario.
  6. Usuario o usuaria válida en LDAP que permita realizar login de forma similar a como lo harían las personas empleadas, para comprobar funcionamiento.

Además de la información anterior, tenemos que recibir un mail con un pantallazo de la ejecución del siguiente comando desde el ordenador Windows que tenga instalado el “Active Directory Domain Services (AD DS) server role” (se debe abrir un powershell como administrador):

dsquery user -name bold*

Nota: en vez de bold se debe pone el usuario o usuaria que nos hayan dado para poder recorrer el árbol del directorio activo y el usuario/s o usuaria/s “de a pie” que nos hayan proporcionado para poder realizar las pruebas con la aplicación simulando ser un/a usuario/a “normal” básico/a. Necesitamos este resultado para la correcta configuración del acceso.

Ejemplo completo de información recibida

Servidor LDAP: server.sjdsse.cat

Usuario con permisos de lectura sobre todo el árbol:

CN=BOLD BOLD,CN=Users,DC=sjdsse,DC=cat

<y_aqui_viene_su_pwd>

Directorio raiz usuarios/as: cn=users,dc=sjdsse,dc=cat

Condición/campo que coincide con el username que introducirán los usuarios y usuarias al logarse (se muestran dos ejemplos típicos: cn y sAMAccountName):

(cn=%s)

(sAMAccountName=%s)

Campo del usuario o usuaria de LDAP por el cual podremos identificar a la persona empleada de Workplanner (DNI/codigo empleado/a): employeeID

Nombre del campo LDAP donde se encuentra el Mail del usuario/a: mail

Ejemplo de captura del comando dsquery:

Parámetros de configuración

Para validar a los usuarios y usuarias que se conectan al Portal del empleado o a la versión Fullweb se puede utilizar un servidor de LDAP (o Directorio Activo). Los parámetros de configuración para realizar esta conexión son los siguientes:

  1. bUseBOLDUserProfile: (sólo versión Fullweb). Nota: Este campo a partir de la versión 1.9.2 es necesario que exista siempre y debe valer “true” (o no estar en blanco). Si el campo existe indica que una vez el usuario o usuaria se haya autenticado externamente (ej: en el LDAP) se le va a permitir logarse en el servidor de BOLD con ese usuario o usuaria sin necesidad de usar el password que pueda estar en BOLD, sino tan solo presentando un login token válido. De otra forma el login se haría con el usuario o usuaria genérico y no permitiría el acceso interactivo desde la Fullweb. Atención! Si activamos esta opción debemos asegurarnos que el usuario adm del campo bolduser es de tipo administrador, no puede ser sólo integrador.
  2. LDAP_ActiveDirectory: URL de la conexión al servidor de LDAP primario. Ej.: ldap://myldaphost con el valor none se desactiva el uso de LDAP.
  3. LDAP_ActiveDirectoryUsers: URL de la conexión al servidor de LDAP de usuarios y usuarias. Se puede dejar vacío. En tal caso se utilizará para validar a los usuarios y usuarias la URL de LDAP_ActiveDirectory.
  4. ADUsersDirectory: directorio raíz a partir del cual se obtiene la información de acceso del usuario o usuaria. Ej. “OU=USUARIOS, DC=FAC, DC=es” o bien “OU=Proveedores Euro,OU=Cuentas Especiales,DC=mydomain,DC=net”. Normalmente esta cadena se extrae a partir de alguna opción como “Copy DN” (dentro del JXplorer) y eliminando el prefijo “CN=xyz,”.
  5. ADUserDN: nombre distinguido de usuario/a (Distinguished Name) que se utilizará para consultar el LDAP. Ej. FAC\bolduser. Atención: este nombre debe coincidir exactamente con el que se encuentra en ese campo en el LDAP. Y se corresponde con el nombre que aparece en la parte del prefijo eliminada anteriormente del ADUsersDirectory. Ejemplos posibles serían: “administrador” (simplemente) o “ADUserDN”: “cn=administrador,CN=Users,DC=miempresa,DC=local” (una query completa para identificar de forma directa el usuario o usuaria de browsing).
  6. Pass: password que se utilizará para poder acceder a la información de cada usuario/a en el LDAP.
  7. ADFilter: filtro que se aplica sobre el parámetro anterior. Se incluirá %s como parámetro que la aplicación sustituirá. Ej.: “(sAMAccountName=%s)”
  8. ADUserPostFix: postfijo al nombre de usuario/a. Se puede dejar vacío. En tal caso no se utiliza postfijo.
  9. DomainToAppendToLDAPUser: dominio que se añadirá a los nombres de los usuarios y usuarias antes de la autenticación.
  10. ADDNIParam: nombre del parámetro del LDAP que contiene el DNI del empleado o empleada. Solo es necesario si hay identificación por DNI.
  11. ADPersonalCodeParam: nombre del parámetro del LDAP que contiene el código de la persona empleada. Solo es necesario si hay identificación por código.
  12. ADMail: nombre del parámetro del LDAP que contiene el mail del empleado o empleada. Solo es necesario si se va a utilizar el mail del empleado o empleada para algo.
  13. UserIDPolicy: indica a partir de qué campo haremos la identificación, ByEmployeeCode por código de empleado/a, ByEmployeeDNI pro DNI, ByEmployeeCodeExt

Operativa de validación de credenciales

El identificador de usuario/a que se utiliza para verificar los pwd del resto de usuarios y usuarias es el que resulta de juntar en la cadena de búsqueda LDAP los atributos ADUserDN y ADUsersDirectory. Es decir, la cadena de identificación de este/a usuario/a es:

"CN=" + ADUserDN + "," + ADUsersDirectory

Que junto con el Pass nos permite logarnos en el LDAP con los permisos necesarios para realizar las consultas y validaciones.

Una vez logado, para validar unas credenciales se usa la query LDAP siguiente: ADFilter + ADUsersDirectory. Por ejemplo supongamos la siguiente configuración:

<PARAMS>
		<bUseBOLDUserProfile>true</bUseBOLDUserProfile>
		<LDAP_ActiveDirectory>ldap://myldaphost</LDAP_ActiveDirectory>
		<ADUserPostFix></ADUserPostFix>		
		<ADUserDN>my-ldap-superuser,OU=Bold,OU=Cuentas de Servicio</ADUserDN>
		<Pass>the-secret-ldap-pwd-for-superuser</Pass>		
		<ADUsersDirectory>DC=mycompany,DC=net</ADUsersDirectory>
		<ADFilter>(sAMAccountName=%s)</ADFilter>
		<DomainToAppendToLDAPUser></DomainToAppendToLDAPUser>
		<ADDNIParam>employeeID</ADDNIParam>
		<ADPersonalCodeParam>employeeNumber</ADPersonalCodeParam>
		<ADMail>mail</ADMail>
		<UseLDAPUserAsWorkerCode>No</UseLDAPUserAsWorkerCode>
</PARAMS>

Casos donde el usuario o usuaria de validación se encuentra en un nodo base diferente de donde está el resto de usuarios/as

Se trata de poner en ADUsersDirectory, un nodo raíz que sea base tanto del usuario o usuaria de browsing como de los usuarios o usuarias a validar. Como en ADUserDN es necesaria una cadena completa que lleve al nodo del usuario o usuaria específica de browsing, se han de añadir en esta variable los nodos necesarios hasta alcanzarlo.

<PARAMS>
    <ADUserDN>BOLDplanner,OU=PTUC</ADUserDN>       
    <ADUsersDirectory>OU=Campus,DC=PTUC,DC=scs,DC=es</ADUsersDirectory>                    
</PARAMS>

Configuraciones de LDAP en que no existe la propiedad distinguishedName en los registros del LDAP

En este caso la autenticación de los usuarios o usuarias se realiza montando la siguiente consulta LDAP:

"cn=%username%," + ADUsersDirectory

Por ejemplo, un posible resultado al introducir el username testuser sería:

cn=testuser,ou=Externos,ou=MiGranOrganizacion,o=MiMundo

Si hacemos un CTRL-F con el JXplorer y ponemos en el campo “Start Searching From…” la consulta LDAP anterior. Si no nos lleva hasta el registro de nuestra usuaria del LDAP es que no tenemos una consulta LDAP correcta. Entonces identificar cuál es primero explorando manualmente por el árbol (con el JXplorer) y una vez localizada seleccionar la opción “Copy DN” (botón derecho).

Utilidades de configuración LDAP

Para localizar los valores de las propiedades más relevantes, pueden ser de utilidad las siguientes aplicaciones: JXplorer y Softerra LDAP Browser (https://www.ldapadministrator.com/download.htm) . A continuación se explica la primera, aunque la segunda es también muy interesante:

JXplorer

Permite conectarnos y navegar por la estructura del LDAP, si disponemos al menos de un hostname, usuario/a y pwd. Ver

http://jxplorer.org/

Una vez instalado el programa, esta es la operativa básica para obtener la información de configuración anterior necesaria:

1. File–>Connect. Rellenar el diálogo que aparece similar a éste:

2. Sobre la vista de árbol, seleccionar el nodo más alto posible, pero dentro del dominio, y pulsar CTRL-F

3. Buscar la entrada de algún o alguna usuaria conocida seleccionando: CTRL-F

En la pestaña de resultados debería aparecer el nodo con los datos del usuario o usuaria localizados. A partir de ahí, la query para llegar a obtener directamente esta información de forma automática es la que se obtiene con el botón derecho “Copy DN”.

Configuración del LDAP desde la aplicación Fullweb

  • Por fullweb es necesario tener activada la boldAction Act_ConfigLDAP_Web en el querycustom.xml, por ejemplo:
<TBoldActionConfigList>	
	<TBoldAction Name="Act_ConfigLDAP_Web" ShowName="Configuración LDAP" UserAccess="u_Administrador, u_Parametrizador, u_Planificador, u_Integrador, u_Consultor, u_Supervisor" Visible="true" Enabled="true"/>
</TBoldActionConfigList>

La configuración se debe realizar desde la opción:

Los campos a rellenar son los mismos que se detallan en este articulo, si se siguen los pasos, finalmente permite Guardar la configuración.

En el último paso tenemos la oportunidad de verificar las credenciales con cualquier usuario de LDAP.

  • Por consola:
  1. Abrir un cmd.exe en la carpeta C:\Program Files (x86)\Global Planning Solutions\gpsnode
  2. Ejecutar:
 node ./routes/webcore/LDAP_console.js <nombre_carpeta_cliente> <nombre_instancia> <usuario> <pwd>
 Por ejemplo:
 node ./routes/webcore/LDAP_console.js Custom_Files development ControlPresencia mypwd

Ver también BoldWebcfg.xml

Herramienta de Windows para consultas sobre LDAP: ldapsearch -h 192.168.8.10 -D “CN=AdminBOLD,CN=Users,DC=paf,DC=paf-ar,DC=es” -w “PASSWORD” -b “DC=PAF, DC=paf-ar, DC=es” -s sub “objectclass=*”

Configurar Usuario/a Active Directory y contraseña

  1. Abrir un cmd.exe en la carpeta C:\Program Files (x86)\Global Planning Solutions\gpsnode
  2. Ejecutar:
 node ./routes/webcore/LDAP_console.js <nombre_carpeta_cliente> <nombre_instancia> /config
 Por ejemplo:
 node ./routes/webcore/LDAP_console.js Custom_Files development /config

El script pedirá el usuario o usuaria (ADUserDN) y su contraseña dos veces para confirmar el cambio, una vez ejecutado aparecerá encriptada en el fichero boldwebcfg.xml campo <Pass>.

Ver también BoldWebcfg.xml

Utilizar el LDAP del node desde el portal

Se tiene que añadir en el BOLDWebCfg.xml las siguientes etiquetas:

<bUseBOLDUserProfile>true</bUseBOLDUserProfile>
<EnableValidationInNode>Yes</EnableValidationInNode>
<ConfigCaseType>workplanner</ConfigCaseType>

Nota Importante: El tag ConfigCaseType es imprescindible si la carpeta de PROductivo no es “production” sino “workplanner”.

Por defecto el ConfigClient y el ConfigCaseType son CustomFiles y production. Lo normal es que ambos tags, no existan. Asegurarse y verificar que la etiqueta <ConfigCaseType> xxx</ConfigCaseType> se corresponde con el caseType utilizado. En los entornos que son de desarrollo/development será necesario añadirlos y en el caso de productivo, tener en cuenta que a menudo la carpeta de configuración es workplanner y no production.

La URL de gpsnode se configura en el PlannerConfig.exe.

Configurar mensaje de aviso de caducidad de contraseñas LDAP

  • Mediante la activación de la BoldAction Act_ConfigWarningLDAPPasswordExpiration_Web:

En la versión web, con un usuario administrador, accedemos al menú de configuración general.

Con la bold action activada, aparece el siguiente apartado:

En días de aviso, se pondrá el número de días de antelación para mostrar el mensaje de aviso.
Política de caducidad, se pondrá el número de días que está configurado como política de caducidad de contraseñas en el sistema LDAP del cliente.
Una vez hagamos click en guardar terminamos con la configuración.

Nota: Si la bold action está activada y no se ha configurado nada, por defecto la política de caducidad son 3000 días, por lo cual no sale el mensaje de aviso hasta que no se configure intencionadamente en el menú Configuración general.

  • Activando la variable de entorno USE_SPAWN_TO_GET_USER_PASSWORD_EXPIRATION:

Si queremos activar esta variable de entorno, nos tenemos que asegurar de que el usuario que está ejecutando node en la máquina de nuestro cliente, tiene permisos necesarios para ejecutar el comando: net user UsuarioDeEjemplo /domain

Si se cumple la anterior condición, el mensaje aparece según los días configurados en el campo “Días de aviso” del menú Configuración general(como en la anterior configuración).
Para poder ver Días de aviso es necesario tener la boldaction Act_ConfigWarningLDAPPasswordExpiration_Web

  • Activando la variable de entorno USE_QUERY_TO_GET_USER_PASSWORD_EXPIRATION:

Se necesita dar de alta la query con nombre GetLDAPPasswordExpiryDate que devuelva el número de días que le falta al usuario por caducar su contraseña.

Si se cumple la anterior condición, el mensaje aparece según los días configurados en el campo “Días de aviso” del menú Configuración general(como en la primera configuración).
Para poder ver Días de aviso es necesario tener la boldaction Act_ConfigWarningLDAPPasswordExpiration_Web

Validar en el LDAP desde el Cliente Windows

Antes de entrar, iremos a la ventana de configuración y comprobaremos que el check Validación LDAP(previa) está activo.

Si es así y el LDAP esta bien configurado, siguiendo las directivas explicadas en esta propia wiki, nos podremos logar a partir de LDAP.

Para comprobar que la configuración es correcta hay que mirar los logs del node.