Connectivity issue from UD


#1

I’ve got a weird connectivity issue.

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?

Thanks,
Tim Curwick


#2

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:

Get-Credential | New-StoredCredential -Target Creds -Persist Enterprise

This can be retrieved (by the same user only) later


#3

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.

Any other ideas?

Thanks,
Tim Curwick


#4

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.


#5

I believe I found the answer.

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.

Thanks,
Tim Curwick


#6

Nope, that wasn’t it.

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.)

Thanks,
Tim Curwick


#7

Hey Tim,

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

Thanks,
Adam


#8

Try logging in as the service account and setting the proxy settings in Internet Explorer if they are not set there already.