<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
0D50Z00008G7UqcSAFOkta Classic EngineAdministrationAnswered2020-09-01T21:59:18.000Z2015-11-09T20:35:03.000Z2016-09-13T05:17:12.000Z

  • brian.ko1.3927405383036187E12 (Okta, Inc.)

    Hi Patrick, 

     

    On a high level, Okta forwards the authentication to your domain controller.  The domain controller authenticates the user and Okta receives the response.  This process can be seen when you look at the AD Agent logs, which tells you which domain controller the authentication attempt was sent to and the response received.  

     

    We hope that answers your question!

    Expand Post

  • PatrickC.59989 (Customer)

    Thx Brian. What protocol does Okta use to forward the authentication to the AD DC? I assume the request goes from Okta to the AD Agent then to the AD DC?

  • svcV.75126 (Customer)

    Hi Patrick,

     

    When i've watched the wire between my AD Agent and DC it is Kerberos for delegated authentication, KPassd for password changes and LDAP for queries with GSSAPI KRB5 inside of SASL'd binds.

     

    -Matt
    Expand Post

  • PatrickC.59989 (Customer)

    Thx Matt. What did you see for the connection from Okta to the AD Agent? Is it GSSAPI as well? What ports do the AD Agent requires in order to receive this communication?

  • svcV.75126 (Customer)

    Okta to the AD Agent is actually AD Agent to Okta.

     

    the AD Agent polls Okta over HTTPS (TLS / standard port 443) collecting jobs and posting responses.

     

    With this model there is actually no requirement to open ports from Okta->AD Agent but you do need to allower outbound HTTPS or provide a proxy server for the AD Agent to communicate out through.

     

    -Matt
    Expand Post

  • PatrickC.59989 (Customer)

    Thx Matt. So when a user logs into Okta, the authentication is forwarded to the AD DC via the AD Agent. Wouldn't that require Okta to AD Agent communication?

  • svcV.75126 (Customer)

    Hi Patrick, not in the polling model that is used.

     

    Basically the AD Agent is constantly polling Okta for tasks. It reaches out and grabs a task returning immediately if it is there or stalling for a moment if one isn't immediatley waiting after a sane period the request for a task will return with no actions waiting and then reaches out again to look for waiting tasks.

     

    A peek at the AD Agent logs in debug mode:

     

    2015/11/13 23:04:52.652 Debug -- myADAgent(10) -- GET: <bigSpecialUrl>

    2015/11/13 23:04:52.652 Debug -- myADAgent(8) -- Finished Request

    2015/11/13 23:04:52.652 Info -- myADAgent(8) -- Next action = NONE

    2015/11/13 23:04:52.652 Info -- myADAgent(8) -- Retrieving next action

    2015/11/13 23:04:52.652 Debug -- myADAgent(8) -- GET: <bigSpecialUrl>

    2015/11/13 23:04:59.074 Debug -- myADAgent(11) -- Finished Request

    2015/11/13 23:04:59.074 Info -- myADAgent(11) -- Next action = NONE

    2015/11/13 23:04:59.074 Info -- myADAgent(11) -- Retrieving next action

    2015/11/13 23:04:59.074 Debug -- myADAgent(11) -- GET: <bigSpecialUrl>

    2015/11/13 23:05:02.043 Debug -- myADAgent(9) -- Finished Request

    2015/11/13 23:05:02.043 Info -- myADAgent(9) -- Next action = Okta.Api.UserAuthAction

    2015/11/13 23:05:02.043 Info -- myADAgent(9) -- Retrieving next action

    2015/11/13 23:05:02.043 Debug -- myADAgent(9) -- GET: <bigSpecialUrl>

    2015/11/13 23:05:02.058 Debug -- myADAgent(5) -- Authenticating user myAccount@devqa.myprev.local

    2015/11/13 23:05:03.136 Debug -- myADAgent(5) -- Processing USER_AUTH action (<stuff>) finished,

    2015/11/13 23:05:03.136 Debug -- myADAgent(5) -- Sending action result (SUCCESS) for action USER_AUTH (<stuff>)

    2015/11/13 23:05:03.136 Debug -- myADAgent(5) -- POSTing ActionResult to Okta. <Result>

    2015/11/13 23:05:03.136 Debug -- myADAgent(5) -- POST: <bigSpecialUrlPost>

    2015/11/13 23:05:03.965 Debug -- myADAgent(5) -- Finished Request

    2015/11/13 23:05:03.980 Debug -- myADAgent(5) -- Data post finished, (executionTime=00:00:00.8346143)

    2015/11/13 23:05:03.980 Debug -- myADAgent(5) -- Sending result for USER_AUTH action (<stuff2>) finished

    2015/11/13 23:05:08.793 Debug -- myADAgent(8) -- Finished Request

    2015/11/13 23:05:08.808 Info -- myADAgent(8) -- Next action = NONE

    2015/11/13 23:05:08.808 Info -- myADAgent(8) -- Retrieving next action

    2015/11/13 23:05:08.808 Debug -- myADAgent(8) -- GET: <bigSpecialUrl>

    2015/11/13 23:05:08.918 Debug -- myADAgent(10) -- Finished Request

    2015/11/13 23:05:08.918 Info -- myADAgent(10) -- Next action = NONE

    2015/11/13 23:05:08.918 Info -- myADAgent(10) -- Retrieving next action

    2015/11/13 23:05:08.918 Debug -- myADAgent(10) -- GET: <bigSpecialUrl>

    2015/11/13 23:05:15.324 Debug -- myADAgent(11) -- Finished Request

    2015/11/13 23:05:15.324 Info -- myADAgent(11) -- Next action = NONE

    2015/11/13 23:05:15.324 Info -- myADAgent(11) -- Retrieving next action

    2015/11/13 23:05:15.324 Debug -- myADAgent(11) -- GET: <bigSpecialUrl>
    Expand Post

  • PatrickC.59989 (Customer)

    Thx Matt. Ok so if I understand this correctly, Okta will have a request (to authenticate a user) waiting in a queue, the AD Agent polls Okta, sees the request in the queue, picks it up, processes the request, and then returns the result to Okta,, correct?

    Also I believe Okta stores the user's AD password in its cloud database, so that a user can still authenticate if the AD Agent is not running for some reason, correct?
    Expand Post
This question is closed.
Loading
Okta and ADSI