- Pulse Secure Community
- :
- About wb_
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
since
10-29-2017
10-29-2017
wb_
Occasional Contributor
8
Posts
0
Kudos
0
Solutions
01-08-2013
07:03:AM
Hello Kannan, thank you for your proposal. But why do you think that this will solve the problem? Where is the important difference between having 1 hours or 2 hours configured on the client? Thank you for your answer, William
... View more
12-20-2012
02:42:PM
Hello, on the IC you configure a max session length at the role level. A client using the oac agent will have a https-control session towards the IC. When the max session timeout is reached the client (and IC/UAC) will not only close the https-session but the client will also send a EAPoL-Logoff message to the switch. This leads to a complete interface interruption and a new authentication is started. This is very bad because the client will terminate all running tcp sessions. For example a rdp-session gets disrupted. The disruption occurs for approximately 15 seconds. To circumvent this Juniper mentions in the admin guide for the IC/UAC a "use case 5" where the problem is described and where the solution is mentioned, that the switch should use a shorter timeout value for the 802.1x session than the "max session timeout" for the IC/UAC session. This can be done by sending a shorter Session-Timeout Radius return attribute from the IC/UAC towards the switch or by configuring a hard reauthentication timer on the switch. Juniper mentions: "When the switch or wireless access point times out a session, the Odyssey Access Client can resume the Infranet Controller session by interacting with the Infranet Controller without interrupting network access. There are two ways that this can be done on the Odyssey Access Client: ´ TTLS session resumption„Odyssey Access Client reauthenticates to the Infranet Controller based on TLS keying material from the previous session. ´ DSID session resumption„this happens when TTLS session resumption fails but the Infranet Controller session is still valid. TTLS session resumption can fail if Odyssey Access Client is configured for a shorter TTLS session resumption maximum than the length of the IC session. In DSID session resumption, Odyssey Access Client authenticates to the Infranet Controller using new TLS keying material, but without creating a new IC session. You configure Session Resumption on the Odyssey Access Client Tools > Options panel." BUT this does not work! In fact it works only when I have a max session timeout value on the IC-role which is not longer than 10 minutes. In this case a reauthentication - for example made by the switch - leads the oac agent to disconnect the session towards the IC and to build up of a new one. Only then the counter the counter of max session is reset. When the max session timeout of the role is longer, the reauthentication takes place at the layer 2-level but the session between the client and the IC/UAC gets not renewed: The max session timer keeps counting down towards Zero. If zero is reached, the session is totally disconnected - also on layer 2. All TCP-sessions fail et cetera. Can anyone explain to me the details of this behaviour? I want to have a max session length of around 10 hours but no disconnection of the client. regards, W.
... View more
10-19-2012
12:50:AM
In the restriction parameters of a realm or a role you can choose certificates and/or host checker policies directed to cert checks, but: The check for the CRL is not configured there but at the layer system -> configuration -> Certificates -> trusted client CAs There you define for a specific Certificate Authority (CA) if you want to check the CRL, or to use the OSC-Protocol (OSCP) to check online the validity of a cert, or to do no checks at all about the validity of the cert when a client presents its client cert. The check to use a crl or not can so far only be decided at this layer but not at the layer of the concrete hc policy itself. This is at least my understanding of the software mechanism in place with Juniper. The "validation of the private key" is always done with every authentication mechanism using certificates on every "real" product from any vendor. Otherwise it would make no sense. The certificate contains only the public key and is spread "all over the world". When someone presents this cert to gain entrance to some secure area, he must have the private key to solve a cryptographic challenge the guard is presenting to him. So the correct answering of this cryptographic challenge is the "validation of the private key": I - and hopefully only I - have it. regards, William
... View more
09-25-2012
08:16:AM
just to close this thread from my side: we have now chosen a max session length of 10h (-> configured on uac -> role, session option) the client is doing a reauthentication every 1h (-> configure on client) host checker is running every 20min, with idle session closing after 1 h the switch is doing a reauthentication every 3 h the staleperiod on the client is set to default 12h now we see every 20 min: a host checker check in the uac log every 1h: a regular reauthentication in the switch log, which is initiated by the client every 10 h: a login - logout process on the uac; it lasts about 4 sec. What is important, it goes along with no disruption of the authorized link on the switch, therefore no dhcp-issues and so forth sometimes (when the client is really idle) after 1h closing of the host checker session, new authentication on the switch, dhcp, new login. total disruption of about 20 sec. But this is ok, because the client is not sending any traffic. regards, William
... View more
09-19-2012
05:31:AM
to add our latest findings: when the staleperiod for the session resumption (configured on the client: machine authentication, tools -> options -> security) is set to a smaller value than the max. session length, but to a greater value than the reauthentication timer, then the reauthentication works with no disruption, but after the staletimeperiod we see the disruption of the client session, an authentication failed message on the switch. It takes about 15-20 seconds to be back online. So we are still not sure if we can avoid the session disruptions when we have the staletimeperiod longer than the max. session length. The default staletimeperiod set on the client is 12 h. So we set the max. session length now to 10 h. By the way. Do you have clarifications on the heartbeat timer and the timeout value (can be set at the session options at the role level) regards, William
... View more
09-17-2012
07:13:AM
ok - here some of my results so far from our testing environment: a) max session length: 6 min Host checker: 2 min oac-agent: reauthentication - no switch periodic reauthentication - no effect: after max session length, logout, no authentication on the switch, authorization failed, complete new session build up inclusive dhcp -> session disruption 20 sec. b) changing Either switch periodic reauthentication (testing: 45 sec) or turning on "enable automatic reauthentication" on oac (180 sec; possible via reg-key, not via gui) -> results in logout/login with UAC, but authentication/authorization on the switch stays up; also on UAC: complete login process with host checker policy, BUT no session disruption, no dhcp still not reproducible the session resumption (it belongs to tls in the reg-key-area) with a max length of 12h where a session resumption takes place. So far I have learnt and understood from JTAC that this is especially usefull fo roaming wireless clients which is not our setting. => So for overcoming our disruption cases I think I will go to the configuration - 3h periodic reauthentication on the switch - 1h reauthentication on the oac agent - another securty measure which acts as the guard in the back is the host checker. If it fails it should bring down the session as wanted - on the roleside of the uac : max session length about 10h I really would appreciate the experiences and the knowledge from you if you have a similar productive environment. regards, W.
... View more
09-17-2012
07:11:AM
ok: in my testing environment: a) max session length: 6 min Host checker: 2 min oac-agent: reauthentication - no switch periodic reauthentication - no effect: after max session length, logout, no authentication on the switch, authorization failed, complete new session build up inclusive dhcp -> session disruption 20 sec. b) changing Either switch periodic reauthentication (testing: 45 sec) or turning on "enable automatic reauthentication" on oac (180 sec; possible via reg-key, not via gui) -> results in logout/login with UAC, but authentication/authorization on the switch stays up; also on UAC: complete login process with host checker policy, BUT no session disruption, no dhcp still not reproducible the session resumption (it belongs to tls in the reg-key-area) with a max length of 12h where a session resumption takes place. So far I have learnt and understood from JTAC that this is especially usefull fo roaming wireless clients which is not our setting. => So for overcoming our disruption cases I think I will go to the configuration - 3h periodic reauthentication on the switch - 1h reauthentication on the oac agent - another securty measure which acts as the guard in the back is the host checker. If it fails it should bring down the session as wanted - on the roleside of the uac : max session length about 10h I really would appreciate the experiences and the knowledge from you if you have a similar productive environment. regards, W.
... View more
09-16-2012
04:03:AM
Hi colleagues, we have a problem: 802.1x clients with oac (newest version) connect to the switch with machine certification. all ok. Then, after a not yet clear amount of time the following happens: uac-log: logout event switch: authorization failed event client: looses connectivity - the complete authentication and authorization process unfolds again. uac: host checker, realm and role check -> passed authentication and authorization on switch Unfortenately with dhcp request and so on ... uac-log: login event effect: the client experiences a 20 second disruption at the beginning we thought that the problem was because of the reauthentication on the switch and the session length defined on the uac: we thought when the process of logout and login would fall in the period when the switch would start the reauthentication we have a "bad" coincidence .. But now we have completely shut down the reauthentication on the switch. Besides that we observed that the disruption was occuring on one client in a 12h-interval From JTAC we learned about the settings on the client profile ("tools -> security:) resumption and reauthentication the acutal settings: resumption enabled, during 12h reauthentication not enabled session length on uac-role: 2 days role heart-beat-interval: 30 min general host checker 20 min I would appreciate your experiences and knowledge about this. William
... View more
Latest Tags
No tags yet
© 2017 Pulse Secure, LLC. Use of this website assumes acceptance of our Legal Notices and Privacy Policy.
Pulse Secure has updated its Privacy Policy effective June 28, 2017.
