- openldap-bugs - openldap.org

(ITS#6158) syncprov: assert causing slapd to core dump
by jonathan＠phillipoux.net 02 Jun '09

02 Jun '09

Full_Name: Jonathan Clarke Version: 2.3.43 OS: Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.243.192) Hi, I have a 2.3.43 running on a Solaris Sparc server, which crashes occasionally - once every week or two, always during the night. At this particular time a large number of operations are performed, including mass deletes and adds. I haven't been able to reproduce this bug, just watch it happen on the production server every now and again... I managed to obtain a coredump, and a backtrace (at the end of this message). I realize this isn't much to go on, but I'm rather unfamiliar with this part of the code, so I wondered if anyone has an idea what's going on here? FWIW, the dynlist and chain overlays are in use on the server, and the database is bdb, with a syncrepl consumer as well as syncprov overlay. Backtrace follows: 8<------------------------------------------------------------- Thread 1 (process 1054014 ): #0 0xfee4aa58 in _lwp_kill () from /lib/libc.so.1 #1 0xfede5a64 in raise () from /lib/libc.so.1 #2 0xfedc1954 in abort () from /lib/libc.so.1 #3 0xfedc1b90 in _assert () from /lib/libc.so.1 #4 0xff30ef44 in ldap_pvt_runqueue_resched (rq=0x16c630, entry=0xee6c0a0, defer=0) at rq.c:165 #5 0xfe7f4a94 in syncprov_qstart (so=0x10acb540) at syncprov.c:933 #6 0xfe7f4d6c in syncprov_qresp (opc=0x1b1bfaf8, so=0x10acb540, mode=2) at syncprov.c:982 #7 0xfe7f5aa4 in syncprov_matchops (op=0xf6bffa50, opc=0x1b1bfaf8, saveit=0) at syncprov.c:1175 #8 0xfe7f7490 in syncprov_op_response (op=0xf6bffa50, rs=0xf6bff644) at syncprov.c:1561 #9 0x000575cc in ?? () #10 0x000575cc in ?? () 8<------------------------------------------------------------- Thanks in advance for any pointers! Regards, Jonathan

1 0

Re: (ITS#6133) back-relay issues
by h.b.furuseth＠usit.uio.no 01 Jun '09

01 Jun '09

Questions: * relay_back_operational() sets up callbacks. Should it? Looks harmless, but as far as I can tell, be->be_operational() functions do not use them, since they (should) send no response. * There is no relay_back_chk_controls(). Should there be? Though I think DNs would then be rewritten four times the same way for each operation:-( Already operational, has_subordinates and finally the operation itself does. And possibly for access controls. I've factored op.c code out to table-driven handlers and a macro, and cleaned away those '#if 0's. Fixed more problems: * Search referrals should have a scope. * relay_back_op_extended() was (still) broken. The handler should return a result which caller should send, so it must set sr->sr_ref without freeing it. Setting REP_REF_MUSTBEFREED instead, and droping the RB_SEND requirement in fail_mode. * For readability, fixed return values from relay_back_chk_referrals() and other unused handlers. (chk_referrals may be unfixable.) * relay_back_entry_<get/release>_rw() returned operationsError for failure. Failing with noSuchObject/unwillingToPerform instead. * relay_back_entry_release_rw() leaked entries when bd->be_release==0. For paranoia, fixed it only when the entry's e_private == NULL. > * The handlers for Abandon, Cancel and connection-init/destroy > should not exist, as far as I can tell. They forward the call to the > underlying backend database, but that means it receives the call twice: So does Unbind. Removed the handler. > * back-relay can be configured to cause infinite recursion. (...) > Anyway, recursion can now be properly caught with op->o_extra. (...) Needed a unique key per <operation type, relay database> combination. Otherwise things like backend_group() called from another operation failed when looking up a relayed DN via relay_back_entry_get_rw(). That fixed relay_back_operational() and relay_back_has_subordinates(), or at least I assume that's what their FIXMEs were about. -- Hallvard

1 0

Re: (ITS#6131) "TLSVerifyClient try" not working with GNU TLS
by subbarao＠computer.org 01 Jun '09

01 Jun '09

Howard Chu wrote: >> I was just looking around for a possible explanation to the problem that >> I'm encountering. >> >> I double-checked the version that I was running and it's actually >> 2.4.15, not 2.4.16. Would there be a significant difference between >> these two versions with respect to TLS certificate handling? > > Yes. Read the 2.4.16 CHANGES. Ok, I see the following: Fixed libldap GnuTLS TLSVerifyCilent try (ITS#5981) Looking at ITS #5981, that seems to be exactly the same problem that I'm having. I tried searching the openldap.org site before for similar keywords, but I guess I missed this. Thanks, -Kartik

1 0

Re: (ITS#6131) "TLSVerifyClient try" not working with GNU TLS
by hyc＠symas.com 01 Jun '09

01 Jun '09

Kartik Subbarao wrote: > Howard Chu wrote: >> This bug report makes no sense; the code you quoted is not part of >> OpenLDAP 2.4.16. The relevant code is in function tlsg_session_accept() >> in tls_g.c, and there is no such bug in that function. > > Well, according to the CVS head branch, the code that I cited in tls.c > is still there: > > http://www.openldap.org/devel/cvsweb.cgi/~checkout~/libraries/libldap/tls.c… > > But I certainly defer to your knowledge of which code is relevant Read the Makefile; tls.c is not used any more. > -- I > was just looking around for a possible explanation to the problem that > I'm encountering. > > I double-checked the version that I was running and it's actually > 2.4.15, not 2.4.16. Would there be a significant difference between > these two versions with respect to TLS certificate handling? Yes. Read the 2.4.16 CHANGES. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6131) "TLSVerifyClient try" not working with GNU TLS
by subbarao＠computer.org 01 Jun '09

01 Jun '09

Howard Chu wrote: > This bug report makes no sense; the code you quoted is not part of > OpenLDAP 2.4.16. The relevant code is in function tlsg_session_accept() > in tls_g.c, and there is no such bug in that function. Well, according to the CVS head branch, the code that I cited in tls.c is still there: http://www.openldap.org/devel/cvsweb.cgi/~checkout~/libraries/libldap/tls.c… But I certainly defer to your knowledge of which code is relevant -- I was just looking around for a possible explanation to the problem that I'm encountering. I double-checked the version that I was running and it's actually 2.4.15, not 2.4.16. Would there be a significant difference between these two versions with respect to TLS certificate handling? Again, here is the error I'm getting on the server side with TLSVerifyClient set to "try" and I do an ldapsearch over SSL without a client certificate: TLS: gnutls_certificate_verify_peers2 failed -49 TLS: can't accept: (unknown error code). connection_read(24): TLS accept failure error=-1 id=3, closing Thanks, -Kartik

1 0

(ITS#6157) unAbandonable operations aren't.
by h.b.furuseth＠usit.uio.no 01 Jun '09

01 Jun '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard RFCs 3909 (Cancel) and 4511 (LDAP protocol) say some operations cannot be cancelled/abandoned: Abandon, Bind, Unbind, StartTLS, Cancel. Clients can cancel least Cancel. That lets a client deadlock slapd, or all slapd threads but one, by spamming slapd with pairs of Cancels that cancel each other. If both are started, each waits for the other. Also cn=config operations need to be at least unCancelable: The same happens if you send pairs of (cn=config op, Cancel that op). Regarding Cancel, one fix resembling current code would be: * Before an operation waits for (an)other operation(s): - Fail if o_cancel, and if o_abandon when the op is abandonable, - Make it uncancellable: set o_cancel = tooLate even when !o_abandon. * Cancel and Abandon operations: - Fail if the targeted operation already has tooLate/cannotCancel. Actually Cancel already does, but with wrong result code + message. I include Abandon to keep the number of cancel/abandon-related states down. Also, (o_abandon, o_cancel) = (1, tooLate) would otherwise mean two things with the fix above: The op was Cancelled but completed anyway, or the op was Abandoned and is uncancellable (but not necessarily unabandonable).

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by Kurt＠OpenLDAP.org 01 Jun '09

01 Jun '09

On Jun 1, 2009, at 4:30 AM, michael(a)stroeder.com wrote: > This is a multi-part message in MIME format. > --------------080004030402080700020504 > Content-Type: text/plain; charset=3DISO-8859-1 > Content-Transfer-Encoding: 8bit > > Updated schema file cosine-update.schema attached. I note that differs are generally preferred, even where the file is =20 mostly changed. This helps ensure changes that others might make to =20 the file you started with are not lost. > Note that some schema > descriptions were copied from old cosine.schema to preserve backward > compability since RFC 4524 does not contain all schema descriptions =20= > e.g. > needed for 'pilotPerson'. Note that 'pilotPerson' is used as superior > class for 'OpenLDAPperson'. Also some aliases were added to NAME of > attribute type descriptions. > > IPR notice: > This patch file is derived from OpenLDAP Software and RFC 4524 and RFC > 1274. All of the modifications to OpenLDAP Software represented in the > attached file were developed by Michael Str=F6der =20 > <michael(a)stroeder.com>. > I have not assigned rights and/or interest in this work to any party. While this notice of origin is fine, you did not include a rights =20 statement. > > > --------------080004030402080700020504 > Content-Type: text/plain; > name=3D"cosine-update.schema" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline; > filename=3D"cosine-update.schema" > > # RFC 4524: COSINE LDAP/X.500 Schema > # $OpenLDAP: pkg/ldap/servers/slapd/schema/cosine.schema,v 1.26 =20 > 2009/01/21 23:40:40 kurt Exp $ > ## This work is part of OpenLDAP Software <http://www.openldap.org/>. > ## > ## Copyright 1998-2009 The OpenLDAP Foundation. > ## All rights reserved. > ## > ## Redistribution and use in source and binary forms, with or without > ## modification, are permitted only as authorized by the OpenLDAP > ## Public License. > ## > ## A copy of this license is available in the file LICENSE in the > ## top-level directory of the distribution or, alternatively, at > ## <http://www.OpenLDAP.org/license.html>. > # > # RFC 4524: COSINE LDAP/X.500 Schema > # This file is mainly based on the schema descriptions found in RFC =20= > 4524. > # To preserve backwards compability with 'pilotPerson' schema some =20 > attribute > # types and object classes not declared in RFC 4524 were copied from > # (obsoleted) RFC 1274 and some attribute type descriptions were =20 > extended > # with aliases for NAME. > # > # Depends on core.schema > > # =20 > = --------------------------------------------------------------------------= > # 2. COSINE Attribute Types > # =20 > = --------------------------------------------------------------------------= > # > # This section details COSINE attribute types for use in LDAP. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.1. associatedDomain > # > # The 'associatedDomain' attribute specifies DNS [RFC1034][RFC2181] > # host names [RFC1123] that are associated with an object. That =20= > is, > # values of this attribute should conform to the following ABNF: > # > # domain =3D root / label *( DOT label ) > # root =3D SPACE > # label =3D LETDIG [ *61( LETDIG / HYPHEN ) LETDIG ] > # LETDIG =3D %x30-39 / %x41-5A / %x61-7A ; "0" - "9" / "A"-"Z" / =20= > "a"-"z" > # SPACE =3D %x20 ; space (" ") > # HYPHEN =3D %x2D ; hyphen ("-") > # DOT =3D %x2E ; period (".") > # > # For example, the entry in the DIT with a DN <DC=3Dexample,DC=3Dcom>= =20 > might > # have an associated domain of "example.com". > # > # (OpenLDAP-specific: Declared in core.schema) > # attributetype ( 0.9.2342.19200300.100.1.37 > # NAME 'associatedDomain' > # EQUALITY caseIgnoreIA5Match > # SUBSTR caseIgnoreIA5SubstringsMatch > # SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > # > # The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the > # 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are > # described in [RFC4517]. > # > # Note that the directory will not ensure that values of this =20 > attribute > # conform to the <domain> production provided above. It is the > # application's responsibility to ensure that domains it stores =20 > in this > # attribute are appropriately represented. > # > # Also note that applications supporting Internationalized Domain =20= > Names > # SHALL use the ToASCII method [RFC3490] to produce <label> =20 > components > # of the <domain> production. > > # =20 > = --------------------------------------------------------------------------= > # 2.2. associatedName > # > # The 'associatedName' attribute specifies names of entries in the > # organizational DIT associated with a DNS domain [RFC1034]=20 > [RFC2181]. > # > > attributetype ( 0.9.2342.19200300.100.1.38 > NAME 'associatedName' > EQUALITY distinguishedNameMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) > > # > # The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax =20 > and the > # 'distinguishedNameMatch' rule are described in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.3. buildingName > # > # The 'buildingName' attribute specifies names of the buildings =20 > where > # an organization or organizational unit is based, for example, =20 > "The > # White House". > # > > attributetype ( 0.9.2342.19200300.100.1.48 > NAME 'buildingName' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.4. co > # > # The 'co' (Friendly Country Name) attribute specifies names of > # countries in human-readable format, for example, "Germany" and > # "Federal Republic of Germany". It is commonly used in =20 > conjunction > # with the 'c' (Country Name) [RFC4519] attribute (whose values are > # restricted to the two-letter codes defined in [ISO3166]). > # > > attributetype ( 0.9.2342.19200300.100.1.43 > NAME 'co' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.5. documentAuthor > # > # The 'documentAuthor' attribute specifies the distinguished =20 > names of > # authors (or editors) of a document. For example, > # > > attributetype ( 0.9.2342.19200300.100.1.14 > NAME 'documentAuthor' > EQUALITY distinguishedNameMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) > > # > # The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax =20 > and the > # 'distinguishedNameMatch' rule are described in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.6. documentIdentifier > # > # The 'documentIdentifier' attribute specifies unique identifiers =20= > for a > # document. A document may be identified by more than one unique > # identifier. For example, RFC 3383 and BCP 64 are unique =20 > identifiers > # that (presently) refer to the same document. > # > > attributetype ( 0.9.2342.19200300.100.1.11 > NAME 'documentIdentifier' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.7. documentLocation > # > # The 'documentLocation' attribute specifies locations of the =20 > document > # original. > # > > attributetype ( 0.9.2342.19200300.100.1.15 > NAME 'documentLocation' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.8. documentPublisher > # > # The 'documentPublisher' attribute is the persons and/or =20 > organizations > # that published the document. Documents that are jointly =20 > published > # have one value for each publisher. > # > > attributetype ( 0.9.2342.19200300.100.1.56 > NAME 'documentPublisher' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.9. documentTitle > # > # The 'documentTitle' attribute specifies the titles of a document. > # Multiple values are allowed to accommodate both long and short > # titles, or other situations where a document has multiple =20 > titles, for > # example, "The Lightweight Directory Access Protocol Technical > # Specification" and "The LDAP Technical Specification". > # > > attributetype ( 0.9.2342.19200300.100.1.12 > NAME 'documentTitle' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.10. documentVersion > # > # The 'documentVersion' attribute specifies the version =20 > information of > # a document. > # > > attributetype ( 0.9.2342.19200300.100.1.13 > NAME 'documentVersion' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.11. drink > # > # The 'drink' (favouriteDrink) attribute specifies the favorite =20 > drinks > # of an object (or person), for instance, "cola" and "beer". > # > > attributetype ( 0.9.2342.19200300.100.1.5 > NAME ( 'drink' 'favouriteDrink' ) > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.12. homePhone > # > # The 'homePhone' (Home Telephone Number) attribute specifies home > # telephone numbers (e.g., "+1 775 555 1234") associated with a =20 > person. > # > > attributetype ( 0.9.2342.19200300.100.1.20 > NAME ( 'homePhone' 'homeTelephoneNumber' ) > EQUALITY telephoneNumberMatch > SUBSTR telephoneNumberSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) > > # > # The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and =20= > the > # 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' =20 > rules are > # described in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.13. homePostalAddress > # > # The 'homePostalAddress' attribute specifies home postal =20 > addresses for > # an object. Each value should be limited to up to 6 directory =20 > strings > # of 30 characters each. (Note: It is not intended that the =20 > directory > # service enforce these limits.) > # > > attributetype ( 0.9.2342.19200300.100.1.39 > NAME 'homePostalAddress' > EQUALITY caseIgnoreListMatch > SUBSTR caseIgnoreListSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) > > # > # The PostalAddress (1.3.6.1.4.1.1466.115.121.1.41) syntax and the > # 'caseIgnoreListMatch' and 'caseIgnoreListSubstringsMatch' rules =20= > are > # described in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.14. host > # > # The 'host' attribute specifies host computers, generally by their > # primary fully qualified domain name (e.g., my-host.example.com). > # > > attributetype ( 0.9.2342.19200300.100.1.9 > NAME 'host' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.15. info > # > # The 'info' attribute specifies any general information =20 > pertinent to > # an object. This information is not necessarily descriptive of =20= > the > # object. > # > # Applications should not attach specific semantics to values of =20= > this > # attribute. The 'description' attribute [RFC4519] is available =20= > for > # specifying descriptive information pertinent to an object. > # > > attributetype ( 0.9.2342.19200300.100.1.4 > NAME 'info' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{2048} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.16. mail > # > # The 'mail' (rfc822mailbox) attribute type holds Internet mail > # addresses in Mailbox [RFC2821] form (e.g., user(a)example.com). > # > # (OpenLDAP-specific: Declared in core.schema) > # attributetype ( 0.9.2342.19200300.100.1.3 > # NAME 'mail' > # EQUALITY caseIgnoreIA5Match > # SUBSTR caseIgnoreIA5SubstringsMatch > # SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) > # > # The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the > # 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are > # described in [RFC4517]. > # > # Note that the directory will not ensure that values of this =20 > attribute > # conform to the <Mailbox> production [RFC2821]. It is the > # application's responsibility to ensure that domains it stores =20 > in this > # attribute are appropriately represented. > # > # Additionally, the directory will compare values per the matching > # rules named in the above attribute type description. As these =20= > rules > # differ from rules that normally apply to <Mailbox> comparisons, > # operational issues may arise. For example, the assertion > # (mail=3Djoe(a)example.com) will match "JOE(a)example.com" even though = =20 > the > # <local-parts> differ. Also, where a user has two <Mailbox>es =20 > whose > # addresses differ only by case of the <local-part>, both cannot be > # listed as values of the user's mail attribute (as they are =20 > considered > # equal by the 'caseIgnoreIA5Match' rule). > # > # Also note that applications supporting internationalized domain =20= > names > # SHALL use the ToASCII method [RFC3490] to produce <sub-domain> > # components of the <Mailbox> production. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.17. manager > # > # The 'manager' attribute specifies managers, by distinguished =20 > name, of > # the person (or entity). > # > > attributetype ( 0.9.2342.19200300.100.1.10 > NAME 'manager' > EQUALITY distinguishedNameMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) > > # > # The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax =20 > and the > # 'distinguishedNameMatch' rule are described in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.18. mobile > # > # The 'mobile' (mobileTelephoneNumber) attribute specifies mobile > # telephone numbers (e.g., "+1 775 555 6789") associated with a =20 > person > # (or entity). > # > > attributetype ( 0.9.2342.19200300.100.1.41 > NAME ( 'mobile' 'mobileTelephoneNumber' ) > EQUALITY telephoneNumberMatch > SUBSTR telephoneNumberSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) > > # > # The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and =20= > the > # 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' =20 > rules are > # described in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.19. organizationalStatus > # > # The 'organizationalStatus' attribute specifies categories by =20 > which a > # person is often referred to in an organization. Examples of =20 > usage in > # academia might include "undergraduate student", "researcher", > # "professor", and "staff". Multiple values are allowed where the > # person is in multiple categories. > # > # Directory administrators and application designers SHOULD =20 > consider > # carefully the distinctions between this and the 'title' and > # 'userClass' attributes. > # > > attributetype ( 0.9.2342.19200300.100.1.45 > NAME 'organizationalStatus' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.20. pager > # > # The 'pager' (pagerTelephoneNumber) attribute specifies pager > # telephone numbers (e.g., "+1 775 555 5555") for an object. > # > > attributetype ( 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 ) > > # > # The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and =20= > the > # 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' =20 > rules are > # described in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.21. personalTitle > # > # The 'personalTitle' attribute specifies personal titles for a =20 > person. > # Examples of personal titles are "Frau", "Dr.", "Herr", and > # "Professor". > # > > attributetype ( 0.9.2342.19200300.100.1.40 > NAME 'personalTitle' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.22. roomNumber > # > # The 'roomNumber' attribute specifies the room number of an =20 > object. > # During periods of renumbering, or in other circumstances where =20= > a room > # has multiple valid room numbers associated with it, multiple =20 > values > # may be provided. Note that the 'cn' (commonName) attribute type > # SHOULD be used for naming room objects. > # > > attributetype ( 0.9.2342.19200300.100.1.6 > NAME 'roomNumber' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.23. secretary > # > # The 'secretary' attribute specifies secretaries and/or =20 > administrative > # assistants, by distinguished name. > # > > attributetype ( 0.9.2342.19200300.100.1.21 > NAME 'secretary' > EQUALITY distinguishedNameMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) > > # > # The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax =20 > and the > # 'distinguishedNameMatch' rule are described in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.24. uniqueIdentifier > # > # The 'uniqueIdentifier' attribute specifies a unique identifier =20= > for an > # object represented in the Directory. The domain within which the > # identifier is unique and the exact semantics of the identifier =20= > are > # for local definition. For a person, this might be an =20 > institution- > # wide payroll number. For an organizational unit, it might be a > # department code. > # > > attributetype ( 0.9.2342.19200300.100.1.44 > NAME 'uniqueIdentifier' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > # Note: X.520 also describes an attribute called 'uniqueIdentifier' > # (2.5.4.45), which is called 'x500UniqueIdentifier' in LDAP > # [RFC4519]. The attribute detailed here ought not be =20 > confused > # with 'x500UniqueIdentifier'. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.25. userClass > # > # The 'userClass' attribute specifies categories of computer or > # application user. The semantics placed on this attribute are for > # local interpretation. Examples of current usage of this =20 > attribute in > # academia are "student", "staff", and "faculty". Note that the > # 'organizationalStatus' attribute type is now often preferred, =20 > as it > # makes no distinction between persons as opposed to users. > # > > attributetype ( 0.9.2342.19200300.100.1.8 > NAME 'userClass' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > > # =20 > = --------------------------------------------------------------------------= > # Attribute types from RFC 1274 which are missing in RFC 4524 > # =20 > = --------------------------------------------------------------------------= > # > # 9.3.2. Text Encoded O/R Address > # > # The Text Encoded O/R Address attribute type specifies a text =20 > encoding > # of an X.400 O/R address, as specified in RFC 987. The use of this > # attribute is deprecated as the attribute is intended for interim =20= > use > # only. This attribute will be the first candidate for the attribute > # expiry mechanisms! > # > # textEncodedORAddress ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # caseIgnoreStringSyntax > # (SIZE (1 .. ub-text-encoded-or-address)) > # ::=3D {pilotAttributeType 2} > # > > attributetype ( 0.9.2342.19200300.100.1.2 > NAME 'textEncodedORAddress' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # =20 > = --------------------------------------------------------------------------= > # 9.3.7. Photo > # > # The Photo attribute type specifies a "photograph" for an object. > # This should be encoded in G3 fax as explained in recommendation T.=20= > 4, > # with an ASN.1 wrapper to make it compatible with an X.400 =20 > BodyPart as > # defined in X.420. > # > # IMPORT G3FacsimileBodyPart FROM { mhs-motis ipms modules > # information-objects } > # > # photo ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # CHOICE { > # g3-facsimile [3] G3FacsimileBodyPart > # } > # (SIZE (1 .. ub-photo)) > # ::=3D {pilotAttributeType 7} > # > > attributetype ( 0.9.2342.19200300.100.1.7 > NAME 'photo' > DESC 'RFC1274: photo (G3 fax)' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.23{25000} ) > > # =20 > = --------------------------------------------------------------------------= > # 9.3.18. Other Mailbox > # > # The Other Mailbox attribute type specifies values for electronic > # mailbox types other than X.400 and rfc822. > # > # otherMailbox ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # SEQUENCE { > # mailboxType PrintableString, -- e.g. Telemail > # mailbox IA5String -- e.g. X378:Joe > # } > # ::=3D {pilotAttributeType 22} > # > > attributetype ( 0.9.2342.19200300.100.1.22 > NAME 'otherMailbox' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.39 ) > > # =20 > = --------------------------------------------------------------------------= > # 9.3.22. DNS ARecord > # > # The A Record attribute type specifies a type A (Address) DNS =20 > resource > # record [6] [7]. > # > # aRecord ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # DNSRecordSyntax > # ::=3D {pilotAttributeType 26} > # > ## incorrect syntax? > attributetype ( 0.9.2342.19200300.100.1.26 > NAME 'aRecord' > EQUALITY caseIgnoreIA5Match > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > > ## missing from RFC1274 > ## incorrect syntax? > attributetype ( 0.9.2342.19200300.100.1.27 > NAME 'mDRecord' > EQUALITY caseIgnoreIA5Match > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > > # =20 > = --------------------------------------------------------------------------= > # 9.3.23. MX Record > # > # The MX Record attribute type specifies a type MX (Mail Exchange) =20= > DNS > # resource record [6] [7]. > # > # mXRecord ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # DNSRecordSyntax > # ::=3D {pilotAttributeType 28} > # > ## incorrect syntax!! > attributetype ( 0.9.2342.19200300.100.1.28 > NAME 'mXRecord' > EQUALITY caseIgnoreIA5Match > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > > # =20 > = --------------------------------------------------------------------------= > # 9.3.24. NS Record > # > # The NS Record attribute type specifies an NS (Name Server) DNS > # resource record [6] [7]. > # > # nSRecord ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # DNSRecordSyntax > # ::=3D {pilotAttributeType 29} > # > ## incorrect syntax!! > > attributetype ( 0.9.2342.19200300.100.1.29 > NAME 'nSRecord' > EQUALITY caseIgnoreIA5Match > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > > # =20 > = --------------------------------------------------------------------------= > # 9.3.25. SOA Record > # > # The SOA Record attribute type specifies a type SOA (Start of > # Authority) DNS resorce record [6] [7]. > # > # sOARecord ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # DNSRecordSyntax > # ::=3D {pilotAttributeType 30} > # > ## incorrect syntax!! > > attributetype ( 0.9.2342.19200300.100.1.30 > NAME 'sOARecord' > EQUALITY caseIgnoreIA5Match > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > > # =20 > = --------------------------------------------------------------------------= > # 9.3.26. CNAME Record > # > # The CNAME Record attribute type specifies a type CNAME (Canonical > # Name) DNS resource record [6] [7]. > # > # cNAMERecord ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # iA5StringSyntax > # ::=3D {pilotAttributeType 31} > # > ## incorrect syntax!! > > attributetype ( 0.9.2342.19200300.100.1.31 > NAME 'cNAMERecord' > EQUALITY caseIgnoreIA5Match > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > > # =20 > = --------------------------------------------------------------------------= > # 9.3.36. Janet Mailbox > # > # The Janet Mailbox attribute type specifies an electronic mailbox > # attribute following the syntax specified in the Grey Book of the > # Coloured Book series. This attribute is intended for the =20 > convenience > # of U.K users unfamiliar with rfc822 and little-endian mail =20 > addresses. > # Entries using this attribute MUST also include an rfc822Mailbox > # attribute. > # > # janetMailbox ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # caseIgnoreIA5StringSyntax > # (SIZE (1 .. ub-janet-mailbox)) > # ::=3D {pilotAttributeType 46} > # > attributetype ( 0.9.2342.19200300.100.1.46 > NAME 'janetMailbox' > DESC 'RFC1274: Janet mailbox' > EQUALITY caseIgnoreIA5Match > SUBSTR caseIgnoreIA5SubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) > > # =20 > = --------------------------------------------------------------------------= > # 9.3.37. Mail Preference Option > # > # An attribute to allow users to indicate a preference for =20 > inclusion of > # their names on mailing lists (electronic or physical). The absence > # of such an attribute should be interpreted as if the attribute was > # present with value "no-list-inclusion". This attribute should be > # interpreted by anyone using the directory to derive mailing lists, > # and its value respected. > # > # mailPreferenceOption ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX ENUMERATED { > # no-list-inclusion(0), > # any-list-inclusion(1), -- may be added to any lists > # professional-list-inclusion(2) > # -- may be added to lists > # -- which the list provider > # -- views as related to the > # -- users professional inter- > # -- ests, perhaps evaluated > # -- from the business of the > # -- organisation or keywords > # -- in the entry. > # } > # ::=3D {pilotAttributeType 47} > # > > attributetype ( 0.9.2342.19200300.100.1.47 > NAME 'mailPreferenceOption' > DESC 'RFC1274: mail preference option' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) > > # =20 > = --------------------------------------------------------------------------= > # 9.3.43. Personal Signature > # > # The Personal Signature attribute type allows for a representation =20= > of > # a person's signature. This should be encoded in G3 fax as =20 > explained > # in recommendation T.4, with an ASN.1 wrapper to make it compatible > # with an X.400 BodyPart as defined in X.420. > # > # IMPORT G3FacsimileBodyPart FROM { mhs-motis ipms modules > # information-objects } > # > # personalSignature ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # CHOICE { > # g3-facsimile [3] G3FacsimileBodyPart > # } > # (SIZE (1 .. ub-personal-signature)) > # ::=3D {pilotAttributeType 53} > # > > attributetype ( 0.9.2342.19200300.100.1.53 > NAME 'personalSignature' > DESC 'RFC1274: Personal Signature (G3 fax)' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.23 ) > > # =20 > = --------------------------------------------------------------------------= > # 9.3.45. Audio > # > # The Audio attribute type allows the storing of sounds in the > # Directory. The attribute uses a u-law encoded sound file as used =20= > by > # the "play" utility on a Sun 4. This is an interim format. > # > # audio ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # Audio > # (SIZE (1 .. ub-audio)) > # ::=3D {pilotAttributeType 55} > # > > attributetype ( 0.9.2342.19200300.100.1.55 > NAME 'audio' > DESC 'RFC1274: audio (u-law)' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.4{25000} ) > > > # =20 > = --------------------------------------------------------------------------= > # 3. COSINE Object Classes > # =20 > = --------------------------------------------------------------------------= > # > # This section details COSINE object classes for use in LDAP. > # > > # =20 > = --------------------------------------------------------------------------= > # 3.1. account > # > # The 'account' object class is used to define entries representing > # computer accounts. The 'uid' attribute SHOULD be used for naming > # entries of this object class. > # > > objectclass ( 0.9.2342.19200300.100.4.5 > NAME 'account' > SUP top STRUCTURAL > MUST uid > MAY ( description $ seeAlso $ l $ o $ ou $ host ) ) > > # > # The 'top' object class is described in [RFC4512]. The =20 > 'description', > # 'seeAlso', 'l', 'o', 'ou', and 'uid' attribute types are =20 > described in > # [RFC4519]. The 'host' attribute type is described in Section 2 =20= > of > # this document. > # > # Example: > # > # dn: uid=3Dkdz,cn=3DAccounts,dc=3DExample,dc=3DCOM > # objectClass: account > # uid: kdz > # seeAlso: cn=3DKurt D. Zeilenga,cn=3DPersons,dc=3DExample,dc=3DCO= M > # > > # =20 > = --------------------------------------------------------------------------= > # 3.2. document > # > # The 'document' object class is used to define entries that =20 > represent > # documents. > # > > objectclass ( 0.9.2342.19200300.100.4.6 > NAME 'document' > SUP top STRUCTURAL > MUST documentIdentifier > MAY ( cn $ description $ seeAlso $ l $ o $ ou $ > documentTitle $ documentVersion $ documentAuthor $ > documentLocation $ documentPublisher ) ) > > # > # The 'top' object class is described in [RFC4512]. The 'cn', > # 'description', 'seeAlso', 'l', 'o', and 'ou' attribute types are > # described in [RFC4519]. The 'documentIdentifier', =20 > 'documentTitle', > # 'documentVersion', 'documentAuthor', 'documentLocation', and > # 'documentPublisher' attribute types are described in Section 2 of > # this document. > # > # Example: > # > # dn: documentIdentifier=3DRFC 4524,cn=3DRFC,dc=3DExample,dc=3DCOM= > # objectClass: document > # documentIdentifier: RFC 4524 > # documentTitle: COSINE LDAP/X.500 Schema > # documentAuthor: cn=3DKurt D. =20 > Zeilenga,cn=3DPersons,dc=3DExample,dc=3DCOM > # documentLocation: http://www.rfc-editor.org/rfc/rfc4524.txt > # documentPublisher: Internet Engineering Task Force > # description: A collection of schema elements for use in LDAP > # description: Obsoletes RFC 1274 > # seeAlso: documentIdentifier=3DRFC = 4510,cn=3DRFC,dc=3DExample,dc=3DCOM > # seeAlso: documentIdentifier=3DRFC = 1274,cn=3DRFC,dc=3DExample,dc=3DCOM > # > > # =20 > = --------------------------------------------------------------------------= > # 3.3. documentSeries > # > # The 'documentSeries' object class is used to define an entry that > # represents a series of documents (e.g., The Request For Comments > # memos). > # > > objectclass ( 0.9.2342.19200300.100.4.9 > NAME 'documentSeries' > SUP top STRUCTURAL > MUST cn > MAY ( description $ l $ o $ ou $ seeAlso $ telephonenumber ) ) > > # > # The 'top' object class is described in [RFC4512]. The =20 > 'description', > # 'l', 'o', 'ou', 'seeAlso', and 'telephoneNumber' attribute =20 > types are > # described in [RFC4519]. > # > # Example: > # > # dn: cn=3DRFC,dc=3DExample,dc=3DCOM > # objectClass: documentSeries > # cn: Request for Comments > # cn: RFC > # description: a series of memos about the Internet > # > > # =20 > = --------------------------------------------------------------------------= > # 3.4. domain > # > # The 'domain' object class is used to define entries that =20 > represent > # DNS domains for objects that are not organizations, =20 > organizational > # units, or other kinds of objects more appropriately defined =20 > using an > # object class specific to the kind of object being defined (e.g., > # 'organization', 'organizationUnit'). > # > # The 'dc' attribute should be used for naming entries of the =20 > 'domain' > # object class. > # > > objectclass ( 0.9.2342.19200300.100.4.13 > NAME 'domain' > SUP top STRUCTURAL > MUST dc > MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ > x121Address $ registeredAddress $ destinationIndicator $ > preferredDeliveryMethod $ telexNumber $ > teletexTerminalIdentifier $ telephoneNumber $ > internationaliSDNNumber $ facsimileTelephoneNumber $ street $ > postOfficeBox $ postalCode $ postalAddress $ > physicalDeliveryOfficeName $ st $ l $ description $ o $ > associatedName ) ) > > # > # The 'top' object class and the 'dc', 'userPassword', =20 > 'searchGuide', > # 'seeAlso', 'businessCategory', 'x121Address', =20 > 'registeredAddress', > # 'destinationIndicator', 'preferredDeliveryMethod', 'telexNumber', > # 'teletexTerminalIdentifier', 'telephoneNumber', > # 'internationaliSDNNumber', 'facsimileTelephoneNumber', 'street', > # 'postOfficeBox', 'postalCode', 'postalAddress', > # 'physicalDeliveryOfficeName', 'st', 'l', 'description', and 'o' =20= > types > # are described in [RFC4519]. The 'associatedName' attribute =20 > type is > # described in Section 2 of this document. > # > # Example: > # > # dn: dc=3Dcom > # objectClass: domain > # dc: com > # description: the .COM TLD > # > > # =20 > = --------------------------------------------------------------------------= > # 3.5. domainRelatedObject > # > # The 'domainRelatedObject' object class is used to define =20 > entries that > # represent DNS domains that are "equivalent" to an X.500 domain, =20= > e.g., > # an organization or organizational unit. > # > > objectclass ( 0.9.2342.19200300.100.4.17 > NAME 'domainRelatedObject' > SUP top AUXILIARY > MUST associatedDomain ) > > # > # The 'top' object class is described in [RFC4512]. The > # 'associatedDomain' attribute type is described in Section 2 of =20= > this > # document. > # > # Example: > # > # dn: dc=3Dexample,dc=3Dcom > # objectClass: organization > # objectClass: dcObject > # objectClass: domainRelatedObject > # dc: example > # associatedDomain: example.com > # o: Example Organization > # > # The 'organization' and 'dcObject' object classes and the 'dc' =20 > and 'o' > # attribute types are described in [RFC4519]. > # > > # =20 > = --------------------------------------------------------------------------= > # 3.6. friendlyCountry > # > # The 'friendlyCountry' object class is used to define entries > # representing countries in the DIT. The object class is used to =20= > allow > # friendlier naming of countries than that allowed by the object =20= > class > # 'country' [RFC4519]. > # > > objectclass ( 0.9.2342.19200300.100.4.18 > NAME 'friendlyCountry' > SUP country STRUCTURAL > MUST co ) > > # > # The 'country' object class is described in [RFC4519]. The 'co' > # attribute type is described in Section 2 of this document. > # > # Example: > # > # dn: c=3DDE > # objectClass: country > # objectClass: friendlyCountry > # c: DE > # co: Deutschland > # co: Germany > # co: Federal Republic of Germany > # co: FRG > # > # The 'c' attribute type is described in [RFC4519]. > # > > # =20 > = --------------------------------------------------------------------------= > # 3.7. rFC822LocalPart > # > # The 'rFC822LocalPart' object class is used to define entries that > # represent the local part of Internet mail addresses [RFC2822]. =20= > This > # treats the local part of the address as a 'domain' object. > # > > objectclass ( 0.9.2342.19200300.100.4.14 > NAME 'rFC822localPart' > SUP domain STRUCTURAL > MAY ( cn $ description $ destinationIndicator $ > facsimileTelephoneNumber $ internationaliSDNNumber $ > physicalDeliveryOfficeName $ postalAddress $ postalCode $ > postOfficeBox $ preferredDeliveryMethod $ registeredAddress $ > seeAlso $ sn $ street $ telephoneNumber $ > teletexTerminalIdentifier $ telexNumber $ x121Address ) ) > > # > # The 'domain' object class is described in Section 3.4 of this > # document. The 'cn', 'description', 'destinationIndicator', > # 'facsimileTelephoneNumber', 'internationaliSDNNumber, > # 'physicalDeliveryOfficeName', 'postalAddress', 'postalCode', > # 'postOfficeBox', 'preferredDeliveryMethod', 'registeredAddress', > # 'seeAlso', 'sn, 'street', 'telephoneNumber', > # 'teletexTerminalIdentifier', 'telexNumber', and 'x121Address' > # attribute types are described in [RFC4519]. > # > # Example: > # > # dn: dc=3Dkdz,dc=3Dexample,dc=3Dcom > # objectClass: domain > # objectClass: rFC822LocalPart > # dc: kdz > # associatedName: cn=3DKurt D. =20 > Zeilenga,cn=3DPersons,dc=3DExample,dc=3DCOM > # > # The 'dc' attribute type is described in [RFC4519]. > # > > # =20 > = --------------------------------------------------------------------------= > # 3.8. room > # > # The 'room' object class is used to define entries representing =20= > rooms. > # The 'cn' (commonName) attribute SHOULD be used for naming =20 > entries of > # this object class. > # > > objectclass ( 0.9.2342.19200300.100.4.7 > NAME 'room' > SUP top STRUCTURAL > MUST cn > MAY ( roomNumber $ description $ seeAlso $ telephoneNumber ) ) > > # > # The 'top' object class is described in [RFC4512]. The 'cn', > # 'description', 'seeAlso', and 'telephoneNumber' attribute types =20= > are > # described in [RFC4519]. The 'roomNumber' attribute type is =20 > described > # in Section 2 of this document. > # > # dn: cn=3Dconference room,dc=3Dexample,dc=3Dcom > # objectClass: room > # cn: conference room > # telephoneNumber: +1 755 555 1111 > # > > # =20 > = --------------------------------------------------------------------------= > # 3.9. simpleSecurityObject > # > # The 'simpleSecurityObject' object class is used to require an =20 > entry > # to have a 'userPassword' attribute when the entry's structural =20= > object > # class does not require (or allow) the 'userPassword attribute'. > # > # (OpenLDAP-specific: Declared in core.schema) > # objectclass ( 0.9.2342.19200300.100.4.19 > # NAME 'simpleSecurityObject' > # SUP top AUXILIARY > # MUST userPassword ) > # > # The 'top' object class is described in [RFC4512]. The =20 > 'userPassword' > # attribute type is described in [RFC4519]. > # > # dn: dc=3Dkdz,dc=3DExample,dc=3DCOM > # objectClass: account > # objectClass: simpleSecurityObject > # uid: kdz > # userPassword: My Password > # seeAlso: cn=3DKurt D. Zeilenga,cn=3DPersons,dc=3DExample,dc=3DCO= M > # > > # =20 > = --------------------------------------------------------------------------= > # Object classes from RFC 1274 which are missing in RFC 4524 > # =20 > = --------------------------------------------------------------------------= > # > # 8.3.2. Pilot Person > # > # The PilotPerson object class is used as a sub-class of person, to > # allow the use of a number of additional attributes to be assigned =20= > to > # entries of object class person. > # > # pilotPerson OBJECT-CLASS > # SUBCLASS OF person > # MAY CONTAIN { > # userid, > # textEncodedORAddress, > # rfc822Mailbox, > # favouriteDrink, > # roomNumber, > # userClass, > # homeTelephoneNumber, > # homePostalAddress, > # secretary, > # personalTitle, > # preferredDeliveryMethod, > # businessCategory, > # janetMailbox, > # otherMailbox, > # mobileTelephoneNumber, > # pagerTelephoneNumber, > # organizationalStatus, > # mailPreferenceOption, > # personalSignature} > # ::=3D {pilotObjectClass 4} > # > > objectclass ( 0.9.2342.19200300.100.4.4 > NAME ( 'pilotPerson' 'newPilotPerson' ) > SUP person STRUCTURAL > MAY ( userid $ textEncodedORAddress $ rfc822Mailbox $ > favouriteDrink $ roomNumber $ userClass $ > homeTelephoneNumber $ homePostalAddress $ secretary $ > personalTitle $ preferredDeliveryMethod $ businessCategory $ > janetMailbox $ otherMailbox $ mobileTelephoneNumber $ > pagerTelephoneNumber $ organizationalStatus $ > mailPreferenceOption $ personalSignature ) ) > > # 8.3.9. DNS Domain > # > # The DNS Domain (Domain NameServer) object class is used to define > # entries for DNS domains. The usage of this object class is =20 > described > # in more detail in [3]. > # > # dNSDomain OBJECT-CLASS > # SUBCLASS OF domain > # MAY CONTAIN { > # ARecord, > # MDRecord, > # MXRecord, > # NSRecord, > # SOARecord, > # CNAMERecord} > # ::=3D {pilotObjectClass 15} > # > > objectclass ( 0.9.2342.19200300.100.4.15 > NAME 'dNSDomain' > SUP domain STRUCTURAL > MAY ( ARecord $ MDRecord $ MXRecord $ NSRecord $ > SOARecord $ CNAMERecord ) ) > > > --------------080004030402080700020504-- > >

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by michael＠stroeder.com 01 Jun '09

01 Jun '09

This is a multi-part message in MIME format. --------------080004030402080700020504 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Updated schema file cosine-update.schema attached. Note that some schema descriptions were copied from old cosine.schema to preserve backward compability since RFC 4524 does not contain all schema descriptions e.g. needed for 'pilotPerson'. Note that 'pilotPerson' is used as superior class for 'OpenLDAPperson'. Also some aliases were added to NAME of attribute type descriptions. IPR notice: This patch file is derived from OpenLDAP Software and RFC 4524 and RFC 1274. All of the modifications to OpenLDAP Software represented in the attached file were developed by Michael Ströder <michael(a)stroeder.com>. I have not assigned rights and/or interest in this work to any party. --------------080004030402080700020504 Content-Type: text/plain; name="cosine-update.schema" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cosine-update.schema" # RFC 4524: COSINE LDAP/X.500 Schema # $OpenLDAP: pkg/ldap/servers/slapd/schema/cosine.schema,v 1.26 2009/01/21 23:40:40 kurt Exp $ ## This work is part of OpenLDAP Software <http://www.openldap.org/>. ## ## Copyright 1998-2009 The OpenLDAP Foundation. ## All rights reserved. ## ## Redistribution and use in source and binary forms, with or without ## modification, are permitted only as authorized by the OpenLDAP ## Public License. ## ## A copy of this license is available in the file LICENSE in the ## top-level directory of the distribution or, alternatively, at ## <http://www.OpenLDAP.org/license.html>. # # RFC 4524: COSINE LDAP/X.500 Schema # This file is mainly based on the schema descriptions found in RFC 4524. # To preserve backwards compability with 'pilotPerson' schema some attribute # types and object classes not declared in RFC 4524 were copied from # (obsoleted) RFC 1274 and some attribute type descriptions were extended # with aliases for NAME. # # Depends on core.schema # -------------------------------------------------------------------------- # 2. COSINE Attribute Types # -------------------------------------------------------------------------- # # This section details COSINE attribute types for use in LDAP. # # -------------------------------------------------------------------------- # 2.1. associatedDomain # # The 'associatedDomain' attribute specifies DNS [RFC1034][RFC2181] # host names [RFC1123] that are associated with an object. That is, # values of this attribute should conform to the following ABNF: # # domain = root / label *( DOT label ) # root = SPACE # label = LETDIG [ *61( LETDIG / HYPHEN ) LETDIG ] # LETDIG = %x30-39 / %x41-5A / %x61-7A ; "0" - "9" / "A"-"Z" / "a"-"z" # SPACE = %x20 ; space (" ") # HYPHEN = %x2D ; hyphen ("-") # DOT = %x2E ; period (".") # # For example, the entry in the DIT with a DN <DC=example,DC=com> might # have an associated domain of "example.com". # # (OpenLDAP-specific: Declared in core.schema) # attributetype ( 0.9.2342.19200300.100.1.37 # NAME 'associatedDomain' # EQUALITY caseIgnoreIA5Match # SUBSTR caseIgnoreIA5SubstringsMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) # # The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the # 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are # described in [RFC4517]. # # Note that the directory will not ensure that values of this attribute # conform to the <domain> production provided above. It is the # application's responsibility to ensure that domains it stores in this # attribute are appropriately represented. # # Also note that applications supporting Internationalized Domain Names # SHALL use the ToASCII method [RFC3490] to produce <label> components # of the <domain> production. # -------------------------------------------------------------------------- # 2.2. associatedName # # The 'associatedName' attribute specifies names of entries in the # organizational DIT associated with a DNS domain [RFC1034][RFC2181]. # attributetype ( 0.9.2342.19200300.100.1.38 NAME 'associatedName' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) # # The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the # 'distinguishedNameMatch' rule are described in [RFC4517]. # # -------------------------------------------------------------------------- # 2.3. buildingName # # The 'buildingName' attribute specifies names of the buildings where # an organization or organizational unit is based, for example, "The # White House". # attributetype ( 0.9.2342.19200300.100.1.48 NAME 'buildingName' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.4. co # # The 'co' (Friendly Country Name) attribute specifies names of # countries in human-readable format, for example, "Germany" and # "Federal Republic of Germany". It is commonly used in conjunction # with the 'c' (Country Name) [RFC4519] attribute (whose values are # restricted to the two-letter codes defined in [ISO3166]). # attributetype ( 0.9.2342.19200300.100.1.43 NAME 'co' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.5. documentAuthor # # The 'documentAuthor' attribute specifies the distinguished names of # authors (or editors) of a document. For example, # attributetype ( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) # # The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the # 'distinguishedNameMatch' rule are described in [RFC4517]. # # -------------------------------------------------------------------------- # 2.6. documentIdentifier # # The 'documentIdentifier' attribute specifies unique identifiers for a # document. A document may be identified by more than one unique # identifier. For example, RFC 3383 and BCP 64 are unique identifiers # that (presently) refer to the same document. # attributetype ( 0.9.2342.19200300.100.1.11 NAME 'documentIdentifier' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.7. documentLocation # # The 'documentLocation' attribute specifies locations of the document # original. # attributetype ( 0.9.2342.19200300.100.1.15 NAME 'documentLocation' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.8. documentPublisher # # The 'documentPublisher' attribute is the persons and/or organizations # that published the document. Documents that are jointly published # have one value for each publisher. # attributetype ( 0.9.2342.19200300.100.1.56 NAME 'documentPublisher' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.9. documentTitle # # The 'documentTitle' attribute specifies the titles of a document. # Multiple values are allowed to accommodate both long and short # titles, or other situations where a document has multiple titles, for # example, "The Lightweight Directory Access Protocol Technical # Specification" and "The LDAP Technical Specification". # attributetype ( 0.9.2342.19200300.100.1.12 NAME 'documentTitle' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.10. documentVersion # # The 'documentVersion' attribute specifies the version information of # a document. # attributetype ( 0.9.2342.19200300.100.1.13 NAME 'documentVersion' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.11. drink # # The 'drink' (favouriteDrink) attribute specifies the favorite drinks # of an object (or person), for instance, "cola" and "beer". # attributetype ( 0.9.2342.19200300.100.1.5 NAME ( 'drink' 'favouriteDrink' ) EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.12. homePhone # # The 'homePhone' (Home Telephone Number) attribute specifies home # telephone numbers (e.g., "+1 775 555 1234") associated with a person. # attributetype ( 0.9.2342.19200300.100.1.20 NAME ( 'homePhone' 'homeTelephoneNumber' ) EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) # # The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the # 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are # described in [RFC4517]. # # -------------------------------------------------------------------------- # 2.13. homePostalAddress # # The 'homePostalAddress' attribute specifies home postal addresses for # an object. Each value should be limited to up to 6 directory strings # of 30 characters each. (Note: It is not intended that the directory # service enforce these limits.) # attributetype ( 0.9.2342.19200300.100.1.39 NAME 'homePostalAddress' EQUALITY caseIgnoreListMatch SUBSTR caseIgnoreListSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) # # The PostalAddress (1.3.6.1.4.1.1466.115.121.1.41) syntax and the # 'caseIgnoreListMatch' and 'caseIgnoreListSubstringsMatch' rules are # described in [RFC4517]. # # -------------------------------------------------------------------------- # 2.14. host # # The 'host' attribute specifies host computers, generally by their # primary fully qualified domain name (e.g., my-host.example.com). # attributetype ( 0.9.2342.19200300.100.1.9 NAME 'host' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.15. info # # The 'info' attribute specifies any general information pertinent to # an object. This information is not necessarily descriptive of the # object. # # Applications should not attach specific semantics to values of this # attribute. The 'description' attribute [RFC4519] is available for # specifying descriptive information pertinent to an object. # attributetype ( 0.9.2342.19200300.100.1.4 NAME 'info' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{2048} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.16. mail # # The 'mail' (rfc822mailbox) attribute type holds Internet mail # addresses in Mailbox [RFC2821] form (e.g., user(a)example.com). # # (OpenLDAP-specific: Declared in core.schema) # attributetype ( 0.9.2342.19200300.100.1.3 # NAME 'mail' # EQUALITY caseIgnoreIA5Match # SUBSTR caseIgnoreIA5SubstringsMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) # # The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the # 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are # described in [RFC4517]. # # Note that the directory will not ensure that values of this attribute # conform to the <Mailbox> production [RFC2821]. It is the # application's responsibility to ensure that domains it stores in this # attribute are appropriately represented. # # Additionally, the directory will compare values per the matching # rules named in the above attribute type description. As these rules # differ from rules that normally apply to <Mailbox> comparisons, # operational issues may arise. For example, the assertion # (mail=joe(a)example.com) will match "JOE(a)example.com" even though the # <local-parts> differ. Also, where a user has two <Mailbox>es whose # addresses differ only by case of the <local-part>, both cannot be # listed as values of the user's mail attribute (as they are considered # equal by the 'caseIgnoreIA5Match' rule). # # Also note that applications supporting internationalized domain names # SHALL use the ToASCII method [RFC3490] to produce <sub-domain> # components of the <Mailbox> production. # # -------------------------------------------------------------------------- # 2.17. manager # # The 'manager' attribute specifies managers, by distinguished name, of # the person (or entity). # attributetype ( 0.9.2342.19200300.100.1.10 NAME 'manager' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) # # The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the # 'distinguishedNameMatch' rule are described in [RFC4517]. # # -------------------------------------------------------------------------- # 2.18. mobile # # The 'mobile' (mobileTelephoneNumber) attribute specifies mobile # telephone numbers (e.g., "+1 775 555 6789") associated with a person # (or entity). # attributetype ( 0.9.2342.19200300.100.1.41 NAME ( 'mobile' 'mobileTelephoneNumber' ) EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) # # The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the # 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are # described in [RFC4517]. # # -------------------------------------------------------------------------- # 2.19. organizationalStatus # # The 'organizationalStatus' attribute specifies categories by which a # person is often referred to in an organization. Examples of usage in # academia might include "undergraduate student", "researcher", # "professor", and "staff". Multiple values are allowed where the # person is in multiple categories. # # Directory administrators and application designers SHOULD consider # carefully the distinctions between this and the 'title' and # 'userClass' attributes. # attributetype ( 0.9.2342.19200300.100.1.45 NAME 'organizationalStatus' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.20. pager # # The 'pager' (pagerTelephoneNumber) attribute specifies pager # telephone numbers (e.g., "+1 775 555 5555") for an object. # attributetype ( 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 ) # # The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the # 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are # described in [RFC4517]. # # -------------------------------------------------------------------------- # 2.21. personalTitle # # The 'personalTitle' attribute specifies personal titles for a person. # Examples of personal titles are "Frau", "Dr.", "Herr", and # "Professor". # attributetype ( 0.9.2342.19200300.100.1.40 NAME 'personalTitle' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.22. roomNumber # # The 'roomNumber' attribute specifies the room number of an object. # During periods of renumbering, or in other circumstances where a room # has multiple valid room numbers associated with it, multiple values # may be provided. Note that the 'cn' (commonName) attribute type # SHOULD be used for naming room objects. # attributetype ( 0.9.2342.19200300.100.1.6 NAME 'roomNumber' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.23. secretary # # The 'secretary' attribute specifies secretaries and/or administrative # assistants, by distinguished name. # attributetype ( 0.9.2342.19200300.100.1.21 NAME 'secretary' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) # # The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the # 'distinguishedNameMatch' rule are described in [RFC4517]. # # -------------------------------------------------------------------------- # 2.24. uniqueIdentifier # # The 'uniqueIdentifier' attribute specifies a unique identifier for an # object represented in the Directory. The domain within which the # identifier is unique and the exact semantics of the identifier are # for local definition. For a person, this might be an institution- # wide payroll number. For an organizational unit, it might be a # department code. # attributetype ( 0.9.2342.19200300.100.1.44 NAME 'uniqueIdentifier' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # Note: X.520 also describes an attribute called 'uniqueIdentifier' # (2.5.4.45), which is called 'x500UniqueIdentifier' in LDAP # [RFC4519]. The attribute detailed here ought not be confused # with 'x500UniqueIdentifier'. # # -------------------------------------------------------------------------- # 2.25. userClass # # The 'userClass' attribute specifies categories of computer or # application user. The semantics placed on this attribute are for # local interpretation. Examples of current usage of this attribute in # academia are "student", "staff", and "faculty". Note that the # 'organizationalStatus' attribute type is now often preferred, as it # makes no distinction between persons as opposed to users. # attributetype ( 0.9.2342.19200300.100.1.8 NAME 'userClass' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # Attribute types from RFC 1274 which are missing in RFC 4524 # -------------------------------------------------------------------------- # # 9.3.2. Text Encoded O/R Address # # The Text Encoded O/R Address attribute type specifies a text encoding # of an X.400 O/R address, as specified in RFC 987. The use of this # attribute is deprecated as the attribute is intended for interim use # only. This attribute will be the first candidate for the attribute # expiry mechanisms! # # textEncodedORAddress ATTRIBUTE # WITH ATTRIBUTE-SYNTAX # caseIgnoreStringSyntax # (SIZE (1 .. ub-text-encoded-or-address)) # ::= {pilotAttributeType 2} # attributetype ( 0.9.2342.19200300.100.1.2 NAME 'textEncodedORAddress' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # -------------------------------------------------------------------------- # 9.3.7. Photo # # The Photo attribute type specifies a "photograph" for an object. # This should be encoded in G3 fax as explained in recommendation T.4, # with an ASN.1 wrapper to make it compatible with an X.400 BodyPart as # defined in X.420. # # IMPORT G3FacsimileBodyPart FROM { mhs-motis ipms modules # information-objects } # # photo ATTRIBUTE # WITH ATTRIBUTE-SYNTAX # CHOICE { # g3-facsimile [3] G3FacsimileBodyPart # } # (SIZE (1 .. ub-photo)) # ::= {pilotAttributeType 7} # attributetype ( 0.9.2342.19200300.100.1.7 NAME 'photo' DESC 'RFC1274: photo (G3 fax)' SYNTAX 1.3.6.1.4.1.1466.115.121.1.23{25000} ) # -------------------------------------------------------------------------- # 9.3.18. Other Mailbox # # The Other Mailbox attribute type specifies values for electronic # mailbox types other than X.400 and rfc822. # # otherMailbox ATTRIBUTE # WITH ATTRIBUTE-SYNTAX # SEQUENCE { # mailboxType PrintableString, -- e.g. Telemail # mailbox IA5String -- e.g. X378:Joe # } # ::= {pilotAttributeType 22} # attributetype ( 0.9.2342.19200300.100.1.22 NAME 'otherMailbox' SYNTAX 1.3.6.1.4.1.1466.115.121.1.39 ) # -------------------------------------------------------------------------- # 9.3.22. DNS ARecord # # The A Record attribute type specifies a type A (Address) DNS resource # record [6] [7]. # # aRecord ATTRIBUTE # WITH ATTRIBUTE-SYNTAX # DNSRecordSyntax # ::= {pilotAttributeType 26} # ## incorrect syntax? attributetype ( 0.9.2342.19200300.100.1.26 NAME 'aRecord' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) ## missing from RFC1274 ## incorrect syntax? attributetype ( 0.9.2342.19200300.100.1.27 NAME 'mDRecord' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) # -------------------------------------------------------------------------- # 9.3.23. MX Record # # The MX Record attribute type specifies a type MX (Mail Exchange) DNS # resource record [6] [7]. # # mXRecord ATTRIBUTE # WITH ATTRIBUTE-SYNTAX # DNSRecordSyntax # ::= {pilotAttributeType 28} # ## incorrect syntax!! attributetype ( 0.9.2342.19200300.100.1.28 NAME 'mXRecord' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) # -------------------------------------------------------------------------- # 9.3.24. NS Record # # The NS Record attribute type specifies an NS (Name Server) DNS # resource record [6] [7]. # # nSRecord ATTRIBUTE # WITH ATTRIBUTE-SYNTAX # DNSRecordSyntax # ::= {pilotAttributeType 29} # ## incorrect syntax!! attributetype ( 0.9.2342.19200300.100.1.29 NAME 'nSRecord' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) # -------------------------------------------------------------------------- # 9.3.25. SOA Record # # The SOA Record attribute type specifies a type SOA (Start of # Authority) DNS resorce record [6] [7]. # # sOARecord ATTRIBUTE # WITH ATTRIBUTE-SYNTAX # DNSRecordSyntax # ::= {pilotAttributeType 30} # ## incorrect syntax!! attributetype ( 0.9.2342.19200300.100.1.30 NAME 'sOARecord' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) # -------------------------------------------------------------------------- # 9.3.26. CNAME Record # # The CNAME Record attribute type specifies a type CNAME (Canonical # Name) DNS resource record [6] [7]. # # cNAMERecord ATTRIBUTE # WITH ATTRIBUTE-SYNTAX # iA5StringSyntax # ::= {pilotAttributeType 31} # ## incorrect syntax!! attributetype ( 0.9.2342.19200300.100.1.31 NAME 'cNAMERecord' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) # -------------------------------------------------------------------------- # 9.3.36. Janet Mailbox # # The Janet Mailbox attribute type specifies an electronic mailbox # attribute following the syntax specified in the Grey Book of the # Coloured Book series. This attribute is intended for the convenience # of U.K users unfamiliar with rfc822 and little-endian mail addresses. # Entries using this attribute MUST also include an rfc822Mailbox # attribute. # # janetMailbox ATTRIBUTE # WITH ATTRIBUTE-SYNTAX # caseIgnoreIA5StringSyntax # (SIZE (1 .. ub-janet-mailbox)) # ::= {pilotAttributeType 46} # attributetype ( 0.9.2342.19200300.100.1.46 NAME 'janetMailbox' DESC 'RFC1274: Janet mailbox' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) # -------------------------------------------------------------------------- # 9.3.37. Mail Preference Option # # An attribute to allow users to indicate a preference for inclusion of # their names on mailing lists (electronic or physical). The absence # of such an attribute should be interpreted as if the attribute was # present with value "no-list-inclusion". This attribute should be # interpreted by anyone using the directory to derive mailing lists, # and its value respected. # # mailPreferenceOption ATTRIBUTE # WITH ATTRIBUTE-SYNTAX ENUMERATED { # no-list-inclusion(0), # any-list-inclusion(1), -- may be added to any lists # professional-list-inclusion(2) # -- may be added to lists # -- which the list provider # -- views as related to the # -- users professional inter- # -- ests, perhaps evaluated # -- from the business of the # -- organisation or keywords # -- in the entry. # } # ::= {pilotAttributeType 47} # attributetype ( 0.9.2342.19200300.100.1.47 NAME 'mailPreferenceOption' DESC 'RFC1274: mail preference option' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) # -------------------------------------------------------------------------- # 9.3.43. Personal Signature # # The Personal Signature attribute type allows for a representation of # a person's signature. This should be encoded in G3 fax as explained # in recommendation T.4, with an ASN.1 wrapper to make it compatible # with an X.400 BodyPart as defined in X.420. # # IMPORT G3FacsimileBodyPart FROM { mhs-motis ipms modules # information-objects } # # personalSignature ATTRIBUTE # WITH ATTRIBUTE-SYNTAX # CHOICE { # g3-facsimile [3] G3FacsimileBodyPart # } # (SIZE (1 .. ub-personal-signature)) # ::= {pilotAttributeType 53} # attributetype ( 0.9.2342.19200300.100.1.53 NAME 'personalSignature' DESC 'RFC1274: Personal Signature (G3 fax)' SYNTAX 1.3.6.1.4.1.1466.115.121.1.23 ) # -------------------------------------------------------------------------- # 9.3.45. Audio # # The Audio attribute type allows the storing of sounds in the # Directory. The attribute uses a u-law encoded sound file as used by # the "play" utility on a Sun 4. This is an interim format. # # audio ATTRIBUTE # WITH ATTRIBUTE-SYNTAX # Audio # (SIZE (1 .. ub-audio)) # ::= {pilotAttributeType 55} # attributetype ( 0.9.2342.19200300.100.1.55 NAME 'audio' DESC 'RFC1274: audio (u-law)' SYNTAX 1.3.6.1.4.1.1466.115.121.1.4{25000} ) # -------------------------------------------------------------------------- # 3. COSINE Object Classes # -------------------------------------------------------------------------- # # This section details COSINE object classes for use in LDAP. # # -------------------------------------------------------------------------- # 3.1. account # # The 'account' object class is used to define entries representing # computer accounts. The 'uid' attribute SHOULD be used for naming # entries of this object class. # objectclass ( 0.9.2342.19200300.100.4.5 NAME 'account' SUP top STRUCTURAL MUST uid MAY ( description $ seeAlso $ l $ o $ ou $ host ) ) # # The 'top' object class is described in [RFC4512]. The 'description', # 'seeAlso', 'l', 'o', 'ou', and 'uid' attribute types are described in # [RFC4519]. The 'host' attribute type is described in Section 2 of # this document. # # Example: # # dn: uid=kdz,cn=Accounts,dc=Example,dc=COM # objectClass: account # uid: kdz # seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM # # -------------------------------------------------------------------------- # 3.2. document # # The 'document' object class is used to define entries that represent # documents. # objectclass ( 0.9.2342.19200300.100.4.6 NAME 'document' SUP top STRUCTURAL MUST documentIdentifier MAY ( cn $ description $ seeAlso $ l $ o $ ou $ documentTitle $ documentVersion $ documentAuthor $ documentLocation $ documentPublisher ) ) # # The 'top' object class is described in [RFC4512]. The 'cn', # 'description', 'seeAlso', 'l', 'o', and 'ou' attribute types are # described in [RFC4519]. The 'documentIdentifier', 'documentTitle', # 'documentVersion', 'documentAuthor', 'documentLocation', and # 'documentPublisher' attribute types are described in Section 2 of # this document. # # Example: # # dn: documentIdentifier=RFC 4524,cn=RFC,dc=Example,dc=COM # objectClass: document # documentIdentifier: RFC 4524 # documentTitle: COSINE LDAP/X.500 Schema # documentAuthor: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM # documentLocation: http://www.rfc-editor.org/rfc/rfc4524.txt # documentPublisher: Internet Engineering Task Force # description: A collection of schema elements for use in LDAP # description: Obsoletes RFC 1274 # seeAlso: documentIdentifier=RFC 4510,cn=RFC,dc=Example,dc=COM # seeAlso: documentIdentifier=RFC 1274,cn=RFC,dc=Example,dc=COM # # -------------------------------------------------------------------------- # 3.3. documentSeries # # The 'documentSeries' object class is used to define an entry that # represents a series of documents (e.g., The Request For Comments # memos). # objectclass ( 0.9.2342.19200300.100.4.9 NAME 'documentSeries' SUP top STRUCTURAL MUST cn MAY ( description $ l $ o $ ou $ seeAlso $ telephonenumber ) ) # # The 'top' object class is described in [RFC4512]. The 'description', # 'l', 'o', 'ou', 'seeAlso', and 'telephoneNumber' attribute types are # described in [RFC4519]. # # Example: # # dn: cn=RFC,dc=Example,dc=COM # objectClass: documentSeries # cn: Request for Comments # cn: RFC # description: a series of memos about the Internet # # -------------------------------------------------------------------------- # 3.4. domain # # The 'domain' object class is used to define entries that represent # DNS domains for objects that are not organizations, organizational # units, or other kinds of objects more appropriately defined using an # object class specific to the kind of object being defined (e.g., # 'organization', 'organizationUnit'). # # The 'dc' attribute should be used for naming entries of the 'domain' # object class. # objectclass ( 0.9.2342.19200300.100.4.13 NAME 'domain' SUP top STRUCTURAL MUST dc MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description $ o $ associatedName ) ) # # The 'top' object class and the 'dc', 'userPassword', 'searchGuide', # 'seeAlso', 'businessCategory', 'x121Address', 'registeredAddress', # 'destinationIndicator', 'preferredDeliveryMethod', 'telexNumber', # 'teletexTerminalIdentifier', 'telephoneNumber', # 'internationaliSDNNumber', 'facsimileTelephoneNumber', 'street', # 'postOfficeBox', 'postalCode', 'postalAddress', # 'physicalDeliveryOfficeName', 'st', 'l', 'description', and 'o' types # are described in [RFC4519]. The 'associatedName' attribute type is # described in Section 2 of this document. # # Example: # # dn: dc=com # objectClass: domain # dc: com # description: the .COM TLD # # -------------------------------------------------------------------------- # 3.5. domainRelatedObject # # The 'domainRelatedObject' object class is used to define entries that # represent DNS domains that are "equivalent" to an X.500 domain, e.g., # an organization or organizational unit. # objectclass ( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject' SUP top AUXILIARY MUST associatedDomain ) # # The 'top' object class is described in [RFC4512]. The # 'associatedDomain' attribute type is described in Section 2 of this # document. # # Example: # # dn: dc=example,dc=com # objectClass: organization # objectClass: dcObject # objectClass: domainRelatedObject # dc: example # associatedDomain: example.com # o: Example Organization # # The 'organization' and 'dcObject' object classes and the 'dc' and 'o' # attribute types are described in [RFC4519]. # # -------------------------------------------------------------------------- # 3.6. friendlyCountry # # The 'friendlyCountry' object class is used to define entries # representing countries in the DIT. The object class is used to allow # friendlier naming of countries than that allowed by the object class # 'country' [RFC4519]. # objectclass ( 0.9.2342.19200300.100.4.18 NAME 'friendlyCountry' SUP country STRUCTURAL MUST co ) # # The 'country' object class is described in [RFC4519]. The 'co' # attribute type is described in Section 2 of this document. # # Example: # # dn: c=DE # objectClass: country # objectClass: friendlyCountry # c: DE # co: Deutschland # co: Germany # co: Federal Republic of Germany # co: FRG # # The 'c' attribute type is described in [RFC4519]. # # -------------------------------------------------------------------------- # 3.7. rFC822LocalPart # # The 'rFC822LocalPart' object class is used to define entries that # represent the local part of Internet mail addresses [RFC2822]. This # treats the local part of the address as a 'domain' object. # objectclass ( 0.9.2342.19200300.100.4.14 NAME 'rFC822localPart' SUP domain STRUCTURAL MAY ( cn $ description $ destinationIndicator $ facsimileTelephoneNumber $ internationaliSDNNumber $ physicalDeliveryOfficeName $ postalAddress $ postalCode $ postOfficeBox $ preferredDeliveryMethod $ registeredAddress $ seeAlso $ sn $ street $ telephoneNumber $ teletexTerminalIdentifier $ telexNumber $ x121Address ) ) # # The 'domain' object class is described in Section 3.4 of this # document. The 'cn', 'description', 'destinationIndicator', # 'facsimileTelephoneNumber', 'internationaliSDNNumber, # 'physicalDeliveryOfficeName', 'postalAddress', 'postalCode', # 'postOfficeBox', 'preferredDeliveryMethod', 'registeredAddress', # 'seeAlso', 'sn, 'street', 'telephoneNumber', # 'teletexTerminalIdentifier', 'telexNumber', and 'x121Address' # attribute types are described in [RFC4519]. # # Example: # # dn: dc=kdz,dc=example,dc=com # objectClass: domain # objectClass: rFC822LocalPart # dc: kdz # associatedName: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM # # The 'dc' attribute type is described in [RFC4519]. # # -------------------------------------------------------------------------- # 3.8. room # # The 'room' object class is used to define entries representing rooms. # The 'cn' (commonName) attribute SHOULD be used for naming entries of # this object class. # objectclass ( 0.9.2342.19200300.100.4.7 NAME 'room' SUP top STRUCTURAL MUST cn MAY ( roomNumber $ description $ seeAlso $ telephoneNumber ) ) # # The 'top' object class is described in [RFC4512]. The 'cn', # 'description', 'seeAlso', and 'telephoneNumber' attribute types are # described in [RFC4519]. The 'roomNumber' attribute type is described # in Section 2 of this document. # # dn: cn=conference room,dc=example,dc=com # objectClass: room # cn: conference room # telephoneNumber: +1 755 555 1111 # # -------------------------------------------------------------------------- # 3.9. simpleSecurityObject # # The 'simpleSecurityObject' object class is used to require an entry # to have a 'userPassword' attribute when the entry's structural object # class does not require (or allow) the 'userPassword attribute'. # # (OpenLDAP-specific: Declared in core.schema) # objectclass ( 0.9.2342.19200300.100.4.19 # NAME 'simpleSecurityObject' # SUP top AUXILIARY # MUST userPassword ) # # The 'top' object class is described in [RFC4512]. The 'userPassword' # attribute type is described in [RFC4519]. # # dn: dc=kdz,dc=Example,dc=COM # objectClass: account # objectClass: simpleSecurityObject # uid: kdz # userPassword: My Password # seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM # # -------------------------------------------------------------------------- # Object classes from RFC 1274 which are missing in RFC 4524 # -------------------------------------------------------------------------- # # 8.3.2. Pilot Person # # The PilotPerson object class is used as a sub-class of person, to # allow the use of a number of additional attributes to be assigned to # entries of object class person. # # pilotPerson OBJECT-CLASS # SUBCLASS OF person # MAY CONTAIN { # userid, # textEncodedORAddress, # rfc822Mailbox, # favouriteDrink, # roomNumber, # userClass, # homeTelephoneNumber, # homePostalAddress, # secretary, # personalTitle, # preferredDeliveryMethod, # businessCategory, # janetMailbox, # otherMailbox, # mobileTelephoneNumber, # pagerTelephoneNumber, # organizationalStatus, # mailPreferenceOption, # personalSignature} # ::= {pilotObjectClass 4} # objectclass ( 0.9.2342.19200300.100.4.4 NAME ( 'pilotPerson' 'newPilotPerson' ) SUP person STRUCTURAL MAY ( userid $ textEncodedORAddress $ rfc822Mailbox $ favouriteDrink $ roomNumber $ userClass $ homeTelephoneNumber $ homePostalAddress $ secretary $ personalTitle $ preferredDeliveryMethod $ businessCategory $ janetMailbox $ otherMailbox $ mobileTelephoneNumber $ pagerTelephoneNumber $ organizationalStatus $ mailPreferenceOption $ personalSignature ) ) # 8.3.9. DNS Domain # # The DNS Domain (Domain NameServer) object class is used to define # entries for DNS domains. The usage of this object class is described # in more detail in [3]. # # dNSDomain OBJECT-CLASS # SUBCLASS OF domain # MAY CONTAIN { # ARecord, # MDRecord, # MXRecord, # NSRecord, # SOARecord, # CNAMERecord} # ::= {pilotObjectClass 15} # objectclass ( 0.9.2342.19200300.100.4.15 NAME 'dNSDomain' SUP domain STRUCTURAL MAY ( ARecord $ MDRecord $ MXRecord $ NSRecord $ SOARecord $ CNAMERecord ) ) --------------080004030402080700020504--

1 0

Re: (ITS#6156) Translucent overlay not working correctly when not asking for attributes included in search filter
by isaac＠ebox-platform.com 30 May '09

30 May '09

> But it will fail if it's an 'and' and both parts match (which was my > original case). This one fails: > $LDAPSEARCH -H $URI2 -b "o=translucent" > "(|(employeeType=foo)(carlicense=right))" preferredLanguage > > $SEARCHOUT 2>&1 Sorry, I meant to write this in the last one: $LDAPSEARCH -H $URI2 -b "o=translucent" "(&(employeeType=consultant)(carlicense=right))" preferredLanguage > $SEARCHOUT 2>&1 -- Isaac Clerencia - Developer isaac(a)ebox-platform.com http://people.warp.es/~isaac/blog/ eBox - Managing Computer Networks Was Never This Easy Download eBox at www.ebox-platform.com

1 0

Re: (ITS#6156) Translucent overlay not working correctly when not asking for attributes included in search filter
by isaac＠ebox-platform.com 30 May '09

30 May '09

I also just realized that if the part that matches is the local filter part, then it works, thus, this one works correctly: $LDAPSEARCH -H $URI2 -b "o=translucent" "(|(employeeType=consultant)(carlicense=aaaa))" preferredLanguage > $SEARCHOUT 2>&1 But it will fail if it's an 'and' and both parts match (which was my original case). This one fails: $LDAPSEARCH -H $URI2 -b "o=translucent" "(|(employeeType=foo)(carlicense=right))" preferredLanguage > $SEARCHOUT 2>&1 -- Isaac Clerencia - Developer isaac(a)ebox-platform.com http://people.warp.es/~isaac/blog/ eBox - Managing Computer Networks Was Never This Easy Download eBox at www.ebox-platform.com

1 0

(ITS#6156) Translucent overlay not working correctly when not asking for attributes included in search filter
by isaac＠ebox-platform.com 30 May '09

30 May '09

Full_Name: Isaac Clerencia Version: 2.4.15 OS: Ubuntu URL: Submission from: (NULL) (88.26.177.14) The translucent overlay doesn't return entries if any of the attributes included in the search filter is remote and is not requested. The easiest way to reproduce this is modifying slightly test034-translucent. The ldapsearch in line 786 looks originally like this: $LDAPSEARCH -H $URI2 -b "o=translucent" "(|(employeeType=foo)(carlicense=right))" > $SEARCHOUT 2>&1 The original test works correctly because it requests all the attributes, including carLicense. If we change it to request a specific attribute such as preferredLanguage: $LDAPSEARCH -H $URI2 -b "o=translucent" "(|(employeeType=foo)(carlicense=right))" preferredLanguage > $SEARCHOUT 2>&1 the test fails. If we just ask for the carLicense attribute, the test passes: $LDAPSEARCH -H $URI2 -b "o=translucent" "(|(employeeType=foo)(carlicense=right))" carLicense > $SEARCHOUT 2>&1 As long as carLicense is included in the request attributes the test will pass, otherwise it will fail.

1 0

(ITS#6155) Segfault during Heimdal's kadmin -l init Realm
by dewayne_freebsd＠yahoo.com 30 May '09

30 May '09

Full_Name: Dewayne Geraghty Version: 2.4.16 OS: FreeBSD 7.2R URL: http://www.consciuminternational.com.au/ldap Submission from: (NULL) (58.172.112.108) FreeBSD version 7.2; Heimdal V1.2.1; OpenLDAP 2.4.16 Heimdal and OpenLDAP are built for heimdal to use OpenLDAP as backend. Segmentation fault during kadmin -l init HS slapd and heimdal work correctly, independently. slapd is running at debug 1019, logs are at enclosed URL along with the full gdb trace, and configuration files. If I can assist please advise. This is a single Pentium CPU, and gcc flags CFLAGS= -pipe -g3 -ggdb3 -O0 -march=pentium4 -mtune=pentium4 -DDO_KRB5 -DDO_SAMBA -DHAVE_OPENSSL #0 0x286447b6 in memmove () from /lib/libc.so.7 #1 0x282a10e8 in ber_write () from /usr/local/lib/liblber-2.4.so.6 #2 0x2829ebf7 in ber_put_ostring () from /usr/local/lib/liblber-2.4.so.6 #3 0x2829ed14 in ber_put_berval () from /usr/local/lib/liblber-2.4.so.6 #4 0x2829faca in ber_printf () from /usr/local/lib/liblber-2.4.so.6 #5 0x2821a0ee in ldap_add_ext () from /usr/local/lib/libldap-2.4.so.6 #6 0x2821a378 in ldap_add_ext_s () from /usr/local/lib/libldap-2.4.so.6 #7 0x280ad493 in LDAP_store (context=0x287050b0, db=0x2870e040, flags=0, entry=0xbfbfe790) at hdb-ldap.c:1600 #8 0x2809875b in kadm5_s_create_principal (server_handle=0x2871b0c0, princ=0xbfbfea3c, mask=17, password=0xbfbfe830 "bQdxg9drKf") at create_s.c:182 #9 0x2808da1c in kadm5_create_principal (server_handle=0x2871b0c0, princ=0xbfbfea3c, mask=17, password=0xbfbfe830 "bQdxg9drKf") at common_glue.c:64 #10 0x0804e496 in ?? () #11 0x2871b0c0 in ?? () #12 0xbfbfea3c in ?? () #13 0x00000011 in ?? () #14 0xbfbfe830 in ?? () #15 0x28084000 in ?? () #16 0x28084200 in ?? () #17 0x28084400 in ?? () #18 0x285b3c8d in _pthread_mutex_init_calloc_cb () from /lib/libc.so.7 #19 0x0804e8c9 in ?? () #20 0x2870c0e0 in ?? () #21 0x00000000 in ?? () #22 0x00000000 in ?? () #23 0x00000000 in ?? () #24 0x2870c085 in ?? () #25 0x00000000 in ?? () #26 0x28650030 in ?? () from /lib/libc.so.7 I have spent weeks trying to get this to work. (Because I'm using and modifing the FreeBSD ports system to build and use the latest version of LDAP and Heimdal.)

1 0

(ITS#6154) response/cleanup callback mismatch
by h.b.furuseth＠usit.uio.no 29 May '09

29 May '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard result.c:slap_send_search_entry() calls slap_cleanup_play() without having called slap_response_play() if backend_operational() failed. This breaks back-relay's cleanup handler relay_back_swap_bd() - or rather, I suppose it makes that handler break cleanup handlers called after it. It restores op->o_bd from o_callback->sc_private, which was supposedly set by the o_callback->sc_response call.

1 0

Re: (ITS#6152) proxycache enhancements
by hyc＠symas.com 29 May '09

29 May '09

Pierangelo Masarati wrote: > hyc(a)OpenLDAP.org wrote: > >> Some ideas that came out of discussions at the Ubuntu Developer Summit this >> week... >> >> It would be nice for pcache to detect when connectivity to the remote server has >> been lost. In that case, cache expiration should be stopped, and the cache >> contents should remain intact until connectivity is restored. > > Sounds fair. > >> Also, when connectivity is restored, pcache should explicitly refresh all the >> entries it currently holds, rather than allowing them to be immediately expired. > > Sounds an overkill? Perhaps. It is certainly likely that any entries in the cache will be stale; when connectivity is restored and expiration is re-enabled the cached entries will probably be immediately removed. While it will be no problem to retrieve the entries again since the network is available, the concern is that only a subset of the originally cached entries will be retrieved through normal user activity, but the entire set needs to be preserved in anticipation of the next disconnect event. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6152) proxycache enhancements
by masarati＠aero.polimi.it 29 May '09

29 May '09

hyc(a)OpenLDAP.org wrote: > Some ideas that came out of discussions at the Ubuntu Developer Summit this > week... > > It would be nice for pcache to detect when connectivity to the remote server has > been lost. In that case, cache expiration should be stopped, and the cache > contents should remain intact until connectivity is restored. Sounds fair. > Also, when connectivity is restored, pcache should explicitly refresh all the > entries it currently holds, rather than allowing them to be immediately expired. Sounds an overkill? Cheers, p.

1 0

Re: (ITS#6152) proxycache enhancements
by rhafer＠suse.de 29 May '09

29 May '09

Am Donnerstag 28 Mai 2009 18:29:55 schrieb hyc(a)openldap.org: > Full_Name: Howard Chu > Version: 2.4.16 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.67.104.102) > Submitted by: hyc > > > Some ideas that came out of discussions at the Ubuntu Developer Summit this > week... > > It would be nice for pcache to detect when connectivity to the remote > server has been lost. In that case, cache expiration should be stopped, and > the cache contents should remain intact until connectivity is restored. Yes that sound reasonable. It's probably also worth to think about a mechanism to explicitly set pcache to "offline" mode. That way on a client machine a hook could be provided for e.g. NetworkManager to bring pcache to offline mode immediately when the network goes offline. That mechanism could either be offered through back-config (back-monitor as for readonly?) and/or through the nssov Socket as that would most probably be the main user of this disconnected pcache mode. > Also, when connectivity is restored, pcache should explicitly refresh all > the entries it currently holds, rather than allowing them to be immediately > expired. -- Ralf

1 0

(ITS#6153) Segfault during Heimdal's kadmin -l init Realm
by dewayne_freebsd＠yahoo.com 29 May '09

29 May '09

Full_Name: Dewayne Geraghty Version: 2.4.16 OS: FreeBSD 7.2R URL: http://www.consciuminternational.com.au/ldap Submission from: (NULL) (58.172.112.108) FreeBSD version 7.2; Heimdal V1.2.1; OpenLDAP 2.4.16 Heimdal and OpenLDAP are built for heimdal to use OpenLDAP as backend. Segmentation fault during kadmin -l init HS slapd and heimdal work correctly, independently. slapd is running at debug 1019, logs are at enclosed URL along with the full gdb trace, and configuration files. If I can assist please advise. This is a single Pentium CPU, and gcc flags CFLAGS= -pipe -g3 -ggdb3 -O0 -march=pentium4 -mtune=pentium4 -DDO_KRB5 -DDO_SAMBA -DHAVE_OPENSSL #0 0x286447b6 in memmove () from /lib/libc.so.7 #1 0x282a10e8 in ber_write () from /usr/local/lib/liblber-2.4.so.6 #2 0x2829ebf7 in ber_put_ostring () from /usr/local/lib/liblber-2.4.so.6 #3 0x2829ed14 in ber_put_berval () from /usr/local/lib/liblber-2.4.so.6 #4 0x2829faca in ber_printf () from /usr/local/lib/liblber-2.4.so.6 #5 0x2821a0ee in ldap_add_ext () from /usr/local/lib/libldap-2.4.so.6 #6 0x2821a378 in ldap_add_ext_s () from /usr/local/lib/libldap-2.4.so.6 #7 0x280ad493 in LDAP_store (context=0x287050b0, db=0x2870e040, flags=0, entry=0xbfbfe790) at hdb-ldap.c:1600 #8 0x2809875b in kadm5_s_create_principal (server_handle=0x2871b0c0, princ=0xbfbfea3c, mask=17, password=0xbfbfe830 "bQdxg9drKf") at create_s.c:182 #9 0x2808da1c in kadm5_create_principal (server_handle=0x2871b0c0, princ=0xbfbfea3c, mask=17, password=0xbfbfe830 "bQdxg9drKf") at common_glue.c:64 #10 0x0804e496 in ?? () #11 0x2871b0c0 in ?? () #12 0xbfbfea3c in ?? () #13 0x00000011 in ?? () #14 0xbfbfe830 in ?? () #15 0x28084000 in ?? () #16 0x28084200 in ?? () #17 0x28084400 in ?? () #18 0x285b3c8d in _pthread_mutex_init_calloc_cb () from /lib/libc.so.7 #19 0x0804e8c9 in ?? () #20 0x2870c0e0 in ?? () #21 0x00000000 in ?? () #22 0x00000000 in ?? () #23 0x00000000 in ?? () #24 0x2870c085 in ?? () #25 0x00000000 in ?? () #26 0x28650030 in ?? () from /lib/libc.so.7 I have spent weeks trying to get this to work. (Because I'm using and modifing the FreeBSD ports system to build and use the latest version of LDAP and Heimdal.)

1 0

(ITS#6152) proxycache enhancements
by hyc＠OpenLDAP.org 28 May '09

28 May '09

Full_Name: Howard Chu Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.67.104.102) Submitted by: hyc Some ideas that came out of discussions at the Ubuntu Developer Summit this week... It would be nice for pcache to detect when connectivity to the remote server has been lost. In that case, cache expiration should be stopped, and the cache contents should remain intact until connectivity is restored. Also, when connectivity is restored, pcache should explicitly refresh all the entries it currently holds, rather than allowing them to be immediately expired.

1 0

Re: (ITS#6056) Samba4 breaks OpenLDAP over ldapi
by hyc＠symas.com 28 May '09

28 May '09

Andrew Bartlett wrote: > On Tue, 2009-05-26 at 04:26 -0700, Howard Chu wrote: >> abartlet(a)samba.org wrote: >>> Full_Name: Andrew Bartlett >>> Version: CVS HEAD >>> OS: Fedora 10 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (59.167.251.137) >>> >>> >>> Samba4's provision and 'make test' seems to create some internal situation in >>> OpenLDAP slapd where it will not accept any more connections over ldapi:/// >>> >>> This is best seen by building Samba4, and running >>> >>> TEST_LDAP=yes OPENLDAP_ROOT=/usr/local make test >>> >>> The slapd does not crash, but simply stops accepting new connections. Samba4 >>> currently then crashes due to some other bug (the LDAP backend not responding is >>> clearly untested code in Samba4). >>> >>> It isn't a Samba4 client bug, as ldapsearch also fails to respond. >>> >>> This seems very, very similar to ITS#5261 >> >> Further testing with Andrew's kvm image shows the hang only occurs when Cyrus >> SASL's libsasldb2.so plugin is present. I always remove that plugin from my >> installs, since I only use in-directory SASL secrets. That's probably why I >> wasn't seeing the reported behavior before. >> >> Also a note - it's still not clear we've been talking about the same thing up >> to this point. Even when the samba test suite hangs, I see that ldapsearch >> still works fine against slapd. At any rate, currently all of the samba4 tests >> pass for me. > > Hmm. Using that KVM image, with the libsasldb moved aside (and with it > left in place), I still get errors. > > However, there is an important difference: Where previously, once it > locked up nothing proceeded, now it proceeds - as if the failure is > temporary now. The error has changed too - instead of a failure to > connect, it is an inability to successfully read the rootDSE. > > I agree, we might be jumping at different shadows here, but your patches > did fix something... I see what you're describing now, with the kvm set with 2 CPUs. It appears to be a bug caused by the recent patch for connection_hangup() processing. Running slapd with -d15 in your test shows that a connection is closed shortly after being established and becoming readable. The bug is (probably) that we queued the reader but processed the hangup immediately, thus closing the connection before the reader executes. I'm not exactly sure why this is causing the problem on your test, since it looks like your client is closing the socket before waiting for the reply. But certainly this is the right area. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6151) Update cosine.schema to RFC 4524
by michael＠stroeder.com 28 May '09

28 May '09

Full_Name: Michael Ströder Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.80.206) cosine.schema is still based on obsoleted RFC 1274. It should be updated to RFC 4524.

1 0

Re: (ITS#6150) schema compliance checking tool
by michael＠stroeder.com 28 May '09

28 May '09

Pierangelo Masarati wrote: > Added to HEAD. Please test. Wow! This was fast! It simply works. I want it in 2.4.17. ;-) Ciao, Michael.

1 0

Re: (ITS#6150) schema compliance checking tool
by masarati＠aero.polimi.it 28 May '09

28 May '09

Added to HEAD. Please test. p.

1 0

(ITS#6150) schema compliance checking tool
by michael＠stroeder.com 28 May '09

28 May '09

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (84.163.68.118) masarati(a)aero.polimi.it wrote: > Comes to mind that something like a schema compliance checking tool, > either off- or on-line could be useful. Sort of a "slapschema" that > checks the schema compliance of each entry (matching a filter or > within a subtree specification) in a given database. The result could contain the DNs of non-compliant entries each with the diagnostic message which would have been returned to a client adding such a non-compliant entry.

1 0

(ITS#6149) ldapsearch is not really script-friendly (patch included)
by bugreporter＠udmvt.ru 28 May '09

28 May '09

Full_Name: Alexey Version: 2.4.15 (LDAP library: OpenLDAP 20415) OS: Debian GNU/Linux URL: http://bugreport.udmvt.ru/attachment/ldapsearch-ttt.patch Submission from: (NULL) (78.85.1.13) Good day, everyone. ldapsearch have such important (mis)feature, like output format conforming to LDIF standard in some or other way. You should already know, that line length in LDIF-output is limited to 76 characters and if line is larger, it is wrapped with space-padding. Also output is sometimes base64 encoded, based on it's "printability". Printability is tested, using single-byte functions, like isgraph(), but when values is multibyte encoded with UTF-8, that sometimes produce random results. That together makes ldapsearch very script-unfriendly and here is why: to limit randomness in output's encoding, one would use -tt switch to always write field values to files and then use some simple script to parse the output and substitute file urls with their contents. But here comes to play line length limit, that will sometimes wrap urls for fields with long names (that is common for AD). Here is example: msExchHomeServerName:< file:///tmp/ldapsearch-msExchHomeServerName-ZhHdx2 msExchMailboxSecurityDescriptor:< file:///tmp/ldapsearch-msExchMailboxSecurit yDescriptor-c4gGc1 msExchUserAccountControl:< file:///tmp/ldapsearch-msExchUserAccountControl-FM UbSZ msExchMailboxGuid:< file:///tmp/ldapsearch-msExchMailboxGuid-6bLIxY End of example. That introduces extra unneeded complexity in otherwise simple script, since now it should parse LDIF, combine whole lines from broken ones, etc. Making it no longer an one-line script. Since wrapping of -tt output is nonsense, but changing that may seem unfeasible for some of you, let me suggest additional option -ttt, that does the same as -tt, but without line wrapping (perhaps, violating some standard). Patch is here, as your ITS asks: http://bugreport.udmvt.ru/attachment/ldapsearch-ttt.patch PS: manpage does not changed to reflect additional option Thanks a lot.

1 0

Re: (ITS#6056) Samba4 breaks OpenLDAP over ldapi
by abartlet＠samba.org 27 May '09

27 May '09

--=-0SnOgocYLpYqWd2pGoMe Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-05-26 at 04:26 -0700, Howard Chu wrote: > abartlet(a)samba.org wrote: > > Full_Name: Andrew Bartlett > > Version: CVS HEAD > > OS: Fedora 10 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (59.167.251.137) > > > > > > Samba4's provision and 'make test' seems to create some internal situat= ion in > > OpenLDAP slapd where it will not accept any more connections over ldapi= :/// > > > > This is best seen by building Samba4, and running > > > > TEST_LDAP=3Dyes OPENLDAP_ROOT=3D/usr/local make test > > > > The slapd does not crash, but simply stops accepting new connections. = Samba4 > > currently then crashes due to some other bug (the LDAP backend not resp= onding is > > clearly untested code in Samba4). > > > > It isn't a Samba4 client bug, as ldapsearch also fails to respond. > > > > This seems very, very similar to ITS#5261 >=20 > Further testing with Andrew's kvm image shows the hang only occurs when C= yrus=20 > SASL's libsasldb2.so plugin is present. I always remove that plugin from = my=20 > installs, since I only use in-directory SASL secrets. That's probably why= I=20 > wasn't seeing the reported behavior before. >=20 > Also a note - it's still not clear we've been talking about the same thin= g up=20 > to this point. Even when the samba test suite hangs, I see that ldapsearc= h=20 > still works fine against slapd. At any rate, currently all of the samba4 = tests=20 > pass for me. Hmm. Using that KVM image, with the libsasldb moved aside (and with it left in place), I still get errors. =20 However, there is an important difference: Where previously, once it locked up nothing proceeded, now it proceeds - as if the failure is temporary now. The error has changed too - instead of a failure to connect, it is an inability to successfully read the rootDSE.=20 I agree, we might be jumping at different shadows here, but your patches did fix something... Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-0SnOgocYLpYqWd2pGoMe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBKHeuvz4A8Wyi0NrsRAoaGAJ9olpo9+ni006pt9kK5CkXJObYNCQCgorgP DswBOLRtdrlhFHibmX4XrC4= =bjw6 -----END PGP SIGNATURE----- --=-0SnOgocYLpYqWd2pGoMe--

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs