How to ban/blacklist user on CE and SE

From GridPP Wiki
Jump to: navigation, search

To ban or blacklist a user on a CE:

Note that the need to ban or blacklist a user does not necessarily imply that the user is at fault. The certificate may have been compromised due to a security incident at a site storing a proxy or private key.

Add the user(s)'s DN into the "ban_users.db" file, which in default can be found at /opt/edg/etc/lcas/ or /opt/glite/etc/lcas/ if it is glite CE, as follow:

  "User1's DN"
  "User2's DN"
  ... ... ...
  "UserN's DN"

If there are multiple DNs to be banned, each DN name should be in seperated lines and must be quoted with the double quote mark (""), otherwise LCAS will not be able to block the user. At the moment, LCAS does not support wild mark, therefore you can not use "/C=UK/O=eScience/OU=CLRC/L=RAL/*" to ban a group of users. To verify that the user has indeed been banned, in the log there should be something like "LCAS failed authorization" if the job of the banned user landed on the CE.

To ban a user on a SE

It is more complicated to ban a user on a SE since different SE uses different configuration files or entirely different authorization service and SE does not use LCAS (therefore can not use ban_user.db to simply blacklist users; DPM developers are working on LCAS for DPM, which will be available at the first quarter of 2008). However most SEs do support "grid-mapfile" kind of authorization to map a user's DN to a local Linux account, the solution would be to map the user's DN to non-exist local account. Please note, however, grid-mapfile is not the only way for SEs to perform authorization (e.g. gPlazma authorization in dCache supports four methods to perform authorization).

dCache uses gPlazma (Grid-aware PLuggable AuthoriZation Management) authorization, which has four authorization plugins. The gPlazma policy file locates in ${ourHomeDir}/etc/dcachesrm-gplazma.policy, which controls which authorization plugins will be enabled and the order in which they will be tried. Please note, it is possible to enable all of the four plugins and specify the order in which they will be tried. Therefore, it is very important to check this policy file to understand which plugins have been enabled and the order in which they are used before you try to block user's access to your dCache.

On dCache with grid-mapfile:

In the file: /opt/edg/etc/grid-mapfile-local, map the user's DN to a non-exist local account, such as:

   "banned_user_DN" nonexist001
   "/DC=org/DC=doegrids/OU=People/CN=XXX" nonexist001

And then rebuild the grid-mapfile by execute

   /opt/edg/sbin/edg-mkgridmap --output=/etc/grid-security/grid-mapfile --safe

On dCache with gplazmalite-vorole-mapping:

To create a revocation entry, add a line with "-" (without quotes) as the username, such as

   "/DC=org/DC=doegrids/OU=People/CN=XXX" "/uscms/production" -

Note: "/uscms/production" is FQAN (Fully Qualified Attribute Name)

or modify the username of the entry if it already exists. The behaviour is undefined if there are two entries which differ only by username. Since DN is matched first, if a user would be authorized by his VO membership through a "*" entry, but is matched according to his DN to a revocation entry, authorization would be denied. Likewise if a whole VO were denied in a revocation entry, but some user in that VO could be mapped to a username through his DN, then authorization would be granted.

More information about gPlazma authorization in dCache can be found here: gPlazma authorization in dCache


As described above, in the file: /opt/edg/etc/grid-mapfile-local or /opt/lcg/etc/lcgdm-mapfile-local, map the user's DN to a non-exist local account, such as:

   "banned_user_DN" nonexist001
   "/DC=org/DC=doegrids/OU=People/CN=XXX" nonexist001

And then rebuild the grid-mapfile by execute

   /opt/edg/sbin/edg-mkgridmap --output=/etc/grid-security/grid-mapfile --safe

to map a user to a non-exist VO

In the file: /opt/lcg/etc/lcgdm-mapfile-local, map the user's DN to a non-exist VO, such as:

   "banned_user_DN" nonexistVO
   "/DC=org/DC=doegrids/OU=People/CN=XXX" nonexistVO

and then rebuilding the lcgdm-mapfile by running:

   /opt/edg/libexec/edg-mkgridmap/ --conf=/opt/lcg/etc/lcgdm-mkgridmap.conf --output=/opt/lcg/etc/lcgdm-mapfile --safe

both files need to be modified on all the DPM nodes (head and pool nodes).


Since SEs also have GridFTP interface, users can use command line tools like globus-url-copy to access files. To block user's access via GridFTP, you should use the LCAS or the grid-mapfile method depending on what that GridFTP is using.