Usuarios para pruebas D365FO

Durante el ciclo de desarrollo de una funcionalidad de D365FO, es necesario que un tercero (un consultor funcional o un usuario clave, por ejemplo) pruebe dicha funcionalidad antes de darlo por válido, con un juego de datos y de permisos lo más realistas posible. Una opción interesante, y que agiliza este proceso, es que el usuario que está probando la funcionalidad lo haga en la misma máquina virtual de desarrollo.

Muchas veces es suficiente con arrancar el cliente web de D365FO desde Visual Studio, simplemente marcando un proyecto de inicio “Startup project“:

Dentro de él, un objeto de inicio “Startup object“:

Y hacer clic en “Start“:

Pero otras veces no basta con esto. Por ejemplo, si lo que queremos probar es la efectividad de cierta funcionalidad bajo determinados permisos de acceso, hay que crear un usuario independiente y asignarle los roles correspondientes: Si lo hacemos con el usuario administrador (que es el que arranca desde Visual Studio) no podremos probarlo, puesto que no se le aplican estas restricciones de seguridad.

Para ello, es necesario, por este orden:

  1. Si estamos trabajando con Visual Studio, ya lo tendremos. Pero si no, deberemos antes de nada asignar el usuario administrador (que será el usuario efectivo cuando arranquemos el cliente desde Visual Studio). Para ello, usamos la utilidad “Admin User Provisioning” que viene en la máquina virtual.Nota: es necesario que el email del usuario administrador pertenezca a algún dominio AAD.

    A partir de este momento, podremos arrancar el navegador web para conectarnos a D365FO empleando el mail indicado y su contraseña. Cuando entremos, lo haremos como usuario administrador, como podemos ver en la esquina superior derecha.

     

  2. Ahora, hay que dar de alta el nuevo usuario. Para ello, nos vamos al menú “System Administration>Users>Users“, y hacemos clic en “New“:
    En esta nueva versión, el mecanismo de autenticación ha cambiado de Active Directory a Active Directory Federation Services (ADFS), con lo que además hay que especificar la URL del proveedor de autenticación.
  3. La máquina virtual está aislada y no pertenece a ningún dominio de Windows, así que usaremos un email para identificar al usuario. Lo pondremos en “User name” y en “email“. Para el proveedor de autenticación tendremos que usar:
      1. Si el dominio AAD tiene su propio proveedor de autenticación, usaremos su URL (e.g., https://auth.adfs.mycompany.com). Si no tenemos esta información, posiblemente habrá que contactar con el Departamento de Sistemas para conocerla.

    Si el dominio no tiene un proveedor de autenticación propio, entonces:

    1. Si el email del usuario pertenece al mismo dominio AAD que el usuario administrador: https://sts.windows.net
    2. Si el email del usuario pertenece a otro dominio Azure Active Directory, habrá que usar el genérico de AAD: https://sts.windows.net/XXXXX.XXX, donde XXXXX.XXX es el dominio del email (e.g, https://sts.windows.net/emiralfg.com)

    Existe una cuarta opción muy interesante, que es vincularlo a una cuenta Microsoft: Es la que se usa, por ejemplo, para entrar en Skype. El proveedor de autenticación sigue el patrón de un usuario perteneciente a otro dominio AAD, es decir, https://sts.windows.net/XXXXX.XXX, siendo XXXXX.XXX el dominio de la dirección de email.

    En este ejemplo hemos usado una cuenta outlook.com (que es una cuenta Microsoft). Tendremos entonces que asignar como proveedor de autenticación https://sts.windows.net/outlook.com. Si tienes una cuenta en outlook.com, o aún conservas una antigua de hotmail.com, puedes usarlas:

    Teóricamente, esto debería funcionar con cualquier email vinculado a una cuenta Microsoft. En nuestras pruebas, por ejemplo, hemos conseguido usar una cuenta de correo electrónico de yahoo.com, previa vinculación a una cuenta Microsoft. Hay que tener en cuenta que la contraseña, en el caso general, NO ES la del email, sino la de la cuenta Microsoft (que en el caso de outlook.com y hotmail.com sí que es la misma).

    Ahora, ya le podemos asignar roles. Como mínimo, necesitará el rol “System user”.

A partir de este momento, el usuario con el email indicado ya debería poder entrar a la máquina de desarrollo para hacer sus pruebas.

A disfrutarlo 🙂

José Miguel Guisado

Entradas recomendadas