There's currently no option to avoid using LDAP for specific names, since ProFTPD doesn't trust the name, as provided by a client, until that name is authenticated. But by that point, you will have needed to use LDAP (or not) to perform the authentication; this chicken-and-egg issue makes it harder to filter/avoid LDAP by name. You *can* enable/disable use of mod_ldap by "network class" (IP address/range from which the client is connecting), if that helps.
ProFTPD does not use initgroups(3) because that function, on many platforms, does not return an error if more than the kernel-supported maximum number of groups per user is exceeded. That is, we encountered cases where a user might be a member of more than 16 groups -- and the kernel in question only supported 16 groups per user. The initgroups(3) function did NOT return an error, and thus the admin was confused as to why that user was unable to access a file (whose permissions allowed one of the silently truncated groups). So now, to work around behavior like that, ProFTPD will manually iterate through all of the groups, and do its own setting of group IDs for the proceses. These are the getgrent(3) function calls you are seeing.
And ProFTPD *does* support/use PAM -- but only for authenticating a user, not for obtaining additional information about that user. See: http://www.proftpd.org/docs/howto/Authentication.html http://www.proftpd.org/docs/contrib/mod_ldap.html