openldap-technical

openldap-technical@openldap.org

5 participants
9899 discussions

openldap back-sql mysql wait_timeout
by Simon Ryf 20 Jul '16

20 Jul '16

Dear members, I have timeout issues with back-sql using mysql as backend (read-only). I could successfully setup open-ldap with back-sql querying from a mysql db. However there is a wait_timeout in mysql and if no query is being made for > then wait_timeout the slapd breaks and I have to restart it to connect to mysql again. http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html As a workaround I could implement a cron-job to execute a query every x hour (depending on wait_timeout). However I would much more like that back-sql is able to (auto-)reconnect. I'm not a developer and have no idea how this can be done - maybe this is in the sql-wrap.c code? executing an ldap query after "wait_timeout" returns slapd.log: Jul 20 17:22:53 STAG-BCC slapd[2054]: ==>backsql_get_db_conn() Jul 20 17:22:53 STAG-BCC slapd[2054]: <==backsql_get_db_conn() Jul 20 17:22:53 STAG-BCC slapd[2054]: ==>backsql_attrlist_add(): adding "objectClass" to list Jul 20 17:22:53 STAG-BCC slapd[2054]: ==>backsql_dn2id("dc=bbn,dc=ch") matched expected Jul 20 17:22:53 STAG-BCC slapd[2054]: backsql_dn2id("dc=bbn,dc=ch"): id_query "SELECT id,keyval,oc_map_id,dn FROM ldap_entries WHERE dn=?" Jul 20 17:22:53 STAG-BCC slapd[2054]: backsql_dn2id("dc=bbn,dc=ch"): error executing query ("SELECT id,keyval,oc_map_id,dn FROM ldap_entries WHERE dn=?", "dc=bbn,dc=ch"): Jul 20 17:22:53 STAG-BCC slapd[2054]: Return code: -1 Jul 20 17:22:53 STAG-BCC slapd[2054]: nativeErrCode=2006 SQLengineState=08S01 msg="[MySQL][ODBC 5.1 Driver][mysqld-5.5.49-0+deb8u1]MySQL server has gone away" Jul 20 17:22:53 STAG-BCC slapd[2054]: <==backsql_dn2id("dc=bbn,dc=ch"): err=80 Any suggestions are most welcome Br Simon I'm using the following setup: ----------------------------- Debian Jessie x86_64 (up to date) Openldap-2.4.44 compiled from source with ./configure --enable-sql libmyodbc 5.1.10-3 mysql 5.5.49-9 odbc.ini: [ldapds] Driver = MySQL Description = BCC MySQL DB SERVER = 127.0.0.1 PORT = 3306 USER = ldap Password = ldap Database = prov_ldap SOCKET = /var/lib/mysql/mysql.sock odbcinst.ini: [MySQL] Description = ODBC for MySQL Driver = /usr/lib/x86_64-linux-gnu/odbc/libmyodbc.so Setup = /usr/lib/x86_64-linux-gnu/odbc/libodbcmyS.so FileUsage = 1 slapd.conf: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/SIP.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args loglevel any database sql suffix "dc=bbn,dc=ch" rootdn "dc=bbn,dc=ch" rootpw ldap dbname ldapds dbuser ldap dbpasswd ldap subtree_cond "ldap_entries.dn LIKE CONCAT('%',?)" insentry_stmt "INSERT INTO ldap_entries (dn,oc_map_id,parent,keyval) VALUES (?,?,?,?)" has_ldapinfo_dn_ru no #cachesize 0

1 0

is there a bug with SSSD
by Kaveh Ehsani 18 Jul '16

18 Jul '16

I have tried using SSSD to switch between ldap provider and consumer. I have: ldap_uri = provider.example.com ldap_backup_uri = consumer.example.com It works fine, until I stop the provider to see if the clients will look at the consumer. They don't. I set ldap_uri = consume.example.com and clear the cache both via sss_cache -E and deleting all the files in /var/lib/sss/db and restart sssd. Even though it starts fine, I have ldap_uri = provider.example.com inside the journalctl -xe file and complains that can not contact the ldapserver., which is intentionally switched off. Looks like ldap_uri is hard coded some where the first time it is set. I have opened a bug report, but no replies to it at the moment. This is the link for the bug report in case anyone is interested. https://bugs.centos.org/view.php?id=11174

3 2

using mdb backend on centos 7
by Kaveh Ehsani 18 Jul '16

18 Jul '16

I am trying to load the module for openldap mdb backend which is suppose to be located in /usr/lib64/openldap but it is not there. I am trying this ldif; dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulepath: /usr/lib64/openldap olcModuleload: back_mdb ldapadd -Y EXTERNAL -H ldap:/// -f mod-mdb.ldif Of course there re no back_bdb or back_hdb, do I not need to load the module first !? I am using centos 7, Thank you.

2 1

Re: OpenLDAP : ASN1 code compiled with ASNC1 compiler from Objective Systems
by Howard Chu 18 Jul '16

18 Jul '16

Sreekanth Sukumaran wrote: > Hi All, > > Does OpenLDAP uses ASN1 code compiled with the ASNC1 compiler from Objective > Systems? No. OpenLDAP uses its own liblber. In supporting component-based matching, we used the SNACC ASN.1 compiler but most of that code has been unused for several years now. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

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 18 Jul '16

18 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical