Data format
The standard text format for LDAP data is in LDAP Date Interchange Format (LDIF).
Each line has an attribute name, then a colon and a space, and the value of the attribute.
Operacions
There are only three basic types of LDAP operations, and each basic type has a few subtypes:
- interrogation (search, compare),
- updating (add, modify, rename, delete),
- and binding/control (bind, unbind, abandon).
Notice there is no "read" operation; if you want to read an entry, you use a search operation to retrieve it.
Nomenclatura
An entry can look like this when represented in LDAP Data Interchange Format (LDIF):
dn: cn=John Doe,dc=example,dc=com
cn: John Doe
givenName: John
sn: Doe
telephoneNumber: +1 888 555 6789
telephoneNumber: +1 888 555 1232
mail: john@example.com
manager: cn=Barbara Doe,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
"dn" is the distinguished name of the entry; it's neither an attribute nor a part of the entry.
"cn=John Doe" is the entry's RDN (Relative Distinguished Name), and "dc=example,dc=com" is the DN of the parent entry,
Attribute names are typically mnemonic strings, like "cn" for common name, "dc" for domain component, "mail" for e-mail address and "sn" for surname.
Wiki
The dn is how an entry is uniquely referred to within an LDAP server,
similar to an absolute path name or a fully qualified domain name.
Notice that the dn is represented similarly to DNS names, with the most specific information first,
as opposed to path names, which have the least specific information first.
Contrary to how it looks, the root of this LDAP tree, also called the "naming context," is dc=domain,dc=com, not dc=com.
There are no requirements about what you name the root of your LDAP tree,
but there are two standards:
either the standard I've followed here, which breaks a domain into its various domain components,
or one where an organization is referred to at the top level (for example, o=domain.com).
The concept of an object in LDAP is extremely simple:
it merely defines what attributes an entry must have and what attributes an entry is allowed to have.
All object classes inherit requirements from their parent object classes and add their own.
Schema
A schema is a set of rules that governs the way that data can be stored in the directory.
The schema defines the type of entries allowed, their attribute structure, and the syntax of the attributes.
The IBM Tivoli Directory Server Version 5.2 includes dynamic schema support.
The schema is published as part of the directory information, and is available in the Subschema entry (DN="cn=schema").
To retrieve schema information, you can perform an ldap_search by using the following:
DN: "cn=schema", search scope: base, filter: objectclass=subschema or objectclass=*
The following command exports the schema to an LDIF file called schemaout.ldif.
ldapsearch -L -h <ipaddress> -p <port> -b "cn=schema, <suffix>" objectclass=* > schemaout.ldif
How to obtain the Domino LDAP Schema
LDAPSEARCH -h hostname -b "cn=schema" -s base "(objectclass=subschema)"
The resulting output will be very large, and will detail the entire LDAP schema of the Domino server.
LDAPSEARCH -h hostname -L -b "cn=schema" -s base "(objectclass=subschema)" * + > out.txt
Note that the -L will output the results in LDIF format.
Domino LDAP schema
ldapsearch
Comes in "Domino" directory, and requires nnotes.dll.
Aldo, in c:\openLDAP\bin !
c:\> ldapsearch -v -LLLh blupages.hal.com -b ou=blupages,o=hal.com "mail=egasit@es.hal.com" cn notesMailServer
ldap_sslinit( blupages.hal.com, 389 )
filter pattern: mail=egasit@es.hal.com
returning: cn notesMailServer
*** Filter is: (mail=egasit@es.hal.com) ***
dn: uid=016450888,c=es,ou=blupages,o=hal.com
cn: Elisbet Gasit Pitori
notesMailServer: CN=T06ML981/OU=06/OU=M/O=HAL
1 matches
display all entries
The "objectclass=*" attribute applies to all entries in the directory:
c:\> ldapsearch -v -LLLh portal.demos.hal.com "objectClass=*" cn
. . . 369 matches
Authentication error message
Use "-x" to solve this error :
ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
more commands
ldapsearch -h portal.demos.ibm.com "cn=wpsadmin"
ldapsearch -h portal.demos.ibm.com "objectClass=*"
ldapsearch -A -h portal.demos.ibm.com "objectClass=*"
ldapsearch -h portal.demos.ibm.com "objectClass=*" cn
ldapsearch -s onelevel -h portal.demos.ibm.com "objectClass=*"
ldapsearch -s base -h portal.demos.ibm.com "objectClass=*"
ldapsearch -z 5 -h portal.demos.ibm.com "objectClass=*"
GSA intro
IBM provides
10 GB.
GSA provides file and directory service for UNIX platforms.
Linux will be configured to access the GSA file service using NFS and automount.
The directory service is accessed using LDAP.
Ho poso al
TP760
amb
SuSE 8.1
Linux
instructions.
The gsa-client RPM has the following dependencies :
- autofs
- nfs-utils
- nss_ldap
- openldap-clients
- openssl
All OK with SuSE 8.1 !
linuxTP760:/home/sebas # rpm -i --test gsa-client-1.4-3.i386.rh72.rpm
error: failed dependencies:
libcrypto.so.2 is needed by gsa-client-1.4-3
libssl.so.2 is needed by gsa-client-1.4-3
Using
RpmFind, we find we need :
libcrypto.so.2 => openssl096b-0.9.6b-6.i386.rpm
libssl.so.2 => openssl096b-0.9.6b-6.i386.rpm
rpm -i --test /media/cdrom/suse/i586/openssl-0.9.6g-18.i586.rpm
package openssl-0.9.6g-18.i586.rpm is already installed
rpm -q -q | grep openssl
openssl-0.9.6g-18
rpm -q -l openssl-0.9.6g-18 | grep libssl
/usr/lib/libssl.0
/usr/lib/libssl.0.9.6
ln -s libssl.so.0.9.6 libssl.so.2
ln -s libcrypto.so.0.9.6 libcrypto.so.2
linuxTP760:/home/sebas # rpm -i --nodeps gsa-client-1.4-3.i386.rh72.rpm
/usr/bin/gsaclient_config must be run to configure your client
linuxTP760:/home/sebas # gsaclient_config
cell: 7 (pokgsa)
mount option: 1 (hard)
use GSA LDAP: 1 (yes) configure NSSWITCH
use GSA PAM: 1 (yes) configure PAM
GSA users: (blank) => all
Install pdksh package recommended
GSA client configuration complete
altemir@linuxTP760:/home/altemir # cd /gsa/pokgsa
altemir@linuxTP760:/gsa/pokgsa # df
1K-blocks Used Available Mounted on
pokgsa.hal.com:/gsa/pokgsa 692.846.592 95.458.688 597.387.904 14% /gsa/pokgsa
altemir@linuxTP760:/gsa/pokgsa # dir
drwxr-xr-x 3 root root 2048 2001-09-26 22:51 .home
drwxr-xr-x 3 root root 2048 2001-09-26 22:51 .projects
drwxr-xr-x 28 root root 2048 2001-09-26 22:51 home
drwxr-xr-x 28 root root 2048 2001-09-26 22:51 projects
drwxr-xr-x 3 root root 2048 2001-09-26 22:51 system
drwxrwxr-x 10 root bin 2048 2001-09-26 22:51 tdisk
altemir@linuxTP760:/home/sebas # gsa-login
GSA password:
Successfully authenticadet altemir@pokgsa.hal.com
"GSA tools" - W95 + Netscape : 10 GB at /gsa/pokgsa/home/a/l/altemir
altemir@linuxTP760:/home/sebas # cd /gsa/pokgsa/home/a/l/altemir
altemir@linuxTP760:/gsa/pokgsa/home/a/l/altemir # mkdir prova
altemir@linuxTP760:/gsa/pokgsa/home/a/l/altemir # dir
drwxr-s--x 2 altemir altemir 2048 2003-05-26 12:06 prova
drwxrwsr-x 2 altemir altemir 2048 2003-05-17 14:08 web
Accés via WS_FTP : host pokgsa.hal.com gives access to
/pokgsa/.home/h1/altemir, exactament el directori de dalt.
Pàgina resultant :
http://pokgsa.hal.com/home/a/l/altemir/web/public/uno.htm
