Skip to main content

Digital Experience

How-To: Using AD groups to manage Rational ClearCase VOB access

ClearCase_Newer

At the client I’m currently with, we use a very simple and straightforward mechanism to manage access to the various ClearCase VOB repositories. It only takes a minimal amount of work to implement for a particular VOB. I haven’t seen it documented anywhere, and I’m sure it would be useful at other shops that have the same setup.

All developers are members of the ClearCase users domain group, named AD_clearcase_users here, and have their Primary Group set to that group on the Domain Controller. This is also the case for the ClearCase Administrator’s account (called vobadmin);

In this client’s development environment, each VOB corresponds to a system, and only certain developers should have access to a particular system’s codebase. This is accomplished for a particular VOB as follows:

  1. A new VOB, \DGS in this example, is created using the vobadmin account, which means it is automatically owned by the AD_clearcase_users group;
  2. A new domain group AD_cc_DGS is provisioned by Security to control access to the new \DGS VOB;
  3. The new domain group is added to the new \DGS VOB’s additional groups list using the protectvob command:
    cleartool protectvob -add_group AD_cc_DGS \\servername\clearcase_storage\VOBs\DGS.vbs
  4. The existing access Group, AD_clearcase_users, of the root of the VOB is changed to the new group, AD_cc_DGS and all Other rights are removed. The easiest way to do this is by right-clicking on the name of the VOB in ClearCase Explorer, selecting Properties of Element and going to the Protection tab:
    vob4
    This effectively makes the entire VOB inaccessible to anyone who is not a member of the AD_cc_DGS group. The corresponding command-line command (to be issued in the root of the VOB) is:

    cleartool protect -chgrp AD_cc_DGS -chmod 770 .
  5. Security adds all the developers who require access to the \DGS VOB to the AD_cc_DGS domain group.

Of course, the above is an all-or-nothing strategy. Users either have full or no access to a particular VOB. If a more granular permissions model is needed, the Access Control List functionality that was introduced starting with ClearCase version 8.0.1 should be used instead. Check out http://www.ibm.com/developerworks/rational/library/effective-governance-compliance-clear-case-ACLs/ for info.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Jozef Vandenmooter

More from this Author

Follow Us
TwitterLinkedinFacebookYoutubeInstagram