Running ldapaddent

Running `ldapaddent`

Before you can start using LDAP as your naming server, you need to populate it with your current NIS or NIS+ data. Solaris 9 OE and the Solaris 8 OE backport provides a utility for doing this called ldapaddent(1M) . Before running this command, you should make sure your source files are cleaned up as described in Chapter 2 "Assessing Your Needs for Naming Service Transition and Consolidation." You also need to be a native LDAP client of the server for which you are importing data. This is so you can use the authentication methods and encrypted data channel you have set up for clients .

A system running the directory service cannot be its own client; therefore, two systems are required to run ldapaddent . One system would run the directory service and the other system that is configured as a client uses the directory service. This might be inconvenient because you may want to configure your clients after the server is populated .

You can cheat a little by temporarily configuring your directory server as its own client, then reverting back to the original configuration. A word of caution: It is very important that a reboot does not occur while the server is configured as its own client, because the server will hang. You should also be aware that after the server is initialized as an LDAP naming service client, you will not be able to access the previous naming service data. For example, if you are using DNS to resolve host addresses, you need to re-initialize DNS.

Supported Databases

The command ldapaddent creates entries in LDAP containers from their corresponding /etc files. This operation is customized for each of the standard databases that are used in the administration of Solaris OE systems. The databases include:

aliases
auto_*
bootparams
ethers
group
hosts
netgroup
netmasks
networks
passwd
shadow
protocols
publickey
rpc
services

By default, ldapaddent reads from the standard input, then adds this data to the LDAP container associated with the database specified on the command line. An input file from which data can be read is specified using the -f option.

The entries are stored in the directory based on the client's configuration, thus the client must be configured to use LDAP naming services. The location where entries are to be written can be overridden by using the -b option. If the entry to be added exists in the directory, the command displays an error and exits, unless the -c option is used.

Even though there is a shadow database, there is no corresponding shadow container. Both the shadow and the passwd data is stored in the ou=people container. Similarly, data from the networks and netmasks databases is stored in the networks container.

You must add entries from the passwd database before you attempt to add entries from the shadow database. The addition of a shadow entry that does not have a corresponding passwd entry will fail.

For better performance, the recommended order in which the databases should be loaded is as follows :

passwd database, followed by shadow database
networks database, followed by netmasks database
bootparams database, followed by ethers database

Note

Only the first entry of a given type that is encountered will be added to the LDAP server. The ldapaddent command skips any duplicate entries.

Authentication Options

The ldapaddent command supports a wide range of authentication options when the -a switch is specified. These include:

simple
SASL DIGEST-MD5
TLS SIMPLE
TLSv1 SASL/DIGEST-MD5

Selecting simple causes passwords to be sent over the network in clear text, and therefore its use is strongly discouraged. Additionally, if the client is configured with a profile which uses no authentication, that is, either the credentialLevel attribute is set to anonymous or authenticationMethod is set to none , the user must use this option to provide an authentication method.

Binding to the Directory Server

The -b base DN option creates entries in the baseDN directory. baseDN is not relative to the client's default search base, but rather, it is the actual location where the entries will be created. If this parameter is not specified, the first search descriptor defined for the service, or the default container will be used.

The -D bindDN creates an entry which has write permission to the baseDN. When used with the -d option, this entry only requires read permission. The -w bind_password option is used for authenticating the bindDN . If this parameter is missing, the command will prompt for a password. NULL passwords are not supported in LDAP. When you use -w bind_password to specify the password for authentication, the password is visible to other users of the system by means of the ps command, in script files, and in shell history.

Examples Using `ldapaddent`

Example 1: Adding password entries to the directory server:

 #  ldapaddent -a simple -D "cn=directory manager" -w mysecret -f   /etc/passwd passwd

Example 2: Adding group entries:

The following example shows how to add group entries to the directory server using sasl/DIGEST-MD5 as the authentication method.

 #  ldapaddent -D "cn=directory manager" -w mysecret -a   "sasl/DIGEST-MD5" -f /etc/group group

Example 3: Adding auto_master entries:

The following example shows how to add auto_master entries to the directory server:

 #  ldapaddent -a simple -D "cn=directory manager" -w mysecret -f /etc/auto_master auto_master

Example 4: Dumping password entries from the directory to a file:

The ldapaddent command can be used to extract LDAP entries and to create equivalent /etc file format by specifying the -d option. The following example shows how to dump password entries from the directory to a file called passwd.file .

 #  ldapaddent -d passwd > passwd.file

Default Entry Formats

The following are examples of entries created by the ldapaddent command.

`passwd` and `shadow` Database Entry Example

 dn: uid=tsmith,ou=people,dc=example,dc=com objectClass: posixAccount objectClass: shadowAccount objectClass: account objectClass: top uid: tsmith cn: Tom Smith uidNumber: 31932 gidNumber: 10 gecos: Tom Smith homeDirectory: /home/tsmith loginShell: /bin/csh userPassword: {crypt}1QfftqDbJHUQQ shadowLastChange: shadowMin: shadowMax: shadowWarning: shadowInactive: shadowExpire: shadowFlag: description:

In this example the entry was created from a file generated from existing NIS maps. For example:

 #  ypcat passwd > passwd.file

The -p option is specified with the ldapaddent command to instruct it to get the password from the input file and not the /etc/shadow file. This is why the shadow* attributes are blank. If the shadow database was used, the shadow* attributes would look like this:

 shadowLastChange: 12138 shadowMin: 30 shadowMax: 180 shadowWarning: 10 shadowInactive: 90 shadowExpire: 12157 shadowFlag: 0

From these examples you can see that uid is used as the naming attribute and account is used as a structural object class to which the posixAccount and shadowAccount auxiliary object classes were added. The gecos attribute is populated from the GECOS field, but there are no commonName(cn) or description attribute values assigned. The password is always stored in UNIX crypt.

It is very likely you would want to extend the user entries beyond what ldapaddent creates for you. Instructions for doing so can be found in Chapter 7 "Performing Administrative Tasks."

`group` Database Entry Example

 dn: cn=einsteins,ou=group,dc=example,dc=com objectClass: posixGroup objectClass: top cn: einsteins gidNumber: 8199 memberUid: rperry memberUid: dmahoney memberUid: dam userPassword: {crypt}XT0vcJvEWY

The DN for these entries uses the cn attribute that defines the name of the group. The password for the group is defined by the userPassword attribute. If the password field contains an asterisk ( * ), it is stored in the password storage scheme for which the directory server is set.

`hosts` Database Entry Example

 dn: cn=xer33a4b+ipHostNumber=10.10.181.22,ou=Hosts,dc=example,dc=com objectClass: ipHost objectClass: device objectClass: top cn: xer33a4b cn: np-ubur03-11 cn: ubur03-11 cn: bur311 cn: bur313 ipHostNumber: 10.10.181.22

The DN for hosts entries contains two naming attributes: cn and ipHostNumber . The reason for this is that a system that has multiple network interfaces, sometimes referred to as multi- homed , might use the same host name with different IP addresses for different interfaces. If only the cn attribute that defines the canonical host name was used, conflict would occur. If a hosts entry has one or more aliases defined, they are specified by additional cn attributes.

`automount` Database Entry Examples

 dn: cn=tcool,nismapname=auto_home,dc=example,dc=com objectClass=nisObject objectClass=top cn=tcool nisMapEntry=hosta:/export/home/tcool2

This entry was created by running ldapaddent on a client that was initialized with a Version 1 profile ( objectclass=SolarisNamingProfile ). You can tell this because the nisObject object class is specified in the entry. If the client running ldapaddent was configured with a Version 2 profile ( objectclass= DUAconfigProfile ), the automountMap object class would be specified in the entry.

The following examples assume the client is configured with a Version 2 profile.

 dn: automountMapName=auto_home,dc=example,dc=com automountMapName: auto_home objectClass: top objectClass: automountMap dn: automountMapName=auto_direct,dc=example,dc=com automountMapName: auto_direct objectClass: top objectClass: automountMap dn: automountMapName=auto_master,dc=example,dc=com automountMapName: auto_master objectClass: top objectClass: automountMap dn: automountMapName=auto_shared,dc=example,dc=com automountMapName: auto_shared objectClass: top objectClass: automountMap

These entries represent the top-level containers for the standard automount maps. The following examples show what the entries look like below one of the top-level containers. In this case, the auto_master container is examined.

 dn: automountKey=/net,automountMapName=auto_master,dc=example,dc=com objectClass: automount objectClass: top automountKey: /net automountInformation: -hosts -nosuid,nobrowse dn: automountKey=/home,automountMapName=auto_master,dc= example,dc=com objectClass: automount objectClass: top automountKey: /home automountInformation: auto_home -nobrowse dn: automountKey=/xfn,automountMapName=auto_master,dc=example,dcom objectClass: automount objectClass: top automountKey: /xfn automountInformation: -xfn dn: automountKey=/tools,automountMapName=auto_master,dc= example,dc=com objectClass: automount objectClass: top automountKey: /tools automountInformation: auto_tools        -intr,nosuid,nobrowse

This example defines the standard /net, /home , and /xfn automaps. In addition, a custom map called /tools is shown. The /tools map contains entries that look like this:

 dn: automountKey=pricebooks,automountMapName=auto_tools,dc= example,dc=com objectClass: automount objectClass: top automountKey: pricebooks automountInformation: salesdesk:/home1/hardware_data/pricebooks dn: automountKey=networker,automountMapName=auto_tools,dc= example,dc=com objectClass: automount objectClass: top automountKey: networker automountInformation: sundries:/export/home3/networker dn: automountKey=upgrades,automountMapName=auto_tools,dc= example,dc=com objectClass: automount objectClass: top automountKey: upgrades automountInformation: crimson-tide:/upgrades

`ethers` Database Entry Example

 dn: cn=eelab14,ou=ethers,dc=example,dc=com objectClass: ieee802Device objectClass: top cn: eelab14 macAddress: 8:0:20:1:2:3

Note

The cn attribute used by ldapaddent to create this entry has been removed from the RFC 2307 schema defined in the Sun ONE Directory Server 5.2 software 11rfc2307.ldif file.

`bootparams` Database Entry Example

 dn: cn=hostb,ou=ethers,dc=example,dc=com objectClass: bootableDevice objectClass: top cn: hostb bootParameter: hostb bootParameter: root= hosta:/export/home/s9_1202/Solaris_9/Tools/Boot bootParameter: install=hosta:/export/home/s9_1202 bootParameter: boottype=:in bootParameter: rootopts=:rsize=32768

Note

The cn attribute used by ldapaddent to create this entry has been removed from the RFC 2307 schema defined in the Sun ONE Directory Server 5.2 software 11rfc2307.ldif file.

`alias` Database Entry Example

 dn: cn=postmaster,ou=aliases,dc=example,dc=com objectClass: mailGroup objectClass: top mail: postmaster mgrpRFC822MailMember: root cn: postmaster

`publickey` Database Entry Example

 dn: cn=eelab14+ipHostNumber=129.148.181.216,ou=Hosts,dc= example,dc=com objectClass: ipHost objectClass: device objectClass: top objectClass: NisKeyObject cn: eelab14 ipHostNumber: 129.148.181.216 nisPublickey: {DES}c8d350d3dbb0fd2c3a00c512572706656e9feb0d5647d 354 nisSecretkey: {DES}4c099ef5f415947efd1cbb3da6a4939425f8bc1db5cfc c30722c735ba9ca101c

This is an example of what a public key for a computer would look like. In this case the NisKeyObject object class is added to the host entry.

In the following example, a public key is added to a user entry.

 dn: uid=tsmith,ou=people,dc=example,dc=com objectClass: posixAccount objectClass: shadowAccount objectClass: account objectClass: top objectClass: NisKeyObject uid: tsmith cn: Tom Smith uidNumber: 3193 gidNumber: 10 gecos: Tom Smith homeDirectory: /home/tsmith loginShell: /bin/csh shadowLastChange: shadowMin: shadowMax: shadowWarning: shadowInactive: shadowExpire: shadowFlag: description: nisPublickey: {dh192-0}36253a65eca 220c00c4db49d2dbc994919cba07 0512984f7 nisSecretkey: {dh192-0}f9c50e98c03f58999aeeb55086868a67bdd8c559 49d72538e69da24a07f2de6d

The public key could also be added with the newkey command:

 #  newkey -u tsmith -s ldap  Adding new key for unix.3193@example.com Enter tsmith's password:  *******  #

Note

The authentication method used by the newkey command is the same as login, unless it is overridden with the serviceAuthenticationMethod attribute.