LDAP System Administration by Gerald Carter The unconfirmed error reports are from readers. They have not yet been approved or disproved by the author or editor and represent solely the opinion of the reader. Here's a key to the markup: [page-number]: serious technical mistake {page-number}: minor technical mistake : important language/formatting problem (page-number): language change or minor formatting problem ?page-number?: reader question or request for clarification This page was updated March 13, 2007. UNCONFIRMED errors and comments from readers: (14) Figure 2-2's figure title; I think the figure title for figure 2-2 shouldn't describe the RDNs pictured as multivalued. The description that precedes the figure suggests that this is a restructuring of the DIT to avoid multivalued RDNs. (41) 2nd full para; 3rd line; ...bit flags that can be logically ORed together. should probably be: ...bit flags that can be logically read together. (Maybe "read" isn't the proper word, but "ORed" definitely isn't.) {48} 3rd paragraph; The example "security update_sasl=128,update_tls=128" is incorrect. It should read "security update_sasl=128 update_tls=128" (blank instead of comma). cf slapd.conf man page : "require Specify a set of conditions (separated by white space) to require (default none).(...)" {54} 1st code example; The comment in the code snippet states "## Maintain presence and equality searches on the cn and uid attributes." yet the following line of code only only refers to cn and not uid. {55} code example; The comment preceeding the 'rootdn' entry states "This is the Base64-encoded MD5 hash of "secret"; this comment does not pertain to 'rootdn', it might pertain to the following 'rootpw' entry. [57,121] first line and examples (57) vs. first ex. (121); attrs vs. attr page 57, use of attrs in ACL page 121, use of attr in ACL man and doc talk about "attrs" but i tested with "attr" and it works (OpenLDAP 2.1.22)... [67-68] Last entry on page, top of next page; On RH 9, using openldap 2.1.22, creating the root directory exactly as instructed by the book would produce the error: "slapadd: could not parse entry", for the OU specification. When I removed the people ou, and just had the organisation in the file, it accepted. I then started the database anew, save this time instead of making the *company* an ou, as the book (and example files online) strangely tell you to do, I made the company an o, and the division an ou. They were both thus accepted without problems: dn: dc=epixmed,dc=com objectClass: dcObject objectClass: organization dc: epixmed o: Epix Medical description: Epix Medical ## Discovery Dept. dn: ou=Discovery,dc=epixmed,dc=com ou: Discovery objectClass: organizationalUnit |ldap:/usr/local/var/openldap/raw-db-data| root# slapadd -v -l epix-root.ldif added: "dc=epixmed,dc=com" (00000001) added: "ou=Discovery,dc=epixmed,dc=com" (00000002) {70} "list of attributes to return" paragraph; "To limit the result to a few specific attributes, list the attributes you want on the command line, separated by commas." should read: "To limit the result to a few specific attributes, list the attributes you want on the command line, separated by blanks." (90) $ldapadd...; >ou:people must be >ou:hosts [92] about -C option; The option -C is not seen in the example, not in manpage either... (94) $ldapsearch ...; > -w n0pass must be > -w secret (98) $ldapmodify ...; > -f testuser.ldif must be > -f /tmp/test.ldif (cf. pg 97) {105} fig. 6-3; Optional are not correct From nis.schema (OpenLDAP 2.1.22) must: cn,uid,uidNumber,gidNumber,homedirectory may: userPassword,loginShell,gecos,description [143] below 1st paragraph, 2nd directory entry block; I feel, the second directory entry has a mistake on the page 143. (the section on sendmail aliases integration with LDAP) the second directory entry look like this: dn: sendmailMTAKey=postmaster,ou=aliases,ou=sendmail, ou=services,dc=plainjoe,dc=org objectClass: sendmailMTAAliasObject sendmailMTAAliasValue: /dev/null sendmailMTAKey: nobody I feel it should be like this: dn: sendmailMTAKey=nobody,ou=aliases,ou=sendmail, ou=services,dc=plainjoe,dc=org objectClass: sendmailMTAAliasObject sendmailMTAAliasValue: /dev/null sendmailMTAKey: nobody difference is nobody will replace postmaster on the first line of the entry. [144] 1st example in section "Mail routing using LDAP"; "The following virtual user table entry would route messages that are addressed to joe@foo.com to the host somehost.foo.com: joe@foo.com somehost.foo.com" The above is incorrect. Without LDAP, Sendmail (v8.13.1) cannot achieve the above. The default "virtualuser table" cannot forward an address to another host without re- writing the address, e.g: joe@foo.com joe@somehost.foo.com {147} 3rd paragraph example code; The example code $ /usr/sbin/sendmail -bt > /parse kcarter@plainjoe.org should be $ echo '/parse kcarter@plainjoe.org' | /usr/sbin/sendmail -bt [167] 2nd paragraph; ldap filter = "(&(uid=%U)(objectclass=sambaAccont))" quite simply doesn't work. It's noted that it is the default, but you never get any entries returned by that command, as its sent as (uid=)(objectclass=sambaAccont), which doesn't return anything. If it is not included in the configuration file, the _Real_ default is used, which works. [196] 3rd paragraph (just below figurer 9-1); The text refers to selecting "Properties" on the "Users" icon in paragraph 2. Paragraph 3 then begins a process of selecting a "Security Tab". However, there is no such tab for the "Users" folder in Active Directory under Windows 2003 (the version that I have). Windows 2000 is out of date and no errata/corrections/updates are found on this web site as to how to proceed with interoperability using Active Directory under Windows 2003.