- openldap-bugs - openldap.org

Re: (ITS#5344) Wrong check for bad Modify DN
by hyc＠symas.com 30 Jan '08

30 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: http://folk.uio.no/hbf/OpenLDAP/modrdn.diff > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > The slapd/modrdn.c check for affectsMultipleDSAs is insufficient, it > requires newSuperior to be in the same backend. That does not catch > moving "cn=x,cn=y" to another database's suffix "cn=z,cn=y". I don't see how it can miss this. > Also > if a database has multiple suffixes it prevents moving an entry > to one of the suffixes. OK, I see that. > slapd/modrdn.c can catch attempts to place an entry above/below itself. > It doesn't need to send those to the database and hope that catches it. > This patch puts it in the frontend (fe_op_modrdn); that needed to > generate the destination DN anyway for the affectsMultipleDSAs check. > Not sure if that's right or if it should go in do_modrdn() instead. > (I'm thinking of DN rewriting in rwm, vs. global overlays.) Probably should look at adding the dest_dn to the op struct, so each backend doesn't have to rebuild it. > In test005-modrdn, the "modrdn with newSuperior as child of target" check > would not catch anything: It expects failure, but the newSuperior did > not exist and would fail with noSuchObject in any case. This patch uses > newSuperior=target instead, and expects unwillingToPerform. > I'll apply the patch later, unless someone thinks it should be done > differently. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5344) Wrong check for bad Modify DN
by h.b.furuseth＠usit.uio.no 30 Jan '08

30 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: http://folk.uio.no/hbf/OpenLDAP/modrdn.diff Submission from: (NULL) (129.240.6.233) Submitted by: hallvard The slapd/modrdn.c check for affectsMultipleDSAs is insufficient, it requires newSuperior to be in the same backend. That does not catch moving "cn=x,cn=y" to another database's suffix "cn=z,cn=y". Also if a database has multiple suffixes it prevents moving an entry to one of the suffixes. slapd/modrdn.c can catch attempts to place an entry above/below itself. It doesn't need to send those to the database and hope that catches it. This patch puts it in the frontend (fe_op_modrdn); that needed to generate the destination DN anyway for the affectsMultipleDSAs check. Not sure if that's right or if it should go in do_modrdn() instead. (I'm thinking of DN rewriting in rwm, vs. global overlays.) In test005-modrdn, the "modrdn with newSuperior as child of target" check would not catch anything: It expects failure, but the newSuperior did not exist and would fail with noSuchObject in any case. This patch uses newSuperior=target instead, and expects unwillingToPerform. I'll apply the patch later, unless someone thinks it should be done differently.

1 0

Re: (ITS#5330) back-null upgrade
by h.b.furuseth＠usit.uio.no 30 Jan '08

30 Jan '08

hyc(a)symas.com writes: > h.b.furuseth(a)usit.uio.no wrote: >> I'll be upgrading back-null a bit. At the moment just support for >> Back-config, Modify-Increment Extension and empty rootpw. > >> Maybe grow it to a useful template of a nontrivial backend later >> (after I learn how to write that), with access control, referrals, >> various extensions... Might be almost-unused and thus subject to >> code rot, but less so than documentation of the backend API. >> (...) > > I don't believe back-null should ever handle access controls or > referrals. OK. However it shouldn't need to _handle_ referrals, since it can have no referral objects. I think the complete implementation would be to set SLAP_BFLAG_REFERRALS and LDAP_CONTROL_MANAGEDSAIT in the init function. Assuming the default_referral code in BDB which neither of us understand (ITS#5339) is unnecessary. SLAP_BFLAG_INCREMENT and (I think) LDAP_CONTROL_X_PERMISSIVE_MODIFY can be set without needing any extra code, and LDAP_CONTROL_NOOP will need one line for the update functions. > It shouldn't have any config options at all, really. Does that mean I shouldn't add back-config support either? I do find "bind on" useful. And it would be convenient to accept and ignore the "directory" option, so it can be used as a drop-in replacement for a minimal back-bdb/back-ldif config. My current motivation is nothing major, just to push back-null through "cd tests/ && ./run -b null all". > Create some other backend if you want a dummy template that shows how > all the other APIs are tied in. OK. Just need to think of something for it to do... -- Hallvard

1 0

(ITS#5343) cn=config crash when deleting attrs
by h.b.furuseth＠usit.uio.no 30 Jan '08

30 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.203.232) Submitted by: hallvard back-config crashes if I delete some attribute, even some which does not exist, and then olcAttributeOptions: bash$ cat slapd.conf include servers/slapd/schema/core.schema database config rootdn cn=config rootpw secret bash$ ldapmodify -xh:3890 -Dcn=config -wsecret dn: cn=config changetype: modify # or use "delete: o" delete: olcAllows - delete: olcAttributeOptions olcAttributeOptions: foo - Crash in bconfig.c:config_modify_internal line 4843 because d == NULL: 4842 if ( ml->sml_values ) { 4843 d = d->next; 4844 ch_free( dels ); 4845 dels = d; 4846 } Backtrace: #0 0x000000000042db19 in config_modify_internal (ce=0x9cb710, op=0x9d7330, rs=0x41801cb0, ca=0x417ff750) at bconfig.c:4843 #1 0x000000000042e34a in config_back_modify (op=0x9d7330, rs=0x41801cb0) at bconfig.c:4991 #2 0x0000000000461107 in fe_op_modify (op=0x9d7330, rs=0x41801cb0) at modify.c:300 #3 0x00000000004609b0 in do_modify (op=0x9d7330, rs=0x41801cb0) at modify.c:175 #4 0x0000000000440dd8 in connection_operation (ctx=0x41801e00, arg_v=0x9d7330) at connection.c:1087 #5 0x0000000000441306 in connection_read_thread (ctx=0x41801e00, argv=0x9) at connection.c:1214 #6 0x00002b100d4c354f in ldap_int_thread_pool_wrapper (xpool=0x927a10) at tpool.c:625 #7 0x00002b100e1e6317 in start_thread () from /lib/libpthread.so.0 #8 0x00002b100f935d5d in clone () from /lib/libc.so.6 #9 0x0000000000000000 in ?? () Also the error message from deleting just olcAttributeOptions is bad: bash$ ldapmodify -xh:3890 -Dcn=config -wsecret dn: cn=config changetype: modify replace: olcAttributeOptions olcAttributeOptions: foo ldap_modify: Internal (implementation specific) error (80) additional info: modify/delete: modifyTimestamp: no such attribute modifying entry "cn=config" Finally "replace:" only needs to fail if there are options to delete, not if one adds a line with just "attributeOptions" to slapd.conf. That removes the default, "lang-".

1 0

Re: (ITS#5342) DN and naming attribute mismatch
by hyc＠symas.com 29 Jan '08

29 Jan '08

Aaron Richton wrote: > Backend is hdb. The add was done under 2.3.37, the server has since been > upgraded to 2.3.40 (last Thursday). > > db_dump -p does show a high character... > > \80\10cn=172.23.58.210\00cn=1\b72.23.58.210\00\00\00\00\00\00\01\e4e > > which I suppose you're theorizing is off-by-one on the disk. BTW, slapcat > doesn't agree with ldapsearch here, which might be construed as a bug? > (Although it's tough to call something a bug in an impossible situation, I > admit.) > I dunno. I suppose if the hardware is bad then I might be seeing all sorts > of crazy stuff. But we're talking modern sparc/solaris hardware: all my > other boxes are pretty good about screaming during their death. And they > also don't have the amazingly-coincidental upgrade to 2.3.40 from last > Thursday, either. (Which I started seeing err=80 returns within 24 hours > of, after not seeing them...well, almost ever in production.) It's all > just a bit too perfect a storm for my taste...but I'd obviously defer to > you when it comes to bdb internals. Well, if the entry was created a while ago and hasn't ever been modrdn'd then this DB record would never have been touched since then. (Or more to the point, not modrdn'd since the 2.3.40 upgrade.) It's possible that a software bug might have caused a stray bitwise OR to toggle that bit in an in-memory cached page, but seems unlikely that a page corrupted in that manner would have been written back to disk. Unless of course this record is one of the last ones in the DB before the upgrade, and new entries were added right after it. ("Last" is obviously imprecise. But the point is you would have had to have created some new entries after the upgrade whose DNs would cause their records to fall on the same DB page as this record, meaning they're close in the sort order and such.) > With that in mind, I might as well see through your theory. I'll play with > a second box tomorrow and see if I can reproduce fresh. And for most err=80 situations, there ought to be BerkeleyDB error messages in the log as well. -- -- Howard Chu Chief Architect, 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#5342) DN and naming attribute mismatch
by richton＠nbcs.rutgers.edu 29 Jan '08

29 Jan '08

Backend is hdb. The add was done under 2.3.37, the server has since been upgraded to 2.3.40 (last Thursday). db_dump -p does show a high character... \80\10cn=172.23.58.210\00cn=1\b72.23.58.210\00\00\00\00\00\00\01\e4e which I suppose you're theorizing is off-by-one on the disk. BTW, slapcat doesn't agree with ldapsearch here, which might be construed as a bug? (Although it's tough to call something a bug in an impossible situation, I admit.) I dunno. I suppose if the hardware is bad then I might be seeing all sorts of crazy stuff. But we're talking modern sparc/solaris hardware: all my other boxes are pretty good about screaming during their death. And they also don't have the amazingly-coincidental upgrade to 2.3.40 from last Thursday, either. (Which I started seeing err=80 returns within 24 hours of, after not seeing them...well, almost ever in production.) It's all just a bit too perfect a storm for my taste...but I'd obviously defer to you when it comes to bdb internals. With that in mind, I might as well see through your theory. I'll play with a second box tomorrow and see if I can reproduce fresh.

1 0

Re: (ITS#5342) DN and naming attribute mismatch
by hyc＠symas.com 29 Jan '08

29 Jan '08

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.40 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.6.31.135) > > > $ ldapsearch -LLL '(cn=172.23.58.210)' > dn:: Y249MbcyLjIzLjU4LjIxMCxjbj1DbGllbnRzLGNuPVJlc05ldCBTZXJ2aWNlIENvbmZpZyxvd > T1Ib3N0IENvbmZpZyxvPVJ1dGdlcnMgQ0NGLGM9VVM= > objectClass: top > objectClass: dhcpHost > cn: 172.23.58.210 > dhcpStatements: fixed-address 172.23.58.210 > dhcpHWAddress: ethernet 00:17:3f:bf:c2:04 > > > Is it just me, or does my cn attribute not match the cn in the dn? Uhhh...now > what? > (and no, I wasn't using an editor on the bdb files, or whatever other conspiracy > theory is out there.) Also, if it helps, you can see on openldap-software my > other misadventures with 2.3.40...this is just one that's really easy to prove. You didn't mention what backend you're using. I'd examine the dn2id.bdb file (use db_dump -p) and see if this DN is corrupted there. Also, was this entry created using 2.3.40, or using an earlier version? Interesting that the byte differs from the expected value by a single bit (it has its high bit set). Personally I suspect the hardware is flaking out. -- -- Howard Chu Chief Architect, 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#5342) DN and naming attribute mismatch
by richton＠nbcs.rutgers.edu 29 Jan '08

29 Jan '08

> does this help? the "7" in 172 is something else (octal 267, I believe). Precisely. How did that get in my database? It MUST match the dn per spec, right? And it doesn't. (The character almost certainly should be '7.' If I go back in my logs far enough, I'll bet I can even find an ADD log showing it as such...)

1 0

Re: (ITS#5342) DN and naming attribute mismatch
by ando＠sys-net.it 29 Jan '08

29 Jan '08

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.40 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.6.31.135) > > > $ ldapsearch -LLL '(cn=172.23.58.210)' > dn:: Y249MbcyLjIzLjU4LjIxMCxjbj1DbGllbnRzLGNuPVJlc05ldCBTZXJ2aWNlIENvbmZpZyxvd > T1Ib3N0IENvbmZpZyxvPVJ1dGdlcnMgQ0NGLGM9VVM= > objectClass: top > objectClass: dhcpHost > cn: 172.23.58.210 > dhcpStatements: fixed-address 172.23.58.210 > dhcpHWAddress: ethernet 00:17:3f:bf:c2:04 > > > Is it just me, or does my cn attribute not match the cn in the dn? Uhhh...now > what? > (and no, I wasn't using an editor on the bdb files, or whatever other conspiracy > theory is out there.) Also, if it helps, you can see on openldap-software my > other misadventures with 2.3.40...this is just one that's really easy to prove. bash-3.00$ echo -n "Y249MbcyLjIzLjU4LjIxMCxjbj1DbGllbnRzLGNuPVJlc05ldCBTZXJ2aWNlIENvbmZpZyxvdT1Ib3N0IENvbmZpZyxvPVJ1dGdlcnMgQ0NGLGM9VVM=" | base64 -d | od -c 0000000 c n = 1 267 2 . 2 3 . 5 8 . 2 1 0 0000020 , c n = C l i e n t s , c n = R 0000040 e s N e t S e r v i c e C o 0000060 n f i g , o u = H o s t C o n 0000100 f i g , o = R u t g e r s C C 0000120 F , c = U S 0000126 does this help? the "7" in 172 is something else (octal 267, I believe). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5342) DN and naming attribute mismatch
by richton＠nbcs.rutgers.edu 29 Jan '08

29 Jan '08

Full_Name: Aaron Richton Version: 2.3.40 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.6.31.135) $ ldapsearch -LLL '(cn=172.23.58.210)' dn:: Y249MbcyLjIzLjU4LjIxMCxjbj1DbGllbnRzLGNuPVJlc05ldCBTZXJ2aWNlIENvbmZpZyxvd T1Ib3N0IENvbmZpZyxvPVJ1dGdlcnMgQ0NGLGM9VVM= objectClass: top objectClass: dhcpHost cn: 172.23.58.210 dhcpStatements: fixed-address 172.23.58.210 dhcpHWAddress: ethernet 00:17:3f:bf:c2:04 Is it just me, or does my cn attribute not match the cn in the dn? Uhhh...now what? (and no, I wasn't using an editor on the bdb files, or whatever other conspiracy theory is out there.) Also, if it helps, you can see on openldap-software my other misadventures with 2.3.40...this is just one that's really easy to prove.

1 0

Re: (ITS#5341) Invalid TLSCipherSuite causes hang
by vorlon＠debian.org 29 Jan '08

29 Jan '08

On Tue, Jan 29, 2008 at 11:31:43AM -0800, Quanah Gibson-Mount wrote: > --On Tuesday, January 29, 2008 11:09 AM -0800 Steve Langasek > <vorlon(a)debian.org> wrote: > > Anyway, the documented syntax for TLSCipherSuite is "$cipher1:$cipher2", > > not "$cipher1 $cipher2"; but setting such values gives me a hang on > > startup (which should be investigated). > Filed upstream: > <http://www.OpenLDAP.org/its/index.cgi?findid=5341> Sorry, the description of this ITS is inverted. It's *valid* ciphersuite values (i.e., "cipher1:cipher2") that cause the hang; invalid space-separated values are merely truncated after the first cipher in the list, which doesn't cause a hang, it just prevents the cipher list from being useful. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek(a)ubuntu.com vorlon(a)debian.org

1 0

(ITS#5341) Invalid TLSCipherSuite causes hang
by quanah＠OpenLDAP.org 29 Jan '08

29 Jan '08

Full_Name: Quanah Gibson-Mount Version: 2.4.7 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) Setting TLSCipherSuite to "cipher1 cipher2" rather than "cipher1:cipher2" causes slapd to hang on startup (at least when using GnuTLS). It appears to be hanging indefinitely in ldap_pvt_tls_set_option() --Quanah

1 0

Re: (ITS#5328) backends sending/setting results
by h.b.furuseth＠usit.uio.no 29 Jan '08

29 Jan '08

Other bugs: * be->be_chk_referrals: back-bdb and back-ldif can send errors from be->be_chk_referrals. As far as I can tell that is wrong: It should return an LDAP result code, but only send it if it is LDAP_REFERRAL. backend_check_referrals() will send other errors, and success means it'll proceed to the be->be_<operation>() call. * be->be_fetch() (bi->bi_entry_get_rw()): The LDAP result code matters to at least aci.c:dynacl_aci_mask() and frontendDB->be_compare() (compare.c:fe_op_compare()). These use it via backend_attribute(), using frontendDB->be_attribute() (fe_acl_attribute()), using backend.c:be_entry_get_rw(). It can return just a boolean in back-null, back-ldif, back-relay and back-config. back-null usually pretends the entries are present, so maybe it should do "return oc ? LDAP_NO_SUCH_ATTRIBUTE : LDAP_BUSY;". * Internal slapd errors. back-ldap:ldap_back_entry_get() can return LDAP_NO_MEMORY. Maybe that's OK and instead send_ldap_response() should change negative negative result codes to LDAP_OTHER? -- Hallvard

1 0

(ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by h.b.furuseth＠usit.uio.no 29 Jan '08

29 Jan '08

Full_Name: Hallvard B Furuseth Version: OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard overlays/dynlist.c lines 371-376 sets REP_ENTRY_MUSTBEFREED in rs->sr_flags without duplicating the entry, if REP_ENTRY_MODIFIABLE was set. Thus the entry gets freed twice. Breaks test044-dynlist with back-ldif. This code snippet fixes it for test044, but it may be the wrong fix: e = rs->sr_entry; e_flags = rs->sr_flags; if ( !( e_flags & REP_ENTRY_MODIFIABLE ) ) { e = entry_dup( e ); if ( e_flags & REP_ENTRY_MUSTBEFREED ) entry_free( rs->sr_entry ); e_flags |= REP_ENTRY_MODIFIABLE | REP_ENTRY_MUSTBEFREED; } First, can something have references into the old sr_entry at this point? Second, there is also a REP_ENTRY_MUSTRELEASE flag which means to call be_entry_release_rw(), maybe that must be handled. Also overlays collect, pcache & valsort ignore REP_ENTRY_MUSTRELEASE. A common function to handle this might be useful - pass it a SlapResponse, BackendDB and flags to set and flags to unset, and let it free, release or dup what is needed.

1 0

Re: (ITS#5339) wrong referral from back-bdb
by h.b.furuseth＠usit.uio.no 29 Jan '08

29 Jan '08

I wrote: > !be_issuffix( op->o_bd,&op->o_req_ndn ) > which looks to me like a test for whether this function is _not_ to be > called for this database. No, that's a test if the DN is the exact suffix, not if it has the suffix. Anyway, for what it's worth "make test" succeeds with an "assert(0)" after the !be_issuffix test. -- Hallvard

1 0

ldap_result error
by Fabio Ubaldi 29 Jan '08

29 Jan '08

Hi all, I have two processes running on the same PC that receive data from an LDAP server. Each process opens a connection with a different "slapd" server (i.e each server runs on a different PC) and launches "search" requests at a fixed rate (about 100 searches/s). Each process creates a thread that polls the server responses using the API "ldap_result" the used macro are LDAP_RES_ANY and LDAP_MSG_ONE. When the two processes send the requestes one of the two "ldap_result" return with error (-1) and the error is "Can't contact the LDAP server". I tried to launch one processes and it works fine (the maximum measured rate is 800 searches/s). Also I launch the two processes alternating the search requestes and it works fine. It seems that the error happens only if the two process runs simultaneously (I use a dual core PC). Thinking of a race condition error , I used the libldap_r library to build process, but the error still remains. The openldap version is 2.3.27 both for slapd servers and the libraries. Have anyone encountered a similar error ? Thanks in advance for the reply

1 0

Re: (ITS#5339) wrong referral from back-bdb
by h.b.furuseth＠usit.uio.no 29 Jan '08

29 Jan '08

hyc(a)symas.com writes: > Can you try testing with be_chk_referrals NULL'd out? That breaks test032-chain. -- Hallvard

1 0

Re: (ITS#5339) wrong referral from back-bdb
by hyc＠symas.com 29 Jan '08

29 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > If a referral object's "ref" DN differs from the entry DN, and > you update a subordinate of the referral object, the DN part > of the referral from back-bdb is wrong. > > bash$ cat ref.ldif > dn: o=we > o: we > ref: ldap://elsewhere/o=they > objectClass: referral > objectClass: extensibleObject > > dn: cn=me,o=we > cn: me > objectClass: organizationalRole > > bash$ ldapadd ...< ref.ldif > adding new entry "o=we" > > adding new entry "cn=me,o=we" > ldap_add: Referral (10) > matched DN: o=we > referrals: > ldap://elsewhere/cn=me,o=we > > It works if NULL is changed to&e->e_name at back-bdb/referral.c line 96: > > rs->sr_ref = referral_rewrite( ref, NULL, > &op->o_req_dn, LDAP_SCOPE_DEFAULT ); > > I don't quite understand that function though: > Why does it use default_referral (slapd.conf 'referral')? That is for > use when no local backend database handles the operation, which I would > think means no database's be_chk_referrals() gets be called. And indeed > the function uses it if > !be_issuffix( op->o_bd,&op->o_req_ndn ) > which looks to me like a test for whether this function is _not_ to be > called for this database. I've never understood that function either. ;) It seems completely unnecessary, since the individual operations' code also does referral checks. Can you try testing with be_chk_referrals NULL'd out? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5339) wrong referral from back-bdb
by h.b.furuseth＠usit.uio.no 29 Jan '08

29 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard If a referral object's "ref" DN differs from the entry DN, and you update a subordinate of the referral object, the DN part of the referral from back-bdb is wrong. bash$ cat ref.ldif dn: o=we o: we ref: ldap://elsewhere/o=they objectClass: referral objectClass: extensibleObject dn: cn=me,o=we cn: me objectClass: organizationalRole bash$ ldapadd ... < ref.ldif adding new entry "o=we" adding new entry "cn=me,o=we" ldap_add: Referral (10) matched DN: o=we referrals: ldap://elsewhere/cn=me,o=we It works if NULL is changed to &e->e_name at back-bdb/referral.c line 96: rs->sr_ref = referral_rewrite( ref, NULL, &op->o_req_dn, LDAP_SCOPE_DEFAULT ); I don't quite understand that function though: Why does it use default_referral (slapd.conf 'referral')? That is for use when no local backend database handles the operation, which I would think means no database's be_chk_referrals() gets be called. And indeed the function uses it if !be_issuffix( op->o_bd, &op->o_req_ndn ) which looks to me like a test for whether this function is _not_ to be called for this database.

1 0

Re: (ITS#5280) JLDAP waits for response for request which hasn't been sent because of connection shutdown
by Rastogi Arpit 25 Jan '08

25 Jan '08

Hi Marcin , I will be out of the city for a couple of weeks . I am copying my manager and back up owner for the issue. However I would like to know which server you are using as I tried replicating the issue but was not able to using edirectory server. the debug messages suggest that it is in search but those are not of much help till we replicate the issue . If you require any help back up owner will try to provide you the help based on his priorities. And also in the forum if any body is interested he can take the bug forward working with you . regards Arpit

1 0

Re: (ITS#5280) JLDAP waits for response for request which hasn't been sent because of connection shutdown
by rarpit＠novell.com 25 Jan '08

25 Jan '08

Hi Marcin , I will be out of the city for a couple of weeks . I am copying my manager and back up owner for the issue. However I would like to know which server you are using as I tried replicating the issue but was not able to using edirectory server. the debug messages suggest that it is in search but those are not of much help till we replicate the issue . If you require any help back up owner will try to provide you the help based on his priorities. And also in the forum if any body is interested he can take the bug forward working with you . regards Arpit

1 0

(ITS#5338) Wrong debug message in ldap_open
by ma＠sernet.de 24 Jan '08

24 Jan '08

Full_Name: Michael Adam Version: 2.3 and current CVS OS: Linux URL: http://samba.org/~obnox/openldap/openldap.ldap_open.diff Submission from: (NULL) (77.181.84.116) I know, ldap_open() is deprecated, but anyhow: The final debug message in ldap_open() is wrong. Success and failure are confused. A patch to fix this debug message is available at the URL mentioned below.

1 0

Re: (ITS#5337) Start Slapd failure!!!
by ando＠sys-net.it 24 Jan '08

24 Jan '08

dugangfeng(a)163.com wrote: > hi all: > I start slapd by -d -1 command,'slapd -d -1',but print this: > > > @(#) $OpenLDAP: slapd 2.2.13 (Aug 19 2004 21:22:15) $ ^^^ you're actully running OpenLDAP 2.2.13 with more recent schema files. > root@porky.build.redhat.com:/usr/src/build/440386-i386/BUILD/openldap-2.2.13/openldap-2.2.13/build-servers/servers/slapd > daemon_init: <null> > daemon_init: listen on ldap:/// > daemon_init: 1 listeners to open... > ldap_url_parse_ext(ldap:///) > daemon: initialized ldap:/// > daemon_init: 2 listeners opened > slapd init: initiated server. > slap_sasl_init: initialized! > bdb_initialize: initialize BDB backend > bdb_initialize: Sleepycat Software: Berkeley DB 4.2.52: (December 3, 2003) > bdb_initialize: initialize BDB backend > bdb_initialize: Sleepycat Software: Berkeley DB 4.2.52: (December 3, 2003) > reading config file /etc/openldap/slapd.conf > line 5 (include /etc/openldap/schema/core.schema) > reading config file /etc/openldap/schema/core.schema > line 78 (attributetype ( 2.5.4.2 NAME 'knowledgeInformation' DESC 'RFC2256: > knowledge information' EQUALITY caseIgnoreMatch SYNTAX > 1.3.6.1.4.1.1466.115.121.1.15{32768} )) > line 87 (attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' ) DESC 'RFC2256: last > (family) name(s) for which the entity is known by' SUP name )) > line 93 (attributetype ( 2.5.4.5 NAME 'serialNumber' DESC 'RFC2256: serial > number of the entity' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} )) > line 100 (attributetype ( 2.5.4.6 NAME ( 'c' 'countryName' ) DESC 'RFC4519: > two-letter ISO-3166 country code' SUP name SYNTAX 1.3.6.1.4.1.1466.115.121.1.11 > SINGLE-VALUE )) > /etc/openldap/schema/core.schema: line 100: AttributeType inappropriate > SUPerior: "c" > slapd shutdown: freeing system resources. > slapd stopped. > connections_destroy: nothing to destroy. > > > please help me ,thanks. You need to use consistent code/configuration. As there is no evidence of a bug, this ITS will be closed. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5337) Start Slapd failure!!!
by hyc＠symas.com 24 Jan '08

24 Jan '08

dugangfeng(a)163.com wrote: > Full_Name: dugangfeng > Version: openldap-2.4.7 > OS: linuxAS4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (61.181.247.78) > > > hi all: > I start slapd by -d -1 command,'slapd -d -1',but print this: Your report says OpenLDAP 2.4.7 but the debug output you provided clearly says OpenLDAP 2.2.13, from August 2004. It appears you're running the wrong version. > @(#) $OpenLDAP: slapd 2.2.13 (Aug 19 2004 21:22:15) $ > root@porky.build.redhat.com:/usr/src/build/440386-i386/BUILD/openldap-2.2.13/openldap-2.2.13/build-servers/servers/slapd > daemon_init:<null> > please help me ,thanks. The ITS is for actual bug reports, not for help requests. Use the OpenLDAP-software mailing list for help using the software. There is no OpenLDAP bug here, this ITS will be closed. If you actually paid attention to the diagnostic output it would be obvious what the problem is. The biggest help we can give you is to tell you to read more carefully. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re:Re: (ITS#5337) Start Slapd failure!!!
by dugangfeng＠163.com 23 Jan '08

23 Jan '08

------=_Part_162959_15053760.1201154655304 Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: 7bit this is my slapd.conf: /////////////////////////////////////////////////////// # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema #include /usr/local/etc/openldap/schema/corba.schema #include /usr/local/etc/openldap/schema/cosine.schema #include /usr/local/etc/openldap/schema/inetorgperson.schema #include /usr/local/etc/openldap/schema/misc.schema #include /usr/local/etc/openldap/schema/openldap.schema #include /usr/local/etc/openldap/schema/nis.schema #include /usr/local/etc/openldap/schema/samba.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args # Load dynamic backend modules: # modulepath /usr/local/libexec/openldap # moduleload back_bdb.la # moduleload back_hdb.la # moduleload back_ldap.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=gfdu,dc=com" rootdn "cn=Manager,dc=gfdu,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/local/var/openldap-data # Indices to maintain index objectClass eq /////////////////////////////////////////////////////////////////// this is my core.schema: # OpenLDAP Core schema # $OpenLDAP: pkg/ldap/servers/slapd/schema/core.schema,v 1.88.2.5 2007/12/13 07:31:15 hyc Exp $ ## This work is part of OpenLDAP Software <http://www.openldap.org/>. ## ## Copyright 1998-2007 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>. # ## Portions Copyright (C) The Internet Society (1997-2006). ## All Rights Reserved. ## ## This document and translations of it may be copied and furnished to ## others, and derivative works that comment on or otherwise explain it ## or assist in its implementation may be prepared, copied, published ## and distributed, in whole or in part, without restriction of any ## kind, provided that the above copyright notice and this paragraph are ## included on all such copies and derivative works. However, this ## document itself may not be modified in any way, such as by removing ## the copyright notice or references to the Internet Society or other ## Internet organizations, except as needed for the purpose of ## developing Internet standards in which case the procedures for ## copyrights defined in the Internet Standards process must be ## followed, or as required to translate it into languages other than ## English. ## ## The limited permissions granted above are perpetual and will not be ## revoked by the Internet Society or its successors or assigns. ## ## This document and the information contained herein is provided on an ## "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING ## TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING ## BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION ## HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF ## MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. # # # Includes LDAPv3 schema items from: # RFC 2252/2256 (LDAPv3) # # Select standard track schema items: # RFC 1274 (uid/dc) # RFC 2079 (URI) # RFC 2247 (dc/dcObject) # RFC 2587 (PKI) # RFC 2589 (Dynamic Directory Services) # RFC 4524 (associatedDomain) # # Select informational schema items: # RFC 2377 (uidObject) # # Standard attribute types from RFC 2256 # # system schema #attributetype ( 2.5.4.0 NAME 'objectClass' # DESC 'RFC2256: object classes of the entity' # EQUALITY objectIdentifierMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) # system schema #attributetype ( 2.5.4.1 NAME ( 'aliasedObjectName' 'aliasedEntryName' ) # DESC 'RFC2256: name of aliased object' # EQUALITY distinguishedNameMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) attributetype ( 2.5.4.2 NAME 'knowledgeInformation' DESC 'RFC2256: knowledge information' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) # system schema #attributetype ( 2.5.4.3 NAME ( 'cn' 'commonName' ) # DESC 'RFC2256: common name(s) for which the entity is known by' # SUP name ) attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' ) DESC 'RFC2256: last (family) name(s) for which the entity is known by' SUP name ) attributetype ( 2.5.4.5 NAME 'serialNumber' DESC 'RFC2256: serial number of the entity' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} ) # RFC 4519 definition ('countryName' in X.500 and RFC2256) attributetype ( 2.5.4.6 NAME ( 'c' 'countryName' ) DESC 'RFC2256: two-letter ISO-3166 country code' SUP name SYNTAX 1.3.6.1.4.1.1466.115.121.1.11 SINGLE-VALUE ) #attributetype ( 2.5.4.6 NAME ( 'c' 'countryName' ) # DESC 'RFC2256: ISO-3166 country 2-letter code' # SUP name SINGLE-VALUE ) attributetype ( 2.5.4.7 NAME ( 'l' 'localityName' ) DESC 'RFC2256: locality which this object resides in' SUP name ) attributetype ( 2.5.4.8 NAME ( 'st' 'stateOrProvinceName' ) DESC 'RFC2256: state or province which this object resides in' SUP name ) attributetype ( 2.5.4.9 NAME ( 'street' 'streetAddress' ) DESC 'RFC2256: street address of this object' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} ) attributetype ( 2.5.4.10 NAME ( 'o' 'organizationName' ) DESC 'RFC2256: organization this object belongs to' SUP name ) attributetype ( 2.5.4.11 NAME ( 'ou' 'organizationalUnitName' ) DESC 'RFC2256: organizational unit this object belongs to' SUP name ) attributetype ( 2.5.4.12 NAME 'title' DESC 'RFC2256: title associated with the entity' SUP name ) # system schema #attributetype ( 2.5.4.13 NAME 'description' # DESC 'RFC2256: descriptive information' # EQUALITY caseIgnoreMatch # SUBSTR caseIgnoreSubstringsMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) # Deprecated by enhancedSearchGuide attributetype ( 2.5.4.14 NAME 'searchGuide' DESC 'RFC2256: search guide, deprecated by enhancedSearchGuide' SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 ) attributetype ( 2.5.4.15 NAME 'businessCategory' DESC 'RFC2256: business category' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} ) attributetype ( 2.5.4.16 NAME 'postalAddress' DESC 'RFC2256: postal address' EQUALITY caseIgnoreListMatch SUBSTR caseIgnoreListSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) attributetype ( 2.5.4.17 NAME 'postalCode' DESC 'RFC2256: postal code' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} ) attributetype ( 2.5.4.18 NAME 'postOfficeBox' DESC 'RFC2256: Post Office Box' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} ) attributetype ( 2.5.4.19 NAME 'physicalDeliveryOfficeName' DESC 'RFC2256: Physical Delivery Office Name' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} ) attributetype ( 2.5.4.20 NAME 'telephoneNumber' DESC 'RFC2256: Telephone Number' EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} ) attributetype ( 2.5.4.21 NAME 'telexNumber' DESC 'RFC2256: Telex Number' SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 ) attributetype ( 2.5.4.22 NAME 'teletexTerminalIdentifier' DESC 'RFC2256: Teletex Terminal Identifier' SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 ) attributetype ( 2.5.4.23 NAME ( 'facsimileTelephoneNumber' 'fax' ) DESC 'RFC2256: Facsimile (Fax) Telephone Number' SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 ) attributetype ( 2.5.4.24 NAME 'x121Address' DESC 'RFC2256: X.121 Address' EQUALITY numericStringMatch SUBSTR numericStringSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{15} ) attributetype ( 2.5.4.25 NAME 'internationaliSDNNumber' DESC 'RFC2256: international ISDN number' EQUALITY numericStringMatch SUBSTR numericStringSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{16} ) attributetype ( 2.5.4.26 NAME 'registeredAddress' DESC 'RFC2256: registered postal address' SUP postalAddress SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) attributetype ( 2.5.4.27 NAME 'destinationIndicator' DESC 'RFC2256: destination indicator' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} ) attributetype ( 2.5.4.28 NAME 'preferredDeliveryMethod' DESC 'RFC2256: preferred delivery method' SYNTAX 1.3.6.1.4.1.1466.115.121.1.14 SINGLE-VALUE ) attributetype ( 2.5.4.29 NAME 'presentationAddress' DESC 'RFC2256: presentation address' EQUALITY presentationAddressMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.43 SINGLE-VALUE ) attributetype ( 2.5.4.30 NAME 'supportedApplicationContext' DESC 'RFC2256: supported application context' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) attributetype ( 2.5.4.31 NAME 'member' DESC 'RFC2256: member of a group' SUP distinguishedName ) attributetype ( 2.5.4.32 NAME 'owner' DESC 'RFC2256: owner (of the object)' SUP distinguishedName ) attributetype ( 2.5.4.33 NAME 'roleOccupant' DESC 'RFC2256: occupant of role' SUP distinguishedName ) # system schema #attributetype ( 2.5.4.34 NAME 'seeAlso' # DESC 'RFC2256: DN of related object' # SUP distinguishedName ) # system schema #attributetype ( 2.5.4.35 NAME 'userPassword' # DESC 'RFC2256/2307: password of user' # EQUALITY octetStringMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} ) # Must be transferred using ;binary # with certificateExactMatch rule (per X.509) attributetype ( 2.5.4.36 NAME 'userCertificate' DESC 'RFC2256: X.509 user certificate, use ;binary' EQUALITY certificateExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 ) # Must be transferred using ;binary # with certificateExactMatch rule (per X.509) attributetype ( 2.5.4.37 NAME 'cACertificate' DESC 'RFC2256: X.509 CA certificate, use ;binary' EQUALITY certificateExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 ) # Must be transferred using ;binary attributetype ( 2.5.4.38 NAME 'authorityRevocationList' DESC 'RFC2256: X.509 authority revocation list, use ;binary' SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 ) # Must be transferred using ;binary attributetype ( 2.5.4.39 NAME 'certificateRevocationList' DESC 'RFC2256: X.509 certificate revocation list, use ;binary' SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 ) # Must be stored and requested in the binary form attributetype ( 2.5.4.40 NAME 'crossCertificatePair' DESC 'RFC2256: X.509 cross certificate pair, use ;binary' SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 ) # system schema #attributetype ( 2.5.4.41 NAME 'name' # EQUALITY caseIgnoreMatch # SUBSTR caseIgnoreSubstringsMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) attributetype ( 2.5.4.42 NAME ( 'givenName' 'gn' ) DESC 'RFC2256: first name(s) for which the entity is known by' SUP name ) attributetype ( 2.5.4.43 NAME 'initials' DESC 'RFC2256: initials of some or all of names, but not the surname(s).' SUP name ) attributetype ( 2.5.4.44 NAME 'generationQualifier' DESC 'RFC2256: name qualifier indicating a generation' SUP name ) attributetype ( 2.5.4.45 NAME 'x500UniqueIdentifier' DESC 'RFC2256: X.500 unique identifier' EQUALITY bitStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) attributetype ( 2.5.4.46 NAME 'dnQualifier' DESC 'RFC2256: DN qualifier' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 ) attributetype ( 2.5.4.47 NAME 'enhancedSearchGuide' DESC 'RFC2256: enhanced search guide' SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 ) attributetype ( 2.5.4.48 NAME 'protocolInformation' DESC 'RFC2256: protocol information' EQUALITY protocolInformationMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 ) # system schema #attributetype ( 2.5.4.49 NAME 'distinguishedName' # EQUALITY distinguishedNameMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) attributetype ( 2.5.4.50 NAME 'uniqueMember' DESC 'RFC2256: unique member of a group' EQUALITY uniqueMemberMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) attributetype ( 2.5.4.51 NAME 'houseIdentifier' DESC 'RFC2256: house identifier' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) # Must be transferred using ;binary attributetype ( 2.5.4.52 NAME 'supportedAlgorithms' DESC 'RFC2256: supported algorithms' SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 ) # Must be transferred using ;binary attributetype ( 2.5.4.53 NAME 'deltaRevocationList' DESC 'RFC2256: delta revocation list; use ;binary' SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 ) attributetype ( 2.5.4.54 NAME 'dmdName' DESC 'RFC2256: name of DMD' SUP name ) attributetype ( 2.5.4.65 NAME 'pseudonym' DESC 'X.520(4th): pseudonym for the object' SUP name ) # Standard object classes from RFC2256 # system schema #objectclass ( 2.5.6.0 NAME 'top' # DESC 'RFC2256: top of the superclass chain' # ABSTRACT # MUST objectClass ) # system schema #objectclass ( 2.5.6.1 NAME 'alias' # DESC 'RFC2256: an alias' # SUP top STRUCTURAL # MUST aliasedObjectName ) objectclass ( 2.5.6.2 NAME 'country' DESC 'RFC2256: a country' SUP top STRUCTURAL MUST c MAY ( searchGuide $ description ) ) objectclass ( 2.5.6.3 NAME 'locality' DESC 'RFC2256: a locality' SUP top STRUCTURAL MAY ( street $ seeAlso $ searchGuide $ st $ l $ description ) ) objectclass ( 2.5.6.4 NAME 'organization' DESC 'RFC2256: an organization' SUP top STRUCTURAL MUST o MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) ) objectclass ( 2.5.6.5 NAME 'organizationalUnit' DESC 'RFC2256: an organizational unit' SUP top STRUCTURAL MUST ou MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) ) objectclass ( 2.5.6.6 NAME 'person' DESC 'RFC2256: a person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) ) objectclass ( 2.5.6.7 NAME 'organizationalPerson' DESC 'RFC2256: an organizational person' SUP person STRUCTURAL MAY ( title $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) ) objectclass ( 2.5.6.8 NAME 'organizationalRole' DESC 'RFC2256: an organizational role' SUP top STRUCTURAL MUST cn MAY ( x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ seeAlso $ roleOccupant $ preferredDeliveryMethod $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l $ description ) ) objectclass ( 2.5.6.9 NAME 'groupOfNames' DESC 'RFC2256: a group of names (DNs)' SUP top STRUCTURAL MUST ( member $ cn ) MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) ) objectclass ( 2.5.6.10 NAME 'residentialPerson' DESC 'RFC2256: an residential person' SUP person STRUCTURAL MUST l MAY ( businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ preferredDeliveryMethod $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l ) ) objectclass ( 2.5.6.11 NAME 'applicationProcess' DESC 'RFC2256: an application process' SUP top STRUCTURAL MUST cn MAY ( seeAlso $ ou $ l $ description ) ) objectclass ( 2.5.6.12 NAME 'applicationEntity' DESC 'RFC2256: an application entity' SUP top STRUCTURAL MUST ( presentationAddress $ cn ) MAY ( supportedApplicationContext $ seeAlso $ ou $ o $ l $ description ) ) objectclass ( 2.5.6.13 NAME 'dSA' DESC 'RFC2256: a directory system agent (a server)' SUP applicationEntity STRUCTURAL MAY knowledgeInformation ) objectclass ( 2.5.6.14 NAME 'device' DESC 'RFC2256: a device' SUP top STRUCTURAL MUST cn MAY ( serialNumber $ seeAlso $ owner $ ou $ o $ l $ description ) ) objectclass ( 2.5.6.15 NAME 'strongAuthenticationUser' DESC 'RFC2256: a strong authentication user' SUP top AUXILIARY MUST userCertificate ) objectclass ( 2.5.6.16 NAME 'certificationAuthority' DESC 'RFC2256: a certificate authority' SUP top AUXILIARY MUST ( authorityRevocationList $ certificateRevocationList $ cACertificate ) MAY crossCertificatePair ) objectclass ( 2.5.6.17 NAME 'groupOfUniqueNames' DESC 'RFC2256: a group of unique names (DN and Unique Identifier)' SUP top STRUCTURAL MUST ( uniqueMember $ cn ) MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) ) objectclass ( 2.5.6.18 NAME 'userSecurityInformation' DESC 'RFC2256: a user security information' SUP top AUXILIARY MAY ( supportedAlgorithms ) ) objectclass ( 2.5.6.16.2 NAME 'certificationAuthority-V2' SUP certificationAuthority AUXILIARY MAY ( deltaRevocationList ) ) objectclass ( 2.5.6.19 NAME 'cRLDistributionPoint' SUP top STRUCTURAL MUST ( cn ) MAY ( certificateRevocationList $ authorityRevocationList $ deltaRevocationList ) ) objectclass ( 2.5.6.20 NAME 'dmd' SUP top STRUCTURAL MUST ( dmdName ) MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) ) # # Object Classes from RFC 2587 # objectclass ( 2.5.6.21 NAME 'pkiUser' DESC 'RFC2587: a PKI user' SUP top AUXILIARY MAY userCertificate ) objectclass ( 2.5.6.22 NAME 'pkiCA' DESC 'RFC2587: PKI certificate authority' SUP top AUXILIARY MAY ( authorityRevocationList $ certificateRevocationList $ cACertificate $ crossCertificatePair ) ) objectclass ( 2.5.6.23 NAME 'deltaCRL' DESC 'RFC2587: PKI user' SUP top AUXILIARY MAY deltaRevocationList ) # # Standard Track URI label schema from RFC 2079 # system schema #attributetype ( 1.3.6.1.4.1.250.1.57 NAME 'labeledURI' # DESC 'RFC2079: Uniform Resource Identifier with optional label' # EQUALITY caseExactMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) objectclass ( 1.3.6.1.4.1.250.3.15 NAME 'labeledURIObject' DESC 'RFC2079: object that contains the URI attribute type' SUP top AUXILIARY MAY ( labeledURI ) ) # # Derived from RFC 1274, but with new "short names" # #attributetype ( 0.9.2342.19200300.100.1.1 # NAME ( 'uid' 'userid' ) # DESC 'RFC1274: user identifier' # EQUALITY caseIgnoreMatch # SUBSTR caseIgnoreSubstringsMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) attributetype ( 0.9.2342.19200300.100.1.3 NAME ( 'mail' 'rfc822Mailbox' ) DESC 'RFC1274: RFC822 Mailbox' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) objectclass ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject' DESC 'RFC1274: simple security object' SUP top AUXILIARY MUST userPassword ) # RFC 1274 + RFC 2247 attributetype ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domainComponent' ) DESC 'RFC1274/2247: domain component' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) # RFC 2247 objectclass ( 1.3.6.1.4.1.1466.344 NAME 'dcObject' DESC 'RFC2247: domain component object' SUP top AUXILIARY MUST dc ) # RFC 2377 objectclass ( 1.3.6.1.1.3.1 NAME 'uidObject' DESC 'RFC2377: uid object' SUP top AUXILIARY MUST uid ) # RFC 4524 # 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 (".") attributetype ( 0.9.2342.19200300.100.1.37 NAME 'associatedDomain' DESC 'RFC1274: domain associated with object' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) # RFC 2459 -- deprecated in favor of 'mail' (in cosine.schema) attributetype ( 1.2.840.113549.1.9.1 NAME ( 'email' 'emailAddress' 'pkcs9email' ) DESC 'RFC3280: legacy attribute for email addresses in DNs' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{128} ) ------=_Part_162959_15053760.1201154655304 Content-Type: text/html; charset=gbk Content-Transfer-Encoding: quoted-printable <DIV>this is my slapd.conf:</DIV> <DIV>///////////////////////////////////////////////////////</DIV> <DIV>#<BR># See slapd.conf(5) for details on configuration options.<BR># Th= is file should NOT be world readable.<BR>#<BR>include  /usr/local= /etc/openldap/schema/core.schema<BR>#include     &= nbsp;   /usr/local/etc/openldap/schema/corba.schema<BR>#include&n= bsp;        /usr/local/etc/openldap/sche= ma/cosine.schema<BR>#include       &nbsp= ; /usr/local/etc/openldap/schema/inetorgperson.schema<BR>#include &nbs= p;       /usr/local/etc/openldap/schema/misc.= schema<BR>#include         /usr/loc= al/etc/openldap/schema/openldap.schema<BR>#include    &= nbsp;    /usr/local/etc/openldap/schema/nis.schema<BR>#inclu= de         /usr/local/etc/openldap/= schema/samba.schema</DIV> <DIV> </DIV> <DIV># Define global ACLs to disable default read access.</DIV> <DIV># Do not enable referrals until AFTER you have a working directory<BR>= # service AND an understanding of referrals.<BR>#referral <A href=3D"l= dap://root.openldap.org">ldap://root.openldap.org</A></DIV> <DIV>pidfile  /usr/local/var/run/slapd.pid<BR>argsfile /usr/= local/var/run/slapd.args</DIV> <DIV># Load dynamic backend modules:<BR># modulepath /usr/local/libexe= c/openldap<BR># moduleload back_bdb.la<BR># moduleload back_hdb.l= a<BR># moduleload back_ldap.la</DIV> <DIV># Sample security restrictions<BR># Require integrity protection = (prevent hijacking)<BR># Require 112-bit (3DES or better) encryption f= or updates<BR># Require 63-bit encryption for simple bind<BR># securit= y ssf=3D1 update_ssf=3D112 simple_bind=3D64</DIV> <DIV># Sample access control policy:<BR># Root DSE: allow anyone to re= ad it<BR># Subschema (sub)entry DSE: allow anyone to read it<BR>#&nbsp= ;Other DSEs:<BR>#  Allow self write access<BR>#  Allow = authenticated users read access<BR>#  Allow anonymous users to au= thenticate<BR># Directives needed to implement policy:<BR># access to = dn.base=3D"" by * read<BR># access to dn.base=3D"cn=3DSubschema" by * read<= BR># access to *<BR># by self write<BR># by users read<BR># = by anonymous auth<BR>#<BR># if no access controls are present, the default = policy<BR># allows anyone and everyone to read anything but restricts<BR># = updates to rootdn.  (e.g., "access to * by * read")<BR>#<BR># rootdn c= an always read and write EVERYTHING!</DIV> <DIV>######################################################################= #<BR># BDB database definitions<BR>########################################= ###############################</DIV> <DIV>database bdb<BR>suffix  "dc=3Dgfdu,dc=3Dcom"<BR>rootdn&= nbsp; "cn=3DManager,dc=3Dgfdu,dc=3Dcom"<BR># Cleartext passwords, espe= cially for the rootdn, should<BR># be avoid.  See slappasswd(8) and sl= apd.conf(5) for details.<BR># Use of strong authentication encouraged.<BR>r= ootpw  secret<BR># The database directory MUST exist prior to run= ning slapd AND <BR># should only be accessible by the slapd and slap tools.= <BR># Mode 700 recommended.<BR>directory /usr/local/var/openldap-data<= BR># Indices to maintain<BR>index objectClass eq<BR></DIV> <DIV>///////////////////////////////////////////////////////////////////</D= IV> <DIV> </DIV> <DIV>this is my core.schema:</DIV> <DIV> </DIV> <DIV># OpenLDAP Core schema<BR># $OpenLDAP: pkg/ldap/servers/slapd/schema/c= ore.schema,v 1.88.2.5 2007/12/13 07:31:15 hyc Exp $<BR>## This work is part= of OpenLDAP Software <<A href=3D"http://www.openldap.org/">http://www.o= penldap.org/</A>>.<BR>##<BR>## Copyright 1998-2007 The OpenLDAP Foundati= on.<BR>## All rights reserved.<BR>##<BR>## Redistribution and use in source= and binary forms, with or without<BR>## modification, are permitted only a= s authorized by the OpenLDAP<BR>## Public License.<BR>##<BR>## A copy of th= is license is available in the file LICENSE in the<BR>## top-level director= y of the distribution or, alternatively, at<BR>## <<A href=3D"http://www= .OpenLDAP.org/license.html">http://www.OpenLDAP.org/license.html</A>>.<B= R>#<BR>## Portions Copyright (C) The Internet Society (1997-2006).<BR>## Al= l Rights Reserved.<BR>##<BR>## This document and translations of it may be = copied and furnished to<BR>## others, and derivative works that comment on = or otherwise explain it<BR>## or assist in its implementation may be prepar= ed, copied, published<BR>## and distributed, in whole or in part, without r= estriction of any<BR>## kind, provided that the above copyright notice and = this paragraph are<BR>## included on all such copies and derivative works.&= nbsp; However, this<BR>## document itself may not be modified in any way, s= uch as by removing<BR>## the copyright notice or references to the Internet= Society or other<BR>## Internet organizations, except as needed for the pu= rpose of<BR>## developing Internet standards in which case the procedures f= or<BR>## copyrights defined in the Internet Standards process must be =         <BR>## followed, or as required = to translate it into languages other than<BR>## English.<BR>##  &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     <BR>## The limited permissions granted above are= perpetual and will not be  <BR>## revoked by the Internet Society or = its successors or assigns.        <BR>##= <BR>## This document and the information contained herein is provided on a= n <BR>## "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERIN= G<BR>## TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING<= BR>## BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION<BR>##= HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF<BR>## MER= CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</DIV> <DIV>#<BR>#<BR># Includes LDAPv3 schema items from:<BR># RFC 2252/2256= (LDAPv3)<BR>#<BR># Select standard track schema items:<BR># RFC 1274 = (uid/dc)<BR># RFC 2079 (URI)<BR># RFC 2247 (dc/dcObject)<BR>#&nbs= p;RFC 2587 (PKI)<BR># RFC 2589 (Dynamic Directory Services)<BR># = RFC 4524 (associatedDomain)<BR>#<BR># Select informational schema items:<BR= ># RFC 2377 (uidObject)</DIV> <DIV>#<BR># Standard attribute types from RFC 2256<BR>#</DIV> <DIV># system schema<BR>#attributetype ( 2.5.4.0 NAME 'objectClass'<BR>#&nb= sp;DESC 'RFC2256: object classes of the entity'<BR># EQUALITY objectId= entifierMatch<BR># SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )</DIV> <DIV># system schema<BR>#attributetype ( 2.5.4.1 NAME ( 'aliasedObjectName'= 'aliasedEntryName' )<BR># DESC 'RFC2256: name of aliased object'<BR>#=  EQUALITY distinguishedNameMatch<BR># SYNTAX 1.3.6.1.4.1.1466.115= .121.1.12 SINGLE-VALUE )</DIV> <DIV>attributetype ( 2.5.4.2 NAME 'knowledgeInformation'<BR> DESC 'RFC= 2256: knowledge information'<BR> EQUALITY caseIgnoreMatch<BR> SYN= TAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )</DIV> <DIV># system schema<BR>#attributetype ( 2.5.4.3 NAME ( 'cn' 'commonName' )= <BR># DESC 'RFC2256: common name(s) for which the entity is known by'<= BR># SUP name )</DIV> <DIV>attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' )<BR> DESC 'RFC2256= : last (family) name(s) for which the entity is known by'<BR> SUP name= )</DIV> <DIV>attributetype ( 2.5.4.5 NAME 'serialNumber'<BR> DESC 'RFC2256: se= rial number of the entity'<BR> EQUALITY caseIgnoreMatch<BR> SUBST= R caseIgnoreSubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{6= 4} )</DIV> <DIV># RFC 4519 definition ('countryName' in X.500 and RFC2256)<BR>attribut= etype ( 2.5.4.6 NAME ( 'c' 'countryName' )<BR> DESC 'RFC2256: two-lett= er ISO-3166 country code'<BR> SUP name<BR> SYNTAX 1.3.6.1.4.1.146= 6.115.121.1.11<BR> SINGLE-VALUE )</DIV> <DIV>#attributetype ( 2.5.4.6 NAME ( 'c' 'countryName' )<BR># DESC 'RF= C2256: ISO-3166 country 2-letter code'<BR># SUP name SINGLE-VALUE )</D= IV> <DIV>attributetype ( 2.5.4.7 NAME ( 'l' 'localityName' )<BR> DESC 'RFC= 2256: locality which this object resides in'<BR> SUP name )</DIV> <DIV>attributetype ( 2.5.4.8 NAME ( 'st' 'stateOrProvinceName' )<BR> D= ESC 'RFC2256: state or province which this object resides in'<BR> SUP = name )</DIV> <DIV>attributetype ( 2.5.4.9 NAME ( 'street' 'streetAddress' )<BR> DES= C 'RFC2256: street address of this object'<BR> EQUALITY caseIgnoreMatc= h<BR> SUBSTR caseIgnoreSubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.146= 6.115.121.1.15{128} )</DIV> <DIV>attributetype ( 2.5.4.10 NAME ( 'o' 'organizationName' )<BR> DESC= 'RFC2256: organization this object belongs to'<BR> SUP name )</DIV> <DIV>attributetype ( 2.5.4.11 NAME ( 'ou' 'organizationalUnitName' )<BR>&nb= sp;DESC 'RFC2256: organizational unit this object belongs to'<BR> SUP = name )</DIV> <DIV>attributetype ( 2.5.4.12 NAME 'title'<BR> DESC 'RFC2256: title as= sociated with the entity'<BR> SUP name )</DIV> <DIV># system schema<BR>#attributetype ( 2.5.4.13 NAME 'description'<BR>#&n= bsp;DESC 'RFC2256: descriptive information'<BR># EQUALITY caseIgnoreMa= tch<BR># SUBSTR caseIgnoreSubstringsMatch<BR># SYNTAX 1.3.6.1.4.1= .1466.115.121.1.15{1024} )</DIV> <DIV># Deprecated by enhancedSearchGuide<BR>attributetype ( 2.5.4.14 NAME '= searchGuide'<BR> DESC 'RFC2256: search guide, deprecated by enhancedSe= archGuide'<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )</DIV> <DIV>attributetype ( 2.5.4.15 NAME 'businessCategory'<BR> DESC 'RFC225= 6: business category'<BR> EQUALITY caseIgnoreMatch<BR> SUBSTR cas= eIgnoreSubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )= </DIV> <DIV>attributetype ( 2.5.4.16 NAME 'postalAddress'<BR> DESC 'RFC2256: = postal address'<BR> EQUALITY caseIgnoreListMatch<BR> SUBSTR caseI= gnoreListSubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )</D= IV> <DIV>attributetype ( 2.5.4.17 NAME 'postalCode'<BR> DESC 'RFC2256: pos= tal code'<BR> EQUALITY caseIgnoreMatch<BR> SUBSTR caseIgnoreSubst= ringsMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )</DIV> <DIV>attributetype ( 2.5.4.18 NAME 'postOfficeBox'<BR> DESC 'RFC2256: = Post Office Box'<BR> EQUALITY caseIgnoreMatch<BR> SUBSTR caseIgno= reSubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )</DIV> <DIV>attributetype ( 2.5.4.19 NAME 'physicalDeliveryOfficeName'<BR> DE= SC 'RFC2256: Physical Delivery Office Name'<BR> EQUALITY caseIgnoreMat= ch<BR> SUBSTR caseIgnoreSubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.14= 66.115.121.1.15{128} )</DIV> <DIV>attributetype ( 2.5.4.20 NAME 'telephoneNumber'<BR> DESC 'RFC2256= : Telephone Number'<BR> EQUALITY telephoneNumberMatch<BR> SUBSTR = telephoneNumberSubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.5= 0{32} )</DIV> <DIV>attributetype ( 2.5.4.21 NAME 'telexNumber'<BR> DESC 'RFC2256: Te= lex Number'<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )</DIV> <DIV>attributetype ( 2.5.4.22 NAME 'teletexTerminalIdentifier'<BR> DES= C 'RFC2256: Teletex Terminal Identifier'<BR> SYNTAX 1.3.6.1.4.1.1466.1= 15.121.1.51 )</DIV> <DIV>attributetype ( 2.5.4.23 NAME ( 'facsimileTelephoneNumber' 'fax' )<BR>=  DESC 'RFC2256: Facsimile (Fax) Telephone Number'<BR> SYNTAX 1.3.= 6.1.4.1.1466.115.121.1.22 )</DIV> <DIV>attributetype ( 2.5.4.24 NAME 'x121Address'<BR> DESC 'RFC2256: X.= 121 Address'<BR> EQUALITY numericStringMatch<BR> SUBSTR numericSt= ringSubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{15} )</DI= V> <DIV>attributetype ( 2.5.4.25 NAME 'internationaliSDNNumber'<BR> DESC = 'RFC2256: international ISDN number'<BR> EQUALITY numericStringMatch<B= R> SUBSTR numericStringSubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.146= 6.115.121.1.36{16} )</DIV> <DIV>attributetype ( 2.5.4.26 NAME 'registeredAddress'<BR> DESC 'RFC22= 56: registered postal address'<BR> SUP postalAddress<BR> SYNTAX 1= .3.6.1.4.1.1466.115.121.1.41 )</DIV> <DIV>attributetype ( 2.5.4.27 NAME 'destinationIndicator'<BR> DESC 'RF= C2256: destination indicator'<BR> EQUALITY caseIgnoreMatch<BR> SU= BSTR caseIgnoreSubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.4= 4{128} )</DIV> <DIV>attributetype ( 2.5.4.28 NAME 'preferredDeliveryMethod'<BR> DESC = 'RFC2256: preferred delivery method'<BR> SYNTAX 1.3.6.1.4.1.1466.115.1= 21.1.14<BR> SINGLE-VALUE )</DIV> <DIV>attributetype ( 2.5.4.29 NAME 'presentationAddress'<BR> DESC 'RFC= 2256: presentation address'<BR> EQUALITY presentationAddressMatch<BR>&= nbsp;SYNTAX 1.3.6.1.4.1.1466.115.121.1.43<BR> SINGLE-VALUE )</DIV> <DIV>attributetype ( 2.5.4.30 NAME 'supportedApplicationContext'<BR> D= ESC 'RFC2256: supported application context'<BR> EQUALITY objectIdenti= fierMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )</DIV> <DIV>attributetype ( 2.5.4.31 NAME 'member'<BR> DESC 'RFC2256: member = of a group'<BR> SUP distinguishedName )</DIV> <DIV>attributetype ( 2.5.4.32 NAME 'owner'<BR> DESC 'RFC2256: owner (o= f the object)'<BR> SUP distinguishedName )</DIV> <DIV>attributetype ( 2.5.4.33 NAME 'roleOccupant'<BR> DESC 'RFC2256: o= ccupant of role'<BR> SUP distinguishedName )</DIV> <DIV># system schema<BR>#attributetype ( 2.5.4.34 NAME 'seeAlso'<BR># = DESC 'RFC2256: DN of related object'<BR># SUP distinguishedName )</DIV= > <DIV># system schema<BR>#attributetype ( 2.5.4.35 NAME 'userPassword'<BR>#&= nbsp;DESC 'RFC2256/2307: password of user'<BR># EQUALITY octetStringMa= tch<BR># SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )</DIV> <DIV># Must be transferred using ;binary<BR># with certificateExactMatch ru= le (per X.509)<BR>attributetype ( 2.5.4.36 NAME 'userCertificate'<BR> = DESC 'RFC2256: X.509 user certificate, use ;binary'<BR> EQUALITY certi= ficateExactMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )</DIV> <DIV># Must be transferred using ;binary<BR># with certificateExactMatch ru= le (per X.509)<BR>attributetype ( 2.5.4.37 NAME 'cACertificate'<BR> DE= SC 'RFC2256: X.509 CA certificate, use ;binary'<BR> EQUALITY certifica= teExactMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )</DIV> <DIV># Must be transferred using ;binary<BR>attributetype ( 2.5.4.38 NAME '= authorityRevocationList'<BR> DESC 'RFC2256: X.509 authority revocation= list, use ;binary'<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )</DIV> <DIV># Must be transferred using ;binary<BR>attributetype ( 2.5.4.39 NAME '= certificateRevocationList'<BR> DESC 'RFC2256: X.509 certificate revoca= tion list, use ;binary'<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )</DIV= > <DIV># Must be stored and requested in the binary form<BR>attributetype ( 2= .5.4.40 NAME 'crossCertificatePair'<BR> DESC 'RFC2256: X.509 cross cer= tificate pair, use ;binary'<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 )= </DIV> <DIV># system schema<BR>#attributetype ( 2.5.4.41 NAME 'name'<BR># EQU= ALITY caseIgnoreMatch<BR># SUBSTR caseIgnoreSubstringsMatch<BR># = SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )</DIV> <DIV>attributetype ( 2.5.4.42 NAME ( 'givenName' 'gn' )<BR> DESC 'RFC2= 256: first name(s) for which the entity is known by'<BR> SUP name )</D= IV> <DIV>attributetype ( 2.5.4.43 NAME 'initials'<BR> DESC 'RFC2256: initi= als of some or all of names, but not the surname(s).'<BR> SUP name )</= DIV> <DIV>attributetype ( 2.5.4.44 NAME 'generationQualifier'<BR> DESC 'RFC= 2256: name qualifier indicating a generation'<BR> SUP name )</DIV> <DIV>attributetype ( 2.5.4.45 NAME 'x500UniqueIdentifier'<BR> DESC 'RF= C2256: X.500 unique identifier'<BR> EQUALITY bitStringMatch<BR> S= YNTAX 1.3.6.1.4.1.1466.115.121.1.6 )</DIV> <DIV>attributetype ( 2.5.4.46 NAME 'dnQualifier'<BR> DESC 'RFC2256: DN= qualifier'<BR> EQUALITY caseIgnoreMatch<BR> ORDERING caseIgnoreO= rderingMatch<BR> SUBSTR caseIgnoreSubstringsMatch<BR> SYNTAX 1.3.= 6.1.4.1.1466.115.121.1.44 )</DIV> <DIV>attributetype ( 2.5.4.47 NAME 'enhancedSearchGuide'<BR> DESC 'RFC= 2256: enhanced search guide'<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 = )</DIV> <DIV>attributetype ( 2.5.4.48 NAME 'protocolInformation'<BR> DESC 'RFC= 2256: protocol information'<BR> EQUALITY protocolInformationMatch<BR>&= nbsp;SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 )</DIV> <DIV># system schema<BR>#attributetype ( 2.5.4.49 NAME 'distinguishedName'<= BR># EQUALITY distinguishedNameMatch<BR># SYNTAX 1.3.6.1.4.1.1466= .115.121.1.12 )</DIV> <DIV>attributetype ( 2.5.4.50 NAME 'uniqueMember'<BR> DESC 'RFC2256: u= nique member of a group'<BR> EQUALITY uniqueMemberMatch<BR> SYNTA= X 1.3.6.1.4.1.1466.115.121.1.34 )</DIV> <DIV>attributetype ( 2.5.4.51 NAME 'houseIdentifier'<BR> DESC 'RFC2256= : house identifier'<BR> EQUALITY caseIgnoreMatch<BR> SUBSTR caseI= gnoreSubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )= </DIV> <DIV># Must be transferred using ;binary<BR>attributetype ( 2.5.4.52 NAME '= supportedAlgorithms'<BR> DESC 'RFC2256: supported algorithms'<BR>&nbsp= ;SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 )</DIV> <DIV># Must be transferred using ;binary<BR>attributetype ( 2.5.4.53 NAME '= deltaRevocationList'<BR> DESC 'RFC2256: delta revocation list; use ;bi= nary'<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )</DIV> <DIV>attributetype ( 2.5.4.54 NAME 'dmdName'<BR> DESC 'RFC2256: name o= f DMD'<BR> SUP name )</DIV> <DIV>attributetype ( 2.5.4.65 NAME 'pseudonym'<BR> DESC 'X.520(4th): p= seudonym for the object'<BR> SUP name )</DIV> <DIV># Standard object classes from RFC2256</DIV> <DIV># system schema<BR>#objectclass ( 2.5.6.0 NAME 'top'<BR># DESC 'R= FC2256: top of the superclass chain'<BR># ABSTRACT<BR># MUST obje= ctClass )</DIV> <DIV># system schema<BR>#objectclass ( 2.5.6.1 NAME 'alias'<BR># DESC = 'RFC2256: an alias'<BR># SUP top STRUCTURAL<BR># MUST aliasedObje= ctName )</DIV> <DIV>objectclass ( 2.5.6.2 NAME 'country'<BR> DESC 'RFC2256: a country= '<BR> SUP top STRUCTURAL<BR> MUST c<BR> MAY ( searchGuide $ = description ) )</DIV> <DIV>objectclass ( 2.5.6.3 NAME 'locality'<BR> DESC 'RFC2256: a locali= ty'<BR> SUP top STRUCTURAL<BR> MAY ( street $ seeAlso $ searchGui= de $ st $ l $ description ) )</DIV> <DIV>objectclass ( 2.5.6.4 NAME 'organization'<BR> DESC 'RFC2256: an o= rganization'<BR> SUP top STRUCTURAL<BR> MUST o<BR> MAY ( use= rPassword $ searchGuide $ seeAlso $ businessCategory $<BR>  x121A= ddress $ registeredAddress $ destinationIndicator $<BR>  preferre= dDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $<BR>  = telephoneNumber $ internationaliSDNNumber $ <BR>  facsimileTeleph= oneNumber $ street $ postOfficeBox $ postalCode $<BR>  postalAddr= ess $ physicalDeliveryOfficeName $ st $ l $ description ) )</DIV> <DIV>objectclass ( 2.5.6.5 NAME 'organizationalUnit'<BR> DESC 'RFC2256= : an organizational unit'<BR> SUP top STRUCTURAL<BR> MUST ou<BR>&= nbsp;MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $<BR>&nb= sp; x121Address $ registeredAddress $ destinationIndicator $<BR> =  preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $<B= R>  telephoneNumber $ internationaliSDNNumber $<BR>  fa= csimileTelephoneNumber $ street $ postOfficeBox $ postalCode $<BR> &nb= sp;postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) )</D= IV> <DIV>objectclass ( 2.5.6.6 NAME 'person'<BR> DESC 'RFC2256: a person'<= BR> SUP top STRUCTURAL<BR> MUST ( sn $ cn )<BR> MAY ( userPa= ssword $ telephoneNumber $ seeAlso $ description ) )</DIV> <DIV>objectclass ( 2.5.6.7 NAME 'organizationalPerson'<BR> DESC 'RFC22= 56: an organizational person'<BR> SUP person STRUCTURAL<BR> MAY (= title $ x121Address $ registeredAddress $ destinationIndicator $<BR> =  preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $<B= R>  telephoneNumber $ internationaliSDNNumber $ <BR>  f= acsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $<BR> &n= bsp;postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) )</DIV> <DIV>objectclass ( 2.5.6.8 NAME 'organizationalRole'<BR> DESC 'RFC2256= : an organizational role'<BR> SUP top STRUCTURAL<BR> MUST cn<BR>&= nbsp;MAY ( x121Address $ registeredAddress $ destinationIndicator $<BR>&nbs= p; preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $= <BR>  telephoneNumber $ internationaliSDNNumber $ facsimileTeleph= oneNumber $<BR>  seeAlso $ roleOccupant $ preferredDeliveryMethod= $ street $<BR>  postOfficeBox $ postalCode $ postalAddress $<BR>=   physicalDeliveryOfficeName $ ou $ st $ l $ description ) )</DIV= > <DIV>objectclass ( 2.5.6.9 NAME 'groupOfNames'<BR> DESC 'RFC2256: a gr= oup of names (DNs)'<BR> SUP top STRUCTURAL<BR> MUST ( member $ cn= )<BR> MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description= ) )</DIV> <DIV>objectclass ( 2.5.6.10 NAME 'residentialPerson'<BR> DESC 'RFC2256= : an residential person'<BR> SUP person STRUCTURAL<BR> MUST l<BR>=  MAY ( businessCategory $ x121Address $ registeredAddress $<BR> &= nbsp;destinationIndicator $ preferredDeliveryMethod $ telexNumber $<BR>&nbs= p; teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumb= er $<BR>  facsimileTelephoneNumber $ preferredDeliveryMethod $ st= reet $<BR>  postOfficeBox $ postalCode $ postalAddress $<BR>&nbsp= ; physicalDeliveryOfficeName $ st $ l ) )</DIV> <DIV>objectclass ( 2.5.6.11 NAME 'applicationProcess'<BR> DESC 'RFC225= 6: an application process'<BR> SUP top STRUCTURAL<BR> MUST cn<BR>=  MAY ( seeAlso $ ou $ l $ description ) )</DIV> <DIV>objectclass ( 2.5.6.12 NAME 'applicationEntity'<BR> DESC 'RFC2256= : an application entity'<BR> SUP top STRUCTURAL<BR> MUST ( presen= tationAddress $ cn )<BR> MAY ( supportedApplicationContext $ seeAlso $= ou $ o $ l $<BR> description ) )</DIV> <DIV>objectclass ( 2.5.6.13 NAME 'dSA'<BR> DESC 'RFC2256: a directory = system agent (a server)'<BR> SUP applicationEntity STRUCTURAL<BR>&nbsp= ;MAY knowledgeInformation )</DIV> <DIV>objectclass ( 2.5.6.14 NAME 'device'<BR> DESC 'RFC2256: a device'= <BR> SUP top STRUCTURAL<BR> MUST cn<BR> MAY ( serialNumber $= seeAlso $ owner $ ou $ o $ l $ description ) )</DIV> <DIV>objectclass ( 2.5.6.15 NAME 'strongAuthenticationUser'<BR> DESC '= RFC2256: a strong authentication user'<BR> SUP top AUXILIARY<BR> = MUST userCertificate )</DIV> <DIV>objectclass ( 2.5.6.16 NAME 'certificationAuthority'<BR> DESC 'RF= C2256: a certificate authority'<BR> SUP top AUXILIARY<BR> MUST ( = authorityRevocationList $ certificateRevocationList $<BR>  cACert= ificate ) MAY crossCertificatePair )</DIV> <DIV>objectclass ( 2.5.6.17 NAME 'groupOfUniqueNames'<BR> DESC 'RFC225= 6: a group of unique names (DN and Unique Identifier)'<BR> SUP top STR= UCTURAL<BR> MUST ( uniqueMember $ cn )<BR> MAY ( businessCategory= $ seeAlso $ owner $ ou $ o $ description ) )</DIV> <DIV>objectclass ( 2.5.6.18 NAME 'userSecurityInformation'<BR> DESC 'R= FC2256: a user security information'<BR> SUP top AUXILIARY<BR> MA= Y ( supportedAlgorithms ) )</DIV> <DIV>objectclass ( 2.5.6.16.2 NAME 'certificationAuthority-V2'<BR> SUP= certificationAuthority<BR> AUXILIARY MAY ( deltaRevocationList ) )</D= IV> <DIV>objectclass ( 2.5.6.19 NAME 'cRLDistributionPoint'<BR> SUP top ST= RUCTURAL<BR> MUST ( cn )<BR> MAY ( certificateRevocationList $ au= thorityRevocationList $<BR>  deltaRevocationList ) )</DIV> <DIV>objectclass ( 2.5.6.20 NAME 'dmd'<BR> SUP top STRUCTURAL<BR>&nbsp= ;MUST ( dmdName )<BR> MAY ( userPassword $ searchGuide $ seeAlso $ bus= inessCategory $<BR>  x121Address $ registeredAddress $ destinatio= nIndicator $<BR>  preferredDeliveryMethod $ telexNumber $ teletex= TerminalIdentifier $<BR>  telephoneNumber $ internationaliSDNNumb= er $ facsimileTelephoneNumber $<BR>  street $ postOfficeBox $ pos= talCode $ postalAddress $<BR>  physicalDeliveryOfficeName $ st $ = l $ description ) )</DIV> <DIV>#<BR># Object Classes from RFC 2587<BR>#<BR>objectclass ( 2.5.6.21 NAM= E 'pkiUser'<BR> DESC 'RFC2587: a PKI user'<BR> SUP top AUXILIARY<= BR> MAY userCertificate )</DIV> <DIV>objectclass ( 2.5.6.22 NAME 'pkiCA'<BR> DESC 'RFC2587: PKI certif= icate authority'<BR> SUP top AUXILIARY<BR> MAY ( authorityRevocat= ionList $ certificateRevocationList $<BR>  cACertificate $ crossC= ertificatePair ) )</DIV> <DIV>objectclass ( 2.5.6.23 NAME 'deltaCRL'<BR> DESC 'RFC2587: PKI use= r'<BR> SUP top AUXILIARY<BR> MAY deltaRevocationList )</DIV> <DIV>#<BR># Standard Track URI label schema from RFC 2079<BR># system schem= a<BR>#attributetype ( 1.3.6.1.4.1.250.1.57 NAME 'labeledURI'<BR># DESC= 'RFC2079: Uniform Resource Identifier with optional label'<BR># EQUAL= ITY caseExactMatch<BR># SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )</DIV> <DIV>objectclass ( 1.3.6.1.4.1.250.3.15 NAME 'labeledURIObject'<BR> DE= SC 'RFC2079: object that contains the URI attribute type'<BR> SUP top = AUXILIARY<BR> MAY ( labeledURI ) )</DIV> <DIV>#<BR># Derived from RFC 1274, but with new "short names"<BR>#<BR>#attr= ibutetype ( 0.9.2342.19200300.100.1.1<BR># NAME ( 'uid' 'userid' )<BR>= # DESC 'RFC1274: user identifier'<BR># EQUALITY caseIgnoreMatch<B= R># SUBSTR caseIgnoreSubstringsMatch<BR># SYNTAX 1.3.6.1.4.1.1466= .115.121.1.15{256} )</DIV> <DIV>attributetype ( 0.9.2342.19200300.100.1.3<BR> NAME ( 'mail' 'rfc8= 22Mailbox' )<BR> DESC 'RFC1274: RFC822 Mailbox'<BR>    = EQUALITY caseIgnoreIA5Match<BR>    SUBSTR caseIgnoreIA5Subst= ringsMatch<BR>    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} = )</DIV> <DIV>objectclass ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject'<B= R> DESC 'RFC1274: simple security object'<BR> SUP top AUXILIARY<B= R> MUST userPassword )</DIV> <DIV># RFC 1274 + RFC 2247<BR>attributetype ( 0.9.2342.19200300.100.1.25<BR= > NAME ( 'dc' 'domainComponent' )<BR> DESC 'RFC1274/2247: domain = component'<BR> EQUALITY caseIgnoreIA5Match<BR> SUBSTR caseIgnoreI= A5SubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALU= E )</DIV> <DIV># RFC 2247<BR>objectclass ( 1.3.6.1.4.1.1466.344 NAME 'dcObject'<BR>&n= bsp;DESC 'RFC2247: domain component object'<BR> SUP top AUXILIARY MUST= dc )</DIV> <DIV># RFC 2377<BR>objectclass ( 1.3.6.1.1.3.1 NAME 'uidObject'<BR> DE= SC 'RFC2377: uid object'<BR> SUP top AUXILIARY MUST uid )</DIV> <DIV># RFC 4524<BR>#   The 'associatedDomain' attribute specifies= DNS [RFC1034][RFC2181]<BR>#   host names [RFC1123] that are asso= ciated with an object.   That is,<BR>#   values of this= attribute should conform to the following ABNF:<BR>#<BR>#  &nbsp= ; domain =3D root / label *( DOT label )<BR>#    root &= nbsp; =3D SPACE<BR>#    label  =3D LETDIG [ *61( LETDIG= / HYPHEN ) LETDIG ]<BR>#    LETDIG =3D %x30-39 / %x41-5A / = %x61-7A ; "0" - "9" / "A"-"Z" / "a"-"z"<BR>#    SPACE  = =3D %x20           &= nbsp;            ; s= pace (" ")<BR>#    HYPHEN =3D %x2D    &n= bsp;           &nbsp= ;       ; hyphen ("-")<BR>#   = DOT    =3D %x2E       &n= bsp;           &nbsp= ;    ; period (".")<BR>attributetype ( 0.9.2342.19200300.100= .1.37<BR> NAME 'associatedDomain'<BR> DESC 'RFC1274: domain assoc= iated with object'<BR> EQUALITY caseIgnoreIA5Match<BR> SUBSTR cas= eIgnoreIA5SubstringsMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )</= DIV> <DIV># RFC 2459 -- deprecated in favor of 'mail' (in cosine.schema)<BR>attr= ibutetype ( 1.2.840.113549.1.9.1<BR> NAME ( 'email' 'emailAddress' 'pk= cs9email' )<BR> DESC 'RFC3280: legacy attribute for email addresses in= DNs'<BR> EQUALITY caseIgnoreIA5Match<BR> SUBSTR caseIgnoreIA5Sub= stringsMatch<BR> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{128} )</DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV><br><br>=20 <hr> <font style=3D"font-size:12px;line-height:15px;">=C3=C0=C0=FB=C9=BD=BF=AA= =C5=CC3000=C8=CB=C7=C0=B9=BA=A3=A1440=CC=D7=CA=DB=F3=C0=A3=AC</font><a styl= e=3D"font-size:12px;line-height:15px; color:blue; text-decoration:underline= ;" href=3D"http://popme.163.com/netease/mail/003865footer.html">=BC=D3=CD= =C6300=CC=D717=BA=C5=BF=AA=CA=BC=B5=C7=BC=C7=A3=A1</a> ------=_Part_162959_15053760.1201154655304--

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs