RHCA Study Notes

Migrate NIS users and groups into LDAP

2012-09-13T08:06:00.000-07:00

yum install openldap-servers

cd /usr/share/openldap/migration

run the migration scripts

verify document signatures

2012-09-12T08:52:00.001-07:00

Verify the signature
#gpg --output document --decrypt document.sig

sign documents

2012-09-12T08:48:00.001-07:00

Sign the document
#gpg --output document.sig --sign document

decrypt documents

2012-09-12T08:42:00.001-07:00

Decrypt a document

#gpg --output document --decrypt document.gpg

encrypt documents

2012-09-12T08:38:00.003-07:00

To encrypt you will need to have the persons public key available to you so you can import it

#gpg --import public-key.gpg

Encrypt a document

#gpg --output document.gpg --encrypt --recipient username@example.com document

generate key pairs

2012-09-12T08:18:00.001-07:00

Generate the key pairs using the following command
#gpg --gen-key

use the Real-time Blackhole List (RBL) via DNS

2012-09-11T13:48:00.001-07:00

Sendmail

Edit /etc/mail/sendmail.mc and add

FEATURE(`dnsbl', `dnsbl.example.com', `you have been rejected mofo')dnl

#make -C /etc/mail

#service sendmail restart

Postfix

#postconf -e "smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_rbl_client dnsbl.example.com"

#service postfix restart

blackhole lists (RBL)

2012-09-11T13:40:00.001-07:00

Blackhole list

blackhole { address_match_list };

blackhole defines a address_match_list of hosts that the server will NOT respond to, or answer queries for. The default is 'none' (all hosts are responded to). This statement may only be used in a global options clause.

Blackhole Zone

Create a new master zone called dnsbl.example.com and edit it so it looks like this

$TTL 1H
@ SOA auth1.example.com. root.auth1.example.com. ( 2
3H
1H
1W
1H )
IN NS auth1.example.com.
IN A 172.16.118.136
128.25.168.192 IN A 127.0.0.2
IN TXT "Spam MOFO"

Add entries like the one in red for all of the spam sources

filter mail based on message characteristics

2012-09-10T13:28:00.001-07:00

Postfix

The following can be used for filtering
/etc/postfix/access
/etc/postfix/header_checks

Sendmail

use TLS for secure communication

2012-09-10T12:14:00.001-07:00

You can use the ca created in configure a certificate authority (CA) and sign certificate requests

Postfix

Create the SSL directory

#mkdir /etc/postfix/ssl

##cd /etc/postfix/ssl

Create the Key and Request

#openssl req -new -nodes -keyout client.example.com.key -out mail.example.com.csr

Sign the Request

#cp mail.example.com.csr /etc/pki/tls/misc/newreq.pem

#cd /etc/pki/tls/misc/

#./CA.pl -sign

Copy cert to SSL dir

#cp newcert.pem /etc/postfix/ssl/mail.example.com.crt

Copy the cacert

#cp /etc/pki/CA/cacert.pem ssl/

Use postconf to configure TSL settings

#postconf -e "smtpd_use_tls = yes"

#postconf -e "smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem"

#postconf -e "smtpd_tls_cert_file = /etc/postfix/ssl/mail.example.com.crt"

#postconf -e "smtpd_tls_key_file = /etc/postfix/ssl/mail.example.com.key"

Restart postfix

#service postfix restart

Sendmail

Install sendmail-mc
#yum install sendmail-mc -y

Create the SSL directory

#mkdir /etc/mail/ssl

##cd /etc/mail/ssl

Create the Key and Request

#openssl req -new -nodes -keyout client.example.com.key -out mail.example.com.csr

Update permissions on the key file
#chmod 400 mail.example.com.key

Sign the Request

#cp mail.example.com.csr /etc/pki/tls/misc/newreq.pem

#cd /etc/pki/tls/misc/

#./CA.pl -sign

Copy cert to SSL dir

#cp newcert.pem /etc/mail/ssl/mail.example.com.crt

Update sendmail config
#cd /etc/mail

Edit sendmail.mc and add the following

define(`confCACERT_PATH', `/etc/mail/ssl')dnl
define(`confCACERT', `/etc/pki/CA/cacert.pem')dnl
define(`confSERVER_CERT', `/etc/mail/ssl/auth1.example.com.crt')dnl
define(`confSERVER_KEY', `/etc/mail/ssl/auth1.example.com.key')dnl

Update sendmail

#make -C .

Restart sendmail

#service sendmail restart

TSIG

2012-09-09T03:48:00.001-07:00

Configure TSIG for zone transfers

On the master

Create the key
#dnssec-keygen -a HMAC-MD5 -b 128 -n HOST master-slave

Get the key value
#cat Kmaster-slave*key
master-slave. IN KEY 512 3 157 ts7byllvrX5r4Il3t177Ug==

Create a key file to include in named.conf
#vim master-slave.key

key master-slave {
algorithm hmac-md5;
secret ts7byllvrX5r4Il3t177Ug==;
};

Change the permissions on the file
#chmod 640 master-slave.key
#chown :named master-slave.key

Link to /etc if in chroot
#ln -s /var/named/chroot/etc/master-slave.key /etc/master-slave.key

Make sure the key has the correct context
#chcon master-slave.key --reference rndc.key

Update named.conf so that the key is included by adding the following
include "/etc/master-slave.key";

Configure the server to allow transfers using the key

allow-transfer { key master-slave; };

Restart the named service on the master
#service named restart

On the slave

Create a key file to include in named.conf
#vim master-slave.key

key master-slave {
algorithm hmac-md5;
secret ts7byllvrX5r4Il3t177Ug==;
};

Add the master server in and configure to use the required key

server SERVERIP {

keys master-slave;

};

Restart bind

#service named restart

Testing

You can use the dig command to test zone transfers

Without tsig

#dig @MASTERIP example.com axfr

With tsig

dig -y master-slave:ts7byllvrX5r4Il3t177Ug== @MASTERIP example.com axfr

master domain

2012-09-09T02:20:00.001-07:00

Use /usr/share/doc/bind-*/sample/etc/named.conf to see examples of configuration

Install the bind packages
#yum install bind-chroot system-config-bind -y

Run the bind configuration utility which will create the config files for you.
#system-config-bind

Create a new master zone

configure httpd to use passwords and/or network location to restrict access to content

2012-09-05T11:44:00.001-07:00

Install apache
#yum install httpd -y

#######################################################################
USING PASSWORDS TO RESTRICT ACCESS
#######################################################################

Edit the apache config

#vim /etc/httpd/conf/httpd.conf

AllowOverride Authconfig

</Directory>

Create the protected area

#mkdir /var/www/html/protected
#echo "Only authorised personal can see this" > /var/www/html/protected/index.html

Use htpasswd to create an auth file
#htpasswd -c -m /var/www/userfile username

Create the following file with the following config
#vim /var/www/html/protected/.htaccess

AuthName "Access to protected area"
AuthType Basic
AuthUserFile /var/www/userfile
require valid-user

Restart apache

#service httpd restart

You should then be prompted when you try and access http://servername/protected

#######################################################################
USING NETWORK LOCATION TO RESTRICT ACCESS
#######################################################################

Edit the apache config

#vim /etc/httpd/conf/httpd.conf

Directory "/var/www/html/protected">

Order allow,deny

Allow from .example.com

Deny from All

</Directory>

Restart apache

#service httpd restart

configure httpd to use a SSL certificate signed by a certifying authority

2012-09-04T13:56:00.001-07:00

You will need to use the CA created using configure-certificate-authority-ca

Install apache and mod_ssl packages
#yum install httpd mod_ssl -y

Create a key
#openssl genrsa -out server.example.com.key 1024

Create a certificate signing request
#openssl req -new -key server.example.com.key -out server.example.com.csr

Sign the certificate with the CA
#cp server.example.com.csr /etc/pki/CA/newreq.pem
#/etc/pki/tls/misc/CA.pl -sign

Copy the signed cert somewhere into the /var/www tree somewhere or make sure that it has the correct security context
#mkdir /var/www/certs
#mv /etc/pki/CA/newreq.pem /var/www/certs/server.example.com.crt
#mv server.example.com.key /var/www/certs/server.example.com.key

Edit /etc/httpd/conf.d/ssl.conf

SSLCertificateFile /var/www/certs/server.example.com.cert
SSLCertificateKeyFile /var/www/certs/server.example.com.key

Restart apache
#service httpd restart

Test connection!

configure a certificate authority (CA) and sign certificate requests

2012-09-04T13:52:00.001-07:00

Install the perl openssl package
# yum install openssl-perl

Change to the directory where the CA.pl script is located
# cd /etc/pki/tls/misc/

Create the CA
# ./CA.pl -newca

Make the CA Certificate available using http or some other method.

Configure POP/IMAP to use SSL/TLS for secure communication

2012-09-04T13:17:00.001-07:00

This needs to be done after creating the certificate authority

#yum install dovecot -y

Edit /etc/dovecot.conf to allow on the protocols you require by changing the protocols value

Edit /etc/pki/dovecot/dovecot-openssl.cnf with the relevant information

Delete the old certificates

#rm /etc/pki/dovecot/private/dovecot.pem

#rm /etc/pki/dovecot/certs/dovecot.pem

Run the mkcert script
#/usr/share/doc/dovecot-1.0.7/examples/mkcert.sh

Restart dovecot
#service dovecot restart

Open the required ports on the firewall

ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:imaps
ACCEPT udp -- anywhere anywhere state NEW udp dpt:imaps
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:pop3s
ACCEPT udp -- anywhere anywhere state NEW udp dpt:pop3s

You can test this using mutt, copy the ca certificate to the .mutt directory in the users home directory and run mutt

#mutt -f imaps://user@server

Check the maillog of the server

Sep 4 13:32:40 auth1 sendmail[6037]: q84KWdRd006036: to=<adam@auth1.example.com>, ctladdr=<root@auth1.example.com> (0/0), delay=00:00:01, xdelay=00:00:00, mailer=local, pri=30529, dsn=2.0.0, stat=Sent

Sep 4 13:34:02 auth1 dovecot: imap-login: Login: user=<user>, method=PLAIN, rip=::ffff:172.16.118.135, lip=::ffff: TLS

implement host based access restrictions

2012-09-03T12:17:00.001-07:00

Use tcp wrappers or iptables

support FTP only users

2012-09-02T08:15:00.001-07:00

use the nolgin shell

configure NFSv4 server

2012-08-21T12:48:00.001-07:00

You need to use the nohide option when using gss/krb5 to see anything that was mounted using bind

/exports gss/krb5p(rw,sync,fsid=0,no_subtree_check)
/exports/home gss/krb5p(rw,sync,nohide,no_subtree_check)

configure Kerberos to provide user authentication

2012-08-16T12:19:00.001-07:00

Install kerberos server packages

[root@auth1 /]# yum install krb5-server

Add the following rules to iptables

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 88 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 88 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 464 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 464 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 749 -j ACCEPT

Edit the kdc conf file

[root@auth1 /]# vim /var/kerberos/krb5kdc/kdc.conf

[kdcdefaults]

v4_mode = nopreauth

kdc_tcp_ports = 88

[realms]

auth1.EXAMPLE.COM = {

#master_key_type = des3-hmac-sha1

default_priniciple_flags = +preauth

acl_file = /var/kerberos/krb5kdc/kadm5.acl

dict_file = /usr/share/dict/words

admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab

supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal des-cbc-crc:v4 des-cbc-crc:afs3

}

Initialise the database

[root@auth1 /]# kdb5_util create

Log in as kadmin.local and create the princs

[root@auth1 /]# kadmin.local

configure an NIS server to provide directory services

2012-08-14T12:08:00.001-07:00

[root@ds1 ~]# yum install ypserv

[root@ds1 ~]# chkconfig portmap on

add the following to iptables

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 111 -j ACCEPT

-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 111 -j ACCEPT

add the following to /etc/sysconfig/network

YPSERV_ARGS="-p 841"

add the following to iptables

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 808 -j ACCEPT

-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 808 -j ACCEPT

Set the NIS domain name

[root@auth1 ~]# nisdomainname NISDOMAINNAME

Start NIS

[root@auth1 ~]# service ypserv start

Initialise maps

[root@auth1 /]# /usr/lib/yp/ypinit -m

check access to maps

[root@client ~]# ypcat -d auth1.example.com -h auth1.example.com passwd

Lock down using securenets

[root@auth1 /]# vim /var/yp/securenets

SUBNETMASK NETWORKADDRESS

Authenticate to the Directory Server using kerberos

2012-03-17T04:50:00.002-07:00

7.12. Using Kerberos GSS-API with SASL

Kerberos v5 must be deployed on the host for Directory Server to utilize the GSS-API mechanism for SASL authentication. GSS-API and Kerberos client libraries must be installed on the Directory Server host to take advantage of Kerberos services.

7.12.1. Authentication Mechanisms for SASL in Directory Server

Directory Server support the following SASL encryption mechanisms:

EXTERNAL. EXTERNAL, as with TLS/SSL, performs certificate-based authentication. This method uses public keys for strong authentication.
CRAM-MD5. CRAM-MD5 is a simple challenge-response authentication method. It does not establish any security layer, unlike GSS-API. Both DIGEST-MD5 and GSS-API are much more secure, so both of those methods are recommended over CRAM-MD5.
DIGEST-MD5. DIGEST-MD5 is a mandatory authentication method for LDAPv3 servers. While it is not as strong as public key systems or Kerberos authentication methods, it is preferred over plain text passwords and does protect against plain text attacks.
Generic Security Services (GSS-API). Generic Security Services (GSS) is a security API that is the native way for UNIX-based operating systems to access and authenticate Kerberos services. GSS-API also supports session encryption, similar to TLS/SSL. This allows LDAP clients to authenticate with the server using Kerberos version 5 credentials (tickets) and to use network session encryption.

For Directory Server to use GSS-API, Kerberos must be configured on the host machine. See Section 7.12, “Using Kerberos GSS-API with SASL”.

NOTE

GSS-API and, thus, Kerberos are only supported on platforms that have GSS-API support. To use GSS-API, it may be necessary to install the Kerberos client libraries; any required Kerberos libraries will be available through the operating system vendor.

CRAM-MD5, DIGEST-MD5, and GSS-API are all shared secret mechanisms. The server challenges the client attempting to bind with a secret, such as a password, that depends on the mechanism. The user sends back the response required by the mechanism.

NOTE

DIGEST-MD5 requires clear text passwords. The Directory Server requires the clear text password in order to generate the shared secret. Passwords already stored as a hashed value, such as SHA1, cannot be used with DIGEST-MD5.

7.12.2. About Kerberos in Directory Server

On Red Hat Enterprise Linux, the supported Kerberos libraries are MIT Kerberos version 5.

The concepts of Kerberos, as well as using and configuring Kerberos, are covered at the MIT Kerberos website,http://web.mit.edu/Kerberos/.

7.12.2.1. About Principals and Realms

A principal is a user in the Kerberos environment. A realm is a set of users and the authentication methods for those users to access the realm. A realm resembles a fully-qualified domain name and can be distributed across either a single server or a single domain across multiple machines. A single server instance can also support multiple realms.

NOTE

Kerberos realms are only supported for GSS-API authentication and encryption, not for DIGEST-MD5.

Realms are used by the server to associate the DN of the client in the following form, which looks like an LDAP DN:

uid=user_name/[server_instance],cn=realm,cn=mechanism,cn=auth

For example, Mike Connors in the engineering realm of the European division of example.com uses the following association to access a server in the US realm:

uid=mconnors/cn=Europe.example.com,cn=engineering,cn=gssapi,cn=auth

Babara Jensen, from the accounting realm of US.example.com, does not have to specify a realm when to access a local server:

uid=bjensen,cn=accounting,cn=gssapi,cn=auth

If realms are supported by the mechanism and the default realm is not used to authenticate to the server, then the realm must be specified in the Kerberos principal. Otherwise, the realm can be omitted.

NOTE

Kerberos systems treat the Kerberos realm as the default realm; other systems default to the server.

7.12.2.2. About the KDC Server and Keytabs

Kerberos is a protocol which allows users or servers to authenticate to a server securely over an insecure connection. As with protocols like TLS and SSL, Kerberos generates and issues session keys which encrypt information. A Kerberos server, then, has two functions: as an authenticating server to validate clients and as a ticket granting server.

Because of this, the Kerberos server is called a key distribution center or KDC.

See the operating system documentation for information on installing and configuring a Kerberos server.

When a client authenticates to the Directory Server using GSS-API, the KDC sends a session key, followed by a ticket granting ticket (TGT). The TGT contains the client's ID and network address, a validity period, and the session key. The ticket and the ticket's lifetime are parameters in the Kerberos client and server configuration. In many systems, this TGT is issued to the client when the user first logs into the operating system.

Command-line utilities provided with the operating system — including kinit, klist, and kdestroy — can acquire, list, and destroy the TGT. These tools usually use a file called a keytab to the issued keys. This file is created by the Kerberos administrator by exporting the key from the KDC.

In order to respond to Kerberos operations, the Directory Server requires access to its own cryptographic key. The Kerberos key is written in the keytab file. The keytab gives the credentials that the Directory Server uses to authenticate to other servers. Directory Server assigns a keytab through the KRB5_KTNAME environment variable in its startup script (/etc/sysconfig/dirsrv):

KRB5_KTNAME=/etc/dirsrv/ds.keytab ; export KRB5_KTNAME

NOTE

The Directory Server must be able to access the host keytab and the krb5.conf file for GSS-API authentication in SASL. For this host keytab file to be properly labeled in SELinux in the dirsrv_config_tcontext, the file must be in the /etc directory.

Only the host keytab and krb5.conf must be in /etc. The user key tabs can still be in any directory.

When the Directory Server authenticates to the server, it is as if it is running a kinit command to initiate the connection:

kinit -k -t /etc/dirsrv/ds.keytab ldap/FQDN@REALM

The Directory Server uses the service name ldap. Its Kerberos principal is ldap/host-fqdn@realm, such as ldap/ldap.corp.example.com/EXAMPLE.COM. The host-fqdn must be the fully-qualified host and domain name, which can be resolved by all LDAP and Kerberos clients through both DNS and reverse DNS lookups. A key with this identity must be stored in the server's keytab in order for Kerberos to work.

Whatever server the Directory Server is authenticating to must have a SASL mapping that maps the Directory Server's principal (its user entry, usually something like ldap/server.example.com@EXAMPLE.COM) to a real entry DN in the receiving server.

On Red Hat Enterprise Linux, the client-side Kerberos configuration is in the /etc/krb5.conf.

NOTE

The Directory Server must be able to access the krb5.conf file for GSS-API authentication in SASL. For these files to be properly labeled in SELinux in the dirsrv_config_t context, the file must be in the /etcdirectory.

For information on setting up the service key, see the Kerberos documentation.

Example 7.4, “KDC Server Configuration” shows a KDC server configured with the company.example.com realm.

Example 7.4. KDC Server Configuration

[libdefaults] 
     ticket_lifetime = 24000 
     default_realm = COMPANY.EXAMPLE.COM 
     dns_lookup_realm = false 
     dns_lookup_kdc = false 
     ccache_type = 1 
     forwardable = true 
     proxiable = true 
     default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc 
     default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc 
     permitted_enctypes = des3-hmac-sha1 des-cbc-crc 
[realms] 
  COMPANY.EXAMPLE.COM = { 
     kdc = kdcserver.company.example.com:88 
     admin_server =adminserver.company.example.com:749 
     default_domain = company.example.com 
  } 
[appdefaults] 
  pam = { 
     debug = true 
     ticket_lifetime = 36000 
     renew_lifetime = 36000 
     forwardable = true 
     krb4_convert = false 
  } 
[logging] 
  default = FILE:/var/krb5/kdc.log 
  kdc = FILE:/var/krb5/kdc.log 
  admin_server = FILE:/var/log/kadmind.log

7.12.3. Configuring SASL Authentication at Directory Server Startup

SASL GSS-API authentication has to be activated in Directory Server so that Kerberos tickets can be used for authentication. This is done by supplying a system configuration file for the init scripts to use which identifies the variable to set the keytab file location. When the init script runs at Directory Server startup, SASL authentication is then immediately active.

The default SASL configuration file is in /etc/sysconfig/dirsrv.

If there are multiple Directory Server instances and not all of them will use SASL authentication, then there can be instance-specific configuration files created in that directory named dirsrv-instance. For example, dirsrv-example. The default dirsrv file can be used if there is a single instance on a host.

To enable SASL authentication, uncomment the KRB5_KTNAME line in the /etc/sysconfig/dirsrv (or instance-specific) file, and set the keytab location for the KRB5_KTNAME variable. For example:

# In order to use SASL/GSSAPI the directory
# server needs to know where to find its keytab
# file - uncomment the following line and set
# the path and filename appropriately
KRB5_KTNAME=/etc/dirsrv/krb5.keytab ; export KRB5_KTNAME

7.12.4. Using an External Keytab

A default keytab file is specified in the Directory Server start script and is used by the Directory Server automatically. However, it is possible to specify a different keytab file, referencing a different principal, by manually running kinit and then specifying the cached credentials.

To specify the cached kinit credentials, add the principal as the KRB5CCNAME line in /etc/sysconfig/dirsrv:

KRB5CCNAME=/tmp/krb_ccache ; export KRB5CCNAME
kinit principalname   
# how to provide the password here is left as an exercise
# or kinit -k -t /path/to/file.keytab principalname
chown serveruid:serveruid $KRB5CCNAME 
# so the server process can read it
# start a cred renewal "daemon"
( while XXX ; do sleep NNN ; kinit ..... ; done ) &
# the exit condition XXX and sleep interval NNN are left as an exercise
...

The server has no way to renew these cached credentials. The kinit process must be run manually, external to Directory Server processes, or the server could begin receiving SASL bind failures when the server attempts to use expired credentials.

Import user information from an LDIF file

2011-11-13T04:09:00.000-08:00

Importing Data

Directory Server provides three methods for importing data:

Import from the Directory Server Console. Use the Directory Server Console to append data to all of the databases, including database links.
Initialize databases. The Directory Server Console can import data to one database; this method overwrites any data contained by the database.
Importing data from the command-line. Directory Server provides command-line utilities to import data.

NOTE

The LDIF files used for import operations must use UTF-8 character set encoding. Import operations do not convert data from local character set encoding to UTF-8 characterset encoding.

Table 4.1, “Import Method Comparison” describes the differences between an import and initializing databases.

Action	Import	Initialize Database
Overwrites database	No	Yes
LDAP operations	Add, modify, delete	Add only
Performance	More time-consuming	Fast
Partition speciality	Works on all partitions	Local partitions only
Response to server failure	Best effort (all changes made up to the point of the failure remain)	Atomic (all changes are lost after a failure)
LDIF file location	Local to Console	Local to Console or local to server
Imports configuration information (`cn=config`)	Yes	No

Table 4.1. Import Method Comparison

The following sections describe importing data:

CAUTION

All imported LDIF files must also contain the root suffix.

Importing a Database from the Console

When performing an import operation from the Directory Server Console, an ldapmodify operation is executed to append data, as well as to modify and delete entries. The operation is performed on all of the databases managed by the Directory Server and on remote databases to which the Directory Server has a configured database link.
You must be logged in as the Directory Manager in order to perform an import.
To import data from the Directory Server Console, do the following:

In the Directory Server Console, select the Tasks tab. Scroll to the bottom of the screen, and selectImport Database.
Alternatively, import by going to the Configuration tab and selecting Import from the Console menu.
In the Import Database dialog box, enter the full path to the LDIF file to import in the LDIF file field, or click Browseto select the file to import.
If the Console is running on a machine remote to the directory, the field name appears asLDIF file (on the machine running the Console). When browsing for a file, you are not browsing the current directory for the Directory Server host, but the filesystem of the machine running the Console.
In the Options box, select one or both of the following options:
- Add Only. The LDIF file may contain modify and delete instructions in addition to the default add instructions. For the server to ignore operations other than add, select the Add only checkbox.
- Continue on Error. Select the Continue on error checkbox for the server to continue with the import even if errors occur. For example, use this option to import an LDIF file that contains some entries that already exist in the database in addition to new ones. The server notes existing entries in the rejects file while adding all new entries.
In the File for Rejects field, enter the full path to the file in which the server is to record all entries it cannot import, or click Browse to select the file which will contain the rejects.
A reject is an entry which cannot be imported into the database; for example, the server cannot import an entry that already exists in the database or an entry that has no parent object. The Console will write the error message sent by the server to the rejects file.
Leaving this field blank means the server will not record rejected entries.
Click OK.

The server performs the import and also creates indexes.

NOTE

Trailing spaces are dropped during a remote Console import but are preserved during both local Console or ldif2db import operations.

Initializing a Database from the Console

The existing data in a database can be overwritten by initializing databases.
You must be logged in as the Directory Manager in order to initialize a database because an LDIF file that contains a root entry cannot be imported into a database except as the Directory Manager (root DN). Only the Directory Manager has access to the root entry, such as dc=example,dc=com.

CAUTION

When initializing databases from an LDIF file, be careful not to overwrite the o=NetscapeRoot suffix unless you are restoring data. Otherwise, initializing the database deletes information and may require re-installing the Directory Server.

To initialize a database using the Directory Server Console, do the following:

Select the Configuration tab.
Expand the Data tree in the left navigation pane. Expand the suffix of the database to initialize, then click the database itself.
Right-click the database, and select Initialize Database.
Alterntatively, select Initialize Database from the Object menu.
In the LDIF file field, enter the full path to the LDIF file to import, or click Browse.
If the Console is running from a machine local to the file being imported, click OK and proceed with the import immediately. If the Console is running from a machine remote to the server containing the LDIF file, select one of the following options, then click OK:
- From local machine. Indicates that the LDIF file is located on the local machine.
- From server machine. Indicates that the LDIF file is located on a remote server.
The default LDIF directory is /var/lib/dirsrv/slapd-instance_name/ldif. ^[3]

Importing from the Command-Line

There are three methods for importing data through the command-line:

Using ldif2db. This import method overwrites the contents of the database and requires the server to be stopped; seeSection 4.1.3.1, “Importing Using the ldif2db Command-Line Script”.
Using ldif2db.pl. This import method overwrites the contents of the database while the server is still running; seeSection 4.1.3.2, “Importing Using the ldif2db.pl Perl Script”.
Using ldif2ldap. This method appends the LDIF file through LDAP. This method is useful to append data to all of the databases; see Section 4.1.3.3, “Importing Using the ldif2ldap Command-Line Script”.

NOTE

To import a database that has been encrypted, use the -E option with the script. See Section 3.2.3.5, “Exporting and Importing an Encrypted Database” for more information.

Importing Using the ldif2db Command-Line Script

The ldif2db script overwrites the data in the specified database. Also, the script requires that the Directory Server be stopped when the import begins.
By default, the script first saves and then merges any existing o=NetscapeRoot configuration information with theo=NetscapeRoot configuration information in the files being imported.

CAUTION

This script overwrites the data in the database.

To import LDIF, do the following:

Stop the server. ^[4]
```
service dirsrv stop instance
```
Open the Directory Server instance directory.
```
cd /usr/lib/dirsrv/slapd-instance_name
```
Run the ldif2db command-line script.
```
ldif2db -n Database1 -i /var/lib/dirsrv/slapd-instance_name/ldif/demo.ldif
 -i /var/lib/dirsrv/slapd-instance_name/ldif/demo2.ldif
```
For more information about using this script, see the Directory Server Configuration, Command, and File Reference.

CAUTION
If the database specified in the -n option does not correspond with the suffix contained by the LDIF file, all of the data contained by the database is deleted, and the import fails. Make sure that the database name is not misspelled.

Option	Description
-i	Specifies the full path name of the LDIF files to be imported. This option is required. To import more than one LDIF file at a time, use multiple `-i` arguments. When multiple files are imported, the server imports the LDIF files in the order which they are specified from the command-line.
-n	Specifies the name of the database to which to import the data.

Table 4.2. ldif2db Parameters

For more information about using this script, see the Directory Server Configuration, Command, and File Reference.

4.1.3.2. Importing Using the ldif2db.pl Perl Script

As with the ldif2db script, the ldif2db.pl script overwrites the data in the specified database. This script requires the server to be running in order to perform the import.

CAUTION

This script overwrites the data in the database.

Open the Directory Server instance directory.
```
cd /usr/lib/dirsrv/slapd-instance_name
```
Run the ldif2db script.
```
ldif2db -D "cn=Directory Manager" -w secretpwd 
    -i /var/lib/dirsrv/slapd-instance_name/ldif/demo.ldif -n Database1
```
For more information about using this script, see the Directory Server Configuration, Command, and File Reference.

NOTE
You do not need root privileges to run the script, but you must authenticate as the Directory Manager.

Option	Description
-D	Specifies the DN of the administrative user.
-w	Specifies the password of the administrative user.
-i	Specifies the LDIF files to be imported. This option is required. To important multiple LDIF files at a time, use multiple `-i` arguments. When multiple files are imported, the server imports the LDIF files in the order they are specified in the command-line.
-n	Specifies the name of the database to which to import the data.

Table 4.3. ldif2db Options

4.1.3.3. Importing Using the ldif2ldap Command-Line Script

The ldif2ldap script appends the LDIF file through LDAP. Using this script, data are imported to all directory databases at the same time. The server must be running in order to import using ldif2ldap.
To import LDIF using ldif2ldap, do the following:

Open the Directory Server instance directory:
```
cd /usr/lib/dirsrv/slapd-instance_name
```
Run the ldif2ldap command-line script.
```
ldif2ldap "cn=Directory Manager" secretpwd /var/lib/dirsrv/slapd-instance_name/ldif/demo.ldif
```
The ldif2ldap script requires the DN of the administrative user, the password of the administrative user, and the absolute path and filename of the LDIF files to be imported.
For more information about using this script, see the Directory Server Configuration, Command, and File Reference.

configure a slave replica

2011-11-12T10:54:00.001-08:00

Creating the Supplier Bind DN Entry

A critical part of setting up replication is to create the entry, called the replication manager or supplier bind DN entry, that the suppliers use to bind to the consumer servers to perform replication updates.
The supplier bind DN must meet the following criteria:

It must be unique.
It must be created on the consumer server (or hub) and not on the supplier server.
It must correspond to an actual entry on the consumer server.
It must be created on every server that receives updates from another server.
It must not be part of the replicated database for security reasons.
It must be defined in the replication agreement on the supplier server.

For example, the entry cn=Replication Manager,cn=config can be created under the cn=config tree on the consumer server. This would be the supplier bind DN that all supplier servers would use to bind to the consumer to perform replication operations.

NOTE

Avoid creating simple entries under the cn=config entry in the dse.ldif file. The cn=cn=config entry in the simple, flat dse.ldif configuration file is not stored in the same highly scalable database as regular entries. As a result, if many entries, and particularly entries that are likely to be updated frequently, are stored under cn=config, performance will suffer. However, although Red Hat recommends not storing simple user entries under cn=config for performance reasons, it can be useful to store special user entries such as the Directory Manager entry or replication manager (supplier bind DN) entry undercn=config since this centralizes configuration information.

On each server that acts as a consumer in replication agreements, create a special entry that the supplier will use to bind to the consumers. Make sure to create the entry with the attributes required by the authentication method specified in the replication agreement.

Stop the Directory Server. If the server is not stopped, the changes to the dse.ldif file will not be saved. SeeSection 1.3, “Starting and Stopping Servers” for more information on stopping the server.
Create a new entry, such as cn=replication manager,cn=config, in the dse.ldif file.
Specify a userPassword attribute-value pair.
If password expiration policy is enabled or ever will be enabled, disable it on the replication manager entry to prevent replication from failing due to passwords expiring. To disable the password expiration policy on theuserPassword attribute, add the passwordExpirationTime attribute with a value of 20380119031407Z, which means that the password will never expire.
Restart the Directory Server. See Section 1.3, “Starting and Stopping Servers” for more information on starting the server.

The final entry should resemble this example:

dn: cn=replication manager,cn=config 
objectClass: inetorgperson 
objectClass: person 
objectClass: top 
cn: replication manager 
sn: RM 
userPassword: password 
passwordExpirationTime: 20380119031407Z

When configuring a replica as a consumer, use the DN of this entry to define the supplier bind DN.

Configuring Single-Master Replication

To set up single-master replication such as the configuration shown in Figure 8.1, “Single-Master Replication”, between supplier server A, which holds a read-write replica, and the two consumers server B and server C, which each hold a read-only replica, there are two major steps:

Configuring the Read-Write Replica on the Supplier Server

Specify the supplier settings for the server.
1. In the Directory Server Console, select the Configuration tab.
2. In the navigation tree, select the Replication folder.
3. In the right-hand side of the window, select the Supplier Settings tab.
4. Check the Enable Changelog checkbox.
  This activates all of the fields in the pane below that were previously grayed out.
5. Specify a changelog by clicking the Use default button, or click the Browse button to display a file selector.
6. Set the changelog parameters for the number and age of the log files.
  Clear the unlimited checkboxes to specify different values.
7. Click Save.
Specify the replication settings required for a read-write replica.
1. In the navigation tree on the Configuration tab, expand the Replication node, and highlight the database to replicate.
  The Replica Settings tab opens in the right-hand side of the window.
2. Check the Enable Replica checkbox.
3. In the Replica Role section, select the Single Master radio button.
4. In the Common Settings section, specify a Replica ID, which is an integer between 1 and 65534, inclusive.
  The replica ID must be unique for a given suffix, different from any other ID used for read-write replicas on this server and on other servers.
5. In the Common Settings section, specify a purge delay in the Purge delay field.
  The purge delay is how often the state information stored in the replicated entries is deleted.
6. Click Save.

Configuring the Read-Only Replica on the Consumer

Create the database for the read-only replica if it does not exist. See Section 3.1.1, “Creating Suffixes” for instructions on creating suffixes.
Create the entry for the supplier bind DN on the consumer server if it does not exist. The supplier bind DN is the special entry that the supplier will use to bind to the consumer. This is described in Section 8.3, “Creating the Supplier Bind DN Entry”.
Specify the replication settings required for a read-only replica.
1. In the Directory Server Console, select the Configuration tab.
2. In the navigation tree, expand the Replication folder, and highlight the replica database.
  The Replica Settings tab for that database opens in the right-hand side of the window.
3. Check the Enable Replica checkbox.
4. In the Replica Role section, select the Dedicated Consumer radio button.
5. In the Common Settings section, specify a purge delay in the Purge delay field.
  This option indicates how often the state information stored in the replicated entries is purged.
6. In the Update Settings section, specify the bind DN that the supplier will use to bind to the replica. Enter the supplier bind DN in the Enter a new Supplier DN field, and click Add. The supplier bind DN appears in the Current Supplier DNs list.
  The supplier bind DN should be the entry created in step 2. The supplier bind DN is a privileged user because it is not subject to access control.
  
  NOTE
  There can be multiple supplier bind DNs per consumer but only one supplier DN per replication agreement.
7. Specify the URL for any supplier servers to which to refer updates.
  By default, all updates are first referred to the supplier servers that are specified here. If no suppliers are set here, updates are referred to the supplier servers that have a replication agreement that includes the current replica.
  Automatic referrals assume that clients bind over a regular connection; this has a URL in the formldap://hostname:port. For clients to bind to the supplier using SSL, use this field to specify a referral of the form ldaps://hostname:port, where the s in ldaps indicates a secure connection.
Click Save.

Repeat these steps for every consumer server in the replication configuration.

8.4.3. Create the Replication Agreement

Create one replication agreement for each read-only replica. For example, in the scenario illustrated in Figure 8.1, “Single-Master Replication”, server A has two replication agreements, one for server B and one for server C.

In the navigation tree of the Configuration tab, right-click the database to replicate, and selectNew Replication Agreement.
Alternatively, highlight the database, and select New Replication Agreement from the Object menu to start theReplication Agreement Wizard.
In the first screen, fill in a name and description for the replication agreement, and hit Next.
In the Source and Destination screen, fill in the URL for the consumer and the supplier bind DN and password on that consumer. If the target server is not available, hit in other to fill in the information manually.
- Unless there is more than one instance of Directory Server configured, by default, there are no consumers available in the drop-down menu.
- The port listed is the non-SSL port, even if the Directory Server instance is configured to run over SSL. This port number is used only for identification of the Directory Server instance in the Console; it does not specify the actual port number or protocol that is used for replication.
- If SSL is enabled on the servers, it is possible to select the Using encrypted SSL connection radio button for SSL client authentication. Otherwise, fill in the supplier bind DN and password.
  NOTE
  If attribute encryption is enabled, a secure connection must be used for the encrypted attributes to be replicated.
Hit Next.
Fractional replication controls which entry attributes are replicated between servers. By default, all attributes are replicated. To select attributes that will not be replicated to the consumer, check the Enable Fractional Replicationcheckbox. Then, highlight the attribute (or attributes) in the Included column on the right, and click Remove. All attributes that will not be replicated are listed in the Excluded column on the left, as well as in the summary the replication agreement is complete.
NOTE
To safeguard against potential integrity problems, the consumer in fractional replication must be a dedicated consumer, not a multi-master supplier or hub. This is not enforced at the time the replication agreement is made, but replication will fail if the consumer is not a read-only replica.
Set the schedule for when replication runs. By default, replication runs continually.
Hit Next.
Set when the consumer is initialized. Initializing a consumer manually copies all data over from the supplier to the consumer. The default is to create an initialization file (an LDIF of all supplier data) so that the consumer can be initialized later. It is also possible to initialize the consumer as soon as the replication agreement is completed or not at all. For information on initializing consumers, see Section 8.10, “Initializing Consumers”.
NOTE
Replication will not begin until the consumer is initialized.
Hit Next.
The final screen shows the settings for the replication agreement, as it will be included in the dse.ldif file. HitDone to save the agreement.

Configure a system to authenticate using LDAP

2011-11-09T12:57:00.001-08:00

system-config-authentication