So i’ve tried to be fancy, and use the new oauth authentication with the fancy tokens.
However… cannot seem to find any reference to what return url is being passed:
I haven’t changed it from a functional “regular” Azure AD authentication, and currently is:
https://dashboard.somedomain.com/signin-oidc
Any suggestions?
(pardon my Norwegian, “Sorry, we could not log you on” - loosely translated)
Ack. I need to get this in the documentation. Sorry about that: http://localhost:10001/signin-callback
I could also make this configurable.
Works-ish.
Now i got a headersize related issue in IIS…
And after increasing:
Static background…
Should i not include group memberships claims in the app-registration?
I sure wish it would tell you what the unhandled exception was… Does it work if you don’t include the group claims?
I’ll test it after dinner and update you 
Hi again @adam,
Yep, no change with “null” for GroupMembershipclaims in the manifest.
The RESTAPI auth works like a charm, but that is a separate auth method.
Could i be misusing some variables anywhere which could lead to this, or is it IIS related issue?
Yep, it’s my authorization policies…
However, i see no reason for these to fail.
All of them are hardcoded to $User.Identities.Name checks, as i am lazy and haven’t gotten around to utilizing groups.
Any ideas?
Do you have debug logging on or just warning level? I wonder if there is more info in the log. Otherwise, I can look at adding some additional logging to see if we can catch that unhandled exception and get it in a kit for you to play with.
I’ll mail you the relevant logs dude
Just checking if it’s 1 of 4 auth policies, or multiple.
UD took a DECENT performance hit aswell with the openid authentication.
42 Endoints idle, checked the diagnostics page. Regular numbers.
(Settings the auth policy to “return $true” works)
I think it’s actually a problem with this: https://github.com/ironmansoftware/universal-dashboard/issues/1372
I think I’ll roll out a 2.8.1 build next week because of that issue. Can you give the nightly enterprise build a shot and see if it’s the same issue with performance?
Hi,
Is it out already?
I’ll give it a go and update along the way!
Well, let me make sure. Doesn’t look like there was a nightly from last night.
Your theory makes sense to my logfile of authpolicies.
Basically i did add-content $User | convertto-json “logfile”
76KB of log file on first login.
I’m hopeful :-3
Yurp…
And Houston down! The build failed last night so I’ll fix that up and get something for you tomorrow that should prevent this from happening.
It’s friday afternoon dude, are you ever “off work”? 
Don’t stress it dude, i can just revert to the old auth method and do some component work if i get bored
Found the main reason for the performance issue by the way:
Log level “debug” seems like it’s taking it’s time to append the log file.
Reverted it back to “warning” and the speed is decent once more!
Could probably have truncated the logfile, but 20MB isn’t that big for a logfile…
Hi again,
Is this the relevant nightly build?
Lack of changelogs on the enterprise edition
