SecurID® Discussions

Browse the SecurID discussion board to get product help and collaborate with other SecurID users.

Call to AceContinueAuth() returning invalid value

According to the RSA Authentication Agent API 8.6 for C Developer's Guide, AceContinueAuth() has 5 possible return values:


  1. ACM_OK = 0 (defined in sdacmvls.h)
  2. ACE_INVALID_ARG = 800 (defined in acclnt.h)
  3. ACE_ERR_INVALID_HANDLE =  101 (defined in acclnt.h 
  4. ACE_NOT_ENOUGH_STORAGE = 750 (defined in acclnt.h)
  5. ACE_TOO_MANY_CALLERS = 700 (defined in acclnt.h)


However, I've encountered a scenario where AceContinueAuth() returns another value that's not listed above: 6, which I'm assuming corresponds to ACM_NEW_PIN_REQURED (defined in sdacmvls.h). The scenario I refer to is Test 1 / 7 for RSA Ready Certification, which tests for if the agent can handle delivering a System Generated PIN. After I enter my username and tokencode, I am asked if I wish to have the system generate a PIN. I enter "y", and that's when AceContinueAuth() returns 6.


Is this some issue with the documentation and/or API, or is there something about what AceContinueAuth() should return that I'm not understanding? I feel like it should be returning ACM_OK = 0.

Labels (1)
4 Replies
Occasional Contributor Occasional Contributor
Occasional Contributor

From the Agent API Developer's Guide:


Note: The return value of AceContinueAuth indicates the success or failure of the

function, not of the authentication in progress. To get the actual authentication status,

use the AceGetAuthenticationStatus function with the handle returned from



You can find examples of how this can be done in the sample applications included in the SDK.


At this point in the authentication process, we don't need to get the actual authentication status. We need to call AceContinueAuth() because more data is required by the authentication context.


From the Developer's Guide:

"The AceStartAuth function provides the first step in authenticating with the

RSA SecurID protocol using the synchronous API.


If the function returns successfully, then your code calls AceContinueAuth with the

required passcode. Your code continues to call AceContinueAuth until no more data is

required by the authentication context, or an error occurs."


This is what's going on:


First, the user enters a username, and then AceStartAuth() is called. When AceStartAuth() successfully returns, moreData = true, so the user is then prompted for a passcode. In response, the user enters their tokencode according to the one being displayed on their authenticator. Then, AceContinueAuth() is called. Provided the username/tokencode combination is valid, when it returns:


  • The return value should be ACM_OK = 0, which indicates it was a successful call
  • moreData = true, indicating that more data is required by the authentication context. According to the section of the developer's guide that I quoted above, this means that we should call AceContinueAuth() again.
  • promptStr = "To continue, you must accept a new PIN generated by the system. Are you ready to have the system generate your PIN? (y/n) "


The user then enters "y", and AceContinueAuth() is called again because moreData = true. However, this time around, AceContinueAuth() returns 6 and not ACM_OK = 0.


Basically, according to the documentation, any value other than 0 that AceContinueAuth() returns is indicative of the fact that something went wrong. I'd like to know two things:


1.) What went wrong?

2.) What meaning does a return value of 6 have? It's not listed in the documentation as one of the return values for AceContinueAuth()


Are you certain that the return value you are seeing is from AceContinueAuth and not from AceGetAuthenticationStatus?  The return values from AceGetAuthenticationStatus are:

  • ACM_OK

The sdacmvls.h header has "6" defined as a response code from AM for ACM_NEW_PIN_ACCEPTED.  I think this would make sense given the context.


Yep, we're definitely seeing it from AceContinueAuth and not from AceGetAuthenticationStatus. We've got some logging setup that writes to a text file whenever we call a function from the RSA Authentication Agent API as well as when that function returns. Both the name of function called and the return values are logged.


Also, I tried the RSA Ready certification with the 8.1.3 dlls and no changes to our code, and the system-generated pin test worked just fine.