In order to exploit the full possibilities of VOMS/LCMAPS the use of 
LDAP as a source of user account information is recommended.
A site can do without by going through the following  procedure:
 
The new system can be made entirely compatible with the 
current poolaccount setup, but then one whould not be 
surprised that you get only reduced functionality. In effect, 
when a site
* pre-allocates a set of poolaccounts for each and every VO,
* pre-assigns the proper group to each (set of accounts), and
* does not use very-fine-grained group-allocations within a VO for
   job execution separation
they can get away without LDAP. For many sites, this will be OK.

For example a sites supports the ATLAS, Alice and LHCb VO's, 
does not want to use LDAP, but does use VOMS. That sites can 
create three three groups and three sets of poolaccounts (say 
"lhcb001-lhcb050", etc.) and put each poolaccount into the 
proper group.

Now, a grid-mapfile on a per-VO basis will look like 

             "/VO=lhcb/GROUP=lhcb/*"       .lhcb
             "/VO=atlas/GROUP=atlas/*"     .atlas
             "/VO=alice/GROUP=alice/*"     .alice

and a groupmapfile:

             "/VO=lhcb/GROUP=lhcb/*"       lhcb                                                                    
             "/VO=atlas/GROUP=atlas/*"     atlas                                                                  
             "/VO=alice/GROUP=alice/*"     alice                                                                   

Now, the acquired credentials will (as if by chance) map 
exactly on to the credentials already present in the user 
directory (be it files, or NIS), and so updating of those 
credentials is not needed. So that site in that config can do 
without the need for updating a central userDB (like LDAP).

You can even do it a bit more fine-grained, adding an LHCb MC 
prod manager like this:

             "/VO=lhcb/GROUP=lhcb/mcprod  .lhcbmc
             "/VO=lhcb/GROUP=lhcb/*       .lhcb

and a group-mapfile:
             "/VO=lhcb/GROUP=lhcb/mcprod  prodmc                                                                  
             "/VO=lhcb/GROUP=lhcb/*       lhcb                                                                   


and assign (statically) in /etc/passwd:

         lhcbmb001:*:501:100:Blah:/home/lhcbmc001:/bin/bash
         lhcbmb002:*:502:100:Blah:/home/lhcbmc002:/bin/bash
         lhcbmb003:*:503:100:Blah:/home/lhcbmc003:/bin/bash
         lhcb001:*:601:100:Blah:/home/lhcb001:/bin/bash
         lhcb002:*:602:100:Blah:/home/lhcb002:/bin/bash

and in /etc/group

         lhcb:*:100:
         prodmc:*:200:lhcbmc001,lhcbmc002,lhcbmc003

This will also do the job of ensuring that the mapping 
created for the fork job manager (in-process, using 
posix_enf) that is used for doing the "qsub" is the same as 
the one used on job execuation on a worker node.

And of course, the obvious solution for those sites that want 
fine-grained authorization but do not want to use LDAP: buy 
a true MPP systems with all your processors seeing the same 
file systems and memory. Cray/SGI will be very happy ;-)