Skip to content, navigation.
Missed the Jan. 27 webcasts on the strategy for Oracle + Sun identity management products, including directory products?
In the webcast on Identity Management you find an 18-minute, Flash-based update that answers quite a few of the questions specifically for that software portfolio.
Webcasts for all the other products are available as well.
Wajih Ahmed writes in his blog entry from yesterday on Improving DSEE7 Import Rate Through ZFS Caching about how good a file system ZFS can be for Directory, and how to tune your pool when you have a lot of entries to import from LDIF. Wajih finds the primary cache to be very important to speeding up import. In his blog he describes how he tuned ZFS for best performance, including an appendix with all the nitty gritty details.
In December and early January, Brad Diggs took DSEE 7.0 into Sun's Benchmark Center to evaluate performance and scalability on Sun's latest hardware including F20 PCIe flash cards.
Brad's first write up describes how much DSEE 7 compression rocks, "Reducing
storage footprint by more than 50% and extending search performance by more than 50%." All the key results are explained in detail. Brad provides the commands to run to get the benefits from DSEE 7.0 in your lab or production environment. A must read for all of you aiming to get the best results from Directory Server 7.0, and to get the most out of your server hardware.
More great work by Sun's Directory Services team. 
Sun OpenDS Standard Edition 2.2 is available for download as announced.
OpenDS 2.2.0 is now also available for download. Congratulations to the team and the community!
As Ludo writes, OpenDS 2.2.0 brings a number of enhancements to your favorite pure Java, open source LDAP directory server, from better import support to remote server management in the console, to fractional replication, and an external changelog.
You can install OpenDS directly from your browser through the Java Web Start installer. The OpenDS Wiki for 2.2.0 is almost finished as well.
At the same time, Sun OpenDS Standard Edition 2.2 builds on OpenDS technology to bring additional directory proxy features including global index functionality to scale write capacity. Get it at http://www.sun.com/software/products/directory_srvr_ee/get.jsp. Sun of course can support your deployment on Sun OpenDS Standard Edition.
This entry covers registering servers and components as Windows Services,
so you no longer need to start them by hand on reboot.
Install as described in Installing Directory Server Enterprise Edition 7.0.
Log on as Administrator or a member of the local group of Administrators.
Register Directory Server instances.
This same procedure also works with dpadm for Directory Proxy instances.
C:\Program Files\Sun\dsee7\bin>dsadm stop C:\DirectoryServer Directory Server instance 'C:/DirectoryServer' stopped C:\Program Files\Sun\dsee7\bin>dsadm enable-service --type WIN_SERVICE C:\DirectoryServer Instance C:/DirectoryServer registered in WIN_SERVICE C:\Program Files\Sun\dsee7\bin>dsadm info C:\DirectoryServer Instance Path: C:/DirectoryServer Non-secure port: 1389 Secure port: 1636 Bit format: 32-bit State: Stopped DSCC url: - Windows service registration: Enabled Instance version: D-A10
Do not forget the DSCC Registry instance.
C:\Program Files\Sun\dsee7\bin>dsadm stop ..\var\dcc\ads Directory Server instance 'C:/Program Files/Sun/dsee7/var/dcc/ads' stopped C:\Program Files\Sun\dsee7\bin>dsadm enable-service --type WIN_SERVICE ..\var\dcc\ads Instance C:/Program Files/Sun/dsee7/var/dcc/ads registered in WIN_SERVICE
Register your Application Server as a Windows Service.
How to do this depends on your Application Server. With GlassFish this was so easy I have already forgotten.
Register the Common Agent Container as a Windows Service.
C:\Program Files\Sun\dsee7\bin>cacaoadm enable --instance default --file pwd.txt
The pwd.txt file contains the password of the current user, such as Administrator.
Important Note: As of this writing, Nov. 20, 2009, Sun is still working on an issue with Common Agent Container in DSEE 7.0 that can crash upon system restart. So until there's a service pack for that, you will need to restart the Common Agent Container by hand after reboot.
This entry takes you through Directory Server Enterprise Edition
installation on Windows Server 2008, showing screen shots taken while installing
Directory Service Control Center with Directory Server and Directory
Proxy Server on a Windows system. I wrote a similar entry for DSEE 6.0 in March 2007.
Downloading Directory Server Enterprise Edition
You can download Directory Server Enterprise Edition 7.0 from http://www.sun.com/software/products/directory_srvr_ee/get1.jsp.
To install Directory Server Enterprise Edition, get the Windows .zip file, DSEE.7.0.Windows-X86-zip.zip.
Note that DSEE 7.0 processes run as 32-bit applications on Windows systems.
Installing Directory Server Enterprise Edition Software
Note that the files are now installed under C:\Program Files\Sun\dsee7\.
Setting Up Directory Service Control Center Components
Before you can create Directory Server and Directory Proxy Server instances through the DSCC console, you must set up the DSCC console (a web app housed in an application server such as GlassFish, Tomcat, or WebLogic that I expect you to have installed already), and set up the DSCC agent (a local service residing in the Common Agent Container, aka Cacao, that allows you to access servers, in particular to start them when they are stopped, and so forth).
Note that on Windows 2008 if you are not Administrator, you cannot register the DSCC Agent in the Common Agent Container until you set the following Windows registry keys to 0:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableInstallerDetection HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA
The procedure below worked with GlassFish v2.1.
// Permissions for Directory Service Control Center
grant codeBase "file:${com.sun.aas.instanceRoot}/applications/j2ee-modules/dscc7/-"
{
permission java.security.AllPermission;
};
Creating a Directory Server Instance
Time to create a directory to hold sample data.
Before going further, add a dc=example,dc=com suffix, and import sample data into the Directory Server instance just created.
Creating a Directory Proxy Server Instance
Next, create a proxy that could be used instead of allowing direct access to the directory.
Finally, you can use DSCC to configure the proxy to send requests to the Directory Server instance.
Trying It Out
Directory Server Enterprise Edition is delivered with command line tools for accessing the directory service. For example, the ldapsearch tool installed here in C:\Program Files\Sun\dsee7\dsrk\bin, allows you to see that the search functionality is working as expected.
First, search Directory Server on port 1389 to verify the data is there. Then, search through Directory Proxy Server on port 9389 to make sure the proxy is properly configured.
Note that you can now access Directory Server data through Directory Proxy Server, and that you can manage both servers through Directory Service Control Center.
Congratulations to the DSEE 7.0 team!
Sun Directory Server Enterprise Edition 7.0 released today. You can download the software for your platform at http://www.sun.com/software/products/directory_srvr_ee/get1.jsp.
The documentation should follow shortly at http://docs.sfbay.sun.com/app/docs/coll/1819.1.
As Ludo mentions in his announcement about RC 1 for OpenDS 2.2, this release adds external changelog access. Directory applications access the changelog to follow what updates are happening to directory data, and so find the changelog useful when aiming to stay synchronized.
Rob Byrne, who has been stitching together big identity deployments for the last few years, writes about how Sun Identity Manager seems to work fine with the OpenDS changelog, just as it does with the Sun Directory Server changelog. Rob hasn't tested every case, but it looks promising.
Last Oct. 21, Neil Gandhi and Nick Wooler offered a Webinar for you on improving compliance, access control, and performance with Sun's latest releases of Role Manager and Directory Server Enterprise Edition.
The presentation is available at https://slx.sun.com/limelight/filevault/1179275769/0/RM5_DSEE7_Customer_Webinar_Presentation_v5.pdf.
Some Q&A are covered in an additional file at https://slx.sun.com/limelight/filevault/1179275769/3/DSRM_Q_A.pdf.
The OpenDS server on my laptop is using a self-signed cert. This entry briefly describes using StartTLS to avoid sending passwords over the network in clear text, despite having a certificate that does not check out, because like a CA cert it is self-signed (and free as in beer).
This is certainly not for production. Instead here is a workaround for testing with the self-signed cert. Thanks to pataisjsu for posting this link, http://marc.info/?l=php-windows&m=116127873321748&w=2, on the PHP ldap_start_tls() function page.
You set up an ldap.conf file to let StartTLS proceed even if the server certificate does not check out with the client application.
C:\>echo %LDAPCONF% C:\openldap\sysconf\ldap.conf
TLS_REQCERT never
ldap_set_option($ldapconn, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_start_tls($ldapconn) or die("StartTLS failed.");
That's it. Happy testing.
An earlier entry demonstrating LDAP Basics with Java uses an unsecured LDAP connection even for authentication. Someone who gets the packets could get the passwords when users do simple authentication. So that scheme will not work in some environments.
One way to get around the problem is to enable SSL (LDAPS) on the LDAP server, and then connect over SSL. If you have official certificates recognized by your Java development kit, moving from an unsecured to a secure SSL connection is as easy as changing the LDAP URL you use to connect. For example, if your Java code currently uses this JNDI:
int port = 389; // Default for LDAP env.put(Context.PROVIDER_URL, "ldap://" + server + ":" + port + "/");
You need only make sure port is pointing to the SSL port, by default 636 instead of 389, and add an s:
int port = 636; // Default for LDAPS env.put(Context.PROVIDER_URL, "ldaps://" + server + ":" + port + "/");
The OpenDS server on my laptop is using a self-signed cert for testing. I found a blog entry on how to get that cert easily into %JAVA_HOME%\jre\lib\security\jssecacerts. See http://blogs.sun.com/andreas/entry/no_more_unable_to_find and the InstallCert.java code posted there.
The laptop has hostname FR-MCRAIG-01, so here is how I got the OpenDS server cert into the keystore.
C:\Program Files\Java\jdk1.6.0_10\jre\lib\security>java InstallCert FR-MCRAIG-01:1636 Loading KeyStore C:\Program Files\Java\jdk1.6.0_10\jre\lib\security\cacerts... Opening connection to FR-MCRAIG-01:1636... Starting SSL handshake... ... Server sent 1 certificate(s): 1 Subject CN=FR-MCRAIG-01, O=OpenDS Self-Signed Certificate Issuer CN=FR-MCRAIG-01, O=OpenDS Self-Signed Certificate sha1 c8 65 09 20 6d cd ce 49 74 79 94 db c5 de c0 9e 88 22 bf 2e md5 91 00 22 b5 af af ce 6f 18 4f d0 53 2a 25 25 79 Enter certificate to add to trusted keystore or 'q' to quit: [1] 1 [ [ Version: V3 Subject: CN=FR-MCRAIG-01, O=OpenDS Self-Signed Certificate Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5 Key: Sun RSA public key, 1024 bits modulus: 959636547431068463830836243017478926177556680160559342022702329015019 40821365387949638940708183584259305099964566669834719666082227059496757860621285 33579944708236976067614804323567219627938381230112392624635758595410619743902787 1114358806677720711353274033441757994535828245906353046883352879347380951654609 public exponent: 65537 Validity: [From: Tue Aug 04 15:35:44 CEST 2009, To: Thu Aug 04 15:35:44 CEST 2011] Issuer: CN=FR-MCRAIG-01, O=OpenDS Self-Signed Certificate SerialNumber: [ 4a783930] ] Algorithm: [SHA1withRSA] Signature: 0000: 60 21 E2 C0 09 D5 11 C8 80 91 55 44 A3 C3 D2 39 `!........UD...9 0010: 37 04 89 76 31 0E 40 9F 11 6D 79 E9 CB 14 1D 63 7..v1.@..my....c 0020: 6B 7B 0E 2A DF 74 18 BD 59 07 44 73 72 C0 D3 EA k..*.t..Y.Dsr... 0030: 61 E1 A7 79 90 EE 73 AB A0 40 FF F7 A9 F5 CA 0B a..y..s..@...... 0040: 6E FE 81 14 E3 1B 5C 50 83 96 9B B7 23 8C 8C ED n.....\P....#... 0050: 7D 1C 22 BA DF 20 8D F4 82 8D 72 20 2C 31 41 3D ..".. ....r ,1A= 0060: 36 01 95 78 23 C2 46 56 D1 9E DC E4 22 E9 0E A9 6..x#.FV...."... 0070: 99 2E 27 EC 96 D4 41 F2 C0 7A 89 2D 02 AF FB F5 ..'...A..z.-.... ] Added certificate to keystore 'jssecacerts' using alias 'FR-MCRAIG-01-1'
In InstallCert.java the default passphrase is changeit. In addition to the change of port number and the use of ldaps:// instead of ldap://, I added this Java to the top of the conf.jsp in the application posted.
// Use the keystore that contains the OpenDS cert
String keystorePath = System.getProperty("java.home") +
"\\lib\\security\\jssecacerts";
System.setProperty("javax.net.ssl.keyStore", keystorePath);
System.setProperty("javax.net.ssl.keyStorePassword", "changeit");
Hope it helps.
The OpenDS server on my laptop is using a self-signed cert. The trick to using StartTLS -- to avoid sending passwords over the network in clear text -- seems to be telling the underlying software to consider this self-signed cert as a CA cert.
Perhaps not safe for production, but seems to work for testing.
C:\>more opends-cert.pem -----BEGIN CERTIFICATE----- MIIB3zCCAUigAwIBAgIESng5szANBgkqhkiG9w0BAQUFADA0MRswGQYDVQQKExJP cGVuRFMgQ2VydGlmaWNhdGUxFTATBgNVBAMTDEZSLU1DUkFJRy0wMTAeFw0wOTA4 MDQxMzM3NTVaFw0yOTA3MzAxMzM3NTVaMDQxGzAZBgNVBAoTEk9wZW5EUyBDZXJ0 aWZpY2F0ZTEVMBMGA1UEAxMMRlItTUNSQUlHLTAxMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQCNnnsxIx7dBdx79Ny7b9uptn+db6eu8qHoGDfaTBFOoEU+Sl7f AW9g3ArSD67kKkmTZnZl/uonSM7+1Mni32/7HyrEQvkZDr1DfndUDG8eVkaP1u/D XcZNPpEGizchFR+vXbCcA45KZFr54/JakdUAABxlevlfrhlo5N5sQH8HIQIDAQAB MA0GCSqGSIb3DQEBBQUAA4GBAErAmCUBeBvKCaL2wPeulPz0HoyumFfdC21LAid7 x2tq7EuniCBEiz1mt04sIRYB2iBKPOQ5uIcQXEpo4zllM1yIeCXretWFzr7EhzsF JlyZRJIaOe5IdkTm9XHENeLACveYd25QsUVClDTPVZHe0AOsH6X2xHQHMCIwSwuw 9pl4 -----END CERTIFICATE-----
>>> import ldap
>>> ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, ldap.OPT_X_TLS_NEVER)
>>> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,"C:\opends-cert.pem")
>>> l = ldap.initialize("ldap://FR-MCRAIG-01:1389")
>>> l.set_option(ldap.OPT_PROTOCOL_VERSION, 3)
>>> l.set_option(ldap.OPT_X_TLS,ldap.OPT_X_TLS_DEMAND)
>>> l.start_tls_s()
>>> l.simple_bind_s('uid=kvaughan,ou=people,dc=example,dc=com','bribery')
(97, [])
>>> l.whoami_s()
'dn:uid=kvaughan,ou=People,dc=example,dc=com'
>>>
If you cannot figure out what hostname is in the self-signed server cert, have a look with ldapsearch.
D:\SunOpenDS_SE2.0\bat>ldapsearch --useStartTLS -p 1389 -b dc=example,dc=com uid=bjensen The server is using the following certificate: Subject DN: CN=FR-MCRAIG-01, O=OpenDS Self-Signed Certificate Issuer DN: CN=FR-MCRAIG-01, O=OpenDS Self-Signed Certificate Validity: Tue Aug 04 15:35:44 CEST 2009 through Thu Aug 04 15:35:44 CEST 2011 Do you wish to trust this certificate and continue connecting to the server? Please enter "yes" or "no":yes dn: uid=bjensen,ou=People,dc=example,dc=com ...
In 2006 Ludo helped me
compose a list of LDAP best practices for a developer guide I was
writing for Sun. This chapter of the guide was removed before
publication.
Many client libraries default to LDAP v2, but you can elect to use LDAP v3. To benefit from LDAP v3 features, you can set up the connection, and then authenticate explicitly using LDAP v3.
With JNDI, you could use LDAP v3 as shown here.
import java.util.Hashtable;
import javax.naming.ldap.InitialLdapContext;
Hashtable env = new Hashtable();
env.put("java.naming.ldap.version", "3");
InitialLdapContext ctx = new InitialLdapContext(env, null);
|
With the Mozilla LDAP C SDK, you could use LDAP v3 as shown here.
#include "ldap.h" int version = LDAP_VERSION3; ldap_set_option( NULL, LDAP_OPT_PROTOCOL_VERSION, &version ); |
Mozilla LDAP C SDK uses LDAP v3 by default.
With the Mozilla LDAP Java SDK, you could use LDAP v3 as shown here.
import netscape.ldap.LDAPConnection; LDAPConnection ld = new LDAPConnection(); ld.setOption(LDAPv3.PROTOCOL_VERSION, new Integer(3)); |
In LDAP v3, you connect, then you bind and perform LDAP operations, then you unbind and disconnect. The bind is the authentication operation in LDAP. Your application can hold onto a connection but change the authentication credentials by using the bind operation again.
Some directories do not allow anonymous access, even for reads. When you build your application, keep the option that allows users to authenticate to the directory. Furthermore, the information sent across the network can be sensitive. You can protect sensitive data by allowing the application to secure the connection by using Secure Sockets Layer (SSL) or Start Transport Layer Security (TLS).
If your application needs to authenticate, obtain a regular account to authenticate with the directory, rather than using the directory superuser account (such as cn=Directory Manager). When you authenticate as directory superuser, you bypass normal access control mechanisms. Bypassing normal access control renders auditing directory access more difficult.
When authenticating, have your application use SSL or SASL DIGEST MD5 to avoid sending passwords over the network in clear text. Furthermore, when using password-based authentication, have your application check password policy controls, especially to determine when a password must be renewed.
A new connection requires system resources. The LDAP model allows you to reuse connections by binding again with a different identity on the same connection. Thus, you can avoid the costs of new connections, particularly negotiated connections such as connections that use SSL, by reusing connections. Your application can use a pool of connections, rebinding when necessary. Your application can alternatively use the proxy authorization control to remain authenticated as the application but perform operations on behalf of a particular user.
When establishing a connection, your application can provide alternate server host names and port numbers to facilitate failover that is transparent to the application. You can also set time limits for LDAP operations to avoid getting blocked.
When finished with a connection, your application should perform an unbind.
Most network equipment can use timeouts to drop stale connections, ensuring the equipment keeps a maximum number of connections that are available.
If your application pools connections or opens connections for persistent search, than guard against timeouts that drop those connections. Use the connections occasionally to reset inactivity timers present in the network.
Alternatively, if you have control over the connection, consider disabling inactivity time outs for your applications that need to keep persistent connections open. Load balancers and proxy software often use inactivity timeouts.
LDAP servers typically respond quickly to requests for entries. Yet, the server can respond most quickly when your application asks it to do only necessary work. If you need to read only a few attributes in an entry, request each attribute explicitly. Avoid reading the entire entry, then parsing the entire entry to obtain the required data.
Furthermore, when you do request attributes in an entry, retrieve all the required attributes at once. Each new request involves a new operation on the server.
If any of the attributes that you require are operational attributes, you must request those attributes specifically. With Sun Directory Server, operational attributes are identifiable in the directory schema by their USAGE, which is directoryOperation or dsaOperation.
When retrieving entries and attributes, recognize that you might not have access to all the attributes that exist.
The best filters use attributes that are indexed according to the way the attributes are indexed. For example, if employeeNumber is indexed for equality, your filter should be an equality filter such as (employeeNumber=12345). Do not use a substring filter instead.
Avoid deeply nested complex filters when you can. When you must use complex filters, place the most specific filters first to narrow the list of candidate entries the directory must check. For best results, use not, !, only with and, &, for example (&(cn=Barbara)(!(sn=Jensen))). When you use not with or in a filter, the directory must construct a candidate list of everything except what your filter specifies.
Modifications are atomic on the entry to which the modifications apply. When modifying multivalued attributes, delete and replace specific values. Do not replace an entire list of multiple values to change only a few values. Replacing specific values is particularly good practice when the changes must be replicated across a set of servers.
Moreover, when you have very large values to store in an attribute, store a reference to the data instead of storing the data object.
LDAP replication trades tight consistency across replica servers for very high performance, availability, and scalability. By allowing loose consistency of data across sets of replica servers, individual servers can respond very quickly to your application. Yet, data replication is not instantaneous. A short but detectable delay can ensue after a server returns success for a write operation, but before the effects are seen on other replicas.
Therefore, when your application receives a result code from an LDAP to indicate that an operation was successful, your application should trust the result code. When application requests are balanced across replicas, reading from another replica might result in errors due to a slight delay in replication.
Directory administrators can get around applications that do not
trust
result codes for example by configuring Sun Directory Proxy Server to
apply server
affinity, which routes operations from the same client to the same
server.
For static groups, Sun Directory Server and OpenDS offer the isMemberOf attribute on the user entry. With Sun Directory Server 5.x versions, compare the DN of the account to the uniqueMember attribute of the group, such as (uniquemember=uid=bjensen,ou=people,dc=example,dc=com). Or use a filter to find all the static groups to which a user belongs, such as (&(member=uid=bjensen,ou=people,dc=example,dc=com)(objectclass=groupofnames)).
For dynamic groups, do the following:
Read the URL from the group definition.
Examine the host, DN, and scope of the URL.
Apply the filter part of the URL to the entry for the account.
For Sun Directory Server roles, compare the DN of the role to the nsRole attribute of the entry for the account, such as (nsrole=cn=management,ou=people,dc=example,dc=com).
Some directory administrators protect access to the root DSE. Yet, applications might read the root DSE to confirm that the server in fact supports functionality required by applications.
Directories offer powerful features that can nevertheless place a heavy load on the server. Two such features are persistent search, and server-side sorting.
Persistent search lets you start a search that does not stop when complete, but instead allows you to receive updates when entries are modified. To provide this feature, the server must handle your search when anything happens to an entry in its scope.
Server-side sorting requires that the server sort the entries that are returned during a search. Instead of returning entries as quickly as possible, the server must therefore get the list to return, and sort the list.
The container entry for a subtree might be not be identical on different directories. Rather than hard code the container entry throughout your application, locate the container entry. Then navigate beneath the container entry in the tree.
Object classes and attribute types for the same information can also differ from directory to directory. Use configuration files, properties files, or other easily modifiable variables rather than hard coding object class and attribute type identifiers into your application.
Be aware as well that object class and attribute type identifiers are not case-sensitive in LDAP. Your application should therefore recognize that inetOrgPerson and inetorgperson are equivalent, as are isMemberOf and ismemberof.
When you must define your own schema objects, follow these guidelines:
Extend existing object classes by using AUXILIARY classes.
Create new attributes rather than redefining existing attributes.
Other applications might depend on existing attributes to keep their existing semantics.
Obtain new object identifiers for the schema elements you define, rather than reusing existing object identifiers.
Obtain new names for the schema elements you define, rather than reusing existing names.
Update schema over LDAP if you can.
When following referrals, realize that authentication procedures might not be exactly the same on different directories. Also, directories that refer to each other could potentially cause a referral loop. With the Mozilla Directory SDKs, you can limit referral hops to prevent your application from being referred endlessly from one directory to another directory. The JNDI interface enables you to follow referrals automatically.
A directory is typically a repository for identity data, and for information that you expect to keep for awhile and read often. You might typically find relational databases better adapted to hold transient data such as session keys and presence information, or voluminous accumulated data such as application logs.
|
1 |
LDAP operations error. The server encountered an error while processing your request. |
|
32 |
No such object. The entry is not present on the server. Also, no referral is defined for the entry. |
|
49 |
Invalid credentials. Your application failed to authenticate properly. |
|
53 |
LDAP unwilling to perform. The directory does not support the request. Alternatively, the directory is not currently in a state in which to complete your request. For example, the directory might be in read-only mode when your application requests a modification. |
|
65 |
Object class violation. Your write request would cause an entry to no longer conform to the schema defined for the directory. |
|
68 |
Already exists. Your application is requesting to add an entry that has the same DN as an entry already present in the directory. |
RFC 4511 defines LDAP error codes.
OpenDS and Sun Directory Server log messages related to server
operation in its instance-path/logs/errors
file. If you have access
to this file, you might find useful troubleshooting information there.
When debugging your application against Sun Directory Server, you can
adjust the log level using the dsconf set-log-prop error level:your-setting
command. Log level settings are explained
in the log(5dsconf) man
page. If you use OpenDS, see https://www.opends.org/wiki/page/HowToConfigureLogsWithDsconfig.
Although LDAP is not a textual protocol, tools such as snoop(1M), ethereal, and tcpdump can decode the packets, sometimes providing you with important debugging information. SLAMD also provides an LDAP decoder to display LDAP packets in human-readable format.
(How many of those rules did I break in Java, PHP, and Python? ;-)
This blog copyright 2010 by mcraig
