RSA Radius in RSA Authentication Manager is a 'standard authentication agent', that lives on the server.
RSA Radius does zero with ldap connections by itself.
10,000 foot view:
It receives an incoming radius auth request, checks IP to see if it is a known RAS client, then sends the userid and password field to RSA server as a normal 'securid auth' (on loopback interface and udp/5500). Radius itself does no name lookups of any type. Then the RSA server sees that one of it's agents (it's own IP address) is doing a securid auth and it processes it the same as any other securid auth. At that stage, the RSA server looks up the username the same way it looks up any other ldap username from any other authentication request. If auth success, then RSA server sends the accept answer back to the agent (which is it's own radius on loopback interface) and then radius will attempt to apply any return radius attributes (if there is a radius profile involved) and then sends the outgoing access-accept or access-reject message to the end device.
So, radius or not radius, RSA Auth Manager and ldap lookups are handled by the same mechanism... which are ldap pools it maintains. These are not normally configurable or tunable. When someone is actually trying to log in, and we are doing a name lookup, this is called a 'runtime' lookup. The only thing we have which is tunable in this regard is, if you configure a global catalog connection for runtime lookups, and pair that with an administrative connection (for admin work, such as assigning tokens and this is the connection used when in Security Console when you list users from ldap). If you use GC's the runtime lookup can be faster as we do less work and less network traffic to do a simple name and account status lookup on a GC connection.
