Los usuarios de su organización pueden acceder a los datos locales (para los que ya tienen permiso de acceso), pero antes de que puedan conectarse al origen de datos local, es necesario instalar y configurar una puerta de enlace de datos local. La puerta de enlace facilita la comunicación interna entre un usuario en la nube y el origen de datos local, y de vuelta a la nube de una manera rápida y segura.

La instalación y configuración de la puerta de enlace suele estar a cargo de un administrador. Puede requerir un conocimiento especial de los servidores locales y, en algunos casos, también se requieren permisos de administrador del servidor.

En este artículo no se proporcionan instrucciones paso a paso acerca de cómo instalar y configurar una puerta de enlace. Para ello, asegúrese de ver On-premises data gateway (Puerta de enlace de datos local). El objetivo de este artículo es profundizar acerca del funcionamiento de la puerta de enlace. También se ofrece información detallada sobre los nombres de usuario y la seguridad en Azure Active Directory y Analysis Services, e información sobre cómo el servicio en la nube usa la puerta de enlace, Active Directory y la dirección de correo con la que un usuario inicia sesión, para conectarse de forma segura y consultar los datos locales.

Cómo funciona la puerta de enlace

on-prem-data-gateway-how-it-works

Veamos primero lo que sucede cuando un usuario interactúa con un elemento conectado a un origen de datos local.

Nota:

Para Power BI, necesitará configurar un origen de datos para la puerta de enlace.

  1. El servicio en la nube crea una consulta, junto con las credenciales cifradas para el origen de datos local y se envía a la cola para que la puerta de enlace la procese.

  2. El servicio en la nube de la puerta de enlace analizará la consulta y enviará la solicitud al Bus de servicio de Azure.

  3. La puerta de enlace de datos local sondea el Bus de servicio de Azure en busca de solicitudes pendientes.

  4. La puerta de enlace obtiene la consulta, descifra las credenciales y se conecta a los orígenes de datos con esas credenciales.

  5. La puerta de enlace envía la consulta al origen de datos para su ejecución.

  6. Los resultados se envían desde el origen de datos a la puerta de enlace y luego al servicio en la nube. Después, el servicio usa los resultados.

Lista de tipos de orígenes de datos disponibles

Origen de datos Dinámica/DirectQuery Actualización programada o manual configurada por el usuario
Modelo tabular de Analysis Services
Modelo multidimensional de Analysis Services
Archivo No
Carpeta No
IBM DB2 No
Base de datos Informix de IBM No
Impala
MySQL No
OData No
ODBC No
Oledb No
Oracle
PostgresSQL No
SAP BW
SAP HANA
Lista de SharePoint (local) No
Snowflake
SQL Server
Sybase No
Teradata
Web No

Cuenta de inicio de sesión

Los usuarios inician sesión con una cuenta profesional o educativa. Es la cuenta de la organización. Si se suscribió a una oferta de Office 365 y no proporcionó la dirección de correo profesional real, se podría parecer a nancy@contoso.onmicrosoft.com. La cuenta, en un servicio en la nube, se almacena en un inquilino de Azure Active Directory (AAD). En la mayoría de los casos, el UPN de la cuenta AAD coincidirá con la dirección de correo.

Autenticación para orígenes de datos locales

Se usará una credencial almacenada para conectarse a orígenes de datos locales de la puerta de enlace excepto a Analysis Services. Independientemente del usuario individual, la puerta de enlace usa la credencial almacenada para conectarse.

Autenticación a un origen de datos de Analysis Services activo

Cada vez que un usuario interactúa con Analysis Services, el nombre de usuario efectivo se envía a la puerta de enlace y después al servidor de Analysis Services local. El nombre principal de usuario (UPN), normalmente la dirección de correo con la que inicia sesión en la nube, es lo que se pasará a Analysis Services como usuario efectivo. El UPN se pasa en la propiedad de conexión EffectiveUserName. Esta dirección de correo debe coincidir con un UPN definido en el dominio de Active Directory local. El UPN es una propiedad de una cuenta de Active Directory. Por tanto, esa cuenta de Windows debe estar presente en un rol de Analysis Services para tener acceso al servidor. Si no se encuentra una coincidencia en Active Directory, el inicio de sesión no será correcto.

Analysis Services también puede proporcionar filtrado basado en esta cuenta. El filtrado puede realizarse con seguridad basada en roles o bien con seguridad de nivel de fila.

Seguridad basada en roles

Los modelos proporcionan seguridad basada en roles de usuario. Los roles para un proyecto de modelo determinado se definen durante la creación en SQL Server Data Tools – Business Intelligence (SSDT-BI), o después de que se implementa un modelo, mediante SQL Server Management Studio (SSMS). Los roles contienen miembros por nombre de usuario o grupo de Windows. Los roles definen los permisos que un usuario tiene para consultar o realizar acciones en el modelo. La mayoría de los usuarios pertenecerá a un rol con permisos de lectura. Otros roles están diseñados para los administradores con permisos para procesar elementos, administrar funciones de bases de datos y administrar otros roles.

Seguridad de nivel de fila

La seguridad de nivel de fila es específica de la seguridad de nivel de fila de Analysis Services. Los modelos pueden proporcionar seguridad dinámica de nivel de fila. A diferencia de tener al menos un rol al que pertenezcan usuarios, la seguridad dinámica no es necesaria para cualquier modelo tabular. En un nivel avanzado, la seguridad dinámica define el acceso de lectura a datos de un usuario delimitado a una fila particular en una tabla específica. Similar a lo que ocurre con los roles, la seguridad dinámica de nivel de fila se basa en el nombre de usuario de Windows de un usuario.

La capacidad de los usuarios para consultar y ver datos de un modelo está determinada, en primer lugar, por los roles a los que pertenece su cuenta de usuario de Windows y, en segundo lugar, por la seguridad dinámica de nivel de fila, si está configurada.

La implementación de la seguridad dinámica de nivel de fila y de roles en los modelos queda fuera del ámbito de este artículo. Puede obtener más información en Roles (SSAS tabular) y Roles de seguridad (Analysis Services - Datos multidimensionales) en MSDN. Para ver una descripción más detallada de la seguridad de modelos tabulares, descargue y lea las notas del documento Tabular BI Semantic Model (Protección del modelo semántico tabular de BI).

¿Qué pasa con Azure Active Directory?

Los servicios en la nube de Microsoft dejan la autenticación de los usuarios a cargo de Azure Active Directory. Azure Active Directory es el inquilino que contiene grupos de nombres de usuario y seguridad. Normalmente, la dirección de correo con la que un usuario inicia sesión coincide con el UPN de la cuenta.

¿Cuál es mi rol de Active Directory local?

Para que Analysis Services determine si un usuario que se conecta a él pertenece a un rol con permisos para leer los datos, el servidor debe convertir el nombre de usuario efectivo pasado de AAD a la puerta de enlace y de ahí al servidor de Analysis Services. El servidor de Analysis Services pasa el nombre de usuario efectivo a un controlador de dominio (DC) de Windows Active Directory. El controlador de dominio de Active Directory, a su vez, valida que el nombre de usuario efectivo es un UPN válido en una cuenta local y devuelve el nombre de usuario de Windows de ese usuario al servidor de Analysis Services.

No se puede usar EffectiveUserName en un servidor de Analysis Services que no esté unido a un dominio. El servidor de Analysis Services debe estar unido a un dominio para evitar errores de inicio de sesión.

¿Cómo sé cuál es mi UPN?

Es posible que no sepa cuál es su UPN y que no sea un administrador de dominio. Puede utilizar el siguiente comando en la estación de trabajo para averiguar el UPN de la cuenta.

whoami /upn

El resultado se asemejará a una dirección de correo, pero se trata del UPN correspondiente a la cuenta de dominio local. Si usa un origen de datos de Analysis Services para las conexiones activas, debe coincidir con lo que se ha pasado a EffectiveUserName desde la puerta de enlace.

Asignación de nombres de usuario a orígenes de datos de Analysis Services

Power BI permite asignar nombres de usuario a orígenes de datos de Analysis Services. Puede configurar reglas para asignar un nombre de usuario que ha iniciado sesión con Power BI a un nombre que se pasa para EffectiveUserName en la conexión de Analysis Services. La función de asignación de nombres de usuario es una excelente solución alternativa cuando su nombre de usuario en AAD no coincide con un UPN en su Active Directory local. Por ejemplo, si su dirección de correo es nancy@contoso.onmicrsoft.com, podría asignarla a nancy@contoso.com y ese valor se pasaría a la puerta de enlace. Puede obtener más información sobre cómo asignar nombres de usuario.

Sincronizar un servidor de Active Directory local con Azure Active Directory

Querrá que las cuentas de Active Directory locales coincidan con Azure Active Directory si va a usar conexiones activas de Analysis Services. Al igual que el UPN debe coincidir entre las cuentas.

Los servicios en la nube solo conocen las cuentas de Azure Active Directory. No importa si ha agregado una cuenta en su Active Directory local, si no existe en AAD, no se puede usar. Hay diferentes formas para hacer coincidir las cuentas de Active Directory locales con Azure Active Directory.

  1. Puede agregar manualmente cuentas a Azure Active Directory.

    Puede crear una cuenta en el portal de Azure, o en el Portal de administración de Office 365, y el nombre de la cuenta coincide con el UPN de la cuenta de Active Directory local.

  2. Puede usar la herramienta Azure AD Connect para sincronizar las cuentas locales para el inquilino de Azure Active Directory.

    La herramienta Azure AD Connect proporciona opciones para la sincronización de directorios y contraseñas. Si no es un administrador de inquilinos o un administrador de dominio local, debe ponerse en contacto con el administrador de TI para configurarlo.

  3. Puede configurar los servicios de federación de Active Directory (ADFS).

    Puede asociar el servidor de ADFS al inquilino AAD con la herramienta Azure AD Connect. ADFS hace uso de la sincronización de directorios descrita anteriormente pero permite una experiencia de inicio de sesión único (SSO). Por ejemplo, si se encuentra en la red del trabajo, cuando acceda a un servicio en la nube y vaya a iniciar sesión, es posible que no se le pida que escriba un nombre de usuario o contraseña. Tendrá que consultar con el administrador de TI si esto está disponible para su organización.

El uso de Azure AD Connect garantiza que el UPN coincida entre AAD y Active Directory local.

Nota:

La sincronización de cuentas con la herramienta Azure AD Connect creará cuentas nuevas dentro de su inquilino de AAD.

Aquí es cuando entra en juego la puerta de enlace

La puerta de enlace actúa como puente entre la nube y el servidor local. La transferencia de datos entre la nube y la puerta de enlace se protege mediante Azure Service Bus. Service Bus crea un canal seguro entre la nube y el servidor local a través de una conexión de salida de la puerta de enlace. No necesita abrir conexiones de entrada en el firewall local.

Si tiene un origen de datos de Analysis Services, deberá instalar la puerta de enlace en un equipo unido al mismo bosque o dominio que el servidor de Analysis Services.

Cuanto más cerca esté la puerta de enlace del servidor, más rápida será la conexión. Si la puerta de enlace puede estar en el mismo servidor que el origen de datos, es mejor evitar la latencia de red entre la puerta de enlace y el servidor.

¿Qué hacer a continuación?

Después de instalar la puerta de enlace, probablemente querrá crear orígenes de datos para esa puerta de enlace. Puede agregar orígenes de datos desde la pantalla Administrar puertas de enlace. Para obtener más información, consulte los artículos sobre la administración de orígenes de datos.

Administrar el origen de datos: Analysis Services
Administrar el origen de datos: SAP HANA
Administrar el origen de datos: SQL Server
Administrar el origen de datos: Oracle
Administrar el origen de datos: importación o actualización programada

Posibles problemas

Algunas veces no se puede instalar la puerta de enlace. O es posible que la puerta de enlace parezca instalarse correctamente, pero el servicio todavía no pueda trabajar con ella. En muchos casos, es algo sencillo, como la contraseña de las credenciales que usa la puerta de enlace para iniciar sesión en el origen de datos.

En otros casos, es posible que haya problemas con el tipo de dirección de correo electrónico con el que los usuarios inician sesión, o que Analysis Services no pueda resolver un nombre de usuario efectivo. Si tiene varios dominios con confianzas entre ellos y la puerta de enlace está en uno y Analysis Services en otro, en ocasiones esto puede causar algunos problemas.

No ahondaremos aquí en cómo resolver los problemas de la puerta de enlace. Para ello hemos preparado una serie de pasos en el artículo Troubleshooting the On-premises Data Gateway (Solución de problemas con la puerta de enlace de datos local). Esperamos que no tenga problemas. Pero si los tiene, le será provechoso comprender cómo funciona todo esto junto con el artículo de solución de problemas.

Cuenta de inicio de sesión

Los usuarios inician sesión con una cuenta profesional o educativa. Es la cuenta de la organización. Si se suscribió a una oferta de Office 365 y no proporcionó la dirección de correo profesional real, se podría parecer a nancy@contoso.onmicrosoft.com. La cuenta, en un servicio en la nube, se almacena en un inquilino de Azure Active Directory (AAD). En la mayoría de los casos, el UPN de la cuenta AAD coincidirá con la dirección de correo.

Cuenta de servicio de Windows

La puerta de enlace de datos local está configurada para usar NT SERVICE\PBIEgwService para la credencial de inicio de sesión del servicio de Windows. De manera predeterminada, tiene el derecho de Iniciar sesión como servicio. Se trata del contexto de la máquina en la que va a instalar la puerta de enlace.

Nota:

Si ha seleccionado el modo personal, configure la cuenta de servicio de Windows por separado.

No es la cuenta que se usa para conectarse a orígenes de datos locales. Tampoco es la cuenta profesional o educativa con la que inicia sesión en servicios en la nube.

Si tiene problemas con el servidor proxy debido a la autenticación, puede cambiar la cuenta de servicio de Windows por un usuario de dominio o una cuenta de servicio administrada. Puede obtener información sobre cómo cambiar la cuenta en la configuración de proxy.

Puertos

La puerta de enlace crea una conexión de salida a Azure Service Bus. Se comunica en los puertos de salida: TCP 443 (predeterminado), 5671, 5672 y de 9350 a 9354. La puerta de enlace no requiere puertos de entrada. Más información

Se recomienda añadir a la lista blanca de su firewall las direcciones IP de su región de datos. Puede descargar la lista de direcciones IP del Centro de datos de Microsoft Azure. Esta lista se actualiza semanalmente. La puerta de enlace usará la dirección IP junto con el nombre de dominio completo (FQDN) para comunicarse con Azure Service Bus. Si fuerza a la puerta de enlace a comunicarse mediante HTTPS, usará estrictamente solo FQDN y no se producirá ninguna comunicación mediante direcciones IP.

Nota:

Las direcciones IP que se muestran en la lista de direcciones IP del Centro de datos de Azure están en la notación CIDR. Por ejemplo, 10.0.0.0/24 no significa “de 10.0.0.0 a de 10.0.0.24”. Obtenga más información sobre la notación CIDR.

Aquí se muestra una lista de los nombres de dominio completos utilizados por la puerta de enlace.

Nombres de dominio Puertos de salida Descripción
*.download.microsoft.com 80 HTTP usado para descargar al instalador.
*.powerbi.com 443 HTTPS
*.analysis.windows.net 443 HTTPS
*.login.windows.net 443 HTTPS
*.servicebus.windows.net 5671-5672 Advanced Message Queuing Protocol (AMQP)
*.servicebus.windows.net 443, 9350-9354 Escuchas en Service Bus Relay sobre TCP (requiere el puerto 443 para la adquisición de tokens de Access Control)
*.frontend.clouddatahub.net 443 HTTPS
*.core.windows.net 443 HTTPS
login.microsoftonline.com 443 HTTPS
*.msftncsi.com 443 Se utiliza para probar la conectividad con Internet si el servicio Power BI no puede alcanzar la puerta de enlace.
*.microsoftonline-p.com 443 Se utiliza para realizar la autenticación en función de la configuración.
Nota:

El tráfico que va a visualstudio.com o visualstudioonline.com es de información de la aplicación y no es necesaria para que funcione la puerta de enlace.

Forzar la comunicación HTTPS con Azure Service Bus

Puede obligar a la puerta de enlace a comunicarse con Azure Service Bus a través de HTTPS, en lugar de TCP directo, lo que puede afectar al rendimiento. Para ello, modifique el archivo Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config, para lo que debe cambiar el valor de AutoDetect a Https, como se muestra en el fragmento de código que se encuentra inmediatamente después de este párrafo. Este archivo se encuentra, de forma predeterminada, en C:\Archivos de programa\On-premises data gateway.

<setting name="ServiceBusSystemConnectivityModeString" serializeAs="String">
    <value>Https</value>
</setting>

Como alternativa, puede forzar a la puerta de enlace a adoptar este comportamiento mediante la interfaz de usuario de la puerta de enlace a partir de la versión de marzo de 2017. En la interfaz de usuario de la puerta de enlace, seleccione Red y cambie Azure Service Bus connectivity mode (Modo de conectividad de Azure Service Bus) a Activado.

Una vez cambiado, al seleccionar Aplicar (un botón solo aparece cuando se realiza un cambio), el servicio de puerta de enlace Windows se reinicia automáticamente, por lo que el cambio puede surtir efecto.

Para referencias futuras puede reiniciar el servicio de puerta de enlace de Windows desde el mismo cuadro de diálogo de la interfaz de usuario si selecciona Configuración del servicio y Reiniciar ahora.

Compatibilidad con TLS 1.1 y 1.2

Con la actualización de agosto de 2017 y posteriores, la puerta de enlace de datos local usa Seguridad de la capa de transporte (TLS) 1.1 o 1.2 para comunicarse con el servicio Power BI de forma predeterminada. Las versiones anteriores de la puerta de enlace de datos local usa TLS 1.0 de forma predeterminada. El 1 de noviembre de 2017 la compatibilidad con TLS 1.0 terminará, incluida la capacidad de la puerta de enlace de interactuar con el servicio Power BI mediante TLS 1.0, por lo que debe actualizar las instalaciones de la puerta de enlace de datos local a la versión de agosto de 2017 o a otra más reciente para asegurarse de que las puertas de enlace sigan funcionando.

Es importante tener en cuenta que TLS 1.0 seguirá siendo compatible con la puerta de enlace de datos local antes del 1 de noviembre y la puerta de enlace la utilizará como un mecanismo de reserva. Para asegurarse de que todo el tráfico de la puerta de enlace usa TLS 1.1 o 1.2 (y para impedir el uso de TLS 1.0 en la puerta de enlace), debe agregar o modificar las siguientes claves de registro en la máquina que ejecuta el servicio de puerta de enlace:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]"SchUseStrongCrypto"=dword:00000001
    [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]"SchUseStrongCrypto"=dword:00000001

Nota: agregar o modificar estas claves de registro permite aplicar el cambio a todas las aplicaciones. NET. Para más información acerca de los cambios del registro que afectan a TLS para otras aplicaciones, consulte Configuración del registro de seguridad de la capa (TLS) de transporte.

Cómo reiniciar la puerta de enlace

La puerta de enlace se ejecuta como servicio de Windows. Se puede iniciar y detener como cualquier servicio de Windows. Hay varias formas de hacerlo. Así es cómo se puede hacer desde el símbolo del sistema.

  1. En el equipo en el que se ejecuta la puerta de enlace, inicie un símbolo de sistema con permisos de administrador.

  2. Use el siguiente comando para detener el servicio.

    net stop PBIEgwService

  3. Use el siguiente comando para iniciar el servicio.

    net start PBIEgwService

Vea también

Troubleshooting the On-Premises Data Gateway (Solución de problemas con la puerta de enlace de datos local)
Azure Service Bus
Azure AD Connect
¿Tiene más preguntas? Pruebe la comunidad de Power BI