To PingFederate Q&A
Choice 1
Choice 2
To PingFederate Q&A
Michael M  asked a question
Loop detection

I have an issue where the browser loops between service (Azure app that requires MFA) and the PingFederate server. I know the reason: it's a missing attribute and I know how to fix it.

But my primary question is: Is there some kind of loop detection built into PF? ADFS has such a feature (tracks client via Cookie and stops when there are too many requests within a specified timeframe).

I am afraid of users running into such a situation and ignoring it while the browser constantly generates requests to the server forever.

KR

Michael

I have an issue where the browser loops between service (Azure app that requires MFA) and the PingFederate server. I know the reason: it's a missing attribute and I know how to fix it.

But my primary question is: Is there some kind of loop detection built into PF? ADFS has such a feature (tracks client via Cookie and stops when there are too many requests within a specified timeframe).

I am afraid of users running into such a situation and ignoring it while the browser constantly generates requests to the server forever.

KR

Michael

More >
Answer   -   Like Share   -  July 6, 2018 at 9:40 AM
Jarred B  asked a question
Sudden loss of LDAP connectivity, only solved by restarting PingFederate service

Looking for some advice from the community; possibly others are seeing this issue as well?   (This is a re-post since I didn't use a group with the original)

 

We've been noticing that about once a week (sometimes more), PingFederate will just stop authenticating users due to a connectivity loss between itself and the LDAP connection associated with the adapter (we use ADLDS).  It's intermittent, and successive SSO attempts may pass in time, but once the error occurs it signals many more errors are on their way.

 

The only way we've found to be able to restore the LDAP connectivity is to restart the PingFederate service on the affected runtime node.  

 

Has anyone else experienced this issue?  I'd be happy with an explanation as to why this happens at the least.  Any guidance on how to trace the cause?  If you know how to fix permanently, that would be amazing :)

 

Thank you for your guidance!

Looking for some advice from the community; possibly others are seeing this issue as well?   (This is a re-post since I didn't use a group with the original)

 

We've been noticing that about once a week (sometimes more), PingFederate will just stop authenticating users due to a connectivity loss between itself and the LDAP connection associated with the adapter (we use ADLDS).  It's intermittent, and successive SSO attempts may pass in time, but once the error occurs it signals many more errors are on their way.

 

The only way we've found to be able to restore the LDAP connectivity is to restart the PingFederate service on the affected runtime node.  

 

Has anyone else experienced this issue?  I'd be happy with an explanation as to why this happens at the least.  Any guidance on how to trace the cause?  If you know how to fix permanently, that would be amazing :)

 

Thank you for your guidance!

More >
Answer   -   Like Share   -  June 28, 2018 at 8:41 PM
Aneesh P  asked a question
multiple password credential validator in an adapter i see we can add it but how can i check supplied user/password is in either one
More >
Answer   -   Like Share   -  June 28, 2018 at 2:40 PM
Karan M  asked a question
SSO to multiple aws role.

Hi,

we have AD user which are parts of multiple AD group for example AWS-admin, AWS-Ops and we have setup the SSO in between AWS and ping federation. We want each users to see the multiple role when they click on the SSO url and then they select the roles. We don’t want to use the multivalved attribute approach since we have large number of users. 

 

So what would be the best approach in this case?

 

Thanks

Hi,

we have AD user which are parts of multiple AD group for example AWS-admin, AWS-Ops and we have setup the SSO in between AWS and ping federation. We want each users to see the multiple role when they click on the SSO url and then they select the roles. We don’t want to use the multivalved attribute approach since we have large number of users. 

 

So what would be the best approach in this case?

 

Thanks

More >
Answer   -   Like Share   -  June 26, 2018 at 12:37 PM
Ã?kos K  asked a question
Reset password - Email One-Time Password

Hi guys,

 

We are using PingFederate 8.4.0 and we haven't been able to find where we can set the expiry for the One-Time Password for the reset password procedure.

 

Our client is struggling to reset/change their password, because their email server is getting the email after an hour and that time the password is expired.

 

Do you know when the One-Time Password is expired? Can we configure it somehow?

 

Thanks,

Ákos

Hi guys,

 

We are using PingFederate 8.4.0 and we haven't been able to find where we can set the expiry for the One-Time Password for the reset password procedure.

 

Our client is struggling to reset/change their password, because their email server is getting the email after an hour and that time the password is expired.

 

Do you know when the One-Time Password is expired? Can we configure it somehow?

 

Thanks,

Ákos

More >
Answer   -   Like Share   -  June 22, 2018 at 2:43 PM
This is configured in your HTML Form Adapter instance.

In the administrative console, go to:
- IdP Configuration
- Adapters
- Click on your HTML Form Adapter instance that's configured for password reset.
- See the OTP TIME TO LIVE setting (now called "PASSWORD RESET TOKEN VALIDITY TIME" in more recent PF versions). By default it is valid for 10 minutes.

For more details, see: https://documentation.pingidentity.com/pingfederate/pf84/index.shtml#adminGuide/pf_r_htmlFormAdapterAdvancedFields.html
Like   -   June 23, 2018 at 6:38 AM
This is configured in your HTML Form Adapter instance.

In the administrative console, go to:
- IdP Configuration
- Adapters
- Click on your HTML Form Adapter instance that's configured for password reset.
- See the OTP TIME TO LIVE setting (now called "PASSWORD RESET TOKEN VALIDITY TIME" in more recent PF versions). By default it is valid for 10 minutes.

For more details, see: https://documentation.pingidentity.com/pingfederate/pf84/index.shtml#adminGuide/pf_r_htmlFormAdapterAdvancedFields.html
Like   -   June 23, 2018 at 6:38 AM
Brian S  asked a question
Is it possible to set up a duplicate SP configuration to a single client partner connection?

We want to test a client's SSO process in a second environment, so that they sign in to the same partner connection URL, but would be forwarded to a different Target URL. Currently using PingFederate version 8.0.3.1

We want to test a client's SSO process in a second environment, so that they sign in to the same partner connection URL, but would be forwarded to a different Target URL. Currently using PingFederate version 8.0.3.1

More >
Answer   -   Like Share   -  June 22, 2018 at 12:22 PM
Simone L  asked a question
Basic authentication not working with ReferenceID adapter and Agentless Integration Kit

Hi,

I have just installed PingFederate 9.0.4 and followed the steps to configure and use the sample application for the Agentless Integration Kit 1.3.2.

When I run the application from the browser, it works upto the ConfirmAttributes.jsp page. When Submit is clicked, SubmitToSP.jsp gives an error:

Error: java.io.IOException: Server returned HTTP response code: 401 for URL: https://localhost:9031/ext/ref/dropoff

See standard error output for details.

Tried to figure this out by using fiddler and sending the POST command as follows:

:9031/ext/ref/dropoff>https://:9031/ext/ref/dropoff

with the headers:

Content-Type: application/json

Authorization: BASIC aWRwX3VzZXI6aWRwX3Bhc3N3b3Jk

ping.instanceId: idpadapter

and json content : 

{"subject":"peter","name":"Peter Tester","groups":["Admins","Network Admins"],"status":"Bronze"}

But it gives an error:

HTTP/1.1 401 HTTP Basic Authentication Required

Any idea why this does not work or how I can trace out why there is a problem?

Hi,

I have just installed PingFederate 9.0.4 and followed the steps to configure and use the sample application for the Agentless Integration Kit 1.3.2.

When I run the application from the browser, it works upto the ConfirmAttributes.jsp page. When Submit is clicked, SubmitToSP.jsp gives an error:

Error: java.io.IOException: Server returned HTTP response code: 401 for URL: https://localhost:9031/ext/ref/dropoff

See standard error output for details.

Tried to figure this out by using fiddler and sending the POST command as follows:

:9031/ext/ref/dropoff>https://:9031/ext/ref/dropoff

with the headers:

Content-Type: application/json

Authorization: BASIC aWRwX3VzZXI6aWRwX3Bhc3N3b3Jk

ping.instanceId: idpadapter

and json content : 

{"subject":"peter","name":"Peter Tester","groups":["Admins","Network Admins"],"status":"Bronze"}

But it gives an error:

HTTP/1.1 401 HTTP Basic Authentication Required

Any idea why this does not work or how I can trace out why there is a problem?

More >
Answer   -   Like Share   -  June 18, 2018 at 10:19 AM
John D 
Take a look at the server.log file.
Like   -   June 18, 2018 at 3:20 PM
Thanks for your reply.

Had a look at the server.log file but it does not give much of a clue. It displays the error along with the stack trace from the java code (See below).

While trying to figure out the problem, removed the "ping.instanceId" header from both the dropoff and pickup calls. When the instanceId is not included in the request header information, the JSON response was received successfully with the REF.

Any idea what is the problem when the "ping.instanceId" is included in the header?


2018-06-18 14:22:31,002 ERROR [SystemErr] Mon Jun 18 14:22:31 IST 2018 SubmitToSP.jsp caught exception: java.io.IOException: Server returned HTTP response code: 401 for URL: https://localhost:9031/ext/ref/dropoff
2018-06-18 14:22:31,002 ERROR [SystemErr]

2018-06-18 14:22:31,002 ERROR [SystemErr] java.io.IOException: Server returned HTTP response code: 401 for URL: https://localhost:9031/ext/ref/dropoff
2018-06-18 14:22:31,002 ERROR [SystemErr]

2018-06-18 14:22:31,002 ERROR [SystemErr] at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1876)
2018-06-18 14:22:31,002 ERROR [SystemErr]

2018-06-18 14:22:31,002 ERROR [SystemErr] at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1474)
2018-06-18 14:22:31,002 ERROR [SystemErr]

2018-06-18 14:22:31,002 ERROR [SystemErr] at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)
2018-06-18 14:22:31,002 ERROR [SystemErr]

2018-06-18 14:22:31,002 ERROR [SystemErr] at org.apache.jsp.SubmitToSP_jsp.dropOffAttributesToRefererenceIdAdapter(SubmitToSP_jsp.java:127)
Like   -   June 19, 2018 at 6:06 AM
John D 
The instanceid is support to match the specific adapter you want to use. And it should match the adapter ID and is case sensitive. The fact that it worked without is actually strange.
Like   -   June 21, 2018 at 8:00 PM
John D 
Take a look at the server.log file.
Like   -   June 18, 2018 at 3:20 PM
Thanks for your reply.

Had a look at the server.log file but it does not give much of a clue. It displays the error along with the stack trace from the java code (See below).

While trying to figure out the problem, removed the "ping.instanceId" header from both the dropoff and pickup calls. When the instanceId is not included in the request header information, the JSON response was received successfully with the REF.

Any idea what is the problem when the "ping.instanceId" is included in the header?


2018-06-18 14:22:31,002 ERROR [SystemErr] Mon Jun 18 14:22:31 IST 2018 SubmitToSP.jsp caught exception: java.io.IOException: Server returned HTTP response code: 401 for URL: https://localhost:9031/ext/ref/dropoff
2018-06-18 14:22:31,002 ERROR [SystemErr]

2018-06-18 14:22:31,002 ERROR [SystemErr] java.io.IOException: Server returned HTTP response code: 401 for URL: https://localhost:9031/ext/ref/dropoff
2018-06-18 14:22:31,002 ERROR [SystemErr]

2018-06-18 14:22:31,002 ERROR [SystemErr] at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1876)
2018-06-18 14:22:31,002 ERROR [SystemErr]

2018-06-18 14:22:31,002 ERROR [SystemErr] at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1474)
2018-06-18 14:22:31,002 ERROR [SystemErr]

2018-06-18 14:22:31,002 ERROR [SystemErr] at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)
2018-06-18 14:22:31,002 ERROR [SystemErr]

2018-06-18 14:22:31,002 ERROR [SystemErr] at org.apache.jsp.SubmitToSP_jsp.dropOffAttributesToRefererenceIdAdapter(SubmitToSP_jsp.java:127)
Like   -   June 19, 2018 at 6:06 AM
John D 
The instanceid is support to match the specific adapter you want to use. And it should match the adapter ID and is case sensitive. The fact that it worked without is actually strange.
Like   -   June 21, 2018 at 8:00 PM
Cameron M  asked a question
Error page for SP initiated SSO

For SP-initiated SSO, is it necessary to redirect the user to the original requested resource (provided by relay state) after failing authn too many times? Is it possible to send them to a default error page?

 

For IDP initiated, when a user has failed to authenticate too many times they are sent to the idp.sso.error.page. 

 

We may be dealing with standards to the SAML protocal here but are not sure.

 

Any help is appreciated.

For SP-initiated SSO, is it necessary to redirect the user to the original requested resource (provided by relay state) after failing authn too many times? Is it possible to send them to a default error page?

 

For IDP initiated, when a user has failed to authenticate too many times they are sent to the idp.sso.error.page. 

 

We may be dealing with standards to the SAML protocal here but are not sure.

 

Any help is appreciated.

More >
Answer   -   Like Share   -  June 14, 2018 at 11:44 PM
Tom G 
Hi Cameron,

For SP initiated I don't believe there is a way - it's down to the SP how they render the authn failure. For SPs that don't handle this very well we have set up a custom selector in conjunction with a connection set selector that redirects the user to the IdP initiated URL when they try to do an SP initiated login.

Cheers,
Tom
Like   -   June 17, 2018 at 8:17 AM
What would be the purpose of the custom selector? To read from the connection set and redirect to the IDP error page on failed login?
Like   -   June 19, 2018 at 4:20 PM
Tom G 
We check that the HTTP 'referer' matches the SP site, and if so redirect the user to the PF startSSO endpoint. So if there is a problem authenticating the user will end up at idp.sso.error.page.template.html and you can have whatever logic you want in there.

So at a basic level in the AuthenticationSelector.selectContext() you could do:

String referrerValue = req.getHeader("Referer");
String samlRequestValue = req.getParameter("SAMLRequest");

if (referrerValue == null || samlRequestValue == null) {
return context;
}

Encoder encoder = new Encoder();

try {
String saml = req.getMethod().equals("POST") ? B64.decodeToString(samlRequestValue) : encoder.decodeSAMLMessage(samlRequestValue);
XmlObject xml = XmlBeansUtil.parse(saml, XmlObject.class);
String issuer = GeneralXmlUtil.getIssuer(xml);
String baseUrl = MgmtFactory.getLocalSettingsManager().getLocalSettings().getBaseUrl();
resp.sendRedirect(MessageFormat.format("{0}/idp/startSSO.ping?PartnerSpId={1}", baseUrl, issuer));
} catch (Exception e) {
// do something
}
return context;


Depending on the SP you might have to do a little more to get the user to the correct URL after signing in.
Like   -   June 19, 2018 at 4:41 PM
Tom G 
Hi Cameron,

For SP initiated I don't believe there is a way - it's down to the SP how they render the authn failure. For SPs that don't handle this very well we have set up a custom selector in conjunction with a connection set selector that redirects the user to the IdP initiated URL when they try to do an SP initiated login.

Cheers,
Tom
Like   -   June 17, 2018 at 8:17 AM
What would be the purpose of the custom selector? To read from the connection set and redirect to the IDP error page on failed login?
Like   -   June 19, 2018 at 4:20 PM
Tom G 
We check that the HTTP 'referer' matches the SP site, and if so redirect the user to the PF startSSO endpoint. So if there is a problem authenticating the user will end up at idp.sso.error.page.template.html and you can have whatever logic you want in there.

So at a basic level in the AuthenticationSelector.selectContext() you could do:

String referrerValue = req.getHeader("Referer");
String samlRequestValue = req.getParameter("SAMLRequest");

if (referrerValue == null || samlRequestValue == null) {
return context;
}

Encoder encoder = new Encoder();

try {
String saml = req.getMethod().equals("POST") ? B64.decodeToString(samlRequestValue) : encoder.decodeSAMLMessage(samlRequestValue);
XmlObject xml = XmlBeansUtil.parse(saml, XmlObject.class);
String issuer = GeneralXmlUtil.getIssuer(xml);
String baseUrl = MgmtFactory.getLocalSettingsManager().getLocalSettings().getBaseUrl();
resp.sendRedirect(MessageFormat.format("{0}/idp/startSSO.ping?PartnerSpId={1}", baseUrl, issuer));
} catch (Exception e) {
// do something
}
return context;


Depending on the SP you might have to do a little more to get the user to the correct URL after signing in.
Like   -   June 19, 2018 at 4:41 PM
Vijender r  asked a question
Policy contracts with OAuth?

Hi, We are trying to use policy contracts for OAuth clients, but in the logs we can see that, the desired policy contract never triggered at all, its just the regular adapter flow all the time? Below are steps what we have done - Can anyone please verify and let us know whats we are missing here?

 

1) Created Oauth client  (Auth Code grant) and tied it to an ATM

2) Mapped that Policy contract in Grant mapping (Authentication policy contract mapping)

3) Mapped ATM to the desired Policy contract in Token mapping & contract fulfillment

4) Configured policy contract in Authentication policies and try to hit from browser with all the oauth parameters - we are able to get the auth code, but its just not from policy contract which we configured exclusively for this client.

 

Have we missing anything here? Is there any document that we can refer to configure Oauth with Policy contracts? Any help would be much appreciated. Thank you!

Hi, We are trying to use policy contracts for OAuth clients, but in the logs we can see that, the desired policy contract never triggered at all, its just the regular adapter flow all the time? Below are steps what we have done - Can anyone please verify and let us know whats we are missing here?

 

1) Created Oauth client  (Auth Code grant) and tied it to an ATM

2) Mapped that Policy contract in Grant mapping (Authentication policy contract mapping)

3) Mapped ATM to the desired Policy contract in Token mapping & contract fulfillment

4) Configured policy contract in Authentication policies and try to hit from browser with all the oauth parameters - we are able to get the auth code, but its just not from policy contract which we configured exclusively for this client.

 

Have we missing anything here? Is there any document that we can refer to configure Oauth with Policy contracts? Any help would be much appreciated. Thank you!

More >
Answer   -   Like Share   -  June 15, 2018 at 10:24 PM
Thanks for the reply Scott.

Here are the answers for your queries:

Have you also checked the "Enable IdP Authentication Policies" checkbox in the Manage Policies screen? -- Yes, we did.

Do you maybe also have an IdP adapter mapping directly in your grant mapping (and as a leaf node in your authentication policy) that might be confusing things?

After removing all the IDP adapter mapping under grant mapping (In our lab), able to get the authcode, but very minimal logs comparatively with typical OAuth Flow. Is there any way that we can increase the log level?

And also, we observed something odd that whatever the first policy contract that we configured in AuthN Policies - that contract is triggering and completes the transaction, irrespective of how many policies with difference policy contracts we configure? We believe this is not how it is supposed to work with Policy contracts?

We tried with 2 different clients tied to- 2 different ATMs and - mapped to 2 different policy contracts and - configure 2 different policies in AuthN policies and tested. Its always executes the adapters what we configured on the top policy with policy contract? We did tried by switching the order and the result is always the top policy. And this is happening only with OAuth context, with regular SAML flows policy contracts are working as expected irrespective of the order in the AuthN policies. Any thoughts would be appreciated. Thank you!
Like   -   June 19, 2018 at 1:31 AM
Glad to hear that clearing the IdP adapter mapping has resolved your immediate issue!

As for your remaining questions:

Logging should be comparable to what you were seeing before in terms of audit logging. For debug logging, there should be some top level messages, however we're aware that that's an area we could be more verbose in - we have a request on our backlog to improve it in the future.

Access Token Manager selection is not controlled by authentication policy results. These are independent, but related, decisions that happen at runtime. For details on how Access Token Managers are selected, please consult the following:

https://documentation.pingidentity.com/pingfederate/pf90/index.shtml#concept_accessTokenManagement.html

To help control authentication policy behavior on a per OAuth client basis, PingFederate 9.1 (coming out later this month) will include an OAuth Client Set Authentication Selector. Hopefully you will find that will meet your needs.
Like   -   June 19, 2018 at 5:24 AM
Thank you Scott!!

Good to know that you are introducing OAuth Client Set Authentication Selector on next release.

Since we recently upgraded to 9x (last month), probably it is not possible to upgrade to 9.2 in recent future (atleast next 6-8 months). So what would be the work around until then? Any suggestions? Thanks again for your prompt response.
Like   -   June 19, 2018 at 5:49 AM
It sounds like you're following the correct steps - ensuring the Policy Contract is in your grant mapping and then mapping the Policy Contract in your authentication policy should be the major pieces.

Have you also checked the "Enable IdP Authentication Policies" checkbox in the Manage Policies screen?

Our documentation touches some on this:

https://documentation.pingidentity.com/pingfederate/pf90/index.shtml#adminGuide/pf_t_defineAuthenticationPolicies.html

https://documentation.pingidentity.com/pingfederate/pf90/index.shtml#pf_t_manageAuthenticationPolicyContractMappings.html

If that doesn't help: Do you maybe also have an IdP adapter mapping directly in your grant mapping (and as a leaf node in your authentication policy) that might be confusing things?
Like   -   June 17, 2018 at 3:57 PM
Thanks for the reply Scott.

Here are the answers for your queries:

Have you also checked the "Enable IdP Authentication Policies" checkbox in the Manage Policies screen? -- Yes, we did.

Do you maybe also have an IdP adapter mapping directly in your grant mapping (and as a leaf node in your authentication policy) that might be confusing things?

After removing all the IDP adapter mapping under grant mapping (In our lab), able to get the authcode, but very minimal logs comparatively with typical OAuth Flow. Is there any way that we can increase the log level?

And also, we observed something odd that whatever the first policy contract that we configured in AuthN Policies - that contract is triggering and completes the transaction, irrespective of how many policies with difference policy contracts we configure? We believe this is not how it is supposed to work with Policy contracts?

We tried with 2 different clients tied to- 2 different ATMs and - mapped to 2 different policy contracts and - configure 2 different policies in AuthN policies and tested. Its always executes the adapters what we configured on the top policy with policy contract? We did tried by switching the order and the result is always the top policy. And this is happening only with OAuth context, with regular SAML flows policy contracts are working as expected irrespective of the order in the AuthN policies. Any thoughts would be appreciated. Thank you!
Like   -   June 19, 2018 at 1:31 AM
Glad to hear that clearing the IdP adapter mapping has resolved your immediate issue!

As for your remaining questions:

Logging should be comparable to what you were seeing before in terms of audit logging. For debug logging, there should be some top level messages, however we're aware that that's an area we could be more verbose in - we have a request on our backlog to improve it in the future.

Access Token Manager selection is not controlled by authentication policy results. These are independent, but related, decisions that happen at runtime. For details on how Access Token Managers are selected, please consult the following:

https://documentation.pingidentity.com/pingfederate/pf90/index.shtml#concept_accessTokenManagement.html

To help control authentication policy behavior on a per OAuth client basis, PingFederate 9.1 (coming out later this month) will include an OAuth Client Set Authentication Selector. Hopefully you will find that will meet your needs.
Like   -   June 19, 2018 at 5:24 AM
Thank you Scott!!

Good to know that you are introducing OAuth Client Set Authentication Selector on next release.

Since we recently upgraded to 9x (last month), probably it is not possible to upgrade to 9.2 in recent future (atleast next 6-8 months). So what would be the work around until then? Any suggestions? Thanks again for your prompt response.
Like   -   June 19, 2018 at 5:49 AM
Ramesh R  asked a question
HTML Form Idp Adapter - Challenge Retries question...

Is there a way to Unlock an account before the lockin time-period is completed?

 

For example, The Lockout Time is configured to 30 mins.

 

Now the user whose account is locked requests to unlock the account before 30 mins, is it possible through Pingfederate?

 

If No, is there any alternative approach for the same.

 

Please do the needful.

Is there a way to Unlock an account before the lockin time-period is completed?

 

For example, The Lockout Time is configured to 30 mins.

 

Now the user whose account is locked requests to unlock the account before 30 mins, is it possible through Pingfederate?

 

If No, is there any alternative approach for the same.

 

Please do the needful.

More >
Answer   -   Like Share   -  April 3, 2017 at 8:15 AM
@Denis B (Customer) No, not currently. It has to be initiated by the user through PingFederate's browser endpoints.
Like   -   June 15, 2018 at 3:06 PM
Is it possible to disable the Account Lockout policy global or for an single adapter?
Like   -   June 18, 2018 at 6:58 AM
There are global controls over how many bad logins affect the lockout and for how long. This is configurable in the com.pingidentity.common.security.AccountLockingService.xml file. See: https://documentation.pingidentity.com/pingfederate/pf90/index.shtml#adminGuide/pf_t_configureAccountLockoutProtection.html

Setting LockoutPeriod to 0 effectively disables the service.
Like   -   June 18, 2018 at 3:19 PM
Hi Ramesh,

Can you clarify which lockout time you are referring to?

Is it the LockoutPeriod in PingFederate's internal account locking service (defined in AccountLockingService.xml)?

Or something in the back end directory service?

For our internal AccountLockingService currently there's no way for the user or an admin to unlock the account - that's why it is set to 1 minute by default.

For the back end directory service - this is really up to the product you are using there.

We do have some new Self-Service Account Unlock features coming in PingFederate 8.4 this summer that will help with either scenario. Users will be able to unlock their locked account (in PF's internal service or the directory) by going through another form of authentication, such as: text message OTP, email OTP or PingID.

I hope this helps.
Like   -   April 4, 2017 at 5:05 PM
Thanks Scott for the information. I was mentioning about the Lockout period mentioned in AccountLockingService.xml.
Like   -   April 20, 2017 at 7:29 AM
Thanks for clarifying. I hope that gives you some options. 8.4 (this summer) will help if you're looking for a self-service approach to solving this.
Like   -   April 20, 2017 at 9:58 PM
Is it possible to unlock an account in v8.4 through Rest Api?
Like   -   June 15, 2018 at 7:03 AM
@Denis B (Customer) No, not currently. It has to be initiated by the user through PingFederate's browser endpoints.
Like   -   June 15, 2018 at 3:06 PM
Is it possible to disable the Account Lockout policy global or for an single adapter?
Like   -   June 18, 2018 at 6:58 AM
There are global controls over how many bad logins affect the lockout and for how long. This is configurable in the com.pingidentity.common.security.AccountLockingService.xml file. See: https://documentation.pingidentity.com/pingfederate/pf90/index.shtml#adminGuide/pf_t_configureAccountLockoutProtection.html

Setting LockoutPeriod to 0 effectively disables the service.
Like   -   June 18, 2018 at 3:19 PM
SHOW MORE >