OpenLDAP Directory Administration Replication, Referrals, Searching, and SASL Explained.

OpenLDAP Directory Administration

Replication, Referrals,

Searching, and SASL Explained

Table of Contents● More Than One Copy Is “a Good Thing”

● Distributing the Directory

● Advanced Searching Options

● Determining a Server's Capabilities

● Creating Custom Schema Files for slapd

● SASL and OpenLDAP







More Than One Copy Is“a Good Thing”

● Directory replication hasn't been standardized yet: vendor-specific

● Cross-vendor replication ? Only using tricks like parsing a change log

● When should I install a replica for all or for part of my directory ? Symptons:

– If one application makes heavy use of the directory and slows things down

– If one Directory server does not have enough CPU power

– Group of clients located behind a slow network link

– IF the directory cannot be taken offline for backups

– If the directory is a critical part of the services provided by your network

● Next question is “How ?”

More Than One Copy Is“a Good Thing” (cont.)

● OpenLDAP uses a secondary daemon, slurpd, to process a change log written by slapd

● slurpd forwards the changes to the replica's local slapd instance using normal LDAP modify commands

slapdslapd

Replica directory

server

Master directory

server

Changes are sent via LDAP operations such as modify,delete,add,etc.

Replication logfile

reads

writes

slapdslapdslurpdslurpd


Building slurpd

– Pass this to the ./configure script:

--enable-slurpd

Replication in a Nutshell

– You must have a working server

– Stop slapd

– Reconfigure slapd.conf to enable replication

– copy database from master to replica

– Configure replica's slapd.conf file

– Start replica server's slapd process

– Start master server's slapd process

– Start master server's slurpd process


Configuring the Master Server

– You can give slurpd its own configuration file (start it with the -f option), but this is generally not done

– Add two directives to the database section of slapd.conf:

replogfile /var/ldap/slapd.replog

replica host=replica1.plainjoe.org:398

suffix=”dc=plainjoe,dc=org”

binddn=”cn=replica,dc=plainjoe,dc=org”

credentials=MyPass

bindmethod=simple

tls=yes


Configuring the Replica Server

– First step: initialize database● Copy database● OR: Export master database to LDIF format

– Restrictions to keep in mind when simply copying:● Both hosts must have same, compatible versions of DBM

libraries● Hosts must have same byte ordering (little-endian vs. big-

endian)● Some methods of copying files (cp) will fill in the holes,

resulting in much larger files on the replica host

– Hence, it's probably better to use LDIF format!● On master:

# slapcat -b “dc=plainjoe,dc=org” -l contents.ldif● On replica:

# slapadd -l contents.diffonly needed if there is more than one “partition”


Configuring the Replica Server (cont.)

– Time to update the slapd.conf file on the replica to accept updates from the master server

– Global section will be identical (certain pieces like server certificate should be unique, though!)

– Database: identical, except:● Replication parameters: an updatedn (tells slave server who

is authorized to make changes) and updateref (points slave to master server (single master model=clients are references to master when write access is required))

updatedn “cn=replica,dc=plainjoe,dc=org”

updateref ldap://pogo.plainjoe.org● Appropriate local rootdn and rootpw paramters

rootdn “cn=replica,dc=plainjoe,dc=org”

rootpw {SSHA}SMKnFP0435G+QstIzNGb4RGjTOKLz2TV

(Note: the development version of OpenLDAP supports an experimental multi-master replication protocol)


slurpd's replogfile

– Replication log uses a format similar to LDIF

– After reading replogfile, slurpd copies the entry to its own replay log (slurpd.replog, -t command-line option)

– Entry in replogfile generated by email address change:

replica: pogo.plainjoe.orgtime: 975434259dn: cn=jerry carter,ou=people,dc=plainjoe,dc=orgchangetype: modifyreplace: mailmail: [email protected]: entryCSNentryCSN: 2002110403:55:49Z#0x0001#0#0000-replace: modifiersNamemodifiersName: cn=Manager,dc=plainjoe,dc=org-replace: modifyTimestampmodifyTimestamp: 200001128175739Z-

replica: pogo.plainjoe.orgtime: 975434259dn: cn=jerry carter,ou=people,dc=plainjoe,dc=orgchangetype: modifyreplace: mailmail: [email protected]: entryCSNentryCSN: 2002110403:55:49Z#0x0001#0#0000-replace: modifiersNamemodifiersName: cn=Manager,dc=plainjoe,dc=org-replace: modifyTimestampmodifyTimestamp: 200001128175739Z-

one attribute value change results in four replication log entries!


slurpd's replogfile

– modifiersName, modifyTimestamp, and entryCSN are maintained by the LDAP server and cannot be modified by clients

– replica directive defines the host to which the change should be propagated (there can be more than one line)

– time parameter defines epoch; slurpd maintains state information (in a file slurpd.status) that prevents it from reparsing entries that have already been processed

– If slurpd cannot propagete the change to the other server, slurpd writes the entry and reason for the failure to a rejext logfile <hostname:port>.rej

– Certain errors (eg. nework errors) cause slurpd to requeue a modification >< entry in a .rej file (requires manual intervention on case-by-case basis)

– slurpd can run as a daemon, or can be run in “one-shot” mode to process a single log and exit


slurpd's replogfile

– Command-line options for slurpd:

– Start slurpd on the master server; slurpd will check for updates every 3 seconds

– Backing up the slave/replica server ? Stop slurpd on the master first, restart after the backup

Option Description-d integer

-f “config filename”

-r replogfile

-o

-t directory

-k “srvtab file”

Specifies debugging information to be written to the log (see loglevel parameter in slapd.confSpecifies location and filename of the slapd.conf file to be usedSpecifies the location and filename of the replication log to be processed. The -r switch is often used in conjunction with the slurpd's one-shot mode to process a partcular fileExecutes slurpd in one-shot mode to process a single replication log and exitSpecifies the directory to be used for temporary files such as lock and status filesSpecifies the location of the srvtab file when using LDAPv2 Kerberos 4 binds to a slave slapd server







Distributing the Directory● So far, scenarios have assumed that the entire directory

consists of only one partition; seldom the case in reality

● Definition for the ou=hosts partition is very similar to the database section we have been using so far

– Main changes are suffix served by the backend (ou=hosts,dc=plainjoe,dc=org) and directory in which BerkeleyDB files are stored (/var/ldap/hosts/)

– rootdn must also be updated (must exists within partition's context)

dc=plainjoe,dc=org

ou=hosts,dc=plainjoe,dc=org

Distributing the Directory (cont.)● Configuration:

## Partition on second server holding ou=hostsdatabase bdb

# Root suffixsuffix “ou=hosts,dc=plainjoe,dc=org”

# Root DN & passwordrootdn “cn=Manager,ou=hosts,dc=plainjoe,dc=org”rootpw {SSHA}2aksIaicAvwc+DhCrXUFlhgWsbBJPLxy

# Directory containing the database filesdirectory /var/ldap/hosts

# Files should be created “rw” for the owner *only*mode 0600

# Indexes to maintainindex objectClass eqindex cn pres,eq

cachesize 2000

Simple ACL granting read access to the worldaccess to *

by * read

## Partition on second server holding ou=hostsdatabase bdb

# Root suffixsuffix “ou=hosts,dc=plainjoe,dc=org”

# Root DN & passwordrootdn “cn=Manager,ou=hosts,dc=plainjoe,dc=org”rootpw {SSHA}2aksIaicAvwc+DhCrXUFlhgWsbBJPLxy

# Directory containing the database filesdirectory /var/ldap/hosts

# Files should be created “rw” for the owner *only*mode 0600

# Indexes to maintainindex objectClass eqindex cn pres,eq

cachesize 2000

Simple ACL granting read access to the worldaccess to *

by * read

Distributing the Directory (cont.)● Superior knowledge references (referrals) point from the

root of a subtree to the server of the larger directory

● Subordinate knowledge references (references) point from a node to the larger dicrectory to the subtree/partition to which it should be attached

● Client can now start a search at any node in the directory and containue down through the directory tree(search reference URI is returned to client – he can choose to continues the search on the other server)

dc=plainjoe,dc=org

ou=hosts,dc=plainjoe,dc=org

superior knowlede reference

subordinate knowledge reference

Distributing the Directory (cont.)● slapd.conf for server holding ou=hosts tree possesses

a global section indentical to existing server, with one exception:

– OpenLDAP uses referral global parameter to define an LDAP URI for the server's superior knowledge reference

– This is a global, server-wide parameter as opposed to a database-specific directive

– Why ? Because it points to knowledge that the server receiving the request doesn't have

## slapd.conf for ou=hosts (ldap2.plainjoe.org)...# Define the URL (only host:port) for the host that clients# should contact in the event that you cannot service their# requestsreferral ldap://master.plainjoe.org:398/

## slapd.conf for ou=hosts (ldap2.plainjoe.org)...# Define the URL (only host:port) for the host that clients# should contact in the event that you cannot service their# requestsreferral ldap://master.plainjoe.org:398/

Distributing the Directory (cont.)● Subordinate knowledge references are implemented as

entries within the directory itself

● These entries use referral structural object class (RFC 3296), contains a single required attribute, ref, which loads the LDAP URI for the root of the subtree

● Command to create this entry:

$ ldapadd -H ldap://localhost/ -D “cn=Manager,dc=plainjoe,dc=org” \> -w secret -x <<EOR> dn: ou=hosts,dc=plainjoe,dc=org> ou: hosts> objectClass: extensibleObject> objectClass: referral> ref: ldap://ldap2.plainjoe.org/ou=hosts,dc=plainjoe,dc=org > EORAdding new entry “ou=hosts,dc=plainjoe,dc=org”

$ ldapadd -H ldap://localhost/ -D “cn=Manager,dc=plainjoe,dc=org” \> -w secret -x <<EOR> dn: ou=hosts,dc=plainjoe,dc=org> ou: hosts> objectClass: extensibleObject> objectClass: referral> ref: ldap://ldap2.plainjoe.org/ou=hosts,dc=plainjoe,dc=org > EORAdding new entry “ou=hosts,dc=plainjoe,dc=org”

Distributing the Directory (cont.)● Creating a sample in the ou=hosts tree ldap2.plainjoe.org for later use:

$ ldapadd -H ldap://ldap2.plainjoe.org/ \> -D “cn=Manager,ou=hosts,dc=plainjoe,dc=org” \> -w secret -x <<EOR> dn: ou=hosts,dc=plainjoe,dc=org> objectClass: organizationalUnit> ou: hosts> description: Container for host info in plainjoe.org domain> EORAdding new entry “ou=hosts,dc=plainjoe,dc=org”

$ ldapadd -H ldap://ldap2.plainjoe.org/ \> -D “cn=Manager,ou=hosts,dc=plainjoe,dc=org” \> -w secret -x <<EOR> dn: ou=hosts,dc=plainjoe,dc=org> objectClass: organizationalUnit> ou: hosts> description: Container for host info in plainjoe.org domain> EORAdding new entry “ou=hosts,dc=plainjoe,dc=org”







Advanced Searching Options● More thorough look at the topic of filters

● Commonly used form – syntax:

( attribute filterOperator value )

● The attribute is the name of the actual attribute type

● The filterOperator is one of:

= for equality matches

~= for approximate matches

<= for less than comparisons

>= for greater than comparisons

● The value can be an absolute value or a pattern using the asterisk (*) as a wildcard, eg.

(cn=*carter)

(telephoneNumber=555*)

Advanced Searching Options (cont.)

● Boolean operators to combine single filters:

& logical AND

| logical OR

! logical NOT

● LDAP search filters use prefix notation!

(|(sn=smith)(sn=jones))

(&(|(sn=smith)(sn=jones))(cn=john*))

● sn attribute uses a case insensitive matching rule

● See RFC 2254 for more information on matching


Following Referrals with ldapsearch

– By default ldapsearch only prints information about referral objects but doesn't automatically follow them

$ ldapsearch -H ldap://localhost/ -LL -x \> -b “dc=plainjoe,dc=org” “ou=*” ou

# plainjoe.orgdn: dc=plainjoe,dc=orgou: Plainjoe Dot Org

# people, plainjoe.orgdn: ou=people,dc=plainjoe,dc=orgou: people

# Search reference# refldap://ldap2.plainjoe.org/ou=hosts,dc=plainjoe,dc=org??sub

$ ldapsearch -H ldap://localhost/ -LL -x \> -b “dc=plainjoe,dc=org” “ou=*” ou



# Search reference# refldap://ldap2.plainjoe.org/ou=hosts,dc=plainjoe,dc=org??sub


Following Referrals with ldapsearch (cont.)

– Add the -C option (“chase referrals”):

$ ldapsearch -H ldap://localhost/ -LL -x -C \> -b “dc=plainjoe,dc=org” “ou=*” ou



# hosts, plainjoe.orgdc: ou=hosts,dc=plainjoe,dc=orgou: hosts

$ ldapsearch -H ldap://localhost/ -LL -x -C \> -b “dc=plainjoe,dc=org” “ou=*” ou



# hosts, plainjoe.orgdc: ou=hosts,dc=plainjoe,dc=orgou: hosts

Advanced Searching Options (cont.)Limiting Your Searches

– Wildcard searching can put a strain on a server with thousands of entries: ldapsearch allows you to define limits for both client and server

– ldapsearch command-line parameters:

– Limits on the server, in slapd.conf:

Option Description- l integer

-z integer

Specifies the number of seconds in real time to wait for a response to a search request. A value of 0 removes the timelimit default in ldap.confDefines the maximum number of entries to be retrieved as a result of a successful search request. A value of 0 removes the limits set by the sizelimit option ldap.conf

Option Descriptionsizelimit integer

timelimit integer

Defines the maximum number of entries that the server will return to a client when responding to a search request (default 500 entries)Specifies the maximum number of seconds in real time to be spent when responding to a search request: the default limit is 1 hour (3600 seconds)







Determining a Server's Capabilities

● Two new LDAPv3 features: subschemaSubentry and rootDSE objects: allow client to find out about a previously unknown directory server

– rootDSE object: contains info about features such as servernaming context, implemented SASL mechanisms, supported LDAP extensions and controls

● LDAPv3 requires that rootDSE has an empty DN

– subschemaSubentry attribute specifies the base search suffix for querying the schema supported by the server

● Means that clients can verify that server supports a given matching rule, attribute type, or object class prior to performing an operation that depends on a certain characteristic

Determining a Server's Capabilities (cont.)

● rootDSE example:

$ ldapsearch -x -s base -b “” “(objectClass=*)” +

dn:structuralObjectClass: OpenLDAProotDSEnamingContexts: dc=plainjoe,dc=orgsupportedControl: 2.16.840.1.113730.3.4.2supportedControl: 1.3.6.1.4.1.4203.1.10.2supportedControl: 1.2.826.0.1.334810.2.3supportedExtension: 1.3.6.1.4.1.4203.1.11.3supportedExtension: 1.3.6.1.4.1.4203.1.11.1supportedExtension: 1.3.6.1.4.1.1466.20037supportedFeatures: 1.3.6.1.4.1.4203.1.5.1supportedFeatures: 1.3.6.1.4.1.4203.1.5.2supportedFeatures: 1.3.6.1.4.1.4203.1.5.3supportedFeatures: 1.3.6.1.4.1.4203.1.5.4supportedFeatures: 1.3.6.1.4.1.4203.1.5.5supportedLDAPVersion: 3supportedSASLMechanisms: GSSAPIsupportedSASLMechanisms: DIGEST-MD5supportedSASLMechanisms: CRAM-MD5subschemaSubentry: cn=Subschema

$ ldapsearch -x -s base -b “” “(objectClass=*)” +

dn:structuralObjectClass: OpenLDAProotDSEnamingContexts: dc=plainjoe,dc=orgsupportedControl: 2.16.840.1.113730.3.4.2supportedControl: 1.3.6.1.4.1.4203.1.10.2supportedControl: 1.2.826.0.1.334810.2.3supportedExtension: 1.3.6.1.4.1.4203.1.11.3supportedExtension: 1.3.6.1.4.1.4203.1.11.1supportedExtension: 1.3.6.1.4.1.1466.20037supportedFeatures: 1.3.6.1.4.1.4203.1.5.1supportedFeatures: 1.3.6.1.4.1.4203.1.5.2supportedFeatures: 1.3.6.1.4.1.4203.1.5.3supportedFeatures: 1.3.6.1.4.1.4203.1.5.4supportedFeatures: 1.3.6.1.4.1.4203.1.5.5supportedLDAPVersion: 3supportedSASLMechanisms: GSSAPIsupportedSASLMechanisms: DIGEST-MD5supportedSASLMechanisms: CRAM-MD5subschemaSubentry: cn=Subschema

StartTLS option

ManageDsaIT control

Determining a Server's Capabilities (cont.)

● subschemaSubentry example:

$ ldapsearch -D “cn=Manager,dc=plainjoe,dc=org” \> -w secret -x -s base -b “cn=SubSchema” \> “(objectclass=*)” +ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )...matchingRules: ( 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX1.3.6.1.4.1.1466.115.121.1.15 )...attributeTypes: ( 0.9.2342.19200300.100.1.42 NAME ( 'pager' 'pagerTelephoneNumber' ) EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )...objectClasses: ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )...

$ ldapsearch -D “cn=Manager,dc=plainjoe,dc=org” \> -w secret -x -s base -b “cn=SubSchema” \> “(objectclass=*)” +ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )...matchingRules: ( 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX1.3.6.1.4.1.1466.115.121.1.15 )...attributeTypes: ( 0.9.2342.19200300.100.1.42 NAME ( 'pager' 'pagerTelephoneNumber' ) EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )...objectClasses: ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )...







Creating Custom Schema Files for slapd

● What when standard schema files distributed with you LDAP server don't meet the needs of your applications ?

– Create a custom schema file for OpenLDAP

● How ?

– Assign unique OID for all new attribute types and object classes

– Create schema file and include it in slapd.conf

● It's also possible to create alternate schema syntaxes and matching rules (typically require implementing a plug-in for the directory server or modifying the server's source code)

● Obtain private enterprise numbers from IANA: see http://www.iana.org/cgi-bin/enterprise.pl and RFC 3383

http://www.iana.org/cgi-bin/enterprise.pl

Creating Custom Schema Files for slapd (cont.)

● Example: suppose LDAP client application requires a new object class based on person. New object should contain all of the attributes possessed by the person object, with addition of userPassword and mail attributes

– Allocated OID arc of 1.3.6.1.4.1.7165.1.1.1 for the new object classes:

iso(1)org(3)

dod(6)internet(1)

private(4)enterprise(1)

SAMBA.org(7165)plainjoe.org(1)

O'Reilly LDAP Book(1)

iso(1)org(3)

dod(6)internet(1)

private(4)enterprise(1)


O'Reilly LDAP Book(1)


● Chose to allocate 7165.1.1.1 to ldap object classes created and 7165.1.1.2 for new attributes:

● Add following definition to schema file plainjoe.schema:

● LDAP's inheritance: you need to add only the new required attributes; if new attributes are used, must be defined prior to use in plainjoePerson object


O'Reilly LDAP Book(1)|-- objectClasses (1)|-- attributeTypes (2)


O'Reilly LDAP Book(1)|-- objectClasses (1)|-- attributeTypes (2)

## objectclass definition for 'plainjoePerson' depends on## core.schemeobjectclass ( 1.3.6.1.4.1.7165.1.1.1.1 NAME 'plainjoePerson' SUB person STRUCTURAL MUST (userPassword $ mail) )

## objectclass definition for 'plainjoePerson' depends on## core.schemeobjectclass ( 1.3.6.1.4.1.7165.1.1.1.1 NAME 'plainjoePerson' SUB person STRUCTURAL MUST (userPassword $ mail) )

Because it's derived from a STRUCTURAL class


● Defining new attributes: same way, RFC 2252

● eg. new attribute plainjoePath to store a single, case-sensitive pathname, add this to plainjoe.schema:

(other LDAP implementations may use different syntax)

● Include line in slapd.conf:

## Store a case-sensitive path to a directoryattributetype( 1.3.6.1.4.1.7165.1.1.2.1 NAME 'plainjoePath' DESC 'A directory on disk' SUBSTR caseExactIA5SubstringsMatch EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

## Store a case-sensitive path to a directoryattributetype( 1.3.6.1.4.1.7165.1.1.2.1 NAME 'plainjoePath' DESC 'A directory on disk' SUBSTR caseExactIA5SubstringsMatch EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

# Global section

include /usr/local/etc/openldap/schema/core.schema

# NEWinclude /usr/local/etc/openldap/schema/plainjoe.schema

# Global section

include /usr/local/etc/openldap/schema/core.schema

# NEWinclude /usr/local/etc/openldap/schema/plainjoe.schema







SASL and OpenLDAP● How to replace the simple authentication used with SASL

mechanisms

● We will use the GSSAPI mechanisms for Kerberos 5 authentication (RFCs 1510, 2743, and 2478)

● Asumptions: Kerberos realm is named PLAINJOE.ORG and a service principal ldapadmin has already been created

– Need more info on Kerberos ? http://www.isi.edu/gost/brian/security/kerberos.html

● In OpenLDAP 2.1, an SASL ID can be converted to a distinguished name and used for authentication or authorization wherever a normal DN would be appropriate

– Exception: Don't use SASL ID as the DN of an entry in the directory

http://www.isi.edu/gost/brian/security/kerberos.html

SASL and OpenLDAP● SASL ID, converted to a DN:

uid=name[,realm=realm],cn=mechanism,cn=auth

● Example: replace rootdn in slapd.conf

rootdn “uid=ldapadmin,cn=gssapi,cn=auth”

● rootpw entry can be deleted: SASL GSSAPI mechanism will take care of authentication

● OpenLDAP server must possess a valid keytab file containing the key for decrypting tickets transmitted with client requests (man kadmin). Moreover, server must use the default realm of PLAINJOE.ORG

● Restart slapd

● Test OpenLDAP by adding an entry using LDIF (ldapadd)

dn: cn=test user,ou=people,dc=plainjoe,dc=orgcn: test usersn: testobjectClass: person

dn: cn=test user,ou=people,dc=plainjoe,dc=orgcn: test usersn: testobjectClass: person

SASL and OpenLDAP● Add this entry to the directory:

● If SASL fails, use -Y option to specify SASL mechanisms

$ kinit [email protected] for [email protected]: password$ klistTicket cache: FILE:/tmp/krb5cc_780Default principal: [email protected]

Valid starting Expires Service principal11/28/02 19:20:15 11/29/02 05:20:15krbtgt/[email protected]

$ ldapmodify -a -H ldap://master.plainjoe.org/ \> -f testuser.ldifSASL/GSSAPI authentication startedSASL username: [email protected] SASL SSL: 56SASL installing layersadding new entry “cn=test user,ou=people,dc=plainjoe,dc=org”

$ klistTicket cache: FILE:/tmp/krb5cc_780 Default principal: [email protected]

Valid starting Expires Service principal11/28/02 19:20:15 11/29/02 05:20:15krbtgt/[email protected]/28/02 19:23:34 11/29/02 05:20:15ldap/[email protected]

$ kinit [email protected] for [email protected]: password$ klistTicket cache: FILE:/tmp/krb5cc_780Default principal: [email protected]

Valid starting Expires Service principal11/28/02 19:20:15 11/29/02 05:20:15krbtgt/[email protected]

$ ldapmodify -a -H ldap://master.plainjoe.org/ \> -f testuser.ldifSASL/GSSAPI authentication startedSASL username: [email protected] SASL SSL: 56SASL installing layersadding new entry “cn=test user,ou=people,dc=plainjoe,dc=org”

$ klistTicket cache: FILE:/tmp/krb5cc_780 Default principal: [email protected]

Valid starting Expires Service principal11/28/02 19:20:15 11/29/02 05:20:15krbtgt/[email protected]/28/02 19:23:34 11/29/02 05:20:15ldap/[email protected]

SASL and OpenLDAP● Client can obtain list of supported mechanisms by

querrying server's rootDSE and viewing supportedSASLMechanisms attribute

● Example definition in slapd.conf that allows principal jerry to edit the mail attribute for all users in the people organizational unit:

access to dn=”.*,ou=people,dc=plainjoe,dc=org” attrs=mail

by “uid=jerry,cn=gssapi,cn=auth” write

Date post:	30-Jan-2016
Category:	Documents
View:	230 times
Download:	0 times

OpenLDAP Directory Administration Replication, Referrals, Searching, and SASL Explained.

Documents