How to set username format sent in claim within a federated scenario? Skip to main content
https://support.okta.com/help/answers?id=906f0000000hzywias&refurl=http%3a%2f%2fsupport.okta.com%2fhelp%2fanswers
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
1
2
3
4
5
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Ask Search:
Shawn VauseShawn Vause 

How to set username format sent in claim within a federated scenario?

So the situation is as follows:

I am a developer working on a project that involves a federated sign-on via the Okta cloud service (Template WS-Fed). Our local Windows 7 machines (running IIS Express) and our dev server running Windows Server 2008 (IIS 7) seem to work as expected by returning a username in the upn format (ie: user@domain.local). However, when running the same code on a Windows Server 2012 box (IIS 8) the UPN is not returned in favor of the older format Domain\User. I know there are a lot of variables here with the inconsistent landscape.  

Is this something at the server OS level or IIS level? In IIS we have windows authentication enabled but I am not quite sure if that is involved here or is it simply a pass through on the IIS instance. In addition, I suppose something at the Active-Directory level could be at fault (but I am by no means an AD expert).

Something to note is it does not appear to be Okta/Okta configuration we have defined (Template Ws-Fed) as it works locally and I tried switching out the test configuration with the dev configuration (that is working on the Win 2008 server) and got the same result with the older username format. Any thoughts would be much appreciated. Thanks in advance!
api-workday api-workdayapi-workday api-workday
Hi Shawn,

It seems most likely the fact that you have Windows Authentication enabled on the Server 2012 system.

From what I have seen the Claim of DOMAIN\User isn't a claim that is presented from an Okta generated WSFED assertion.

If the intent is to use federated authentication exclusively i would disable Windows Authentication from the equation.

-Matt
Shawn VauseShawn Vause
Hi Matt,

If I disable Windows Authentication how till the pass through occur to Okta when someone is on the network?  They shouldn't need to enter their network credentials if they are already logged on internally.  Thanks for the assistance!

-Shawn
api-workday api-workdayapi-workday api-workday
The single sign on experience with federation and okta would involve having an IWA server for desktop SSO.

The sequence would be (longest possible quasi SP initiated flow described)
  1. useragent visits your app (or any app that supports federated auth SAML or WS)
  2. authentication is required so you redirect them to the okta application link
  3. useragent is directed to your okta wsfed endpoint but isn't authenticated with okta
  4. Okta detects that the user came from your network (after you've registed the egress ip address)
  5. Okta directs the useragent to the IWA server
  6. IWA server leverages Kerberos/NTLM to authenticate the user
  7. IWA server redirects useragent to okta with authentication message
  8. Okta accepts the authentication message for the user
  9. Okta redirects the useragent to your app with a WSFED assertion
Here are some details about desktop SSO / IWA
https://support.okta.com/help/articles/Knowledge_Article/28101616-Configuring-Desktop-SSO

 
Shawn VauseShawn Vause
Matt,

I turned off Windows Authentication to try it and now I am issued a 401.3 access denied message.

Regards,

Shawn