The intent of this article is to provide information on how to configure and use the group mapping functionality that was introduced in SAMBA 3.0 for use with IBM® Rational® ClearCase MultiSite®. This new functionality is provided using the new Samba command:
net, which maps UNIX® groups with Microsoft® Windows® group SIDs. Using this new feature, you can expose the UNIX groups over the SAMBA domain in order to have ClearCase function properly by identifying the correct user privileges.
This article is meant for both new and experienced ClearCase administrators with sufficient knowledge of the ClearCase environment and SAMBA.
|Version control||IBM Rational ClearCase MultiSite 2003.06|
|Domain controller||SAMBA 3.0.4|
|Server OS||Red Hat® Enterprise Linux® 3.0|
|Client OS||Microsoft® Windows XP®; Windows 2000 Server Edition®|
ClearCase is a distributed application built on client-server architecture. This distributed environment consists of:
- Client host
- Server host
- ClearCase users
Both client and server host(s) can be either UNIX or Windows operating system. In addition to this, the various ClearCase server roles (for instance, registry server, license server, and so on) can be broken up and deployed on separate hosts. For example, the registry server application can be hosted on a separate host from the rest of the ClearCase application.
Since the ClearCase application works on client-server architecture, and uses remote procedure calls (RPCs), it is suited to run in a LAN environment. ClearCase relies on the host(s) authentication mechanism to authenticate users. In Windows, this is the reason a domain controller is required for maintaining such an access list for authenticating ClearCase users in such an environment.
In a Windows environment, your ClearCase domain account consists of a user ID (SID) and a group name, which is termed your primary group. You can be a member of multiple groups. ClearCase uses both your user ID and primary group ID to grant access rights to ClearCase objects.
In order to implement access control over various ClearCase objects, you should classify types of users. You can also restrict access using locks or triggers, but in this case assume that there will be one set of privileged users who can create, modify, and delete any ClearCase objects, and another set of ClearCase users who can modify only those VOBs and views that they can create.
We will be using SAMBA to implement groups both to classify these sets of ClearCase users and to provide correct access control over ClearCase objects.
Samba is an open source software package providing file and print services for SMB/CIFS hosts. It allows for interoperability between Linux/UNIX servers and Windows-based clients. When correctly configured, it allows that host to interact with a Microsoft Windows client or server as if it is a Windows file and print server. Hosts running the Samba software can function as a primary domain controller (PDC), backup domain controller (BDC), or as a stand alone server. You can get the current version of Samba from the main Samba website listed in the Resources section at the end of this article.
As mentioned at the beginning of the article, you will now learn how to use the SAMBA 3.0
net command to map UNIX groups with Windows group SIDs.
SAMBA configuration optimization for your ClearCase environment
You should already have a configured SAMBA server as a primary domain controller (PDC) using
security = user, acting as the domain master browser on your SAMBA network to maintain browse lists between subnets. You should also have WINS support enabled (if you donât already have a WINS server on your network, whose IP address you should have provided in the SAMBA configuration). Once your basic SAMBA configuration is ready, you can use this section to add more parameters to it and optimize it for your ClearCase environment. (Some of these parameters were suggested by Joel Abbott. You can reach him at: firstname.lastname@example.org)
You can secure your SAMBA network by exposing it to limited subnets on your network. Use
hosts allow configuration parameter to do so:
hosts allow = 192.168.100. 192.168.10.
Set user-based access restriction to SMB shares by using:
valid users = +validGroupName
Make sure that your ClearCase server hosts and client hosts are exposed to each other if they are on different subnets.
You can keep track of each host connecting to the SAMBA network by filtering each hostâs log into a separate file:
log file = /var/log/samba/%m.log
In addition, you can limit the size (Kb) of these log files, such that the SAMBA server will rotate the log after it reaches the max log size and start writing to a new log file. The old log file is retained with a suffix .old and is overwritten upon subsequent log rotates. The example below will rotate the log after it has reached a 1000 Kb size limit.
max log size = 1000
You should also have socket options specified in your SAMBA configuration, as per your needs. Using the following options has been found to increase SAMBA performance.
socket options = SO_RCVBUF=8192 SO_SNDBUF=8192 SO_KEEPALIVE IPTOS_LOWDELAY TCP_NODELAY
The values of
SO_SNDBUF used here are example values, set to a higher value than their corresponding host operating systemsâ send and receive buffer values.
TCP_NODELAY are used in conjunction to avoid packet delays.
Make the following settings in your global SAMBA configuration. When the Windows host reads and writes files on the SMB shares, this will preserve the case of these files, and maintain the capital letters in file paths:
preserve case = yes short preserve case = yes case sensitive = no
Other tuning parameters found useful are:
- To close inactive client sessions, using the
- Set masks globally across SMB shares, using the
- To limit the number of open files on SMB shares to less than that of the operating systemâs value, use
max open files.
Deadtime = 15 create mask = 0775 directory mask = 0775 max open files = 10000
Note: These are example values and you should assign values per your needs.
oplocks help to cache files on the client side, you might want to avoid this in the ClearCase environment by disabling them using the following configuration parameters in your SAMBA configuration:
kernel oplocks = no oplocks = no level2 oplocks = no
There are more configuration parameters to optimize SAMBA (See the Resources section at the end of this article).
Configuring SMB shares to expose VOBs over the SAMBA network
While you are configuring an SMB share for the VOBs, use the following parameters (aside from the mandatory path parameter):
valid users = +validSystemGoupName writeable = Yes browseable = Yes
Note: If you are also using the SAMBA server host to distribute the ClearCase Client release, then that SMB share should not be writeable and you could use
fake oplocks to enable caching of release files when the user installs the ClearCase client release on their machines:
valid users = +validSystemGroupName writeable = No browseable = Yes fake oplocks = Yes
Group mapping using SAMBA
In previous versions of SAMBA, you needed to do a neat hack on a client operating system in order to trick ClearCase server authorization to access VOBs. You would need to add the following registry key to work around the work-group authorization:
HKEY_LOCAL_MACHINE > SOFTWARE > Atria > ClearCase > CurrentVersion > DisableAlbdGroupCheck
You should set the value for this registry to "1", as shown here:
After this you had to add locally the groups that are required by ClearCase to function properly, on the client OS machines.
But with the new
net command, all you have to do now is expose the UNIX groups created for ClearCase environment on your SAMBA domain controller using this command. The steps are simple to follow:
- Create the groups required by the ClearCase deployment environment.
- Add existing users to these groups, either by manually editing
/etc/group, or by using the
vigrcommand on your Red Hat Linux box (or any other system management utility on your Linux distribution).
- Now use the
netcommand provided with SAMBA to map these groups:
net groupmap add ntgroup=clearcase unixgroup=clearcase
net groupmap add ntgroup=ccusers unixgroup=ccusers
Note: You must be careful not to have any white space surrounding the equal character, "=". If your Windows group name has white space then you would have to surround it with single quotes in the command as shown above.
You can check the groups exported over the domain by using:
net groupmap list System Operators (S-1-5-32-549) -> -1 Domain Users (S-1-5-21-1445431747-2827100975-1654049431-513) -> -1 Replicators (S-1-5-32-552) -> -1 Guests (S-1-5-32-546) -> -1 Power Users (S-1-5-32-547) -> -1 Domain Admins (S-1-5-21-1445431747-2827100975-1654049431-512) -> -1 Print Operators (S-1-5-32-550) -> -1 Administrators (S-1-5-32-544) -> -1 Domain Guests (S-1-5-21-1445431747-2827100975-1654049431-514) -> -1 ccusers (S-1-5-21-1445431747-2827100975-1654049431-5003) -> ccusers Account Operators (S-1-5-32-548) -> -1 Backup Operators (S-1-5-32-551) -> -1 Users (S-1-5-32-545) -> -1 clearcase (S-1-5-21-1445431747-2827100975-1654049431-5005) -> clearcase
Note: Windows NT® 4.x, Windows® 200x, and Windows XP® operating systems provide certain default RID, and in order to maintain the integrity of our heterogeneous environment SAMBA provides the above SID.
You can check if the groups are visible on a Windows client using the Windows
C:\>net group /dom The request will be processed at a domain controller for domain MYDOMAIN. Group Accounts for \\COMPUTER ----------------------------------------------------------------------- *ccusers *clearcase The command completed successfully.
You can also look at the members of these groups as shown below:
C:\>net group clearcase /dom The request will be processed at a domain controller for domain MYDOMAIN. Group name clearcase Comment Local Unix group Members ----------------------------------------------------------------------- clearcase_albd jabbot trajat The command completed successfully.
Note: If you use the
net user username /dom command, you can see details about local and global group memberships for this user.
So, once the users have joined their ClearCase client hosts to the domain serving the ClearCase environment, creds output would show who has administrative privileges.
If you now check the output of
creds for a user with administrative privileges, you would notice the login name as <MYDOMAIN>\<USER> and the primary group as
<MYDOMAIN>\<ccusers>, with the
Groups section listing the administrative group
<MYDOMAIN>\<clearcase>. (This would be the case when you are following a policy in which all users have a common primary group, and the administrative user id has to be explicitly added to the administrative group). The output would also mention
"You have ClearCase administrative privileges" for this user.
The users who donât have administrative privileges will not have the administrative group as part of their additional groups and
creds will report
"You do not have ClearCase administrative privileges" for those users.
Other groupmap sub-commands
|add||Create a new group mapping|
|modify||Update a group mapping|
|delete||Remove a group mapping|
|addmem||Add a foreign alias member|
|delmem||Delete a foreign alias member|
|listmem||List foreign group members|
|memberships||Add a foreign group memberships|
|list||List current group map|
|set||Set group mapping|
|cleanup||Remove foreign group maping entries|
- For more information on configuring SAMBA, please see the official Samba 3 how-to and reference guide.
- For more details on the "net" command please refer to the listing in the Samba man pages.
Get products and technologies
- To learn more about IBM Rational products, visit the developerWorks Rational zone. You'll find technical documentation, how-to articles, education, downloads, product information, and more.
- Find more resources for ClearCase users and administrators in the ClearCase area of the developerWorks Rational zone.
- You can get the current version of Samba from the main Samba website.