My dashboard is running in IIS as an IIS application on a recently built Server 2016 server. It runs as a service account. Many of my pages connect to login.microsoft.com to get an authorization token to talk to the Power BI API.
If I am logged in to the server as the service account (even if I disconnect the session), the dashboard works as expected and can successfully retrieve a security token.
But if the service account is logged out, this step fails. IIS is running normally. The dashboard is otherwise running normally. But when I try to connect to login.microsoft.com to get the authorization token, it fails with an error that is normally indicative of a connectivity issue.
The server is on-prem and domain joined in a large enterprise with all of the usual networking and security nonsense that implies.
I don’t have reason to assume this is a Universal Dashboard issue, but I don’t know what else it could be either.
Does anyone have any ideas what could cause this behavior?
For IIS, i use the CredentialManager module to store a credential object as a service account, then retrieve it with -Credential (Get-StoredCredential -Target MyCredentialObject) Seems to work fine with me being logged out.
So essentially, open Powershell, (As the service account! you can check by issuing whoami), then run:
The credential being passed to login.microsoft.com is not the service account that UD is running as. The credential is retrieved from a CLIXML file. I have verified that it is correctly retrieving the credential object. It’s the sending of that credential to login.microsoft.com that is failing, apparently due to network problem, which makes no sense to me.
It doesn’t have to be, it can literally be any thing you want. I use it to encrypt our Tenant ID, heck you could put in a domain admin user (try not to do that lol)
If you’re using Import-CliXml, did you export it on that same computer and user? You must do both or it won’t work.
HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\disabledomaincreds was set to 1. This is normally done via GPO, specifically “Computer Configuration\Windows Settings\Local Policies\Security Options\Network access: Do not allow storage of passwords and credentials for network authentication”. But in this case it was not.
I discovered this when, during troubleshooting, I couldn’t create a scheduled task to run when logged off, and then had an error message to research.
Waiting for client to flip the bit back to 0 to test the proposed solution.
On further testing, the script can’t find the corporate web proxy.
Would adding default proxy details to machine.config help? Does this need to be the machine.config in the system .Net folder, or can this be an app specific machine.config that goes somewhere in the UD folder structure? @adam?
The same code running outside of UD finds and uses the web proxy without a problem. (I haven’t testing running in UD without IIS.)
This is beyond my area of expertise when it comes to IIS configuration and ASP.NET Core. I’m happy to do some research into it but am traveling for the next week so I probably won’t have much time to do so until I get back. If you want to try and attach to the UD instance from within IIS to help with debugging, you should be able to use the technique I describe here: https://youtu.be/BlMbcewR9Rw?t=223
I am using the .dll that comes with AzureRm.Profile to get the OAuth token. It uses the logged-in user’s internet settings. If the user isn’t logged in to Windows “interactively”, those settings are not in the expected place in the registry. Running as an IIS application turns out to be one of those places which does not in and of itself constitute an interactive Windows session.
I talked with lots of people in the community and at Microsoft and cannot find an alternative method to get the OAuth token which allows for specifying web proxy settings.
Workaround:
I created a scheduled task on the server to run a script that does nothing but sleep for 24 hours as the service account that runs my dashboard. The task kicks off at start up, 8 AM, and 8 PM, so there should always be a couple running.
Running a scheduled task as a particular user opens/maintains an interactive Windows sessions for the duration, which allows the dashboard script to find the service account’s web proxy settings.