HPlogo HP-UX Reference > L

ldapugadd(1M)

HP-UX 11i Version 2: December 2007 Update
» 

Technical documentation

 » Table of Contents

 » Index

NAME

ldapugadd — add new accounts or groups to an LDAP directory server

SYNOPSIS

ldapugadd [-t passwd] [options] [-h hostname] [-p port] [-b base] [-u uid_number] [-g group/gid] [-f full_name] [-x domain] [-G group/gid[,...] [-s login_shell] [-d home_directory] [-I gecos] [-c comment] [-m [-k skel_dir]] [-T template_file] uid_name [[attr=value][...]]

ldapugadd -t group [options] [-h hostname] [-p port] [-b base] [-g gid_number] [-x domain] [-M member[,...]] [-c comment] [-T template_file] group_name [[attr=value][...]]

ldapugadd -D [-d default_home] [-s default_shell] [-g default_gid] [-u min_uid:max_uid] [-g min_gid:max_gid]

DESCRIPTION

ldapugadd allows HP-UX administrators to add new POSIX accounts or groups to an LDAP directory server (see first and second syntaxes in SYNOPSIS above). Furthermore, ldapugadd can be used to modify the /etc/opt/ldapux/ldapug.conf file to set defaults for creation of new users or groups (see the third syntax in the SYNOPSIS above).

ldapugadd makes use of user and group template files that allow ldapugadd to conform to the information model used for the types of entries being created. Users of ldapugadd are required to provide LDAP administrator credentials that have sufficient privilege to perform the user or group add operation in the LDAP directory server.

Options

-P

Prompt for the administrators bind identity (typically LDAP DN or kerberos principal) and bind password.

Without -P, ldapugadd will discover the bind identity and password from the environment variables LDAP_BINDDN and LDAP_BINDCRED. If either the LDAP_BINDDN or LDAP_BINDCRED environment variable has not been specified, ldapugadd will follow the bind configuration specified in the ldapux configuration profile (see ldapux(5)).

If ldapux has specified "proxy" bind, the bind credential will be read from either the /etc/opt/ldapux/acred or /etc/opt/ldapux/pcred file. The acred file will only be used by users that have sufficient administrative privileges to read that file. Refer to Binding to the Directory Server below for additional details.

-PP

Prompt for the password of the user or group being created. Also, if LDAP-UX attributed mapping for the userPassword attribute has not been defined or set to *NULL*, ldapugadd will create new passwords in the userPassword attribute. To assure accuracy, the user will be prompted twice for the password. ldapugadd relies on the directory server for setting of password policy, such as user-must-change-password-at-first-login.

-PW

Set the user or group password attribute. Also, if LDAP-UX attributed mapping for the userPassword attribute has not been defined or set to *NULL*, ldapugadd will create new passwords in the userPassword attribute. If -PW is specified, either the LDAP_UGCRED environment variable or the -PP option must be specified.

-Z

Requires an SSL connection to the directory server, even if the LDAP-UX configuration does not require the use of SSL. Use of -Z requires either a valid server or CA certificate be defined in the /etc/opt/ldapux/cert8.db file. An error will occur if the SSL connection could not be established. Refer to Binding to the Directory Server below for additional details.

-ZZ

Attempt a TLS connection to the directory server, even if the LDAP-UX configuration does not require the use of TLS. If a TLS connection is unable to be established a non-TLS and non-SSL connection will be established. Use of -ZZ is not recommended unless alternative methods are used to protect from network eavesdropping. Use of -ZZ requires either a valid server or CA certificate be defined in the /etc/opt/ldapux/cert8.db file. Refer to Binding to the Directory Server below for additional details.

-ZZZ

Requires a TLS connection to the directory server, even if the LDAP-UX configuration does not require the use of TLS. Use of -ZZZ requires either a valid server or CA certificate be defined in the /etc/opt/ldapux/cert8.db file. An error will occur if the TLS connection could not be established. Refer to Binding to the Directory Server below for additional details.

-F

Force creation of new user or group entries even if particular error conditions occur. These are:

  • The user name or group name already exists in the directory server.

  • The user id or group id number already exists in the directory server

  • The shell specified with the -s option does not exist on the local system or is not an executable.

  • Adding a member to a group when that member is not defined in the LDAP directory.

Note that some directory servers perform their own attribute uniqueness checks. In this case, even if the -F option is specified; ldapugadd will be unable to add the new entry.

-S

Display the DN of the newly created entry.

Arguments

-h hostname

Specifies the host name and optional port number (hostname:port) of the directory server. This option overrides the server list configured by LDAP-UX. The hostname field also supports specification of IPv4 and IPv6 addresses.

Note that when a port is specified for an IPv6 address, the IPv6 address must be specified in square-bracketed form. If the optional port is unspecified, the port number is assumed to be 389 or 636 for SSL connections (-Z). Refer to Binding to the Directory Server below for additional details.

-p port

Specifies the port number of the directory server to contact. This option is ignored if the port number is specified in the hostname as part of the -h option. Refer to Binding to the Directory Server below for additional details.

-b base

This option overrides value of the ${basedn} substitution construct used in the respective template file. Instead of discovering the ${basedn} value from the LDAP-UX configuration profile, the value defined in base will be used. Please refer to Template Files below for additional information. base is expected to be an LDAP distinguished name.

-t type

Specifies on which service type ldapugadd will operate. The service type can be either passwd or group, where

passwd

implies posixAccount-type entries, and

group

implies posixGroup-type entries.

The command-line arguments that are applicable will depend on the service specified. If unspecified, ldapugadd defaults to passwd.

Note: to be consistent with the Name Service Switch (see switch(4)), the term passwd is used to represent LDAP user entries which contain POSIX account-related information.

Arguments Applicable to -D

-D

Used to permanently alter local host defaults which are used by ldapugadd when creating new user or group entries in the LDAP directory. Configuration changes made using the -D options will appear in the /etc/opt/ldapux/ldapug.conf file. Please refer to the LDAP-UX Client Services Administrator's Guide for an example of the ldapug.conf file.

-d default_home

Specifies the parent directory that will be used when creating new user home directories.

-s default_shell

Specifies the default login shell that will be used when creating user entries.

-g default_gid

Specifies the default group ID number used when creating new user entries. To avoid warning messages displayed by ldapugadd, this group ID should represent a POSIX-style group stored in the LDAP directory.

If this group ID is not defined in the LDAP directory, ldapugadd will display a warning message every time a new user is added using this default group, since ldapugadd will be unable to add the user as a member of that group.

-g min_gid:max_gid

Sets new default minimum and maximum ranges that ldapugadd will use when provisioning a group ID number for newly created group entries. The gid range is inclusive of the specified end values. The colon character (:) will be used to indicate a range has been specified, instead of the default_gid specified above.

-u min_uid:max_uid

Sets new default minimum and maximum ranges that ldapugadd will use when provisioning an uid number for newly created user entries. The uid range is inclusive of the specified end values.

Arguments Applicable to '-t passwd'

-u uid_number

Specifies the user's numeric ID number. If the specified uidNumber already exists in the directory server, ldapugadd will not add the new entry and return an error exit status, unless the -F option is specified.

If this argument is not specified, a new user ID number will be provisioned by randomly selecting a value from the uidNumber range specified by ldapugadd -D -u. If ldapugadd randomly selects a uidNumber that is already in use on the directory server, ldapugadd will randomly select another uidNumber and try again until it finds an unused uidNumber or exhausts retry attempts. Retry attempts will be limited to 90% of the range of available uidNumbers (specified with -D -u min_uid:max_uid and described above).

-g group/gid

Specifies the user's primary login group name or id number. After creating the user entry ldapugadd will also attempt to add the user as a member of the specified group using the ldapugmod -t group command.

Note: to support numeric group names, ldapugadd will always attempt to resolve the specified argument as a group name (even if it is a numeric string). If the specified argument is not found as a group name, ldapugadd will check to see if the argument is a numeric string and if so, use that as the group ID number. If that numeric group can not be found in any active name service repository, ldapugadd will issue an ERROR message. If the specific argument is not numeric and can not be found in an active name service repository, ldapugadd will exit with an ERROR and not create the new entry.

If this argument is not specified, the user will become a member of default login group, as specified by the ldapugadd -D -g default_gid command.

-f full_name

This option is only required for the passwd service and is used to specify the user's full name. If undefined, the user's full name will default to the account name.

-x domain

Specifies the user's domain name. This variable is used to specify the ${domain} value that can be used in the template file. If this value is not specified, the domain name will be created by using the first "dc" component of the new user's distinguished name. If the distinguished name does not contain any "dc" components, and the ${domain} variable is specified in the template file, ldapugadd will generate an error.

-G group/gid[,...]

Specifies the user's alternate group memberships. group/gid is expected to be the POSIX textual name of the group or the group ID number. That group must exist in the directory server (not the /etc/group file).

If the specified group name is invalid or does not exist in the directory server, ldapugadd will issue a warning message for each invalid group. To support numeric group names, ldapugadd will always attempt to resolve the specified argument as a group name (even if it is a numeric string). If the specified argument is not found as a group name, ldapugadd will check to see if the argument is a numeric string and if so, use that as the group ID number.

After the user's entry is successfully created (and only if), ldapugadd will call ldapugmod -t group (see ldapugmod(1M)) for each group specified, to add the user to listed groups.

If more than one group is specified, each group name must be separated by a comma. No whitespace is allowed between or within group names. If ldapugadd fails to add the user as a member of a particular group, ldapugadd will issue a warning message and continue to add the user to the other remaining groups specified.

If this argument is not specified, the user will not be added to alternate groups.

-s login_shell

Specifies the full path name to the executable that will be used to handle login sessions for this user. If this argument is not specified, the default, as configured by ldapugadd -D -s default_shell, will be used.

-d home_directory

Specifies the full path name (including the user name) of the user's home directory. If this argument is not specified, the combination of the default base directory, as configured by ldapugadd -D -d default_home, and the user's account name, will be used. If you wish to also create the home directory on this system, the -m option must specified.

-I gecos

Specifies GECOS fields for the user. Typically the GECOS contains four fields which represent (in order):

  • The user's full name

  • The user's work location

  • The user's work telephone number

  • The user's home telephone number (often omitted)

Each field in the gecos should be separated by a comma. If the data within the gecos field contains any white space or other characters that might be parsed by the shell, the entire string must be protected by enclosing quotes. White space should not be used between each field and the separating commas.

Note that LDAP-UX supports mapping of the gecos field to multiple attributes. If attribute mapping has been specified in the LDAP-UX configuration profile, each field will be mapped to its representative attribute, in the order specified.

If -I is not specified, the gecos attribute(s) will not be added to the user's entry.

WARNING: If the -I option is specified and attribute mapping has been defined for the gecos attribute, be careful not to specify the same attributes in the command line that are also used in the gecos map. For example, suppose the gecos has been mapped to cn, l and telephoneNumber. Because -f below represents the cn attribute when creating new user account entries, the following command might produce unpredictable results since cn is specified by both -f and by the gecos mapping:

ldapugadd -f "Jim Smith" \

-I "Jim Smith,Boston,555-12354" \

jsmith "sn=Smith" "telePhoneNumber=555-1234"

In the above example, because of the gecos attribute mapping, the cn and telephoneNumbers are specified twice and will result an error when the same attribute and value are added to the directory server ldapcfinfo can be used to determine gecos attribute mapping configuration.

NOTE: Since the gecos attribute may be mapped to one or several attributes, the number of values specified with -I (between the commas) should, but is not required to, match the number of mapped attributes. If there are more mapped attributes than specified values in -I, then trailing mapped attributes will not be added to the directory server. If there are more values than mapped attributes, extra values will be combined in the last mapped attribute.

-c comment

Specifies a comment that will be stored in the description attribute, as defined by RFC2307. Attribute mapping is not defined for the description attribute. If unspecified, the description attribute will not be added to the user's entry. Since the comment field often contains white-space, be sure to protect it from shell parsing with enclosing quote characters.

-T template_file

Specifies the LDIF template file that will be used to create new user entries. The template_file parameter may either be a full or relative path name or a "short" name. Refer to Template File Naming below for additional information.

uid_name

Required Argument. Contains the POSIX-style textual login name for the new user entry. This user name should conform to HP-UX login name requirements. Please refer to passwd(4) for login name requirements.

uid_name is a required parameter, and it must follow all command-line options and must precede the attr=value parameters (if provided).

-m

Create a new home directory for the defined user. User and group ownership of the newly created directory will be assigned to the user and his/her primary login group.

If -k is specified, the files and sub-directories found in skel_dir will be copied to the user's home directory, and user and group ownership permissions altered as specified above. If -k is not specified, skeleton files will be copied from /etc/skel.

The -m option requires the user has sufficient privilege to create the new home directory, copy skeleton files and change ownership of those files and directories. ldapugadd will create a user's home directory only after successfully adding the user's entry in the directory server.

If ldapugadd is unable to properly create the user's home directory, per the above process, the newly created changes in the directory server will not be removed. See Security Consideration below for more information.

-k skel_dir

-k is ignored unless the -m option is specified. skel_dir specifies a directory which contains skeleton files and directories that should be copied into newly created user home directories. See -m above.

attr=value

Allows specification of arbitrary LDAP attributes and values. Because of potential objectclass requirements, additional information beyond the basic POSIX account and group data may be need to be specified in order to create new entries in the directory server.

For example, if the "InetOrgPerson" objectclass is used as a structural class for posixAccounts, then the sn (surname) attribute must be specified in order to properly create a new entry. This value would need to be defined in the template file (see Template Files), and would need to be specified at the end of the ldapugadd command line.

The attr=value parameter is generally used to specify attributes required by the template file. However, if an attribute is specified which is not defined in the defined template file, that attribute/value pair will be considered as an optional attribute/value which will be added to the entry exactly as specified.

attr=value parameters are optional, but must be specified as the last parameters on the command line.

Arguments Applicable to '-t group'

-g gid_number

Specifies the group's numeric id number. If the specified gidNumber already exists in the directory server, ldapugadd will not add the new entry and return an error exit status, unless the -F option is specified.

If this argument is not specified, a new group ID number will be provisioned by randomly selecting a value from the gidNumber range specified by ldapugadd -d -g min_gid:max_gid. If ldapugadd randomly selects a gidNumber that is already in use on the directory server, ldapugadd will randomly select another gidNumber and try again until it finds an unused gidNumber or exhausts retry attempts. Retry attempts will be limited to 90% of the range of available gidNumbers (specified with -D -g min_gid:max_gid and described above).

-x domain

Specifies the group's domain name. This variable is used to specify the ${domain} value that can be used in the template file. If this value is not specified, the domain name will be created by using the first "dc" component of the new group's distinguished name. If the distinguished name does not contain any "dc" components, and the ${domain} variable is specified in the template file, ldapugadd will generate an error.

-M member[,...]

Defines initial group membership by adding the specified user accounts as members. The members must be defined as a comma-separated list of account names, similar to the -G requirements defined above. Use of -M requires that the specified user's account already be defined in the directory server, unless the -F option is specified.

When the -F option is used, the users group membership will be defined using the memberUid attribute, regardless of the attribute mapping configuration defined by LDAP-UX. Use of -F is not recommended, and will not succeed if the directory server does not support the memberUid attribute.

ldapugadd will follow the same membership syntax as defined by LDAP-UX attribute mapping. Specifically, if LDAP-UX has mapped the RFC2307 group membership attribute (memberUid) to a DN-based membership attribute such as member or uniqueMember, then ldapugadd will define membership using the DN of the specified user. If memberUid has been mapped to more than one attribute type, ldapugadd will use the first attribute defined by the mapping.

Note that ldapugadd can only add members to a group that follow a static membership syntax (like memberUid, member, and uniqueMember). ldapugadd will fail if the only mapping defined uses a dynamic group membership syntax (like memberUrl).

-c comment

Specifies a comment that will be stored in the description attribute, as defined by RFC2307. Attribute mapping is not defined for the description attribute. If unspecified, the description attribute will not be added to the user's entry.

-T template_file

Specifies the LDIF template file that will be used to create new group entries. The template_file parameter may either be a full or relative path name or a "short" name. Refer to Template File Naming below for additional information.

group_name

Required Argument. Contains the POSIX-style textual group name for the new group entry. This name should conform to HP-UX group name requirements. Please refer to group(4) for group name requirements. gid_name is a required parameter, must follow all command-line options and must precede the attr=value parameters (if provided).

attr=value

Allows specification of arbitrary LDAP attributes and values. Refer to attr=value in the section above for additional information. attr=value parameters are optional, but must be specified as the last parameters on the command line.

Template Files

One of the benefits of LDAP directory servers is the flexibility to support customized data models to meet organizational requirements. This flexibility allows each directory deployment to define unique data models for users and groups. Because of this, it's not possible for ldapugadd to be able to create new user or group entries in the directory server and also follow the desired data model, without some description of that data model.

Template files for user and group entries allow ldapugadd to discover the required data models for new user and group entries. Template files define what data is required to create new user and group entries and allow ldapugadd to discover required attributes and data elements before creating the entries.

To explain this concept, the below examples show the default templates for a standard directory server for a passwd and group entry. Samples, such as the one below, are delivered with LDAP-UX, including samples for ADS.

Below is a sample default template for standard directory server:

dn: uid=${uid},ou=people,${basedn} objectclass: InetOrgPerson objectclass: posixAccount sn: ${Surname} ${posixProfile} dn: cn=${cn},ou=groups,${basedn} objectclass: groupOfNames objectclass: posixGroup ${posixProfile}

Below is a sample default template for Windows ADS:

dn: cn=${cn},cn=users,${basedn} objectclass: user ${posixProfile} sAMAccountName: ${uid} msSFU30NisDomain: ${domain} #By default, ldapugadd creates disabled accounts. #Change below to 544 to enable accounts by default. userAccountControl: 546 dn: cn=${cn},ou=users,${basedn} objectclass: group ${posixProfile} sAMAccountName: ${cn} msSFU30NisDomain: ${domain}

Each template file must follow the LDIF data format and also allow for substitution of values from the ldapugadd command. Two default template files (for user and group entries) for standard directory servers, along with two default template files for ADS are provided under /etc/opt/ldapux/ug_templates. The following guidelines can be used when creating template files.

  • Each template file is used for defining only one entry in the directory server.

  • Each template file may contain comment lines. Each comment line must begin with the pound (#) character.

  • Each template file can be built using custom attributes and values. Customized attribute values are defined using the ${name} construct. However, for each non-RFC2307 attribute used, when ldapugadd creates a new entry, each one of those attributes must be specified on the command line as an attr=value pair.

  • ldapugadd supports several pre-defined substitution constructs, where name is represented by:

    posixProfile

    Represents all RFC2307-type attributes and values for the particular name service (either passwd or group). If LDAP-UX has defined attribute mapping for particular attributes, the mapped attributes will be substituted in its place. When used for posixAccount-type entries, the following attributes and values will be added to the entry:

    • cn

    • uid

    • userPassword

    • uidNumber

    • gidNumber

    • gecos

    • homeDirectory

    • loginShell

    When used with posixGroup-type entries, the following attributes and values will be added to the entry:

    • cn

    • userPassword

    • gidNumber

    • memberUid

    Note: Since use of posixProfile supports attribute mapping, if the above attributes have been mapped as configured in the LDAP-UX configuration profile, the mapped attributes and values will be added to the entry instead of the RFC2307 defined attributes. For example, if the posixAccount attribute gecos has been mapped to cn l telephoneNumber then cn, l and telephoneNumber will be added to the entry instead of gecos. And for another example with posixGroups, if memberUid has been mapped to uniqueMember, then uniqueMember will be added (using the DN syntax) to the entry instead of memberUid.

    basedn

    Represents the distinguished name of the default search base (defaultSearchBase) as obtained from the LDAP-UX configuration profile.

    uid

    Represents the user's account name when used in a passwd template file.

    uidNumber

    Represents the user's account ID number when used in a passwd template file.

    cn

    Represents the user's full name when used in a passwd template file. Represents the group name when used in a group template file.

    gidNumber

    Represents the group ID number when used in a group template file.

  • The first line of the template file is used to define the distinguished name of the new entry. Since each DN is unique, the first component of the DN (the Relative Distinguished Name or RDN) must be able to construct a unique value for each new entry. Thus the RDN should be constructed using a ${name} construct. Typically the cn or uid attribute would be used in the RDN for new passwd entries and the cn attribute would be used for new group entries.

  • The userPassword attribute can not be specified in the template file. See the -PP option for additional information about specifying an initial user or group password.

  • The memberUid attribute can not be specified in the template file, since the number of eventual members of a group can not be statically defined when the group is newly created. ldapugadd will ignore the memberUid attribute if specified in the template file.

As mentioned above, for each non-pre-defined substitution construct, using the ${name}, requires specification of the name attribute and value on the ldapugadd command line. If a non-POSIX attribute is specified in the template file (such as sn) and that attribute/value pair has not been specified on the command line (attr=value), ldapugadd will return an error.

To assist with programmatic discovery of the required attributes when creating new entries, the ldapcfinfo has provided command line options to list the these attributes. ldapcfinfo -t passwd -R will display required attributes when creating new passwd entries. ldapinfo -t group -R will display required attributes when creating new group entries.

Multi-Valued Attributes in Template Files

Template files can support multi-valued attributes. This means that the same attribute name and/or value can be specified more than once in the template file. Example:

dn: uid=${uid},ou=people,${basedn} objectclass: InetOrgPerson objectclass: myOrg objectclass: posixAccount sn: ${Surname} primaryTeam: ${primaryTeam} secondaryTeams: ${secondaryTeams} secondaryTeams: ${secondaryTeams} ${posixProfile}

In the above example we assume that secondaryTeams is a multi-valued attribute which should be specified at least twice for each new posixAccount entry created. In this case, ldapugadd will fill each attribute value in order specified in the template file based on the order that those attributes are specified on the command line. Note if not enough attribute values have been specified on the command line to fill the attribute values used in the template file, ldapugadd will return an error.

Template File Naming

The default template files for new passwd and group entries are stored in /etc/opt/ldapux/ug_templates and are named ug_passwd_default.tmpl and ug_group_default.tmpl.

All template files stored in the /etc/opt/ldapux/ug_templates directory must follow a specific naming format. To allow specification of template files by their short name (see below), the template file name must begin with ug followed by the service name being supported. Underbars are used to separate sections of the name. The remainder of the name may be any keystring, followed by a .tmpl extension.

For example ug_passwd_vpn_user.tmpl might be used when creating new users of the "VPN" type. Template files stored outside of the ug_templates directory need not follow any specific format.

When specifying the name of a template file as part of the -T option on the command line, either the exact file name or a short name may be used. When specifying the file name, that name may be either a full or relative path name, but must begin with either the slash (/) or dot (.) characters. That file name may exist anywhere in the file system.

When specifying the short name, the file must exist under the /etc/opt/ldapux/ug_templates directory and must follow the format specified above. For example -t passwd -T vpn_user would be used to specify the template file mentioned above: /etc/opt/ldapux/ug_templates/ug_passwd_vpn_user.tmpl.

A short name is defined as the distinguishing portion of the template file name. For example, for the passwd service, if the short name "operator" is specified, the resulting template file would be /etc/opt/ldapux/ug_templates/ug_passwd_operator.tmpl.

All LDAP-UX default template files will be stored in the /etc/opt/ldapux/ug_templates directory.

A full or relative path name must begin with either the slash (/) or dot (.) characters. If unspecified, either of the following default template file will be used:

  • /etc/opt/ldapux/ug_templates/ug_passwd_default.tmpl, or

  • /etc/opt/ldapux/ug_templates/ug_group_default.tmpl.

Binding to the Directory Server

ldapugadd has been designed to take advantage of the existing LDAP-UX configuration for determining to which directory server to bind and how to perform the bind operation. ldapugadd will consult the LDAP-UX configuration profile for the following information:

  • The list of LDAP directory server hosts.

  • The authentication method (simple passwords, SASL Digest MD5, etc.)

If either of the environment variables LDAP_BINDDN or LDAP_BINDCRED have not been specified, ldapugadd will also consult the LDAP-UX configuration for additional information:

  • The type of credential (user, proxy or anonymous) to use.

  • The credential used for binding as a proxy user (either /etc/opt/ldapux/acred for administrative users or /etc/opt/ldapux/pcred for non-privileged users.)

As with LDAP-UX, ldapugadd will attempt to contact the first available directory server as defined in the LDAP-UX host list. As soon as a connection is established, further directory servers on the host list will not be contacted. Once connected, ldapugadd will first determine if the environment variables LDAP_BINDDN or LDAP_BINDCRED have been specified. If both are specified, then ldapugadd will attempt to bind to the directory server using the specified credentials and configured LDAP-UX authentication method.

If either of the above mentioned environment variables have not been specified, then ldapugadd will determine if the configured credential type is "proxy" and if so, attempt to bind to the directory server using the configured LDAP-UX proxy credential. If configured, the acred proxy credential will be used for administrative users (determined if the user running ldapugadd has enough privilege to read the /etc/opt/ldapux/acred file). Otherwise the credential configured in /etc/opt/ldapux/pcred will be used.

Note, to prevent discovery of the LDAP administrator's credentials, the LDAP user DN and password may not be specified as command-line options to the ldapugadd utility.

Security Considerations

  • Use of ldapugadd requires permissions of an LDAP administrator when it performs its operations on the directory server. The rights to create new LDAP directory entries under the requested subtree, along with creation of the required attributes in that entry must be granted to the LDAP administrator identity that is specified when executing ldapugadd.

  • As with any POSIX-type identity, the HP-UX operating system uses the specified user and group ID number to determine rights and capabilities in the OS as well as in the file system.

    For example, the root user ID 0, typically has unlimited OS administration and file access rights. Before creating a new entry, be aware of the selected user and group ID number and any policy that may be associated with that ID.

  • If ldapugadd is used to randomly assign a user or group ID number, it only checks for ID collisions found in the LDAP directory server, and not other policy repositories. When setting user and group ID number ranges (-D option with either -u or -g) be sure to set a range that is not used by other user or group ID repositories, to assure collisions would not occur with existing users or groups that exist in other repositories.

  • As would occur in any identity repository, modification of this repository will likely have impacts as defined by the organization's security policy. Users of ldapugadd are expected to have full knowledge of the impact to the organization's security policy when adding new identity information to that identity repository.

  • In order to support non-interactive use of the ldapugadd command, specification of the LDAP administrator's credentials is required through use of the LDAP_BINDDN and LDAP_BINDCRED environment variables. To prevent exposure of these environment variables, they should be unset after use.

    Note also that shells command history log may contain copies of the executed commands that show setting of these variables. Access to a shell's history file must be protected. Specification of the LDAP administrator's credentials on the command line is not allowed since information about the currently running processes can be exposed externally from the session.

    Use of the -P eliminates the need to set the mentioned environment variables by interactively prompting for the required credentials.

LDAP-UX PROFILE

ldapugadd makes use of the LDAP-UX configuration profile to determine the information model used in the directory server to store POSIX attributes. Please refer to the LDAP-UX Client Services Administrator's Guide for additional information about the configuration profile.

LDAP UG CONFIGURATION FILE

LDAP-UX supports a local configuration file, /etc/opt/ldapux/ldapug.conf. The ldapugadd tool uses the ldapug.conf file to manage the following default values when creating new user and group entries in an LDAP directory server:

  • A default group ID for new users

  • The valid UID number range for new users

  • The valid GID number range for new groups

  • The base path for a new user's home directory. By default, LDAP-UX appends the user's account name to the base path to create the full path name.

  • The default login shell for new users

LDAP-UX provides the default ldapug.conf file as follows:

# This file is used by the ldapugadd tool for management # of default values for creating new user and group entries. # This file can not be modified directly, but instead through # the ldapugadd -D command. # uidNumber_range=100:20000 gidNumber_range=100:2000 default_gidNumber=20 default_homeDirectory=/home default_loginShell=/usr/bin/sh

EXTERNAL INFLUENCES

Environment Variables

LDAP_UGCRED

When used in combination with the -PW option, LDAP_UGCRED specifies the password of a newly created user or group.

Note, use of passwords for groups is not recommended.

Also, if LDAP-UX attributed mapping for the userPassword attribute has not been defined or set to *NULL*, ldapugadd will create new passwords in the userPassword attribute.

LDAP_BINDDN

Specifies the DN of a user with sufficient directory server privilege to create new users and/or groups in the LDAP directory server.

While this variable is optional, if LDAP_BINDDN is specified, LDAP_BINDCRED must also be specified.

LDAP_BINDCRED

A password or other type of credential used for the user specified by the LDAP_BINDDN.

While this variable is optional, if LDAP_BINDCRED is specified, LDAP_BINDDN must also be specified.

Refer to Security Considerations for important security impacts when these environment variables are used.

RETURN VALUE

Upon exit, ldapugadd returns the following:

0

Success. ldapugadd exits with no errors or with one or more warnings.

<>0

ldapugadd returns with a non-zero exit status if it encounters an error, and messages will be logged to stderr.

Messages will follow the below format:

ERROR:

code

message

or

WARNING:

code

message

Leading extra white space may be inserted to improve readability and follow 80 column screen formatting.

code

will be a programmatically parsable error key-string, while

message

will be human-readable. Refer to the LDAP-UX Client Services Administrator's Guide for a list of possible error codes generated by the LDAP user and group management tools.

LIMITATIONS

  • Since LDAP directories require data be stored according to the UTF-8 (RFC3629) character encoding method, all characters passed into ldapugadd are assumed to UTF-8, and part of the ISO-10646 character set. ldapugadd does not perform conversion of the locale character set to/from the UTF-8 character set.

  • Since ldapugadd calls functions to discover if groups exists before adding a user to a group, it is possible to encounter timing issues with cached information. For example, if an administrator wishes to see if a group exists by using grget, this group information will be cached by both ldapclientd and pwgrd.

    If the group does not exist when calling grget, and the administrator shortly there after creates this group with ldapugadd, the information that the group still does not exist will still be cached. Then, when adding a new user and specifying that this user is a member of the just created group, an error will be generated to indicate the user can not be added to the group. To resolve this, the pwgrd and ldapclientd caches must be flushed.