CONFIDENTIAL Designator

Red Hat Directory Server 10

RHDS
Design Workshop
Muhammad Aizuddin Bin Zali(Din)
Kuala Lumpur, Malaysia
ASEAN Assoc. Principal Platform Consultant

1
 AGENDA CONFIDENTIAL Designator

Objective & Outcome of this workshop

● Objective is for Red Hat consultant:

○ To understand customer requirement in technical depth
○ To agree on the final architecture and deployment method

● Outcome:
○ Red Hat to provide design document for customer to review and sign-off.

2
 AGENDA CONFIDENTIAL Designator

What we’ll be
RHDS Introduction
discussing
Data/DIT Design Discussion
● Planning the Directory Data
● Designing Directory Schema
● Designing Directory Tree
● Designing Directory Topology

Server Design Discussion:

● Design the Replication Process
● Securing Directory
● Backup & Recovery
● Monitoring

3
 CONFIDENTIAL Designator

RHDS “Hello World!”

4
 Red Hat Directory Server 10 Hello World! CONFIDENTIAL Designator

Brief history of RHDS

University of Michigan slapd Sun Microsystems bought

Project the IP from AOL
Started as a project in Sold & developed as
university of Michigan JES/SunOne Directory Server
(and later Oracle Directory
Server)

2005

1996

Acquired by Netscape (AOL) Acquired by Red Hat

Project became Netscape AOL/Netscape rights bought
Directory Server (NDS) by Red Hat (389 and RHDS)

Sources:
https://en.wikipedia.org/wiki/389_Directory_Server
 CONFIDENTIAL Designator

Data & DIT Discussion

Planning the Directory Data

6
 Planning the Directory Data CONFIDENTIAL Designator
Data & DIT Discussion

Some types of data are better suited to the directory than

others. Ideal data for a directory has some of the following
characteristics:

● It is read more often than written.

● It is expressible in attribute-data format (for

example, surname=jensen).

● It is of interest to more than one person or group.

For example, an employee's name or the physical
location of a printer can be of interest to many
people and applications.

● It will be accessed from more than one physical

location.
7
 Planning the Directory Data CONFIDENTIAL Designator
Data & DIT Discussion

● Discussion:
○ What information will be stored?
○ What information to be excluded?
○ Defining directory needs:
■ What kind of apps/user accessing the directory?
■ Where directory will get the data source (Data Master)?
● A data master is a server that is the master source of data.

■ Who will be responsible to data master (Data Ownership)?

● Data ownership refers to the person or organization responsible for
making sure the data is up-to-date.
● Entity that has permission to write to the directory.

■ Determining Data Access

● Can the data be read anonymously?

8
 CONFIDENTIAL Designator

Data & DIT Discussion

Designing the Directory Schema

9
 Designing the Directory Schema CONFIDENTIAL Designator
Data & DIT Discussion

● The directory schema describes the types of data in

the directory, so determining what schema to use
reflects decisions on how to represent the data
stored in the directory.

● Each data element is mapped to an LDAP attribute,

and related elements are gathered into LDAP object
classes.

● A well-designed schema helps to maintain the

integrity of the directory data.

10
 Designing the Directory Schema CONFIDENTIAL Designator
Data & DIT Discussion

objectClass: person

object distinguishedName:
dn: uid=bjensen,ou=people,dc=example,dc=com Schema for using
person objectClass

11
Directory Structure
CONFIDENTIAL Designator
 CONFIDENTIAL Designator

Data & DIT Discussion

Designing the Directory Tree

13
 Designing the Directory Tree CONFIDENTIAL Designator
Data & DIT Discussion

● The directory tree provides a means for the directory

data to be named and referred to by client
applications.
● A well-designed directory tree provides the
following:

○ Simplified directory data maintenance.

○ Flexibility in creating replication policies and
access controls.
○ Support for the applications using the
directory service.
○ Simplified directory navigation for directory
users.

14
 Designing the Directory Tree CONFIDENTIAL Designator
Data & DIT Discussion

● How should the DIT looks like?

15
 CONFIDENTIAL Designator

Data & DIT Discussion

Designing the Directory Topology

16
 Designing the Directory Topology CONFIDENTIAL Designator
Data & DIT Discussion

● Directory Server stores data in LDBM databases.

This a high-performance, disk-based database. Each
database consists of a set of large files that contain
all of the data assigned to it.

● Different portions of the directory tree can be stored

in different databases.

17
 Designing the Directory Topology CONFIDENTIAL Designator
Data & DIT Discussion

● Indexing can improve database performance:

○ Indexes increase the time it takes to modify
entries.
■ The more indexes being maintained,
the longer it takes the directory
service to update the database.

○ Index files use disk space.

○ Index files use memory.

○ Index files take time to create.

■ Although index files save time during
searches, maintaining unnecessary
indexes can waste time.

18
 Designing the Directory Topology CONFIDENTIAL Designator
Data & DIT Discussion

● How should topology based on DIT?

● Using Indexes to improve database performance:
○ Which attributes required index?
■ Presence index — Lists entries that
possess a particular attribute, such as
uid
■ Equality index — Lists entries that
contain a specific attribute value, such
as cn=Babs Jensen
■ Approximate index — Allows
approximate (or "sounds-like")
searches.
■ Substring index — Allows searches
against substrings within entries.
(cn=*derson)

19
 CONFIDENTIAL Designator

Server Design Discussion

Designing the replication process

20
 Designing the replication process CONFIDENTIAL Designator
Server Design Discussion

● Replication is the mechanism that automatically copies directory data from one Red Hat Directory
Server to another.
● In practical terms, replication provides the following benefits:
○ Fault tolerance and failover
■ By replicating directory trees to multiple servers

○ Load balancing
■ Replicating the directory tree across servers reduces the access load on any given
machine

○ Higher performance and reduced response time

■ Replicating directory entries to a location close to users significantly improves
directory response times

○ Local data management

■ Replication allows information to be owned and managed locally while sharing it with
21
other Directory Servers across the enterprise.
 Designing the replication process CONFIDENTIAL Designator
Server Design Discussion

● Planning replication:
○ What information to replicate.
○ Which servers hold the master copy, or read-write replica, of that information.
○ Which servers hold the read-only copy, or read-only replica, of that information.
○ What should happen when a read-only replica receives an update request; that is, to which
server it should refer the request.
○
● Unit of replication:
○ The smallest unit of replication is a database. An entire database can be replicated but not a
subtree within a database.
○ The replication mechanism also requires that one database correspond to one suffix. A suffix
(or namespace) that is distributed over two or more databases cannot be replicated.

● Suppliers and Consumers:

○ In the case of cascading replication, the hub supplier holds a read-only replica that it
supplies to consumers.
22
○ In the case of multi-master replication, the suppliers function as both suppliers and
consumers for the same read-write replica
 Designing the replication process CONFIDENTIAL Designator
Server Design Discussion

● Multi-Master Replication:
○ In a multi-master replication environment, master copies of the same information can exist
on multiple servers.
○ Red Hat Directory Server supports a maximum of 20 master servers in any replication
environment, as well as an unlimited number of hub suppliers. The number of consumer
servers that hold the read-only replicas is unlimited.

23
 Designing the replication process CONFIDENTIAL Designator
Server Design Discussion

● Replication Survey:
○ The quality of the LANs and WANs connecting different buildings or remote sites and the
amount of available bandwidth.
○ The physical location of users, how many users are at each site, and their usage patterns;
that is how they intend to use the directory service.
○ The number of applications that access the directory service and the relative percentage of
read, search, and compare operations to write operations.
○ The number and size of the entries stored in the directory service.

24
 CONFIDENTIAL Designator

Server Design Discussion

Securing Directory

25
 Performance Expectation CONFIDENTIAL Designator
Server Design Discussion

● Number of query per second?

● Number of concurrent query per second?
● Malaysiàs banking customer benchmark RHDS 10, with 8vCPU and 16GB of RAM on vSphere:
○ ~500 Write ops/second
○ ~1000 Read ops/second
○ ~50 concurrent qps
NOTE: With this kind of load, server at only 20-40% usage and still a lot room for more load.

26
 Server Version CONFIDENTIAL Designator
Server Design Discussion

● Current is RHDS 12
○ RHEL 8.x
○ Min 4 vCPU
○ Min 8GB of RAM
○ Min 120GB of OS storage
○ Min xxxGB of LDAP Data storage
○ Cockpit console available

27
 Securing Directory CONFIDENTIAL Designator
Server Design Discussion

● Threats:
○ Unauthorized access
○ Unauthorized tampering
○ Denial of service
○ SSL

28
 Securing Directory CONFIDENTIAL Designator
Server Design Discussion

● Authentication Method (not limited to):

○ Anonymous
■ Anonymous access provides the easiest form of access to the directory. It makes data
available to any user of the directory, regardless of whether they have authenticate

○ Simple Binds & Secure Binds

■ simple password authentication, a client authenticates to the server by sending a
reusable password.

○ Certificate-Based Authentication
■ An alternative form of directory authentication involves using digital certificates to
bind to the directory. The directory prompts users for a password when they first
access it. However, rather than matching a password stored in the directory, the
password opens the user's certificate database.

29
 Securing Directory CONFIDENTIAL Designator
Server Design Discussion

● Password Policy
○ Max Failure
○ Password change after reset
○ Password Expiration
○ Password Syntax Checking
○ Password Length
○ Password Minimum Age
○ Password History

30
 Securing Directory CONFIDENTIAL Designator
Server Design Discussion

● Database encryption
○ Do we require some attributes to be encrypted?
■ Special step required for import/export later due to encryption key.
● Securing connection
○ TLS - LDAPS
■ LDAPS
■ Cockpit HTTPS
○ Start TLS
○ SASL

31
 Service Access CONFIDENTIAL Designator
Server Design Discussion

● Load balancer?

● DNS SRV Record?

_ldap._tcp.example.com. IN SRV 10 50 389 ldap1.example.com.
_ldap._tcp.example.com. IN SRV 20 75 389 ldap2.example.com.

● LDAP URI Construct?

ldap://ldap1.example.com,ldap://ldap2.example.com

32
 Backup & Restore CONFIDENTIAL Designator
Server Design Discussion

● In place backup & restore?

● Native script?
● Multi master replicas?

33
 Migration from old directory server CONFIDENTIAL Designator
Server Design Discussion

● How we plan to migrate from old server to new RHDS?

● LDIF export/import.
● Downtime involved?
● Lift and Shift?

34
 Console Access CONFIDENTIAL Designator
Server Design Discussion

● LDAP CLI
● X11 Console (Require SSH X11 Forwarding and X11 capable client)

35
 Monitoring CONFIDENTIAL Designator
Server Design Discussion

● In place monitoring?
● SNMP?

36
 CONFIDENTIAL Designator
OPTIONAL SECTION MARKER OR TITLE

Thank you
Red Hat is the world’s leading provider of enterprise

open source software solutions. Award-winning

support, training, and consulting services make Red

Hat a trusted adviser to the Fortune 500.

linkedin.com/company/red-hat facebook.com/redhatinc

youtube.com/user/RedHatVideos twitter.com/RedHat

37