CID (Closed In Directory) is a set of bash scripts for inserting and managing Linux computers in Active Directory (AD) domains. Modifications made to the system allow Linux to behave like a Windows computer within AD. You can do things like:
CID consists of four main tools subdivided into two GUI tools (cid-gtk and cid-change-pass-gtk) and two CLI utilities (cid and cid-change-pass). Both pairs contain equivalent features and they all accept the following general options as a argument in the command line:
| Option | Description |
|---|---|
| -v, –version | Show the version |
| -h, –help | Show the help |
Open Synaptic and search and install the following packages: cid, cid-base and cid-gtk or open a terminal and digit and install the packages below with this command:
sudo nala install cid cid-base cid-gtk
The cid-gtk is the tool that contains the main features of the program. Through it you can insert your Linux computer in an AD domain and later manage a series of functions in the system.
The available features are described in the following sections.
This function allows you to join the Linux computer to an AD domain. For that, it is necessary to inform the domain data in the respective fields as shown in the table below:
| Field | Description |
|---|---|
| Domain | Domain name (FQDN). |
| Hostname | Name for computer account that will be created in AD. If not specified, the account will be created with the same hostname defined in the system. |
| Organizational Unit | Optionally, you can specify an Organizational Unit where the computer account will must be created when join it the domain. If the OU is not entered or is not found, the computer account will be created in the default container (computers). |
| User | Domain administrator user. |
| Password | User password. |
| Mode | Select one of two join modes: Default or Advanced. Default mode is adopted if no selection is made. Advanced mode opens a form that allows you to customize the settings that the CID will perform on the system during the process of joining the domain. All configuration options available in this mode are directly opposite to the settings adopted in the Default mode. |
Note: Before modifying the system files, the CID makes a backup in the /var/lib/cid/backups/ori directory.
The options available in this mode are:
| Option | Description |
|---|---|
| Disable NetBIOS over TCP/IP | Disables support for the NetBIOS API implemented by Samba. |
| Disable authentication via Kerberos | This causes the pam_winbind module to not attempt to obtain the kerberos tickets known as Ticket Granting Tickets (TGTs) of the Authentication Server (AS) during user login. |
| Disable credential caching | Disables support for off-line authentication, or authentication with local cached credentials. This requires real-time communication with the authentication server for the logins the domain users. |
| Disable logon scripts | This disables logon scripts. |
| Do not use domain as default | Configures winbind not to use the joined domain as the system default. This makes it necessary to specify the domain name before the user or group name (format: DOMAIN\user or DOMAIN\group), both in authentication and in system commands that receive user or group names as argument. |
| Enable authentication for sudo | This requires that domain users who are given administrative privileges on the Linux computer need to authenticate when running the sudo command (see Manage AD accounts in local groups). |
| Use idmap_ad (RFC 2307) | This option allows the use of the idmap_ad backend, which implements an API to obtain the Unix attributes of users and groups in the domain through domain controllers, as long as they have NIS extensions enabled. By default, the CID configures winbind to use the idmap_autorid backend, which establishes these attributes through a predefined configuration on the local system. You can use the id_range_size, max_num_domains, wbd_userprofile and wbd_usershell parameters in cid.conf to customize this configuration. When selecting this option, a new form will be presented for configuring the backend with the following fields. Initial ID: Initial value of the range of UIDs and GIDs that will be mapped by the backend. This field is required, and the value assigned must be greater than the IDs already used by local users and groups; Final ID: End value of the range of UIDs and GIDs that will be mapped by the backend. When not set, the CID will use a random value based on the value set in the Initial ID field; winbind nss info: This defines whether information about the home directory and the shell of domain users should also be obtained by the DC with the rfc2307 option, or whether through a predefined configuration with the template option. The template option is adopted by default. |
| Share all printers on CUPS | Enables automatic sharing of all printers configured on the local CUPS server through Samba (SMB protocol). This makes it unnecessary to configure individual shares for each printer through the Manage shares option. |
| Use keytab file method | Configures Samba to use a dedicated keytab file as an kerberos authentication method. The krb_principal_names parameter in the cid.conf file can be used to specify principal names that you want to be added to the keytab. |
| Add config file to Samba | It allows adding a file containing parameters to be attached to the Global section of the samba configuration file (smb.conf). The contents of this file will be filtered so that there is no conflict with the parameters predefined by the CID. |
This function undoes the modifications made in the system for the computer to join the domain, and by the use of the other CID functionalities after that join.
When using it, you can optionally fill in the fields with the credentials of a domain administrator for what the CID try remotely delete the computer account from the AD database. If this fails, the operation of this function will not be affected.
Note: A copy of the files modified during this process is stored in the /var/lib/cid/backups/mod directory.
This function allows you to change the options of the Advanced mode after the system joins an AD domain.
Note: Whenever a change is made through this função, a copy of the affected files in the state before modification is stored in the /var/lib/cid/backups/mod directory.
This function restricts logon in the system to a specific user or group of the domain. When selecting it you must inform the Account Type (User or Group) and the Account Name. If no type is selected, the User type is assumed by default.
This function removes the logon restriction applied by the block logon function.
This function allows you to associate AD user accounts with groups on the local system so that they can perform specific routines that require the administrative privileges of those groups, in addition to allowing them to run the sudo command.
Authentication for the sudo command can be enabled or disabled via the Enable authentication for “sudo” option in advanced join mode or in Change station behavior.
The CID uses the groups that the default user (usually the first user created on the system) belongs to to determine these groups. You can specify any other user using the defaultuserid parameter, and you can also add other specific groups using the localgroups parameter in the cid.conf file.
In the Add account option, you must inform the type and name of the account in the same way as when using the block logon function.
Note that on Unix systems there is no group nesting. Therefore, when a group account is added, members of that group are individually associated to the local groups as they log on to this system. If you enter an asterisk (*) at the end of the group’s name, all its members will be immediately associated. If the user is removed from the domain group, the user will be automatically removed from local groups on a next login to this computer.
The Remove account option lists domain accounts added to local groups and allows you to select them for removal.
Note: Members of the Domain Admins group are automatically associated with local groups.
This function allows you to manage Samba shares intuitively.
The Add share option displays a form where you must enter the arguments to create or update a share.
Three share modes are available:
Common mode
This mode allows you to share a directory on one of the local file systems via Samba (SMB protocol).
The directory path to be shared must be entered in the Path argument. If the directory path does not start with a forward slash (/) and you are using a template for the share, the parent directory of the template share is used as the parent directory for this share. If the directory does not exist, it will be created automatically.
The access permissions of the share can be managed locally through the Rule argument, or through a remote Windows system using the Microsoft Management Console (MMC).
When set locally, permissions are translated into extended POSIX ACLs and interpreted by Samba as Windows ACLs. They must be composed of 03 fields separated by colons (:) and have the format [Type]:Account:[Permission], where:
Other important aspects about permissions are:
Some examples:
Allowing full access to the Domain Users group
g:domain users:f
Adding read-only permission to the Guest user account
+u:guest:r
Removing permissions for the Guest user account
-u:guest
Allowing full access to all users and denying access to the Guests group
u:everyone:f;g:guests:d
Userfolder mode
This mode enables the homes section of Samba, which is a special type of file sharing that automatically provides a share with the same name as the user who accesses it. In this mode, the Path argument must contain the path of the parent directory where the diretories for each user are to be created. If this argument is omitted, the /home directory will be assumed by default. CID automatically creates user directories with appropriate permissions as users first access their respective shares. If disk quota is used, it will be automatically applied to each user directory.