<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
System Status
Announcements
Announcements
Search
Search
Select Language
Knowledge Base
Knowledge Articles
Support Videos ↗
Documentation
Product Documentation ↗
Developer Documentation ↗
Product Release Notes ↗
Community
Events & Webinars
Okta Ideas ↗
Resources
Product Hub
Customer Success Hub
Product Release Update
Learning
Okta Learning ↗
Get Support
Open a Case
HomeCommunityForum
0D50Z00008G7VPrSANOkta Classic EngineSingle Sign-OnAnswered2024-04-17T12:05:19.000Z2016-02-17T14:28:32.000Z2017-08-11T15:31:19.000Z

deh7h (deh7h) asked a question.

Edited by varun.kavoori1.5210444522562532E12 September 5, 2018 at 1:20 AM
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!
  • 4 answers
  • 1.17K views

  • svcV.75126 (Customer)

    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
    Expand Post

  • deh7h (deh7h)

    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
    Expand Post

  • svcV.75126 (Customer)

    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

     

     
    Expand Post

  • deh7h (deh7h)

    Matt,

     

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

     

    Regards,

     

    Shawn
    Expand Post
This question is closed.
Loading
How to set username format sent in claim within a federated scenario?