Chapter 15. User and Group Schema
When 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.)
| Object Classes | Description |
|---|---|
|
ipaobject
ipasshuser
| IdM object classes |
|
person
organizationalperson
inetorgperson
inetuser
posixAccount
| Person object classes |
|
krbprincipalaux
krbticketpolicyaux
| Kerberos object classes |
| mepOriginEntry | Managed entries (template) object classes |
A number of attributes are available to user entries. Some are set manually and some are set based on defaults if a specific value is not set. There is also an option to add any attributes available in the object classes in Table 15.1, “Default Identity Management User Object Classes”, even if there is not a UI or command-line argument for that attribute. Additionally, the values generated or used by the default attributes can be configured, as in Section 15.4, “Specifying Default User and Group Attributes”.
| UI Field | Command-Line Option | Required, Optional, or Default[a] |
|---|---|---|
| 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 [b] | 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 |
| Department Number | --departmentnumber | Optional |
| Employee Number | --employeenumber | Optional |
| Employee Type | --employeetype | Optional |
| Preferred Language | --preferredlanguage | Optional |
[a]
Required attributes must be set for every entry. Optional attributes may be set, while default attributes are automatically added with a predefined value unless a specific value is given.
[b]
The script prompts for the new password, rather than accepting a value with the argument.
| ||
15.1. About Changing the Default User and Group Schema
It is possible to add or change the object classes and attributes used for user and group entries (Chapter 15, User and Group Schema).
The IdM configuration provides some validation when object classes are changed:
- All of the object classes and their specified attributes must be known to the LDAP server.
- All default attributes that are configured for the entry must be supported by the configured object classes.
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.
