USERPRINCIPALNAME zwraca konto Windows zamiast adresu e-mail w Power BI Desktop

Power BI - Bezpieczeństwo: RLS, OLS i etykiety poufności

USERPRINCIPALNAME zwraca konto Windows zamiast adresu e-mail w Power BI Desktop

W skrócie

USERPRINCIPALNAME w Power BI Desktop zwróciła w kursie POWERBI-KURS\powerbi, czyli nazwę konta Windows, a nie adres e-mail. Przy budowie dynamicznego RLS, czyli jednej roli, która sama rozpoznaje osobę otwierającą raport, taki wynik sprawia, że raport pod rolą robi się pusty. Wyjaśniamy, co funkcja zwraca w Desktopie i w usłudze, jak testować rolę bez publikowania i jak przygotować tabelę mapującą na modelu Nordvelli.

Jak to wygląda w praktyce

W modelu Nordvelli rola Manager sklepu ma na tabeli DimSklepy regułę, która szuka adresu zalogowanej osoby w tabeli MapaManagerow. Mapa ma sześć adresów kierowników, na przykład piotr.nowak@nordvella.pl ze sklepem 4. W widoku zapytań w języku DAX bez podglądu roli funkcja USERPRINCIPALNAME () zwróciła w kursie POWERBI-KURS\powerbi, nazwę konta Windows, na którym działał Desktop. Sprawdziliśmy to też osobnym połączeniem z modelem z konta administratora maszyny: USERPRINCIPALNAME i USERNAME zwróciły to samo, POWERBI-KURS\Administrator, bez znaku @, a USEROBJECTID identyfikator zabezpieczeń Windows zaczynający się od S-1-5-21.

Skutek widać w regule. Dla nazwy konta Windows LOOKUPVALUE po kolumnie Email zwraca pustą wartość, a reguła roli zostawia 0 sklepów. Pod rolą bez podanego adresu funkcja zwracała w kursie pusty tekst, co daje ten sam wynik: karty z dwiema kreskami i puste wizualizacje. Autor dochodzi wtedy do wniosku, że funkcja nie działa.

Zobacz też: Szkolenie Power BI - Desktop, DAX i Online + Copilot

Dlaczego tak się dzieje

Dokumentacja Microsoft opisuje wynik funkcji jednym zdaniem: nazwa główna użytkownika z chwili połączenia. Nazwa główna użytkownika (po angielsku user principal name, w skrócie UPN) to login konta w Microsoft Entra ID, zwykle równy adresowi e-mail. Według dokumentacji w usłudze Power BI funkcje USERPRINCIPALNAME i USERNAME zwracają UPN osoby, która otwiera raport. W Desktopie model działa na Twoim komputerze i bez podglądu roli funkcja może pokazać konto Windows, na którym pracujesz. Dokumentacja podaje dla Desktopu postać user@contoso.com przy USERPRINCIPALNAME i DOMENA\użytkownik przy USERNAME, ale na komputerze kursu, spoza domeny i z lokalnym kontem Windows, obie funkcje zwróciły postać DOMENA\użytkownik.

Druga pułapka to założenie, że UPN to adres poczty. Według dokumentacji Microsoft wartość zwracana przez funkcję jest identyfikatorem logowania, który nie musi być równy adresowi e-mail, na przykład gdy adres jest aliasem. U gości z innej organizacji (Microsoft Entra B2B) funkcja może zwrócić identyfikator z dopiskiem #EXT#. Dlatego tabela mapująca ma przechowywać dokładnie to, co funkcja zwraca w usłudze. Inne przyczyny pustego raportu opisujemy w poście o pustym raporcie pod rolą RLS.

Co zrobić krok po kroku

1. Sprawdź, co funkcja zwraca u Ciebie. Otwórz widok zapytań w języku DAX (ikona na pasku po lewej) i uruchom zapytanie bez podglądu roli. W kursie zwróciło POWERBI-KURS\powerbi, 15 sklepów i 6 wierszy mapy, a na naszym połączeniu z modelem POWERBI-KURS\Administrator i te same liczniki. Wynik bez znaku @ znaczy, że reguła z tabelą mapującą nie znajdzie w Desktopie nikogo, i tak ma być.

   EVALUATE
   ROW (
       "Zalogowany", USERPRINCIPALNAME (),
       "Sklepy widoczne", COUNTROWS ( DimSklepy ) + 0,
       "Wiersze mapy", COUNTROWS ( MapaManagerow ) + 0
   )

2. Nie dopisuj do mapy nazw kont Windows ani warunku, który przy braku dopasowania pokazuje wszystkie sklepy. W usłudze taki warunek otworzyłby dane każdemu, kogo nie ma w mapie. Rolę testujesz podstawieniem adresu: na karcie Modelowanie kliknij Wyświetl jako, zaznacz Inni użytkownicy, wpisz piotr.nowak@nordvella.pl, naciśnij Tab, zaznacz Manager sklepu i kliknij OK.
3. Przeczytaj pasek nad raportem. Ma pokazać Oglądasz jako: Manager sklepu, piotr.nowak@nordvella.pl. Gdy widzisz samą rolę, bez adresu, adres przepadł, bo nie został zatwierdzony klawiszem Tab, a funkcja zwraca pusty tekst. W kursie poprawny podgląd pokazał 31 545 740 zł i jeden sklep, Nordvella Kraków Stare Miasto. Z podglądu wychodzisz przyciskiem Zatrzymaj wyświetlanie.
4. Pod podglądem roli uruchom zapytanie z kroku 1 jeszcze raz. Widok zapytań w języku DAX działa pod rolą wybraną w Wyświetl jako, więc kolumna Zalogowany pokaże podstawiony adres, a liczniki 1 sklep i 1 wiersz mapy. Wtedy wiesz, że reguła i relacja są poprawne, a różnica dotyczyła tylko tożsamości.
5. Przygotuj tabelę mapującą pod usługę. Zapisz w kolumnie Email dokładnie wartość, którą funkcja zwraca w usłudze, a nie ładniejszy alias. Wielkość liter nie przeszkadza, bo porównanie tekstów w DAX jej nie rozróżnia: adres Piotr.Nowak@Nordvella.pl znalazł w mapie sklep 4 i 31 545 739,77 zł. Przeszkadza spacja na końcu i inna domena: dla adresu ze spacją i dla domeny .com reguła zostawiła 0 sklepów.
6. Po publikacji sprawdź wartość w usłudze. Dokumentacja Microsoft radzi do testów miarę zwracającą tożsamość, położoną na karcie w raporcie. Dodaj ją, opublikuj raport, poproś osobę testową o otwarcie raportu i porównaj wynik z mapą. W Desktopie pokaże nazwę konta Windows, w kursie POWERBI-KURS\powerbi. U gości z innej organizacji szukaj w wyniku dopisku #EXT#.

   Kto ogląda = USERPRINCIPALNAME ()

Jak sprawdzić, że problem zniknął

Naprawione, gdy w Desktopie podgląd z adresem kierownika pokazuje jego sklep, a w usłudze karta z miarą Kto ogląda pokazuje adres, który znajdziesz w kolumnie Email tabeli mapującej. W kursie każdy z sześciu adresów mapy dawał inny sklep, od 27 854 861 zł w Gdańsku do 141 772 849 zł w sklepie internetowym, a adres spoza mapy dawał pusty raport. Sprawdź co najmniej dwóch kierowników i jeden adres spoza mapy.

Buduj mapę z tego samego źródła, z którego pochodzą konta logowania, i przycinaj spacje w Power Query, zanim dane trafią do modelu, co opisujemy w poście o funkcji Przytnij i niewidocznych znakach. Gdy przy poprawnym adresie raport pokazuje całą sieć, sprawdź, czy reguła leży na wymiarze, a nie na tabeli mapującej, jak w poście o filtrze zabezpieczeń w obu kierunkach. Testową miarę po sprawdzeniu usuń z raportu.

Źródła i sposób sprawdzenia

• Microsoft Learn: USERPRINCIPALNAME function (DAX) (źródło)
• Microsoft Learn: USERNAME function (DAX) (źródło)
• Microsoft Learn: Row-level security (RLS) with Power BI (username() i userprincipalname() w Desktopie i w usłudze, goście B2B) (źródło)
• Microsoft Learn: Row-level security (RLS) guidance in Power BI Desktop (miara do testu tożsamości) (źródło)
• Kurs Power BI, lekcja 21: test roli poleceniem Wyświetl jako, dynamiczny RLS z USERPRINCIPALNAME, dynamiczny RLS zwraca pusty raport
• Sprawdzone zapytaniami DAX na modelu Nordvelli: USERPRINCIPALNAME, USERNAME i USEROBJECTID na połączeniu Windows, porównania adresów z tabelą MapaManagerow

Zachowanie programu sprawdziliśmy w Power BI Desktop 2.157 (wydanie z sierpnia 2026 r.) z polskim interfejsem, a przykłady na modelu sieci Nordvella z bezpłatnego kursu Power BI. Microsoft wydaje nową wersję Power BI Desktop co miesiąc, więc nazwy przycisków i limity usługi mogą się zmieniać. Aktualne wartości podaje dokumentacja Microsoft Learn.

Wróć do listy: 131 najczęstszych pytań i problemów związanych z Power BI