Your two OpenBI addresses
When your company runs OpenBI Server, you get two web addresses under your own domain, here with norwayanalytics.no as the example:
| Address | What it is | Who uses it |
|---|---|---|
| bi.norwayanalytics.no | OpenBI Server, the place for your company’s reports: workspaces, report pages, data refresh, publishing from OpenBI Studio, and Excel connections | Everyone who reads or publishes reports |
| accounts.norwayanalytics.no | OpenBI Accounts, your company’s sign-in service: passwords, the authenticator app, invitations and “Forgot password?” | Everyone, but only briefly, to sign in |
How they work together
A person opens bi.norwayanalytics.no. If they aren’t signed in, they’re sent to accounts.norwayanalytics.no, where they type their password and the code from their authenticator app. Then they’re sent back to their reports. The report server never sees the password: it only gets confirmation from the sign-in service that this is that person. It’s the same pattern as Microsoft’s own sign-in pages, but it’s yours.
Why two addresses and not one?
- Security: passwords and authenticator secrets live in a separate service from the reports, so a problem in one doesn’t expose the other.
- One sign-in for everything: the same sign-in works for the reports, for OpenBI Studio when it publishes, and for several report servers if you have them.
- You can replace it: if your company already has a sign-in system, such as Microsoft Entra ID or another one that speaks OpenID Connect, OpenBI Server can use that instead. Then you don’t need accounts.norwayanalytics.no at all. See Or use your own sign-in provider.
Where they run
Both run on your own machines, usually the same server. Norway Analytics hosts nothing for you: your data, your users and your passwords stay with you. On its own, the server sends only the licence check, to Keygen, the licensing service Norway Analytics uses. It sends your licence key, your domain, the server’s machine name and platform, and a machine fingerprint: a one-way hash of the machine’s id, which tells your server from another and says nothing about people. With a seat licence, it also tells the seller’s billing service how many seats are in use, as a number. What leaves our network? lists exactly what goes, and when. Invitation and password e-mails go out from your own mailbox (Microsoft 365 or your mail server).
What your IT needs to set up
- DNS: two records, bi.<your domain> and accounts.<your domain>, pointing to the OpenBI server. Use public DNS if people should reach it from outside, or internal DNS for the office only.
- Certificates: an HTTPS certificate for each address. OpenBI can get free Let’s Encrypt certificates and renew them by itself.
- Firewall: port 443 inbound for people. If OpenBI gets its certificates from Let’s Encrypt, port 80 too: Let’s Encrypt checks each address over plain HTTP.
- Licence: your OpenBI licence covers your domain, so both addresses are included. You buy it on the server’s setup page: see Buy OpenBI Server. No domain yet? See No domain yet: a made-up one.
Commands
The steps above, with OpenBI.Server.exe, the command line that comes with OpenBI Server. On Windows, run them on the server in a Command Prompt opened as administrator, from the folder OpenBI Server is installed in:
cd "C:\Program Files\OpenBI Server"
Replace each <…> with your own value: for norwayanalytics.no, https://bi.<domain> is https://bi.norwayanalytics.no. In PowerShell, start each command with .\OpenBI.Server.exe. When something isn’t right, each command says what to run, including when a service must restart to take a change.
Set up OpenBI Accounts
Gives OpenBI Accounts its public address, and your company’s name, which people see on its sign-in pages.
OpenBI.Server.exe accounts setup --public-url https://accounts.<domain> --name "<Company AS>"
OpenBI.Server.exe accounts service restart
Get a certificate for each address
Let’s Encrypt certificates for both addresses, installed and renewed by OpenBI. --email is IT’s address: Let’s Encrypt sends its notices about the certificate there. On Windows, IIS must answer for each address and the firewall let ports 80 and 443 in first: the first three lines (see Put IIS in front). On a Mac, leave those three out: the server answers on ports 80 and 443 itself.
OpenBI.Server.exe iis setup --host bi.<domain> --apply
OpenBI.Server.exe iis setup --host accounts.<domain> --apply
OpenBI.Server.exe firewall --apply
OpenBI.Server.exe https letsencrypt --host bi.<domain> --email <address> --apply
OpenBI.Server.exe https letsencrypt --host accounts.<domain> --email <address> --apply
Without --apply, the command changes nothing: it lists the steps, each done or still to do, with the command for each one left.
Sign people in with OpenBI Accounts
Registers OpenBI Server with OpenBI Accounts on the same machine, under the address people open, and signs people in there.
OpenBI.Server.exe signin use-accounts --server-url https://bi.<domain>
OpenBI.Server.exe service restart
Or use your own sign-in provider
Instead of OpenBI Accounts, any sign-in provider that speaks OpenID Connect. Register OpenBI Server there as a web application with the redirect address https://bi.<domain>/signin-oidc, then:
OpenBI.Server.exe signin set --authority <https://…> --client-id <id>
OpenBI.Server.exe service restart
For Microsoft Entra ID, the authority is https://login.microsoftonline.com/<tenant id>/v2.0. The command asks for the client secret, or reads it from its input, so it stays out of your command history. OpenBI Studio signs in through the same provider when it publishes; OpenBI.Server.exe help lists the options for its registration there. With your own provider, you don’t need accounts.<domain>, its DNS record or its certificate.
Check everything
Checks everything the server needs, and gives each problem with the command that fixes it. Run it after the steps above, and whenever something seems wrong.
OpenBI.Server.exe doctor
On a Mac
No domain yet: a made-up one
A company without a domain of its own, or not yet, licenses the server for a made-up name, such as openbi.home.arpa. The ending home.arpa is reserved for private networks, so it never clashes with a real website. OpenBI then works on your own network under that name: people open https://bi.openbi.home.arpa and sign in at https://accounts.openbi.home.arpa. It is reached from that network only, and when you get a real domain, you move to it with Change domain.
No public certificate authority issues certificates for such a name, and Let’s Encrypt can’t prove it (https letsencrypt says so), so the server makes its own, with https local. Buy the licence for the made-up name first (see Your server’s web address), then:
OpenBI.Server.exe iis setup --host bi.openbi.home.arpa --apply
OpenBI.Server.exe accounts setup --public-url https://accounts.openbi.home.arpa --name "<Company AS>"
OpenBI.Server.exe iis setup --host accounts.openbi.home.arpa --apply
OpenBI.Server.exe https local --domain openbi.home.arpa
OpenBI.Server.exe https local --domain openbi.home.arpa --apply
OpenBI.Server.exe https redirect --apply
OpenBI.Server.exe signin use-accounts --server-url https://bi.openbi.home.arpa
OpenBI.Server.exe service restart
Without --apply, https local lists its steps, each done or still to do. On a Mac, the same with sudo openbi-server, without the iis lines and https redirect: the server’s own front door serves the certificate, and sends http:// to https:// by itself.
The server’s own certificate authority
- For that domain alone. Made once: RSA 3072, SHA-256, valid 10 years, with a critical X.509 name constraint that permits the domain and the names under it and excludes every IP address, and for HTTPS servers only. Trusting it vouches for nothing else, no other website, no code, no e-mail, even if its key were ever stolen: Windows and macOS refuse any other name from it.
- Its key never leaves the server: sealed for the machine in the data folder’s
certs\, as the licence key is, never in the clear, never exported, never printed. A sealed key that no longer opens is never replaced by a new authority on its own, as every device would have to trust the new one. - The server’s certificate from it, for bi.<domain>, accounts.<domain>, the domain and the server’s other names under it: ECDSA P-256, valid 397 days, within what Apple, Chrome and Firefox allow a public certificate. On Windows it goes into the machine’s certificate store, its key not exportable, and into IIS’s HTTPS bindings for both names; a scheduled task, “OpenBI Server local certificate <domain>”, runs daily and renews it 30 days before it runs out. On a Mac, the server renews it itself.
https local --domain <domain> --renew --applyrenews it now; the authority stays, so devices go on trusting the server. - Nothing on the server has to trust it: the server reaches OpenBI Accounts on the same machine directly, at
http://localhost:5790. Where the sign-in is reached by its name instead, the server’s calls to it trust the authorities in its owncerts\folder, for their own names only. https statusanddoctorsay a certificate is the server’s own, and until when: a warning 30 days before it runs out on Windows, 14 on a Mac.
Trust it once on each device
https local prints where its public certificate is, certs\openbi-local-ca-<domain>.cer (and .pem) in the data folder, with its SHA-256 fingerprint, and these steps. Compare the fingerprint on each device before you trust it:
| Device | Trust “OpenBI local CA for <domain>” |
|---|---|
| Windows | Double-click the .cer, Install Certificate, Local Machine, Place all certificates in the following store, Trusted Root Certification Authorities. Or, as an administrator: certutil -addstore -f Root openbi-local-ca-<domain>.cer. OpenBI Studio, OpenBI Gateway and Excel use it from there. |
| macOS | Double-click the .cer (Keychain Access, the System keychain), double-click “OpenBI local CA for <domain>”, Trust, When using this certificate: Always Trust. Or: sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain openbi-local-ca-<domain>.cer |
| iPhone, iPad | Send the file to the device (mail, AirDrop, Files) and open it; Settings, Profile Downloaded, Install; then Settings, General, About, Certificate Trust Settings, and turn on “OpenBI local CA for <domain>”. |
| Android | Settings, Security, Encryption & credentials, Install a certificate, CA certificate, the file. Chrome trusts it; an app may trust the system’s own authorities only. |
| Firefox | Its own list, unless it uses the system’s (security.enterprise_roots.enabled): Settings, Privacy & Security, Certificates, View Certificates, Authorities, Import, Trust this CA to identify websites. |
The names on your network
The names are yours to give: in your router’s local DNS, bi.<domain> and accounts.<domain> pointing to the server’s address (phones need this); or in each PC’s hosts file (C:\Windows\System32\drivers\etc\hosts, /etc/hosts), a line such as:
192.168.1.20 bi.openbi.home.arpa accounts.openbi.home.arpa
When the company gets a real domain, change it in Billing (see Change domain) and get Let’s Encrypt’s certificates for the new names. The devices can then forget the server’s own authority.
For your users
In one paragraph, ready to pass on:
You’ll get an invitation e-mail from your company. The link opens accounts.<your domain>, where you choose a password and connect an authenticator app on your phone. From then on, open bi.<your domain> to see your reports. When asked to sign in, you’ll briefly see accounts.<your domain>. That’s your company’s own sign-in page, and the only place you type your password.
Frequently asked questions
Can we use one address only?
No. OpenBI uses two names: bi.<your domain> for the reports and accounts.<your domain> for signing in. If you use your own sign-in provider instead of OpenBI Accounts, you need only bi.<your domain>.
What leaves our network?
On its own, only the licence check and, with a seat licence, the number of seats in use. The check goes over HTTPS to Keygen, the licensing service Norway Analytics uses, at api.keygen.sh:
- When a domain’s licence is activated on the server: the licence key, the domain, the server’s machine name, its platform (operating system, its version and processor type) and the machine fingerprint.
- Every six hours after that: a heartbeat with the licence key and the id Keygen gave the server at activation, which brings back a new signed licence file. Removing a domain sends the same two, to free its licence.
- With every request: the version of OpenBI Server and, as with any connection, the server’s public IP address.
With a seat licence, the server also sends the seller’s billing service, billing.querex.no, its licence key and fingerprint and the number of seats in use, every 6 hours and a minute after the count changes: never a name or an address (see What the server sends to the seller).
The fingerprint is an HMAC-SHA256 hash of the operating system’s own machine id (Windows’ MachineGuid, a Mac’s hardware UUID), never the id itself. It tells your server from another machine, and says nothing about people.
Your data, your users and your passwords stay with you. Invitation and password e-mails go out through your own mailbox. If OpenBI gets its certificates from Let’s Encrypt, it asks Let’s Encrypt for them, and while you set it up on Windows, it downloads Microsoft’s IIS modules and the win-acme certificate client. A model’s refresh reads its own data sources, and a report page that shows a map or pictures by their address has the server fetch them: map tiles from OpenStreetMap by default. What leaves the machine lists each of these.
Can people sign in from outside the office?
Yes, if your DNS records are public and port 443 is open to the server. With internal DNS only, or a made-up domain, OpenBI is reachable from the office only, with a certificate of your own: see Office only, with internal DNS.