| Identity Management GuideChapter 5. Identity: Managing Users and User GroupsUsers in Identity Management are able to access services and servers within the domain through Kerberos authentication. This chapter covers general management tasks for users, groups, password policies, and other configuration for users. 5.1. Setting up User Home DirectoriesA home directory is required for any IdM user. Without a home directory in the expected location, a user may be unable to log into the domain. While systems administrators can manage home directories outside of IdM, it is also possible to use a PAM module to create home directories automatically on both IdM servers and clients. 5.1.1. About Home DirectoriesIdM, as part of managing users, can manage user home directories. However, IdM has certain defined parameters for any managed home directories: The default prefix for users' home directories is /home. IdM does not automatically create home directories when users log in. Automatically creating home directories requires either the pam_oddjob_mkhomedir module or the pam_mkhomedir module. This module can be configured as part of client installation or after installation, as described in Section 5.1.2, "Enabling the PAM Home Directory Module". The home directory process for IdM first attempts to use the pam_oddjob_mkhomedir module because this requires fewer user privileges and access to create the home directories, as well as integrating smoothly with SELinux. If this module is not available, then the process falls back to the pam_mkhomedir module. On Red Hat Enterprise Linux 5 clients, the client installation script uses the pam_mkhomedir module even if the pam_oddjob_mkhomedir module is available. To use the pam_oddjob_mkhomedir module on Red Hat Enterprise Linux 5, edit the PAM configuration manually. It is possible to use an NFS file server that provides /home that can be made available to all machines in the domain and then automounted on the IdM server. There are potential issues when using NFS, such as security issues related to granting root access to the NFS user, performance issues with loading the entire /home tree, and network performance issues for using remote servers for home directories. There are some general guidelines for using NFS with Identity Management: Use automount to mount only the user's home directory and only when the user logs in, rather than loading the entire /home tree. Use a remote user who has limited permissions to create home directories and mount the share on the IdM server as that user. Since the IdM server runs as an httpd process, it is possible to use sudo or a similar program to grant limited access to the IdM server to create home directories on the NFS server. Use a mechanism, such as the pam_oddjob_mkhomedir module, to create the home directory as that user.
If a suitable directory and mechanism are not available for to create home directories, users may not be able to log in.
5.1.2. Enabling the PAM Home Directory ModuleFor a home directory to be created automatically when a user logs in, IdM can use either the pam_oddjob_mkhomedir module or the pam_mkhomedir module. Because it requires fewer permissions and works well with SELinux, IdM preferentially uses the pam_oddjob_mkhomedir module. If that module is not installed, then it falls back to the pam_mkhomedir module. IdM does not require the pam_oddjob_mkhomedir module or pam_mkhomedir module. This is because the *_mkhomedir module may try to create home directories even when the shared storage is not available. If the module is unable to create the home directory, then users can be blocked from logging into the IdM domain. The system administrator must activate this module on each client or server as needed. There are two ways to enable the pam_oddjob_mkhomedir (or pam_mkhomedir) module: The --mkhomedir option can be used with the ipa-client-install command. While this is possible for clients, this option is not available to servers when they are set up. The pam_oddjob_mkhomedir module can be enabled using the system's authconfig command. For example: authconfig --enablemkhomedir --update This option can be used for both server and client machines post-installation.
On Red Hat Enterprise Linux 5 clients, the client installation script uses the pam_mkhomedir module even if the pam_oddjob_mkhomedir module is available. To use the pam_oddjob_mkhomedir module on Red Hat Enterprise Linux 5, edit the PAM configuration manually. 5.1.3. Manually Mounting Home DirectoriesWhile PAM modules can be used to create home directories for users automatically, this may not be desirable behavior in every environment. In that case, home directories can be manually added to the IdM server from separate locations using NFS shares and automount. Create a new location for the user directory maps: $ ipa automountlocation-add userdirsLocation: userdirs Add a direct map to the new location's auto.direct file. In this example, the mount point is /share: $ ipa automountkey-add userdirs auto.direct --key=/share --info="-ro,soft, ipaserver.example.com:/home/share"Key: /shareMount information: -ro,soft, ipaserver.example.com:/home/share
5.2. Managing User Entries5.2.1. About Username FormatsThe default length for usernames is 32 characters. IdM supports a wide range of username formats, based on this regular expression: [a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?The trailing $ symbol is permitted for Samba 3.x machine support. Any system limits - such as starting a username with a number on Unix systems - apply to the usernames in IdM. Open the Identity tab, and select the Users subtab. Click the Add link at the top of the users list. Fill in the user's first and last names. The user login (UID) is automatically generated based on the user's full name, but this can be set manually by clicking the Optional field link. Click the Add and Edit button to go directly to the expanded entry page and fill in more attribute information, as in Section 5.2.3.1, "From the Web UI". The user entry is created with some basic information already filled in, based on the given user information and the user entry template.
5.2.2.2. From the Command Line$ ipa user-add [username] [attributes] When no arguments are used, the command prompts for the required user account information and uses the defaults for the other attributes, with the defaults printed below. For example: $ ipa user-addFirst name: JohnLast name: SmithUser login [jsmith]: jsmith--------------------Added user "jsmith"--------------------User login: jsmithFirst name: JohnLast name: SmithHome directory: /home/jsmithGECOS field: jsmithLogin shell: /bin/shKerberos principal: [email protected]: 387115841 Any of the user attributes can be passed with the command. This will either set values for optional attributes or override the default values for default attributes. $ ipa user-add jsmith --first=John --last=Smith --manager=bjensen [email protected] --homedir=/home/work/johns --password When a user is created without specifying a UID or GID number, then the user account is automatically assigned an ID number that is next available in the server or replica range. (Number ranges are described more in Section 5.7, "Managing Unique UID and GID Number Assignments".) This means that a user always has a unique number for its UID number and, if configured, for its private group. If a number is manually assigned to a user entry, the server does not validate that the uidNumber is unique. It will allow duplicate IDs; this is expected (though discouraged) behavior for POSIX entries. If two entries are assigned the same ID number, only the first entry is returned in a search for that ID number. However, both entries will be returned in searches for other attributes or with ipa user-find --all. Open the Identity tab, and select the Users subtab. Click the name of the user to edit. There are a number of different types of attributes that can be edited for the user. All of the default attributes are listed in Table 5.2, "Default Identity Management User Attributes". Most of the attributes in the Identity Settings and Account Settings areas have default values filled in for them, based on the user information or on the user entry template. Edit the fields or, if necessary, click the Add link by an attribute to create the attribute on the entry. When the edits are done, click the Update link at the top of the page.
5.2.3.2. From the Command LineThe user-mod command edits user accounts by adding or changing attributes. At its most basic, the user-mod specifies the user account by login ID, the attribute to edit, and the new value: $ ipa user-mod loginID --attributeName=newValue For example, to change a user's work title from Editor II to Editor III: $ ipa user-mod jsmith --title="Editor III" Identity Management allows multi-valued attributes, based on attributes in LDAP that are allowed to have multiple values. For example, a person may have two email addresses, one for work and one for personal, that are both stored in the mail attribute. Managing multi-valued attributes can be done using the --addattr option. If an attribute allows multiple values - like mail - simply using the command-line argument will overwrite the value with the new value. This is also true for using --setattr. However, using --addattr will add a new attribute; for a multi-valued attribute, it adds the new value in addition to any existing values. Example 5.1. Multiple Mail Attributes A user is created first using his work email account. $ ipa user-add jsmith --first=John --last=Smith [email protected] Then, his personal email account is added. $ ipa user-mod jsmith [email protected] Both email addresses are listed for the user. $ ipa user-find jsmith --all--------------1 user matched-------------- dn: uid=jsmith,cn=users,cn=accounts,dc=example,dc=com User login: jsmith ..... Email address: [email protected], [email protected] To set two values at the same time, use the --addattr option twice: $ ipa user-add jsmith --first=John --last=Smith [email protected] [email protected] [email protected] 5.2.4. Activating and Deactivating User AccountsUser accounts can be deactivated. A deactivated user cannot log into IdM or its related services (like Kerberos) and he cannot perform any tasks. However, the user account still exists within Identity Management and all of the associated information remains unchanged. Any existing connections remain valid until the Kerberos TGT and other tickets expire. Once the ticket expires, the user cannot renew the ticket. Open the Identity tab, and select the Users subtab. Click the name of the user for whom to deactivate or activate. Scroll to the Account Settings area. Click the Deactivate link. Click the Update link at the top of the page.
5.2.4.2. From the Command LineUsers are activated and disabled using user-enable and user-disable commands. All that is required is the user login. For example: $ ipa user-disable jsmith Deleting a user account permanently removes the user entry and all its information from IdM, including group memberships and passwords. External configuration - like a system account and home directory - will still exist on any server or local machine where they were created, but they cannot be accessed through IdM. Deleting a user account is permanent. The information cannot be recovered; a new account must be created. If all admin users are deleted, then you must use the Directory Manager account to create a new administrative user. Alternatively, any user who belongs in the group management role can also add a new admin user. Open the Identity tab, and select the Users subtab. Select the checkboxes by the names of the users to delete. Click the Delete link at the top of the task area. When prompted, confirm the delete action.
5.2.5.2. From the Command LineUsers are deleted using the user-del command and then the user login. For example, a single user: $ ipa user-del jsmith To delete multiple users, simply list the users, separated by spaces. $ ipa user-del jsmith bjensen mreynolds cdickens When deleting multiple users, use the --continue option to force the command to continue regardless of errors. A summary of the successful and failed operations is printed to stdout when the command completes. If --continue is not used, then the command proceeds with deleting users until it encounters an error, and then it exits. 5.3. Managing Public SSH Keys for UsersOpenSSH uses public-private key pairs to authenticate users. A user attempts to access some network resource and presents its key pair. The first time the user authenticates, the administrator on the target machine has to approve the request manually. The machine then stores the user's public key in an authorized_keys file. Any time that the user attempts to access the resource again, the machine simply checks its authorized_keys file and then grants access automatically to approved users. There are a couple of problems with this system: SSH keys have to be distributed manually and separately to all machines in an environment. Administrators have to approve user keys to add them to the configuration, but it is difficult to verify either the user or key issuer properly, which can create security problems.
On Red Hat Enterprise Linux, the System Security Services Daemon (SSSD) can be configured to cache and retrieve user SSH keys so that applications and services only have to look in one location for user keys. Because SSSD can use Identity Management as one of its identity information providers, Identity Management provides a universal and centralized repository of keys. Administrators do not need to worry about distributing, updating, or verifying user SSH keys. 5.3.1. About the SSH Key FormatWhen keys are uploaded to the IdM entry, the key format can be either an OpenSSH-style key or a raw RFC 4253-style blob. Any RFC 4253-style key is automatically converted into an OpenSSH-style key before it is imported and saved into the IdM LDAP server. The IdM server can identify the type of key, such as an RSA or DSA key, from the uploaded key blob. However, in a key file such as id_rsa.pub, a key entry is identified by its type, then the key itself, and then an additional comment or identifier. For example, for an RSA key associated with a specific hostname: "ssh-rsa ABCD1234...== ipaclient.example.com" All three parts from the key file can be uploaded to and viewed for the user entry, or only the key itself can be uploaded. 5.3.2. Uploading User SSH Keys Through the Web UIGenerate a user key. For example, using the OpenSSH tools: [jsmith@server ~]$ ssh-keygen -t rsa -C [email protected] public/private rsa key pair.Enter file in which to save the key (/home/jsmith/.ssh/id_rsa):Created directory '/home/jsmith/.ssh'.Enter passphrase (empty for no passphrase):Enter same passphrase again:Your identification has been saved in /home/jsmith/.ssh/id_rsa.Your public key has been saved in /home/jsmith/.ssh/id_rsa.pub.The key fingerprint is:a5:fd:ac:d3:9b:39:29:d0:ab:0e:9a:44:d1:78:9c:f2 [email protected] key's randomart image is:+--[ RSA 2048]----+| || + . || + = . || = + || . E S.. || . . .o || . . . oo. || . o . +.+o || o .o..o+o |+-----------------+ Copy the public key from the key file. The full key entry has the form type key== comment. Only the key== is required, but the entire entry can be stored. [jsmith@server ~]$ cat /home/jsmith/.ssh/id_rsa.pubssh-rsa AAAAB3NzaC1yc2E...tJG1PK2Mq++wQ== [email protected] Open the Identity tab, and select the Users subtab. Click the name of the user to edit. In the Account Settings area of the Settings tab, click the SSH public keys: Add link. The UI opens a new link, New: key not set Show/Set key. Click the Show/Set key link. Paste in the public key for the user, and click the Set button. The SSH public keys field now shows New: key set. Clicking the Show/Set key link opens the submitted key. To upload multiple keys, click the Add link below the list of public keys, and upload the other keys. When all the keys have been submitted, click the Update link at the top of the user's page to save the changes.
When the public key is saved, the entry is displayed as the key fingerprint, the comment (if one was included), and the key type . After uploading the user keys, configure SSSD to use Identity Management as one of its identity domains and set up OpenSSH to use the SSSD tooling for managing user keys. This is covered in the Red Hat Enterprise Linux Deployment Guide. 5.3.3. Uploading User SSH Keys Through the Command LineThe --sshpubkey option uploads the 64 bit-encoded public key to the user entry. For example: [jsmith@server ~]$ ipa user-mod jsmith --sshpubkey="ssh-rsa 12345abcde= ipaclient.example.com" With a real key, the key is longer and usually ends with an equals sign (=). To upload multiple keys, pass a comma-separated list of keys with a single --sshpubkey option: --sshpubkey="12345abcde==,key2==,key3==" After uploading the user keys, configure SSSD to use Identity Management as one of its identity domains and set up OpenSSH to use the SSSD tooling for managing user keys. This is covered in the Red Hat Enterprise Linux Deployment Guide. 5.3.4. Deleting User KeysOpen the Identity tab, and select the Users subtab. Click the name of the user to edit. Open the Account Settings area of the Settings tab. Click the Delete link by the fingerprint of the key to remove. Click the Update link at the top of the user's page to save the changes.
The command-line tools can be used to remove all keys. This is done by running ipa user-mod with the --sshpubkey= set to a blank value; this removes all public keys for the user. For example: [jsmith@server ~]$ kinit admin[jsmith@server ~]$ ipa user-mod --sshpubkey= jsmith Regular, non-administrative users can change only their personal passwords, and all passwords are constrained by the IdM password policies. This allows administrators to create intro passwords or to reset passwords easily, while still keeping the final password confidential. Since any password sent by an administrator to the user is temporary, there is little security risk. Changing a password as the IdM admin user overrides any IdM password policies, but the password expires immediately. This requires the user to change the password at the next login. Similarly, any user who has password change rights can change a password and no password policies are applied, but the other user must reset the password at the next log in. Changing a password as the LDAP Directory Manager user, using LDAP tools, overrides any IdM password policies.
Open the Identity tab, and select the Users subtab. Click the name of the user for whom to reset the password. All users can change their own password; only administrators or users with delegated permissions can change other user's passwords. Scroll to the Account Settings area. Click the Reset Password link. In the pop-up box, enter and confirm the new password.
5.4.2. From the Command LineChanging a password - your own or another user's - is done using the user-mod command, as with other user account changes. [bjensen@ipaserver ~]$ kinit admin[bjensen@ipaserver ~]$ ipa user-mod jsmith --password 5.5. Unlocking User Accounts After Password FailuresIf a user attempts to log in and uses the wrong password a certain number of times, then that user account is locked. The exact number of failed attempts that locks and account and the duration of the lockout is defined as part of the password policy ( Section 12.6, "Setting Account Lockout Policies"). A password policy can implicitly define a reset period, where the account unlocks naturally after a certain amount of time lapses. However, if the duration is fairly long or if the deployment requires stronger security checks before unlocking an account, then an administrator can unlock an account manually. An account is unlocked using the user-unlock command. For example: [bjensen@ipaserver ~]$ kinit admin[bjensen@ipaserver ~]$ ipa user-unlock jsmith 5.6. Managing User Private GroupsOn Red Hat Enterprise Linux systems, every time a user is created, a corresponding, secret user group is automatically created with that new user as its only member. This is a user private group. Using user private groups makes it simpler and safer to manage file and directory permissions because umask defaults only have to restrict user access, not group access. When a new user is created in the IdM domain, it is also created with a corresponding private group, following the Red Hat Enterprise Linux convention. For most environments, this is an acceptable default behavior, but there may be certain users or types of users which do not require a private group or the environment may already have those GIDs assigned to NIS groups or other system groups. 5.6.1. Disabling Private Groups for a Specific UserPrivate group creation can be disabled when the user is created by using the --noprivate option. [jsmith@server ~]$ ipa user-add jsmith --first=John --last=Smith --noprivate 5.6.2. Disabling Private Groups GloballyUser private groups are managed through the Managed Entries Plug-in in 389 Directory Server. This plug-in can be disabled, which effectively disables private group creation for all new users. This is done using the ipa-managed-entries command. Use the ipa-managed-entries command to list possible Managed Entries Plug-in definitions. By default, there are two, one for new users (UPG) and one for netgroups (NGP). [root@ipaserver ~]# ipa-managed-entries --list -p DMpasswordAvailable Managed Entry Definitions:UPG DefinitionNGP Definition Disable the desired Managed Entries Plug-in instance. For example: [root@ipaserver ~]# ipa-managed-entries -e "UPG Definition" -p DMpassword disableDisabling Plugin Restart the 389 Directory Server to load the new plug-in configuration. [root@ipaserver ~]# service dirsrv restart
Managed Entries Plug-in instances can be re-enabled with the enable option. 5.7. Managing Unique UID and GID Number AssignmentsAn IdM server must generate random UID and GID values and simultaneously ensure that replicas never generate the same UID or GID value. The need for unique UID and GID numbers might even cross IdM domains, if a single organization has multiple disparate domains. The UID and GID numbers are divided into ranges. By keeping separate numeric ranges for individual servers and replicas, the chances are minimal that any numbers issued by one server or replica will duplicate those from another. Ranges are updated and shared intelligently between servers and replicas through the Dynamic Numeric Assignment (DNA) Plug-in, as part of the backend 389 Directory Server instance for the domain. The same range is used for user IDs (uidNumber) and group IDs (gidNumber). A user and a group may have the same ID, but since the ID is set in different attributes, there is no conflict. Using the same ID number for both a user and a group also allows an administrator to configure user private groups, where a unique system group is created for each user and the ID number is the same for both the user and the group. When a user is created interactively or without specifying a UID or GID number, then the user account is created with an ID number that is next available in the server or replica range. This means that a user always has a unique number for its UID number and, if configured, for its private group. If a number is manually assigned to a user entry, the server does not validate that the uidNumber is unique. It will allow duplicate IDs; this is expected (though discouraged) behavior for POSIX entries. The same is true for group entries: a duplicate gidNumber can be manually assigned to the entry. If two entries are assigned the same ID number, only the first entry is returned in a search for that ID number. However, both entries will be returned in searches for other attributes or with ipa user-find --all. 5.7.1. About ID Range Assignments During InstallationThe IdM administrator can initially define a range during server installation, using the --idstart and --idmax options with ipa-server-install. These options are not required, so the setup script can assign random ranges during installation. If no range is set manually when the first IdM server is installed, a range of 200,000 IDs is randomly selected. There are 10,000 possible ranges. Selecting a random range from that number provides a high probability of non-conflicting IDs if two separate IdM domains are ever merged in the future. With a single IdM server, IDs are assigned to entries in order through the range. With replicas, the initial server ID range is split and distributed. When a replica is installed, it is configured with an invalid range. It also has a directory entry (that is shared among replicas) that instructs the replica where it can request a valid range. When the replica starts, or as its current range is depleted so that less than 100 IDs are available, it can contact one of the available servers for a new range allotment. A special extended operation splits the range in two, so that the original server and the replica each have half of the available range. If the range for the entire domain is close to depletion, a new range can be manually selected and assigned to one of the master servers. All replicas then request ID ranges from the master as necessary. The changes to the range are done by editing the 389 Directory Server configuration to change the DNA Plug-in instance. The range is defined in the dnaNextRange parameter. For example: ldapmodify -x -D "cn=Directory Manager" -W -h server.example.com -p 389Enter LDAP Password: *******dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=configchangetype: modifyadd: dnaNextRangednaNextRange: 123400000-123500000 This command only adds the specified range of values; it does not check that the values in that range are actually available. This check is performed when an attempt is made to allocate those values. If a range is added that contains mostly values that were already allocated, the system will cycle through the entire range searching for unallocated values, and then the operation ultimately fails if none are available. 5.8. Managing User and Group SchemaWhen a user entry is created, it is automatically assigned certain LDAP object classes which, in turn, make available certain attributes. LDAP attributes are the way that information is stored in the directory. (This is discussed in detail in the Directory Server Deployment Guide and the Directory Server Schema Reference.) Table 5.1. Default Identity Management User Object Classes | Description | Object Classes |
|---|
| IdM object classes | ipaobject | | Person object classes | | person | | organizationalperson | | inetorgperson | | inetuser | | posixaccount |
| | Kerberos object classes | | krbprincipalaux | | krbticketpolicyaux |
| | Managed entries (template) object classes | mepOriginEntry |
Table 5.2. Default Identity Management User Attributes | UI Field | Command-Line Option | Required, Optional, or Default |
|---|
| User login | username | Required | | First name | --first | Required | | Last name | --last | Required | | Full name | --cn | Optional | | Display name | --displayname | Optional | | Initials | --initials | Default | | Home directory | --homedir | Default | | GECOS field | --gecos | Default | | Shell | --shell | Default | | Kerberos principal | --principal | Default | | Email address | --email | Optional | | Password | --password Unlike the other options, this accepts no value. The script prompts for the new password. | Optional | | User ID number | --uid | Default | | Group ID number | --gidnumber | Default | | Street address | --street | Optional | | City | --city | Optional | | State/Province | --state | Optional | | Zip code | --postalcode | Optional | | Telephone number | --phone | Optional | | Mobile telephone number | --mobile | Optional | | Pager number | --pager | Optional | | Fax number | --fax | Optional | | Organizational unit | --orgunit | Optional | | Job title | --title | Optional | | Manager | --manager | Optional | | Car license | --carlicense | Optional | | --noprivate | Optional | | SSH Keys | --sshpubkey | Optional | | Additional attributes | --addattr | Optional |
5.8.1. About Changing the Default User and Group SchemaThe IdM configuration provides some validation when object classes are changed: There are limits to the IdM schema validation, however. Most important, the IdM server does not check that the defined user or group object classes contain all of the required object classes for IdM entries. For example, all IdM entries require the ipaobject object class. However, when the user or group schema is changed, the server does not check to make sure that this object class is included; if the object class is accidentally deleted, then future entry add operations will fail. Also, all object class changes are atomic, not incremental. The entire list of default object classes has to be defined every time there is a change. For example, a company may create a custom object class to store employee information like birthdays and employment start dates. The administrator cannot simply add the custom object class to the list; he must set the entire list of current default object classes plus the new object class. The existing default object classes must always be included when the configuration is updated. Otherwise, the current settings will be overwritten, which causes serious performance problems. 5.8.2. Applying Custom Object Classes to New User EntriesUser and group accounts are created with a pre-defined set of LDAP object classes applied to the entry. Any attributes which belong to the object class can be added to the user entry. While the standard and IdM-specific LDAP object classes will cover most deployment scenarios, administrators may have custom object classes with custom attributes which should be applied to user entries. Open the IPA Server tab. Select the Configuration subtab. Scroll to the User Options area. At the bottom of the users area, click the Add link to add a new field for another object class. Always include the existing default object classes when the configuration is updated. Otherwise, the current settings will be overwritten. If any object classes required by Identity Management are not included, then subsequent attempts to add an entry will fail with object class violations. When the changes are complete, click the Update link at the top of the Configuration page. 5.8.2.2. From the Command Line Add the new object class to the list of object classes added to entries. The option for user object classes is --userobjectclasses. Always include the existing default object classes when the configuration is updated. Otherwise, the current settings will be overwritten. If any object classes required by Identity Management are not included, then subsequent attempts to add an entry will fail with object class violations. For example: $ ipa config-mod --userobjectclasses=top,person,organizationalperson,inetorgperson,inetuser,posixaccount, krbprincipalaux,krbticketpolicyaux,ipaobject,employeeinfo 5.8.3. Applying Custom Object Classes to New Group EntriesAs with user entries, administrators may have custom object classes with custom attributes which should be applied to group entries. These can be added automatically by adding the object classes to the IdM server configuration. Open the IPA Server tab. Select the Configuration subtab. Scroll to the Group Options area. Click the Add link to add a new field for another object class. Always include the existing default object classes when the configuration is updated. Otherwise, the current settings will be overwritten. If any object classes required by Identity Management are not included, then subsequent attempts to add an entry will fail with object class violations. When the changes are complete, click the Update link at the top of the Configuration page. 5.8.3.2. From the Command Line Add the new object class to the list of object classes added to entries. The option for group object classes is --groupobjectclasses. Always include the existing default object classes when the configuration is updated. Otherwise, the current settings will be overwritten. If any object classes required by Identity Management are not included, then subsequent attempts to add an entry will fail with object class violations. For example: $ ipa config-mod --groupobjectclasses=top,groupofnames,nestedgroup,ipausergroup,ipaobject,employeegroup 5.9. Managing User GroupsUser groups are a way of centralizing control over important management tasks, particularly access control and password policies. Three groups are created during the installation, specifically for use by IdM operations: ipausers, which contains all users. admins, which contains administrative users. The initial admin user belongs to this group. editors, which is a special group for users working through the web UI. This group allows users to edit other users' entries, though without all of the rights of the admin user.
All groups in Identity Management are essentially static groups, meaning that the members of the group are manually and explicitly added to the group. Tangentially, IdM allows nested groups, where a group is a member of another group. In that case, all of the group members of the member group automatically belong to the parent group, as well. Because groups are easy to create, it is possible to be very flexible in what groups to create and how they are organized. Groups can be defined around organizational divisions like departments, physical locations, or IdM or infrastructure usage guidelines for access controls. Some operating systems limit the number of groups that can be assigned to system users. For example, Solaris and AIX systems both limit users to 16 groups per user. This can be an issue when using nested groups, when a user may be automatically added to multiple groups. When a group entry is created, it is automatically assigned certain LDAP object classes. (LDAP object classes and attributes are discussed in detail in the Directory Server Deployment Guide and the Directory Server Schema Reference.) For groups, only two attributes truly matter: the name and the description. Table 5.3. Default Identity Management Group Object Classes | Description | Object Classes |
|---|
| IdM object classes | | ipaobject | | ipausergroup | | nestedgroup |
| | Group object classes | |
5.9.1. Creating User GroupsOpen the Identity tab, and select the User Groups subtab. Click the Add link at the top of the groups list. Enter all of the information for the group. A unique name. This is the identifier used for the group in the IdM domain, and it cannot be changed after it is created. The name cannot contain spaces, but other separators like an underscore (_) are allowed. A text description of the group. Whether the group is a Posix group, which adds Linux-specific information to the entry. By default, all groups are Posix groups unless they are explicitly configured not to be. Non-Posix groups can be created for interoperability with Windows or Samba. Optionally, the GID number for the group. All Posix groups require a GID number, but IdM automatically assigns the GID number. Setting a GID number is not necessary because of the risk of collisions. If a GID number is given manually, IdM will not override the specified GID number, even if it is not unique.
Click the Add and Edit button to go immediately to the member selection page.
5.9.1.2. With the Command LineNew groups are created using the group-add command. (This adds only the group; members are added separately.) Two attributes are always required: the group name and the group description. If those attributes are not given as arguments, then the script prompts for them. $ ipa group-add groupName --desc="description" [--nonposix] Additionally, there is one other configuration option, --nonposix. (By default, all groups are created as POSIX groups.) To enable interoperability with Windows users and groups and programs like Samba, it is possible to create non-POSIX groups by using the --nonposix option. This option tells the script not to add the posixGroup object class to the entry. For example: $ ipa group-add examplegroup --desc="for examples" --nonposix----------------------Added group "examplegroup"---------------------- Group name: examplegroup Description: for examples GID: 855800010 When no arguments are used, the command prompts for the required group account information: $ ipa group-addGroup name: engineeringDescription: for engineers-------------------------Added group "engineering"------------------------- Group name: engineering Description: for engineers GID: 387115842 When a group is created without specifying a GID number, then the group entry is assigned the ID number that is next available in the server or replica range. (Number ranges are described more in Section 5.7, "Managing Unique UID and GID Number Assignments".) This means that a group always has a unique number for its GID number. If a number is manually assigned to a group entry, the server does not validate that the gidNumber is unique. It will allow duplicate IDs; this is expected (though discouraged) behavior for POSIX entries. If two entries are assigned the same ID number, only the first entry is returned in a search for that ID number. However, both entries will be returned in searches for other attributes or with ipa group-find --all. You cannot edit the group name. The group name is the primary key, so changing it is the equivalent of deleting the group and creating a new one. 5.9.2. Adding Group Members5.9.2.1. With the Web UI (Group Page)This procedure adds a user to a group. User groups can contain other user groups as their members. These are nested groups. It can take up to several minutes for the members of the child group to show up as members of the parent group. This is especially true on virtual machines where the nested groups have more than 500 members. When creating nested groups, be careful not to create recursive groups. For example, if GroupA is a member of GroupB, do not add GroupB as a member of GroupA. Recursive groups are not supported and can cause unpredictable behavior. Open the Identity tab, and select the User Groups subtab. Click the name of the group to which to add members. Click the Add link at the top of the task area. Click the checkbox by the names of the users to add, and click the right arrows button, >>, to move the names to the selection box. Click the Add button.
Group members can be users or other user groups. It can take up to several minutes for the members of the child group to show up as members of the parent group. This is especially true on virtual machines where the nested groups have more than 500 members. 5.9.2.2. With the Web UI (User's Page)Users can also be added to a group through the user's page. Open the Identity tab, and select the Users subtab. Click the name of the user to edit. Open the User Groups tab on the user entry page. Click the Add link at the top of the task area. Click the checkbox by the names of the groups for the user to join, and click the right arrows button, >>, to move the groups to the selection box. Click the Add button.
5.9.2.3. With the Command LineMembers are added to a group using the group-add-member command. This command can add both users as group members and other groups as group members. The syntax of the group-add-member command requires only the group name and a comma-separated list of users to add: $ ipa group-add-member groupName [--users=list] [--groups=list] For example, this adds three users to the engineering group: $ ipa group-add-member engineering --users=jsmith,bjensen,mreynolds Group name: engineering Description: for engineers GID: 387115842 Member users: jsmith,bjensen,mreynolds-------------------------Number of members added 3------------------------- Likewise, other groups can be added as members, which creates nested groups: $ ipa group-add-member engineering --groups=dev,qe1,dev2 Group name: engineering Description: for engineers GID: 387115842 Member groups: dev,qe1,dev2 ------------------------- Number of members added 3 ------------------------- When displaying nested groups, members are listed as members and the members of any member groups are listed as indirect members. For example: $ ipa group-show examplegroup Group name: examplegroup Description: for examples GID: 93200002 Member users: jsmith,bjensen,mreynolds Member groups: californiausers Indirect Member users: sbeckett,acalavicci It can take up to several minutes for the members of the child group to show up as members of the parent group. This is especially true on virtual machines where the nested groups have more than 500 members. When creating nested groups, be careful not to create recursive groups. For example, if GroupA is a member of GroupB, do not add GroupB as a member of GroupA. Recursive groups are not supported and can cause unpredictable behavior. A group member is removed using the group-remove-member command. $ ipa group-remove-member engineering --users=jsmith Group name: engineering Description: for engineers GID: 855800009 Member users: bjensen,mreynolds---------------------------Number of members removed 1--------------------------- 5.9.2.4. Viewing Direct and Indirect Members of a GroupUser groups can contain other user groups as members. This is called a nested group. This also means that a group has two types of members: Direct members, which are added explicitly to the group Indirect members, which are members of the group because they are members of another user group which is a member of the group
The IdM web UI has an easy way to view direct and indirect members of a group. The members list is filtered by member type, and this can be toggled by selecting the Direct and Indirect radio buttons at the top right corner of the members list. Being able to track indirect members makes it easier to assign group membership properly, without duplicating membership. 5.9.3. Deleting User GroupsWhen a user group is deleted, only the group is removed. The user accounts of group members (including nested groups) are not affected. Additionally, any access control delegations that apply to that group are removed. Deleting a group is immediate and permanent. If any group configuration (such as delegations) is required, it must be assigned to another group or a new group created. Open the Identity tab, and select the User Groups subtab. Select the checkbox by the name of the group to delete. Click the Delete link at the top of the task area. When prompted, confirm the delete action.
5.9.3.2. With the Command LineThe group-del command to deletes the specified group. For example: $ ipa group-del examplegroup 5.10. Searching for Users and GroupsBy default, there are six attributes that are indexed for user searches and two that are indexed for group searches. These are listed in Table 5.4, "Default Search Attributes". All search attributes are searched in a user/group search. Table 5.4. Default Search Attributes | User Search Attributes | | First name | Last name | | Login ID | Job title | | Organizational unit | Phone number | | Group Search Attributes | | Name | Description |
Both user and group main pages have a search bar in the upper right corner of the task area. This search box searches against all of the fields listed in Table 5.4, "Default Search Attributes". Type in any string, even a single letter, and click the magnifying glass icon. The UI filters the displayed list to match the search string. 5.10.2. With the Command LineSearches are simple: $ ipa user-find|group-find string options There are a few general rules with searches: If there is no string, then the search returns every entry in IdM, up to the search limit. With the command-line tools, only a single search string can be used for user and group searches. With the UI, multiple strings can be used. Searches are case insensitive. Search results are displayed alphabetically, with exact matches listed first, followed by partial matches. Wildcards cannot be used in searches. The search string must include at least one character that appears in one of the indexed search fields.
Example 5.2. User Search for John The basic search looks for the string john, which can appear in any of the search indexes. $ ipa user-find john---------------2 users matched--------------- User login: jpeterson First name: john Last name: peterson Home directory: /home/jpeterson Login shell: /bin/sh UID: 855800007 GID: 855800007 Account disabled: False User login: jsmith First name: john Last name: smith Home directory: /home/jsmith Login shell: /bin/sh UID: 855800004 GID: 855800004 Account disabled: False----------------------------Number of entries returned 2---------------------------- A search can also accept options like --raw. --raw prints the LDAP attributes for the user account rather than the reading-friendly field names. $ ipa user-find john --raw---------------2 users matched--------------- uid: jpeterson givenname: john sn: peterson homedirectory: /home/jpeterson loginshell: /bin/sh uidnumber: 855800007 gidnumber: 855800007 nsaccountlock: False uid: jsmith givenname: john sn: smith homedirectory: /home/jsmith loginshell: /bin/sh uidnumber: 855800004 gidnumber: 855800004 nsaccountlock: False----------------------------Number of entries returned 2---------------------------- If the desired entry is not listed, it is possible that the search hit the preset search size limit before the entry was found. Change the search record or time limits, as in Section 4.4.2, "Setting IdM Search Limits", to allow more entries to be returned. 5.11. Specifying Default User and Group SettingsIdentity Management uses a template when it creates new entries. For users, the template is very specific. Identity Management uses default values for several core attributes for IdM user accounts. These defaults can define actual values for user account attributes (such as the home directory location) or it can define the format of attribute values, such as the username length. These settings also define the object classes assigned to users. For groups, the template only defines the assigned object classes. These default definitions are all contained in a single configuration entry for the IdM server, cn=ipaconfig,cn=etc,dc=example,dc=com. The configuration can be changed using the ipa config-mod command. Table 5.5. Default User Parameters | Field | Command-Line Option | Descriptions |
|---|
| Maximum username length | --maxusername | Sets the maximum number of characters for usernames. The default value is eight. | | Root for home directories | --homedirectory | Sets the default directory to use for user home directories. The default value is /home. | | Default shell | --defaultshell | Sets the default shell to use for users. The default value is /bin/sh. | | Default user group | --defaultgroup | Sets the default group to which all newly created accounts are added. The default value is ipausers, which is automatically created during the IdM server installation process. | | Default e-mail domain | --emaildomain | Sets the email domain to use to create email addressed based on the new accounts. The default is the IdM server domain. | | Search time limit | --searchtimelimit | Sets the maximum amount of time, in seconds, to spend on a search before the server returns results. | | Search size limit | --searchrecordslimit | Sets the maximum number of records to return in a search. | | User search fields | --usersearch | Sets the fields in a user entry that can be used as a search string. Any attribute listed has an index kept for that attribute, so setting too many attributes could affect server performance. | | Group search fields | --groupsearch | Sets the fields in a group entry that can be used as a search string. | | Certificate subject base | | Sets the base DN to use when creating subject DNs for client certificates. This is configured when the server is set up. | | Default user object classes | --userobjectclasses | Sets a list of object classes that are used to create IdM user accounts. | | Default group object classes | --groupobjectclasses | Sets a list of object classes that are used to create IdM group accounts. | | Password expiration notification | --pwdexpnotify | Sets how long, in days, before a password expires for the server to send a notification. | | Password plug-in features | | Sets the format of passwords that are allowed for users. |
5.11.1. Viewing Settings from the Web UIOpen the IPA Server tab. Select the Configuration subtab. The complete configuration entry is shown in three sections, one for all search limits, one for user templates, and one for group templates.
5.11.2. Viewing Settings from the Command LineThe config-show command shows the current configuration which applies to all new user accounts. By default, only the most common attributes are displayed; use the --all option to show the complete configuration. # ipa config-show --all dn: cn=ipaconfig,cn=etc,dc=example,dc=com Max. username length: 32 Home directory base: /home Default shell: /bin/sh Default users group: ipausers Default e-mail domain for new users: example.com Search time limit: 2 Search size limit: 100 User search fields: uid,givenname,sn,telephonenumber,ou,title Group search fields: cn,description Enable migration mode: FALSE Certificate Subject base: O=EXAMPLE.COM Default group objectclasses: top, groupofnames, nestedgroup, ipausergroup, ipaobject Default user objectclasses: top, person, organizationalperson, inetorgperson, inetuser, posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject Password Expiration Notification (days): 4 Password plugin features: AllowNThash cn: ipaConfig objectclass: nsContainer, top, ipaGuiConfig, ipaConfigObject |
| |
