Barracuda should be able to handle the 3-way handshake when a user logs in with a tokencode and that token needs a pin, but doesn't have one yet, and the user can create a pin during the VPN login process, as the RSA server will ask the Barracuda to prompt the user for a pin. If not, the user can access the self-service console and do a passcode login, and the same pin setup can happen there. Typically when setting a new pin it goes like this: username and code from token, then it asks to set up a pin, then confirm pin, then it asks now enter next passcode. What this now means is wait for the token to change to a new code, and now enter the new pin followed by the new code on token.
Terminology we use: 'Tokencode' is the code from a token with no pin involved. 'Passcode' means pin combined with the code from a token. Most login prompts will ask for the passcode but the user should know if they don't have a pin yet, just enter the tokencode when needed, and a full passcode once there is a pin set.
Handheld tokens are always pin+tokencode displayed. Software tokens, if set up keyfob style, work the same way, but if software tokens are set up pin-pad style, then it works a bit differently. Pin-pad tokens always ask to enter a pin into the application, if there is no pin yet, just enter nothing, and it displays a tokencode. Login with that code, and go through the pin setup. Now when the login asks for a passcode, you enter the pin into the software token app (not the login prompt) and the app will add the pin to the tokencode it would have displayed, and show you a passcode (and it will be the same number of digits as the tokencode). The pin is mathematically hidden inside the digits. Login with that passcode.
