DirectAccess and Dsktop SSO Skip to main content
https://support.okta.com/help/answers?id=906f0000000qtgsia0&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:
Administrator Jorge GolvanoAdministrator Jorge Golvano 

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

api-workday api-workdayapi-workday api-workday
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

 
Administrator Jorge GolvanoAdministrator Jorge Golvano
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?
api-workday api-workdayapi-workday api-workday
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
 
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
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
api-workday api-workdayapi-workday api-workday
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:
Message	IWA authentication result: SUCCESSAttempted IWA login user=myid@org.com, domain=org, ip=199.199.92.85, redirectUrl=geo1-ssoiwa.org.com
Session ID	101XMzPX39xRx6B2X4n1Mi9xx
Request ID	VmMcx7dajZJTL2zrQU9m5QXXXhU
Performed by	Matt Egan (myid@org.com)
Client IP	199.199.92.85
Request URI	/login/sso_iwa_auth

 
Administrator Jorge GolvanoAdministrator Jorge Golvano

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!