<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
0D50Z00008G7VQGSA3Okta Classic EngineAdministrationAnswered2024-04-17T09:30:38.000Z2015-12-03T02:46:03.000Z2018-04-19T22:44:49.000Z

exx9s (exx9s) asked a question.

Edited by varun.kavoori1.5210444522562532E12 September 5, 2018 at 1:20 AM
DirectAccess and Dsktop SSO

We are rolling out Microsoft DirectAccess to allow user to connect to our internal resources.

 

Okta Desktop SSO is used at the moment to provide automatic login (Desktop SSO)for a few services, however, when the users go to Okta through the DirectAccess tunnel it prompts for credentiasl as the connection is not coming from the Public Gateway IP defined in Okta.

 

Is there anyway to "trust" these connections other than the Public Gateway IP (NTLM, certificate or otherwise)?

  • 6 answers
  • 1.57K views
j5v7c likes this.

  • svcV.75126 (Customer)

    Hi Jorge,

     

    we accomplish this with DirectAccess by adding <ourorg>.okta.com to the NRPT in DirectAccess. This causes all traffic bound for our Okta org to go through the DA Tunnel -> to our datacenters -> Okta. This allows Okta to recognize the requests as having come from our registered network ranges and the desktop sso redirect can take place.

     

    Hope that helps,

    -Matt

     

    Expand Post

  • exx9s (exx9s)

    Thanks Matt,

    I tried that but can't get it to work. When you add entries to the NRPT you need to also add a DNS server for them (if you don't they are considered exceptions and not tunneled) so if I add out internal DNS there, it doesn't resolve the <ourorg>.okta.com.

    What DNS server did you add to your entry in the NRPT?

  • svcV.75126 (Customer)

    Hi, I guess I was a little vague.

     

    The idea is to leverage the DNS64 Service provided by DA to tunnel the traffic bound for org.okta.com TO the DA server and thus out of a your corporate internet access that is already registered with Okta to redirect to the Desktop SSO/IWA server.

     

    The other assumption is that your IWA server is already configured to be available through the same DNS64 service provided by DA.

     

    I'll cover the setup of my IWA/Desktop SSO servers some other time. They are configured to be HA and use SSL, SPN's have been published to ensure Kerberos etc etc.

     

    Standard internal Domain registered to hit the DA tunnel is: varian.com, the HA name of the IWA servers is ssoiwa.org.com so it is already hitting the DA Tunnel.

     

    I added varian.okta.com to the DA Tunnel, I've configured this domain to use the same DNS servers as the org.com namespace and that is the IPV6 address's of the Direct Access Servers 
    1.  netsh namespace show effectivepolicy Settings for .org.com ---------------------------------------------------------------------- Certification authority : DNSSEC (Validation) : disabled IPsec settings : disabled DirectAccess (DNS Servers) : ffff:ffff:aaaa:3333::1 DirectAccess (Proxy Settings) : Bypass proxy Settings for nls.org.com ---------------------------------------------------------------------- Certification authority : DNSSEC (Validation) : disabled IPsec settings : disabled DirectAccess (DNS Servers) : DirectAccess (Proxy Settings) : Use default browser settings Settings for .org.okta.com ---------------------------------------------------------------------- Certification authority : DNSSEC (Validation) : disabled IPsec settings : disabled DirectAccess (DNS Servers) : ffff:ffff:aaaa:3333::1 DirectAccess (Proxy Settings) : Bypass proxy 
     The Result is this 
    1.  C:\Users\me>ping org.okta.com Pinging org.okta.com [ffff:ffff:aaaa:7777::36c5:c0a4] with 32 bytes of data: 
     

    Now the traffic for org.okta.com is heading for the DA tunnel where NAT6to4 will take over and send the traffic to 54.197.192.164 (36c5:c0a4).

     

    Hope that helps,

    -Matt
    Expand Post

  • svcV.75126 (Customer)

    Oh yes, the real results.

     

    Me sitting in some random location with public WIFI get the benefit (convienience and security IMO).

     

    The egress address of the random place i'm sitting at is: 23.30.59.197, the egress address of my DA server is 199.199.92.85.

     

    From the Okta logs: 
    1.  MessageIWA authentication result: SUCCESSAttempted IWA login user=myid@org.com, domain=org, ip=199.199.92.85, redirectUrl=geo1-ssoiwa.org.com Session ID101XMzPX39xRx6B2X4n1Mi9xx Request IDVmMcx7dajZJTL2zrQU9m5QXXXhU Performed byMatt Egan (myid@org.com) Client IP199.199.92.85 Request URI/login/sso_iwa_auth
     

    Expand Post

  • exx9s (exx9s)

    Thanks Matt, I think I got it working!

     

    When I added the <mydomain>.okta.com to the NTRP I coudl see the requests were going to the DA server but it was timing out.. .Turns out I needed to add static routes to the Okta IP ranges in my DA server!

    The DA Server has 2 interfaces (Public and Private) and the defautl gateway is the public interface, but anything you add to the DA tunnel has to be routed internally, so I added the routes and it seems to be working.

    Will do some more testing today but looking good.

    Thanks for the help! 

    Expand Post

  • Hari SundarG.01170 (Customer)

    HI Matt,

    Will you please explain "The other assumption is that your IWA server is already configured to be available through the same DNS64 service provided by DA."  how to configure this set up
This question is closed.
Loading
DirectAccess and Dsktop SSO