La función UserName () DAX devuelve un GUID en PowerBI

---

@DominiqueGire escribió:

Cuando usa UserName () en una función DAX en PowerBI Desktop que funciona bien y muestra algo como «AzureAD FirstnameLastname» si uso esa función en una medida calculada que se mostrará.

En realidad, para mí, NOMBRE DE USUARIO () devuelve un GUID cuando lo invoco desde una medida en Power BI Desktop. Esto parece un error.

Tengo algunos datos en un Power BI Push DataSet con análisis de datos históricos que se comprometen a través de REST de varios usuarios, necesito filtrar ese Streaming DataSet para el usuario actual para que la experiencia del usuario sea más amigable [1]. Desafortunadamente, tengo entendido que no es posible aplicar la seguridad de nivel de fila a Push DataSets.

[1] – En este punto, no es un riesgo de seguridad si otro usuario ve los datos ingresados ​​por un usuario diferente, pero se ve feo.

Funciona tan pronto como haces lo siguiente:

1) Publique el informe y el conjunto de datos en el servicio Power Bi

2) Vaya al conjunto de datos, haga clic en los puntos suspensivos a la derecha y elija – SEGURIDAD

3) Haga clic en Crear nuevo rol y presione Intro (no se moleste en cambiarle el nombre, agregar usuarios o definir la expresión DAX)

4) Presione Mayús-F5 o haga clic en la barra de direcciones en la parte superior y presione Mayús-Retorno para actualizar la página.

Luego, debería encontrar que el nombre de usuario que se muestra en su medida es el nombre de inicio de sesión para el portal en la nube, que en mi caso también es la dirección de correo electrónico de mi cuenta de trabajo de Office 365.

Como probablemente sepa, lo que logra no es ningún tipo de bloqueo de seguridad en el conjunto de datos basado en el usuario que inició sesión. Para eso, tendría que definir el Rol y agregar usuarios y un DAX Express según corresponda.

En cambio, lo que tiene es la capacidad de entregar informes que muestren «Mi equipo de ventas», «Mis hojas de asistencia», etc., en función del usuario que inició sesión, que para mí es el santo grial: poder ayudar al usuario a perfeccionarse directamente al contenido que les importa sin tener que encontrarse en un largo dropdown lleno de nombres. Nada peor que los administradores ocupados a los que se les permite ver una amplia gama de regiones o áreas comerciales, perdiéndose cuando intentan ver sus propios datos.

Parece un poco extraño: habilitar Row Level Security pero no definir ningún rol adecuado o expresión DAX, ¡pero no me quejo ahora de que funciona!

Espero que ayude.

Para aprovechar este problema, podríamos devolver el nombre de usuario a través de un parámetro de entrada StoredProcedure y filtrar previamente los datos antes de que lleguen a PowerBI. En la versión de escritorio de abril, definimos los parámetros de consulta:

En Editar consulta

Haga clic en el botón Administrar parámetros

Nuevo parámetro

Ahorrar

Luego haga clic derecho en el parámetro en la lista de consultas del margen izquierdo

Elija «Habilitar carga»

Cree otra consulta (estilo SQL) y copie y pegue su comando Ejecutar sp con parámetros sql sp codificados en algunos valores de muestra

Después de crear, previsualizar y guardar (cargar)

Ahora regrese a la barra de fórmulas de su consulta e interrumpa el DAX con una frase concatenada

Ejemplo, el nombre de mi parámetro de PowerBI es pOrgUnit (por cierto, PowerBI / DAX distingue entre mayúsculas y minúsculas)

Mi comando SQL Execute original

DECLARAR @return_value int

EXEC @return_value = [dbo].[sp_AccountComparisons_InSummary]

@CompanyDB = N’DOS ‘,

@userid = N’User1 ‘,

@OrgUnit = N’100 ‘

SELECCIONAR ‘Valor de retorno’ = @return_value

Reemplacé @OrgUnit = N’100 ‘

Con @OrgUnit = N ‘”& pOrgUnit &”’

Fórmula DAX resultante

= Sql.Database («dynbuddev», «DynamicBudgets», [Query=»DECLARE#(tab)@return_value int#(lf)#(lf)EXEC#(tab)@return_value = [dbo].[sp_AccountComparisons_InSummary]# (lf) # (tab) # (tab) @CompanyDB = N’TWO ‘, # (lf) # (tab) # (tab) @userid = N’dynbudsm’, # (lf) # (tab) # ( tab) @OrgUnit = N ‘»& pOrgUnit &»‘ # (lf) # (lf) SELECT # (tab) ‘Return Value’ = @ return_value # (lf) «])

Ahora, la parte complicada es que debe ir a EditQueries, elegir editar parámetros y luego cambiar de un valor de parámetro a otro

En mi ejemplo, cambiando de 500 a 100 …

El cambio de parámetro se puede invocar desde el botón Editar consulta en la ventana Editar consulta o en un Informe.

Esperaría que un usuario quisiera cambiar el enfoque haciendo clic en un elemento visual, no en una opción de cinta, por lo que a continuación intentaré pasar el nombre de usuario () como mi parámetro @UserID sp.

Si puedo prefiltrar la lista a lo que el usuario tiene derechos de acceso de seguridad, entonces no me importa en qué hacen clic dentro del informe porque ya se ha prefiltrado solo para sus datos respectivos que tienen autorización de seguridad para ver.

Ya tenemos una seguridad compleja a nivel de cuenta financiera definida en nuestra fuente de datos local, no quiero replicar eso en Seguridad a nivel de rol en PowerBI … entonces, ¿por qué el enfoque de sp param para el prefiltrado?

Entonces, para intentar usar esto en el mundo real, es posible que aún necesite configurar la seguridad de nivel de rol para poder hacer referencia a un nombre de usuario () en lugar de un GUID …

Supongo que la clave es que necesito que el conjunto de datos se cargue a pedido y no tenga datos almacenados en caché (consulta directa u Odata).

¿ODATA funciona con SP?

@zgidwani finalmente, ¿encontraste la manera de pasar el nombre de usuario () por parámetro?

---

@zgidwani escribió:

@ Esperaría que un usuario quisiera cambiar el enfoque haciendo clic en un elemento visual, no en una opción de cinta, por lo que a continuación intentaré pasar el nombre de usuario () como mi parámetro @UserID sp.

Si puedo prefiltrar la lista a lo que el usuario tiene derechos de acceso de seguridad, entonces no me importa en qué hacen clic dentro del informe porque ya se ha prefiltrado solo para sus datos respectivos que tienen autorización de seguridad para ver.

---

Hola Brian,

¡Gracias, esto fue de mucha ayuda! Desafortunadamente, la razón por la que estoy usando la función NOMBRE DE USUARIO () para implementar RLS es porque me gustaría poder aplicar RLS en cuentas fuera de mi organización, y usando una tabla calculada puedo hacer esto.

El problema surge cuando crea un rol, todas las direcciones de correo electrónico extraorganizacionales no pueden acceder a los datos, consulte: https://dl.dropboxusercontent.com/u/25095474/ShareX/2016/05/chrome_2016-05-26_09-57 -13.png

¿Alguna idea sobre cómo evitar el acceso restringido a los datos cuando se habilita un rol? ¿O quizás un método para generar la cadena hexadecimal de X para compararla con la función NOMBRE DE USUARIO ()? (`XXXXXXXXXXXXXXXX yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy`)

Hola Jexah,

El vínculo a la imagen en su cuenta de Dropbox no parece funcionar.

Creo que entiendo lo que estás diciendo, estoy tratando de probar esa restricción en este sentido. ¿Está diciendo que la vista del usuario externo de la función NOMBRE DE USUARIO () vuelve a un GUID si intenta acceder al informe, o está bloqueado para que no vea el informe por completo?

El problema se «resuelve» después de que se haya implementado RLS.

Una vez que «enciende» RLS, la función de nombre de usuario ahora devuelve su dirección de correo electrónico (dirección de inicio de sesión)

Hola johnny

¿Podrías poner un ejemplo de cómo lo hiciste?

Aprecia tu ¡ayuda!

Saludos,

Niket Talati

Johnny, ¿podrías publicar un ejemplo de cómo usar el nombre de usuario () en el RLS?

¡Sí, tengo el mismo problema!

UserName () funciona bien en PBI Desktop pero muestra algo como «10037FFEBDC1B 3fe697b9-2e85-33….» En PBI en línea.

Estoy tratando de filtrar filas usando el usuario real. ¿Es posible usar Power BI?

¡Gracias!

USERNAME () en el servicio PBI devuelve el nombre de usuario de la cuenta de servicio de Microsoft para esa instancia del servidor. (Esta es una suposición informada, no he tenido una preocupación por verificar).

Si el objetivo es aplicar seguridad a nivel de fila en Power BI, el único método realmente seguro es usar DirectQuery contra un cubo SSAS o una fuente de datos SQL que tenga seguridad a nivel de fila. El modelo de Power BI Power Pivot ** NO PUEDE ** admitir la seguridad de nivel de fila.

Al realizar una consulta directa, el servicio Power BI transmitirá las credenciales del usuario que ha iniciado sesión actualmente para la autenticación en la fuente de datos, y devolverá solo los datos que el rol de ese usuario puede ver según los criterios de seguridad.