openldap-technical July 2016

openldap-technical@openldap.org

33 participants
36 discussions

OpenLDAP : ASN1 code compiled with ASNC1 compiler from Objective Systems
by Sreekanth Sukumaran 18 Jul '16

18 Jul '16

Hi All, Does OpenLDAP uses ASN1 code compiled with the ASNC1 compiler from Objective Systems? Thanks in advance. . -- Regards, Sreekanth

1 0

OpenLDAP ldapsearch issue
by Shashi Ranjan 18 Jul '16

18 Jul '16

Hi, I have a problem in OpenLDAP 2.4.11 with BDB backend. I search an LDIF entry using ldapsearch command. It is giving me correct result and fetching the entry as given below. ldapsearch -x -D cn=Manager,dc=my-domain,dc=COM -w secret -b ou=TEST,ou=people,dc=my-domain,dc=COM -s sub '(&(objectClass=organizationalUnit)(ou=test*))' -H ldap://localhost:1399 # extended LDIF # # LDAPv3 # base <ou=TEST,ou=people,dc=my-domain,dc=COM> with scope subtree # filter: (objectclass=organizationalUnit) # requesting: ALL # # TEST, people, my-domain.COM dn: ou=TEST,ou=people,dc=my-domain,dc=COM ou: TEST companyName: test objectClass: top objectClass: organizationalUnit # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 But when I am searching the same request from ldapbrowser it is giving me error code 32 - No Such object. Below is the short dump of slapd debugging logs: ############################################################################################ SRCH "ou=people,dc=my-domain,dc=COM" 1 0 20000 3600 0 begin get_filter AND begin get_filter_list begin get_filter EQUALITY ber_scanf fmt ({mm}) ber: ber_dump: buf=0x8f59820 ptr=0x8f59856 end=0x8f59903 len=173 0000: a3 21 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 04 .!..objectClass. 0010: 12 6f 72 67 61 6e 69 7a 61 74 69 6f 6e 61 6c 55 .organizationalU 0020: 6e 69 74 a4 0c 04 02 6f 75 30 06 80 04 54 4f 55 nit....ou0...TES 0030: 53 30 7a 04 02 6f 75 04 0b 63 6f 6d 70 61 6e 79 T0z..ou..company 0040: 4e 61 6d 65 04 08 63 6f 64 65 44 49 53 45 04 11 Name..codeDISE.. 0050: 66 72 65 65 4c 61 62 65 6c 61 64 64 49 6e 66 6f freeLabeladdInfo 0060: 31 04 11 66 72 65 65 4c 61 62 65 6c 61 64 64 49 1..freeLabeladdI 0070: 6e 66 6f 32 04 11 66 72 65 65 4c 61 62 65 6c 61 nfo2..freeLabela 0080: 64 64 49 6e 66 6f 33 04 11 66 72 65 65 4c 61 62 ddInfo3..freeLab 0090: 65 6c 61 64 64 49 6e 66 6f 34 04 11 66 72 65 65 eladdInfo4..free 00a0: 4c 61 62 65 6c 61 64 64 49 6e 66 6f 35 LabeladdInfo5 end get_filter 0 begin get_filter SUBSTRINGS begin get_ssa ber_scanf fmt ({m) ber: ber_dump: buf=0x8f59820 ptr=0x8f59879 end=0x8f59903 len=138 0000: 00 0c 04 02 6f 75 30 06 80 04 54 4f 55 53 30 7a ....ou0...test0z 0010: 04 02 6f 75 04 0b 63 6f 6d 70 61 6e 79 4e 61 6d ..ou..companyNam 0020: 65 04 08 63 6f 64 65 44 49 53 45 04 11 66 72 65 e..codeDISE..fre 0030: 65 4c 61 62 65 6c 61 64 64 49 6e 66 6f 31 04 11 eLabeladdInfo1.. 0040: 66 72 65 65 4c 61 62 65 6c 61 64 64 49 6e 66 6f freeLabeladdInfo 0050: 32 04 11 66 72 65 65 4c 61 62 65 6c 61 64 64 49 2..freeLabeladdI 0060: 6e 66 6f 33 04 11 66 72 65 65 4c 61 62 65 6c 61 nfo3..freeLabela 0070: 64 64 49 6e 66 6f 34 04 11 66 72 65 65 4c 61 62 ddInfo4..freeLab 0080: 65 6c 61 64 64 49 6e 66 6f 35 eladdInfo5 ber_scanf fmt (m) ber: ber_dump: buf=0x8f59820 ptr=0x8f59881 end=0x8f59903 len=130 0000: 80 04 54 4f 55 53 30 7a 04 02 6f 75 04 0b 63 6f ..test0z..ou..co 0010: 6d 70 61 6e 79 4e 61 6d 65 04 08 63 6f 64 65 44 mpanyName..codeD 0020: 49 53 45 04 11 66 72 65 65 4c 61 62 65 6c 61 64 ISE..freeLabelad 0030: 64 49 6e 66 6f 31 04 11 66 72 65 65 4c 61 62 65 dInfo1..freeLabe 0040: 6c 61 64 64 49 6e 66 6f 32 04 11 66 72 65 65 4c laddInfo2..freeL 0050: 61 62 65 6c 61 64 64 49 6e 66 6f 33 04 11 66 72 abeladdInfo3..fr 0060: 65 65 4c 61 62 65 6c 61 64 64 49 6e 66 6f 34 04 eeLabeladdInfo4. 0070: 11 66 72 65 65 4c 61 62 65 6c 61 64 64 49 6e 66 .freeLabeladdInf 0080: 6f 35 o5 INITIAL end get_ssa end get_filter 0 end get_filter_list end get_filter 0 filter: (&(objectClass=organizationalUnit)(ou=test*)) ber_scanf fmt ({M}}) ber: ber_dump: buf=0x8f59820 ptr=0x8f59887 end=0x8f59903 len=124 0000: 00 7a 04 02 6f 75 04 0b 63 6f 6d 70 61 6e 79 4e .z..ou..companyN 0010: 61 6d 65 04 08 63 6f 64 65 44 49 53 45 04 11 66 ame..codeDISE..f 0020: 72 65 65 4c 61 62 65 6c 61 64 64 49 6e 66 6f 31 reeLabeladdInfo1 0030: 04 11 66 72 65 65 4c 61 62 65 6c 61 64 64 49 6e ..freeLabeladdIn 0040: 66 6f 32 04 11 66 72 65 65 4c 61 62 65 6c 61 64 fo2..freeLabelad 0050: 64 49 6e 66 6f 33 04 11 66 72 65 65 4c 61 62 65 dInfo3..freeLabe 0060: 6c 61 64 64 49 6e 66 6f 34 04 11 66 72 65 65 4c laddInfo4..freeL 0070: 61 62 65 6c 61 64 64 49 6e 66 6f 35 abeladdInfo5 attrs: ou companyName codeDISE freeLabeladdInfo1 freeLabeladdInfo2 freeLabeladdInfo3 freeLabeladdInfo4 freeLabeladdInfo5 conn=1 op=1 SRCH base="ou=people,dc=my-domain,dc=COM" scope=1 deref=0 filter="(&(objectClass=organizationalUnit)(ou=test*))" conn=1 op=1 SRCH attr=ou companyName codeDISE freeLabeladdInfo1 freeLabeladdInfo2 freeLabeladdInfo3 freeLabeladdInfo4 freeLabeladdInfo5 => bdb_search bdb_dn2entry("ou=people,dc=my-domain,dc=com") => access_allowed: disclose access to "dc=my-domain,dc=COM" "entry" requested <= root access granted => access_allowed: disclose access granted by manage(=mwrscxd) send_ldap_result: conn=1 op=1 p=3 send_ldap_result: err=10 matched="dc=my-domain,dc=COM" text="" send_ldap_response: msgid=4803 tag=101 err=32 ber_flush2: 31 bytes to sd 13 0000: 30 1d 02 02 12 c3 65 17 0a 01 20 04 10 64 63 3d 0.....e... ..dc= 0010: 4f 52 41 4e 47 45 2c 64 63 3d 43 4f 4d 04 00 my-domain,dc=COM.. ldap_write: want=31, written=31 0000: 30 1d 02 02 12 c3 65 17 0a 01 20 04 10 64 63 3d 0.....e... ..dc= 0010: 4f 52 41 4e 47 45 2c 64 63 3d 43 4f 4d 04 00 my-domain,dc=COM.. conn=1 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text= daemon: activity on 1 descriptor daemon: activity on: 13r daemon: read active on 13 ############################################################################################ Can you please tell me what is the problem in these two? Thanks Shashi Ranjan "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

3 3

RE: Antw: replication issue with MDB in ldapadd
by Gurjot Kaur 17 Jul '16

17 Jul '16

Yes, I agree with you. My basic question is that how come the same scenario is supported in the older version but not in latest OpenLDAP 2.4.44 with MDB backend. During this scenario, contextCSNs of both the MM1 and MM2 get updated correctly on MDB (OpenLDAP 2.4.44) and BDB (OpenLDAP 2.4.11) See below the contextCSN values of MM1 and MM2. ######################### MM1 on BDB (OpenLDAP 2.4.11) ######################### contextCSN: 20160718052917.405929Z#000000#000#000000 contextCSN: 20160718053109.639168Z#000000#001#000000 contextCSN: 20160718053249.495430Z#000000#002#000000 ######################### MM2 on BDB (OpenLDAP 2.4.11) ######################### contextCSN: 20160718052917.405929Z#000000#000#000000 contextCSN: 20160718053249.495430Z#000000#002#000000 contextCSN: 20160718053109.639168Z#000000#001#000000 ######################### MM1 on MDB (OpenLDAP 2.4.44) ######################### contextCSN: 20160717234101.093387Z#000000#000#000000 contextCSN: 20160717234320.498152Z#000000#001#000000 contextCSN: 20160717234453.544103Z#000000#002#000000 ######################### MM2 on MDB (OpenLDAP 2.4.44) ######################### contextCSN: 20160717234101.093387Z#000000#000#000000 contextCSN: 20160717234320.498152Z#000000#001#000000 contextCSN: 20160717234453.544103Z#000000#002#000000 >From the contextCSNs values on both backends I got that MM1 and MM2 are in sync. When I did slapcat on BDB, I found that LDIF entries with entryCSN equals to three contextCSN with i.e. server id #000, #001 and #002 are present in the LDIF files (attached files 'slapcatExportMM1_BDB.ldif' and 'slapcatExportMM2_BDB.ldif'). When I did slapcat on MDB, I found that LDIF entries with entryCSN equals to contextCSN with i.e. server id #000 and #002 are present in the LDIF file (exported file) but LDIF with entryCSN equals to contextCSN with server id #001 is not present in LDIF files (attached files 'slapcatExportMM1_MDB.ldif' and 'slapcatExportMM2_MDB.ldif'). Is it possible that contextCSN value is updated in the MDB but LDIF entry is not present in the DB corresponding to the same contextCSN? Thanks Gurjot Kaur -----Original Message----- From: Ulrich Windl [mailto:Ulrich.Windl@rz.uni-regensburg.de] Sent: Friday, July 15, 2016 4:56 PM To: Gurjot Kaur <gurjot.kaur(a)aricent.com>; openldap-technical(a)openldap.org Subject: Antw: replication issue with MDB in ldapadd >>> Gurjot Kaur <gurjot.kaur(a)aricent.com> schrieb am 15.07.2016 um 11:39 >>> in Nachricht <KL1PR04MB1205CDDF22D4A812AA099785E1330(a)KL1PR04MB1205.apcprd04.prod.outlook.com> > Hello, > > I have encountered with a problem in OpenLDAP2.4.44 with MDB backend. > I have two LDAP servers in Multi Master Mode MM1 and MM2. I am doing > the following steps: > 1. Both the LDAP DBs MM1 and MM2 have existing LDIF entries. > 2.Start MM1. Stop MM2. > 3. Add an entry A to MM1 using ldapadd. Stop MM1. > 4. Start MM2. Add LDIF entry B to MM2 using ldapadd. > 5. Start MM1. > > I am getting the below result. > The last added entry i.e. B in MM2 gets replicated to MM1. But LDIF > entry A doesn't get replicated to MM2. > But this scenario works fine in OpenLDAP 2.4.11 with BDB backend. It > replicates entry A to MM2 and entry B to MM1 correctly. > > How the above scenario with MBD in 2.4.44 can be avoided? As this is > very common scenario. It is a very common scenario that both LDAP servers are down at the same time? It is very common that one server is down? I think replication basically works like this: If a consumer gets an update from a provider, it is assumed to be up to date regarding that provider. I'm not sure whether your situation can be resolved. Ulrich > > Thanks > Gurjot Kaur > > "DISCLAIMER: This message is proprietary to Aricent and is intended > solely for the use of the individual to whom it is addressed. It may > contain privileged or confidential information and should not be > circulated or used for any purpose other than for what it is intended. > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, you are > notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. > Aricent accepts no responsibility for loss or damage arising from the > use of the information transmitted by this email including damage from virus." "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

1 0

sssd.conf bug using parameter ldap_uri
by Kaveh Ehsani 15 Jul '16

15 Jul '16

I have filed this bug report with centos as I believe sssd has a bug with regard to ldap_uri as it does not change value affter initial starting of sssd, another words when I change the ldap_uri to another server and restart sssd it maintains the original value. Wonder if anyone else has the same encountered the same problem. Within sssd.conf on the client side of a ldapserver I have set : ldap_uri = simple-provider.example.com ldap_backup_uri = clone-provider.example.com It works fine, but when I take down the simple-provider.example.com (all are virtual boxes), it fails to change over to the back up or secondary which is clone-provider.example.com. I clean the cahce sss_cache -E, I delete all the files under /var/lib/sss/db, and I even change the ldap_uri = clone-provider.example.com and restart sssd I still have : [838cb2] <group/member="root"> ldap_start_tls_s() failed (uri=ldaps://simple-provider.example.com): Can't contact LDAP server: Transport endpoint It is still looking at the old server simple-provider and not clone-provider. It seems once set, it can not be reconfigured. Steps To Reproduce On a virtual box, inside /etc/sssd/sssd.conf ldap_uri = simple-provider.example.com ldap_backup_uri = clone-provider.example.com initially, and start sssd, then either swith them or simply put ldap_uri = clone-provider.example.com and restart sssd, the uri = .... does not change. Additional Information authconfig --ldapserver=simple-provider.example,clone-provider.example.com has the same issue, but if you switch the two servers it will accept the first one. sssd does not seem to do so. This is the link for authconfig bug report on redhat: https://bugzilla.redhat.com/show_bug.cgi?id=1142830 [^<https://bugzilla.redhat.com/show_bug.cgi?id=1142830>]

1 0

replication issue with MDB in ldapadd
by Gurjot Kaur 15 Jul '16

15 Jul '16

Hello, I have encountered with a problem in OpenLDAP2.4.44 with MDB backend. I have two LDAP servers in Multi Master Mode MM1 and MM2. I am doing the following steps: 1. Both the LDAP DBs MM1 and MM2 have existing LDIF entries. 2.Start MM1. Stop MM2. 3. Add an entry A to MM1 using ldapadd. Stop MM1. 4. Start MM2. Add LDIF entry B to MM2 using ldapadd. 5. Start MM1. I am getting the below result. The last added entry i.e. B in MM2 gets replicated to MM1. But LDIF entry A doesn't get replicated to MM2. But this scenario works fine in OpenLDAP 2.4.11 with BDB backend. It replicates entry A to MM2 and entry B to MM1 correctly. How the above scenario with MBD in 2.4.44 can be avoided? As this is very common scenario. Thanks Gurjot Kaur "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

1 0

ContextCSN doesn't get updated correctly
by Gurjot Kaur 14 Jul '16

14 Jul '16

Hi, I have a doubt in the difference of contextCSN of two OpenLDAP servers where one is installed with BDB backend (version 2.4.11) and the other one is installed with MDB backend (version 2.4.44). An LDIF entry "dn: ou=grp_71,ou=people,dc=my-domain,dc=com" was already existing in both the DBs. The following two LDIF entries were added again using slapadd with -w option enabled. dn: ou=grp_71,ou=people,dc=my-domain,dc=com [ Old entry ] dn: ou=alpha,ou=people,dc=my-domain,dc=com [ New entry ] In BDB backend LDAP server, contextCSN gets updated with the latest added entryCSN ( i.e. entryCSN of "dn: ou=alpha,ou=people,dc=my-domain,dc=com"). But in MDB backend LDAP server, contextCSN doesn't get updated with the latest added entryCSN. Rather it still has the old entryCSN value ( i.e. entryCSN of "dn: ou=grp_71,ou=people,dc=my-domain,dc=com") Please let me know, why is it so? Is this correct? Below is the short dump of slapcat from both the servers. ################################################### BDB backend (version 2.4.11) ################################################### dn: dc=my-domain,dc=com dc: my-domain objectClass: dcObject objectClass: organization o: my-domain structuralObjectClass: organization entryUUID: 3a896474-dba7-1035-95f9-abdba6d92f92 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20160711113452Z entryCSN: 20160711113452.876767Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20160711113452Z contextCSN: 20160711113900.374218Z#000000#000#000000 dn: cn=Manager,dc=my-domain,dc=com objectClass: organizationalRole cn: Manager structuralObjectClass: organizationalRole entryUUID: 3a8ae100-dba7-1035-95fa-abdba6d92f92 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20160711113452Z entryCSN: 20160711113452.886601Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20160711113452Z dn: ou=people,dc=my-domain,dc=com ou: people objectClass: organizationalUnit objectClass: top companyName: aricent structuralObjectClass: organizationalUnit entryUUID: 3a8b836c-dba7-1035-95fb-abdba6d92f92 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20160711113452Z entryCSN: 20160711113452.890761Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20160711113452Z dn: ou=grp_71,ou=people,dc=my-domain,dc=com ou: grp_71 objectClass: organizationalUnit companyName: aricent4 structuralObjectClass: organizationalUnit entryUUID: 9231b848-dba7-1035-9211-3f7458963df7 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20160711113719Z entryCSN: 20160711113719.941790Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20160711113719Z dn: ou=alpha,ou=people,dc=my-domain,dc=com ou: alpha objectClass: organizationalUnit companyName: aricent2 structuralObjectClass: organizationalUnit entryUUID: ce0e7de2-dba7-1035-86a6-852dc551e076 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20160711113900Z entryCSN: 20160711113900.374218Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20160711113900Z ################################################### MDB backend (version 2.4.44) ################################################### dn: dc=my-domain,dc=com dc: my-domain objectClass: dcObject objectClass: organization o: my-domain structuralObjectClass: organization entryUUID: 95197aa4-db76-1035-8cd9-9f963a69ea08 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20160711054639Z entryCSN: 20160711054639.476247Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20160711054639Z contextCSN: 20160711054904.666167Z#000000#000#000000 dn: cn=Manager,dc=my-domain,dc=com objectClass: organizationalRole cn: Manager structuralObjectClass: organizationalRole entryUUID: 951bbbde-db76-1035-8cda-9f963a69ea08 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20160711054639Z entryCSN: 20160711054639.491130Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20160711054639Z dn: ou=people,dc=my-domain,dc=com ou: people objectClass: organizationalUnit objectClass: top companyName: aricent structuralObjectClass: organizationalUnit entryUUID: 951d7f64-db76-1035-8cdb-9f963a69ea08 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20160711054639Z entryCSN: 20160711054639.502690Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20160711054639Z dn: ou=grp_71,ou=people,dc=my-domain,dc=com ou: grp_71 objectClass: organizationalUnit companyName: aricent4 structuralObjectClass: organizationalUnit entryUUID: eba3afca-db76-1035-9667-b5e8d6738a99 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20160711054904Z entryCSN: 20160711054904.666167Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20160711054904Z dn: ou=alpha,ou=people,dc=my-domain,dc=com ou: alpha objectClass: organizationalUnit companyName: aricent2 structuralObjectClass: organizationalUnit entryUUID: 27ed19c6-db77-1035-82e2-f54af7597a9e creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20160711055045Z entryCSN: 20160711055045.810589Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20160711055045Z Please let me know, why is it so? Is this correct? Best Regards, Gurjot Kaur "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

2 2

AttributeType not found but I have this attribute
by Jose Legido 13 Jul '16

13 Jul '16

Hello. I'm trying to modify schema (importing from AD) but i have a problem whith some objectclasses: ldap_initialize( ldapi:///??base ) add olcobjectClasses: ( 1.2.840.113556.1.5.263 NAME 'msImaging-PostScanProcess' SUP top STRUCTURAL MUST ( displayName $ msImaging-PSPIdentifier ) MAY (serverName $ msImaging-PSPString ) ) modifying entry "cn={1}core,cn=schema,cn=config" modify complete But when I do a test: 57850fb8 olcObjectClasses: value #447 olcObjectClasses: AttributeType not found: "displayName" 57850fb8 config error processing cn={1}core,cn=schema,cn=config: olcObjectClasses: AttributeType not found: "displayName" slaptest: bad configuration file! But I have this attribute: ldapsearch -LLL -H ldap://127.0.0.1 -x -s base -b "CN=Subschema" attributetypes -v attributeTypes: ( 2.16.840.1.113730.3.1.241 NAME 'displayName' DESC 'RFC2798: preferred name to be used when displaying entries' EQUALITY caseIgnoreMatch S UBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-V ALUE ) I have openldap 2.4.40 with mode config and inetorgperson.ldif in cn=schema Thank you!

2 2

Do you have any recommendations of utilities for manipulating rfc2307 attributes?
by John Lewis 12 Jul '16

12 Jul '16

I would like to manipulate the attributes described in in rfc2307 https://www.ietf.org/rfc/rfc2307.txt. Do you have any recommendations of utilities that do that?

4 3

ContextCSN showing Junk Characters
by scn_73＠yahoo.com 08 Jul '16

08 Jul '16

Hi, My ldapmaster ContextCSN showing Junk Characters. Please advice how can reset to valid one. contextCSN:: 0CKRuTQrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= CentOS 5.8Openldap Version is OpenLDAP: slapd 2.3.43 - Sachin

3 4

How does a client changes from provider to consumer when provider is down
by Kaveh Ehsani 07 Jul '16

07 Jul '16

I have setup a provider/replicator(consumer) with a client and all functioning well. Except when I switch off the provider, the client does not read from the consumer. Of course I have not told the client to do so any where, not sure where to do this. I can set it up manually but there has to be a way for a switch to take place automatically. Thanks, for all the feedbacks.

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical July 2016