Set up a person's access by location

Say someone works in the office with their Windows account, works from home with a personal key, and now and then presents Power BI reports to the board. In the office, they should be able to work without a code; from outside, only with a code; and the report should be able to read data only during the meeting. This guide sets that up in eight steps and shows you what applies where before the person signs in for the first time.

Two things work together to make this happen:

• The sign-in policy, set once for everyone: no code on the company network, a code from outside, and Windows accounts only on the company network.
• The person, with a Windows account, a workstation key, an on-demand presentation key, and a second factor.

If your sign-in policy is already in place, skip steps 1 and 2.

Sign-in policy (once)

1. Open Anmelderichtlinie (Sign-in policy) and choose Weitere (More) > Vorlagen der Richtlinie (Policy templates) > Büro ohne Code, außen mit Code (No code in the office, code from outside). Enter your company network, for example 10.0.0.0/8 (separate several networks with commas).
2. Choose Weitere > Vorlagen der Richtlinie > Außen nur Schlüssel (Keys only from outside) and confirm the same network.

The person (“Neue Person” wizard)

3. Open Personen und Schlüssel (People and keys), choose Neue Person … (New person …), and enter the name, for example John Smith. Select Weiter (Next).
4. Choose Windows-Konto (Windows account) and enter the account, for example CORP\jsmith. Select Weiter.
5. Select the rules the person needs, then Weiter.
6. Pick a database identity if you use them; otherwise, just select Weiter.
7. Select Schlüssel für den Arbeitsplatz (Workstation key) with a label such as Home, plus Schlüssel “Präsentation” auf Abruf (On-demand presentation key) and Zweiten Faktor einrichten (Set up second factor). Select Weiter.
8. Select Links kopieren (Copy links) and pass the three one-time links on to the person through a channel only they read, such as in person or in a message to their own mailbox, not a shared one: whoever opens a link first gets what's behind it. Then select Fertig (Done).

The person opens the links. They enter the Home key in the ODBC driver and the presentation key in Power BI as the password (authentication type “Basic”, user name pkuser; see HTTP: sign-in (reference), section “Personal keys” (data service documentation)), and they scan the QR code with their authenticator app.

Check what applies where

Select the person and choose Weitere > Rechte (Rights) > Anmeldung und Rechte … (Sign-in and permissions …). The view to the right of the list works out, for each of the person's sign-in methods and each location, what the service would do if they signed in. It uses the same rules as an actual sign-in:

The columns are the IPv4 networks named in your sign-in rules (at most the first two, each represented by its first address), plus Außen and Unbekannt (Unknown). Unbekannt stands for a request whose origin the service can't determine; it never counts as inside. The Regeln (Rules) column names the sign-in rules that decide the result; a rule on trial is listed with “(Probe)” (trial) and doesn't change any result. The view doesn't show any other networks or any IPv6 networks, and it tells you nothing about them.

Annahme prüfen … (Check an assumption) asks what would apply if the sign-in came in differently, for example “from Thailand, on a Saturday, with Excel”: enter an address, a country, a network operator, a program, and a time in UTC, each as needed. The view gets an extra column “Annahme: …” (Assumption) for it, which the service calculates like a real sign-in. Whatever you leave empty, it determines from the address as usual, and it takes the current time. Annahme entfernen (Remove assumption) removes the column again.

In the screenshot: (1) the key's row.

Before a meeting

Select the person, choose Weitere > Schlüssel (Keys) > Schlüssel freischalten … (Activate key …), and enter the number of hours. If no key is selected, the command uses the person's only on-demand key. Anmeldung und Rechte then shows the presentation key as “erlaubt” from outside, too, with no code and read-only.

Result: The person works without a code in the office and with a code from home, and Power BI can read data only during the activated hours.

• Get the company network right. Only an origin within the network you specify counts as inside. If there's a proxy in front of the service, it has to be registered as trusted; otherwise, every caller coming through the proxy's address counts as inside. See Tier access by location (data service documentation).
• Groups. For a Windows account, Anmeldung und Rechte calculates without the account's Windows groups, because the service only learns them during an actual sign-in. If a sign-in rule names groups, the actual result can differ.
• After the meeting, the key goes dormant on its own; Freischaltung beenden (End activation) ends the activation sooner.
• What the person sees from outside. If they open an Access application at home whose tables are linked using their Windows account, the service rejects the sign-in. The ODBC driver then shows its connection form with the message “Die Anmelderichtlinie laesst dieses Anmeldeverfahren von dieser Herkunft nicht zu.” (The sign-in policy doesn't allow this sign-in method from this origin.) There, they choose the Persönlicher Schlüssel (Personal key) sign-in method, paste their key, and then enter the code from their authenticator app. Unless they select Schlüssel speichern (Save key), the driver asks again the next time the application starts; Access doesn't store the key in the database.
• One address inside and outside. A linked table remembers the service's address. If the same application needs to run both in the office and at home, the service needs a name that reaches it from inside and outside alike. Otherwise, you'll have to relink the tables for each location.
• If the person still can't get in, Weitere > Störung und Austritt (Problems and departures) > Warum abgewiesen? … (Why rejected? …) shows their latest rejections with the cause and the fix; see Troubleshooting.

• Define the sign-in policy: templates and custom sign-in rules
• Create a person and issue a key: every step of the wizard
• Issue a presentation key and replace a lost key
• Set up or reset the second factor