openldap-technical

openldap-technical@openldap.org

5 participants
9899 discussions

Re: Incorrect snippet in delta-syncrepl example in admin guide?
by Brad T Waldorf 06 Oct '08

06 Oct '08

My own thoughts, for what they're worth... A "complete working examples" section would be invaluable. The most useful part of the man pages for the command line & admin tools was the example section... it ties everything together. Same for the examples in the admin guide... a complete example to compliment the conceptual words is priceless. Funny you mention it, but i was also disappointed in the N-Way configuration example (17.4.3)... but because it was in the "new" config file format, which i wasn't using. Anyway, I understand you want readers to read thoroughly and try creating their own configuration from scratch... but i've found it's rare that a user will spend the time to "properly" understand something before they actually try making it work. Rather, they try something, research/fix the error, try again, research/fix, etc... whatever it takes to get it working as quick as possible. In my experience, syntax diagrams and working examples are the most important, time-saving (and sanity-saving) pieces of documentation. Having working example configurations that are commented thoroughly ("see section ____ for more info on configuration specifics for this", "modify the following statements with your own specific values", etc.) might be the best solution. Thanks again for all your help

1 0

Re: Incorrect snippet in delta-syncrepl example in admin guide?
by Pierangelo Masarati 06 Oct '08

06 Oct '08

Gavin Henry wrote: > ----- "Pierangelo Masarati" <ando(a)sys-net.it> wrote: > >> Brad T Waldorf wrote: >>> I would >>> definitely recommend replacing "may need to" with "must" in the >> following >>> statement, as you suggested. "This ACL may need to be merged with >> other >>> ACL statements." >> Probably, that whole example should be removed, as it belongs to >> access >> control rather than to replication. > > It's hard to present complete examples that way. I've other external feedback in various forums > whereby users complain that N-Way is hard to understand, but they merely need to read the whole guide. I0'm not speaking in general, but specifically related to that case. access to * by <canreadall> read by * break is: 1) generic, not necessarily specific to replication 2) incomplete, since it needs to integrate with other access rules 3) should be per-database, rather than global, IMHO. So like it's now it creates more trouble than it helps solving. > I'm tempted to move complete working examples to the follow existing empty section: > > http://www.openldap.org/doc/admin24/appendix-deployments.html Sounds good. > This would however promoted copy-and-paste configurations. That's inevitable, I fear, no matter what. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

rfc4523
by Gavin Henry 06 Oct '08

06 Oct '08

Hi All, How can slapd take advantage of rfc4523 for example? test21 only shows search/add/delete to a users entry, so I'm trying to understand the bigger picture from the server and clients point of view. Is it intended to be used just as a data store for 3rd party application to retrieve all the X.509 information? Thanks, Gavin.

2 1

Using ACIs in our opensource project
by Faraz Khan 06 Oct '08

06 Oct '08

Dear All, We are developing a webbased opensource identity management solution which includes a graphical frontend to manage openldap ACLs. Previously we were using Cn=config and 'standard' ACLs to manage our tree but we later moved on to OpenLdap ACIs for in-tree ACLs. Gavin Henry suggested that I take this discussion to the list since ACIs are not being actively maintained and its advisable to move to the 'normal' openldap ACLs. My problem with that model is that management through a graphical interface becomes VERY ugly (parsing and rendering text acls, maintaining priority, managing referential integrity if a dn is deleted, etc). I have found OpenLdapACIs extremely handy to use for my task. We are willing to provide resources/dev time in the future for the support of OpenLDAP ACIs since its crucial to our project. I wanted to know if support/interest is the ONLY problem or are there fundamental flaws in the way ACIs work? Thank you. -- Faraz R Khan Zivios::Open Source Enterprise Management www.zivios.org

1 0

Incorrect snippet in delta-syncrepl example in admin guide?
by Brad T Waldorf 05 Oct '08

05 Oct '08

Hi. I used the Delta-syncrepl configuration example from the admin guide (http://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl) to create configuration files for a basic 1 Master, 1 Slave configuration. With a populated & functional master, i started the slave and hit this error... slap_client_connect: URI=ldap://9.57.13.249:389 DN="cn=user.replicator,ou=people ,dc=exampleb,dc=com" ldap_sasl_bind_s failed (49)+ (The replicator DN couldn't bind.) In fact, i couldn't execute a basic ldapsearch while binding as the replicator DN... kept getting "ldap_bind: Invalid credentials (49)". Long story short, the fix was to comment out the following ACL statements in the master config file ... i could then bind as the replicator DN and delta-syncrepl worked... # Give the replica DN unlimited read access. access to * by dn.base="cn=user.replicator,ou=People,dc=exampleb,dc=com" read by * break I might be missing something... but based on my results, it seems like those ACL statements aren't needed and actually prevented me from delta-syncrepl'ing successfully. Wanted to pass along this info incase i'm actually on to something... so you can fix the documentation if need be. Thanks! Master 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 pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args # Give the replica DN unlimited read access. #access to * # by dn.base="cn=user.replicator,ou=People,dc=exampleb,dc=com" read # by * break # Accesslog database definitions database hdb suffix cn=accesslog directory /usr/local/var/openldap-data/db/accesslog rootdn cn=accesslog index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE # Let the replica DN have limitless searches limits dn.exact="cn=user.replicator,ou=People,dc=exampleb,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited database hdb suffix "dc=exampleb,dc=com" rootdn "cn=kingb,dc=exampleb,dc=com" rootpw pappie directory /usr/local/var/openldap-data index objectclass,entryCSN,entryUUID eq overlay syncprov syncprov-checkpoint 1000 60 # accesslog overlay definitions for primary db overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE # scan the accesslog DB every day, and purge entries older than 7 days logpurge 07+00:00 01+00:00 # Let the replica DN have limitless searches limits dn.exact="cn=user.replicator,ou=People,dc=exampleb,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited Slave 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 pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args database hdb suffix "dc=exampleb,dc=com" rootdn "cn=kingb,dc=exampleb,dc=com" rootpw pappie directory /usr/local/var/openldap-data index entryUUID eq # syncrepl directives syncrepl rid=0 provider=ldap://(my_ip_address):389 bindmethod=simple binddn="cn=user.replicator,ou=People,dc=exampleb,dc=com" credentials=metsrbad searchbase="dc=exampleb,dc=com" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog # Refer updates to the master updateref ldap://(my_ip_address):389

2 3

AW: Re: AW: openldap and TLS certificates
by Hauke Coltzau 03 Oct '08

03 Oct '08

Hi Nick, just to make sure: Your CA certificate is not the same as your ldap server certificate, is it? If so, then there will be the problem. To get a proper server certificate, you will have to do the following steps: 1. Create a root CA (that means, create a self signed certificate) 2. Using your root CA, create a CA for your server certificate generation and, if needed, a user CA for your user certificate generation Now you have two certificates, already. A root CA cert and a server CA cert. Still, those are not your ldap server certificates. 3. With your server CA (NOT the root ca), create a server certificate for ldap. 4. Copy the server CA certificate and the root CA certificate into one file and call it something like serverca.chain.pem. This is NOT your ldap server certificate but the certification authority, your client will trust. 5. The serverca.chain.pem is to be copied to your ldap client and will be used as CACertFile. So if the client receives the ldap server cert, it can check that it came from a trusted CA and therefore can be accpeted. There is a very good tutorial for the CA creation available at http://fra.nksteidl.de/Erinnerungen/OpenSSL.php, but it is in German. I used that tutorial and it worked out perfectly. Hope, it helps, Hauke ----- Ursprüngliche Mail ----- Von: "Nick Kasparidis" <nick.kasparidis(a)toumaz.com> An: "Hauke Coltzau" <hauke.coltzau(a)FernUni-Hagen.de> CC: "openldap-technical" <openldap-technical(a)openldap.org> Gesendet: Donnerstag, 2. Oktober 2008 12:04:43 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien Betreff: Re: AW: openldap and TLS certificates Hello again, I followed your instructions, and I keep getting the same errors. I have also tried to remove the entries before the actual certificate and still no change. There was another suggestion on generating the certificates. I will try that and hope for the best. Thanks for the help Nick On Tue, 2008-09-30 at 02:10 +0200, Hauke Coltzau wrote: > Hi Nick, > > it took me some time to set up TLS successfully, so I'm with > you in this journey ;-) > > >From my own experience, I would suggest to start verfifying > the server first. Let the client simply have the > > TLS_CACERT /<path>/<to>/<cachain>/cacert.chain.pem > TLS_REQCERT demand > > options set and not send any certificate at all. > On the server's side, only set > > TLSCertificateFile /your/cert.pem > TLSCertificateKeyFile /your/private/key.pem > > You will not need a CACert file on the server for now. > > Make sure that the client will not send any certificate, so > check your current users .ldaprc, because the client certificate > depends on the user that runs the ldapsearch command. > > If you can set up TLS this way, you can be sure that the > server is valid. To validate your client, you will need > a .ldaprc in the current user's home directory which points > to the user's cert and key. The server must be able to > verify the user's cert. > > Hope, this helps, > > Hauke > > > ----- Ursprüngliche Mail ----- > Von: "Nick Kasparidis" <nick.kasparidis(a)toumaz.com> > An: openldap-technical(a)openldap.org > Gesendet: Montag, 29. September 2008 17:11:10 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien > Betreff: openldap and TLS certificates > > Hello everyone, > I seem to have a problem with setting up secure connections with my > LDAP server. I believe the problem has mainly to do with my certificates > rather than anything else. I used the tutorial provided by the openLDAP > admin guide to generate my certificates > http://damncoolpics.blogspot.com/2008/09/oktoberfest-2008-in-munich.html > > My slapd.conf files has the following entries > > #SSL/TLS Options > TLSCipherSuite HIGH:MEDIUM > TLSCACertificateFile /usr/local/etc/slapd-cacert.pem > TLSCertificateFile /usr/local/etc/slapd-cert.pem > TLSCertificateKeyFile /usr/local/etc/slapd-key.pem > > and my ldap.conf > TLS_CACERTDIR /etc/openldap/cacerts > TLS_CACERT /etc/openldap/cacerts/slapd-cert.pem > > slapd-cacert.pem is the certificate of the CA > slapd-cert.pem is the server certificate (same copy on client and > server) > slapd-key.pem is the server key (I manually removed the certificate > request that was generated by the process on the link above) > > I start the server using /usr/local/libexec/slapd -h ldap:/// ( also > tried the -d 9 flag for debugging), and when I use ldapsearch I get the > following errors > > (from the client) > ldapsearch -x -ZZ (I have most of the settings in my ldap.conf) > > ldap_start_tls: Connect error (-11) > additional info: error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed > > (from the server with the -d 9 flag) > I get load of stuff, but the important seems to be the following > > TLS trace: SSL3 alert read:fatal:unknown CA > TLS trace: SSL_accept:failed in SSLv3 read client certificate A > TLS: can't accept. > TLS: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca > s3_pkt.c:1053 > connection_read(12): TLS accept failure error=-1 id=0, closing > > When I try a search without the -ZZ flag everything works fine. When I > created the certificates I tried different common names. I tried the ip > address, fully qualified name (as shown below), the short name, even my > name, but no luck. I have read the proper RFC but could not get > anyusefull information. By the way I have a local DNS server and the > domain name should match the correct IP address (and the reverse). > > Truth is I do not know much about SSL and certificates, so I might be > missing something. Just for your information, The certificate authority > is the same with the LDAP server. I will provide the certificate below, > with email and addresses altered. Also the hashes have been altered so > key and cert will not match. I merely provide them just in case you see > something wrong in the syntax. > > The server certificate > > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 1 (0x1) > Signature Algorithm: sha1WithRSAEncryption > Issuer: C=GB, ST=Oxfordshire, O=Company, OU=IT, > CN=ldapserver.eng.mydomain.com/emailAddress=admin@mydomain.com > Validity > Not Before: Sep 29 09:49:07 2008 GMT > Not After : Sep 29 09:49:07 2009 GMT > Subject: C=GB, ST=Oxfordshire, L=Abingdon, O=Company,, OU=IT, > CN=ldapserver.eng.mydomain.com/emailAddress=admin@mydomain.com > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > RSA Public Key: (2048 bit) > Modulus (2048 bit): > 00:c4:4d:49:ce:35:a6:80:67:d5:c5:ea:2e:5a:b0: > 0f:96:a2:de:28:c3:97:fc:5d:9d:05:57:ae:a8:db: > d4:cd:8c:bb:1d:4d:2c:41:51:45:0e:c9:17:8f:a0: > 5b:bb:a0:5e:d3:d7:5d:a4:64:dd:23:9a:64:ad:dc: > 7b:49:5a:92:68:65:32:6c:0c:50:84:8a:75:26:da: > 76:7f:65:13:14:0a:05:eb:5e:d3:f7:1e:89:7f:a2: > d8:1b:4a:46:28:ee:98:5f:f9:bd:21:88:df:76:5c: > b9:8e:7e:5b:09:29:65:e7:6b:a7:5b:5f:4a:99:77: > 7d:6c:d1:44:7e:7a:77:05:fe:1c:b9:6d:2b:e2:57: > 63:63:29:b3:cb:c6:68:35:b5:81:fa:ef:ee:ba:c0: > 54:3e:d8:70:0a:f6:c9:39:74:21:f8:75:b9:08:89: > 6a:5e:e3:fe:1e:5e:37:b0:29:2d:13:35:b4:7c:aa: > 55:3e:c3:c4:59:cd:08:e1:ef:21:43:29:0f:82:8f: > 84:7d:f2:65:b5:79:2e:fc:87:7c:7d:ca:fb:7a:ef: > 54:c4:33:20:ed:f5:8a:64:de:60:18:60:07:ee:f9: > ea:0f:97:bf:af:63:e1:e4:e8:b2:15:1b:5f:95:fd: > ad:c7:83:8c:94:f3:e4:ef:95:63:f0:d4:a8:f8:49: > 13:05 > Exponent: 65537 (0x10001) > X509v3 extensions: > X509v3 Basic Constraints: > CA:FALSE > Netscape Comment: > OpenSSL Generated Certificate > X509v3 Subject Key Identifier: > > 1F:9F:4E:5A:C8:61:53:4B:5F:50:28:84:F8:D7:45:54:C0:C9:7E:67 > X509v3 Authority Key Identifier: > > keyid:7C:5A:92:7E:5C:6B:3E:9B:0E:87:46:7C:FB:27:8F:34:AD:42:3B:27 > > Signature Algorithm: sha1WithRSAEncryption > 04:3d:f9:64:e9:c1:13:8c:98:e6:b6:33:a9:e0:8b:8e:b0:68: > 2f:70:8e:8e:b4:b2:6f:61:7c:bd:63:f2:cb:20:b8:6e:4f:0a: > 53:5f:ba:ed:32:20:c7:31:24:0c:c3:e8:d6:42:1c:a8:3e:7b: > 32:b4:87:94:71:d6:8b:ca:c9:57:f5:9f:fc:8d:89:77:e2:3e: > ac:49:cd:c8:c7:01:83:41:41:a6:05:7c:df:c6:37:0e:15:d8: > d2:51:3f:a5:92:b7:bf:3f:65:4e:68:71:b7:4e:3e:26:f6:15: > fe:38:72:e1:f9:b7:60:29:e8:ff:78:3c:aa:34:be:e8:46:f1: > 5f:87:8b:a1:60:8b:82:31:ca:5e:a1:31:83:e7:b7:90:be:a5: > 2f:ac:f7:1c:fe:af:89:15:02:af:c7:4f:2f:97:87:2b:0b:83: > 5c:07:83:f9:f9:c7:63:00:69:fa:c9:d0:fc:fb:7a:ef:7a:41: > 1c:e0:99:e4:01:73:7f:94:fa:2c:12:0f:8e:3f:8f:b4:9b:b6: > 85:42:90:1a:aa:d6:11:9b:49:db:83:f9:19:1e:dd:8b:0a:c7: > b5:c0:5c:06:78:ca:f1:75:f9:8b:eb:c0:94:b0:3f:96:fc:b8: > 88:7c:52:46:ad:ab:bb:22:52:c1:31:dc:87:a7:c9:bd:de:98: > bd:76:45:2b > -----BEGIN CERTIFICATE----- > MIIESTCCAzGgAwIBAgIBATANBgkqhkiG9w0BAQUFADCBnzELMAkGA1UEBhMCR0Ix > FDASBgNVBAgTC094Zm9yZHNoaXJlMSIwIAYdVQQKExlUb3VtYXogVGVjaG5vbG9n > eSBMaW8pdGVkMQswCQYDVQQLEwJJVDEeMBwGA1UEAxMVbWFnZ2llLmVuZy50b3Vt > YXouY29tMSkwJwYJKoZIhvcNAQkBFhpuaWNrLmthc3BhcmlkaXNAdG91bWF6LmNv > bTAeFw0wODA5MjkwOTQ5MDdaFw0wOTA5MjkwOTQ5MDdaMIGyMQswCQYDVQQGEwJH > QjEUMBIGA1UECBMLT3hmb3Jkc2hpcmUxETAPBgNVBAcTCEFiaW5nZG9uMSIwIAYD > VQQKExlUb3VtYXogVGVjaG5vbG9neSBMaW1pdGVkMQswCQYDVQQLEwJJVDEeMBwG > A1UEAxMVbWFnZ2llLmVuZy50b3VtYXouY29tMSkwJwYJKoZIhvcNAQkBFhpuaWNr > Lmthc3BhcmlkaXNAdG91bWF6LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC > AQoCggEBAMRNSc41poBn1cXqLlqwD5ai3ijDl&xdnQVXrqjb1M2cux1NLEFRRQ7J > F4+gW7ugXtPXXaRk3SOaZK3ce0lakmhlMmwMUISKdSbadn9lExQKBete0/ceiX+i > 2BtKRijumF/5vSGI33ZcuY5+WwkpZedrp1tfSpl3fWzRRH56dwX+3LltK+JXY2Mp > s8vGaDW1gfrv7rrAVD7YcAr2yTl0Ifh1uQiJal7j/h5eN7ApLRM1tHyqVT7DxFnN > COHvIUMpD4KPhH3yZbV5LvgHfH3K+3rvVMQzIO31imTeYBdgB+756g+Xv69j4eTo > shUbX5X9rceCjJTz5O+VY/DUqPhJEwUCAwEAAaN7MHkwCQYDVR0TBAIwADAsBglg > hkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0O > BBYEFB+fXlrIYVNLX1AphPjXRVTAyX9nMB8GA1UdIwQYMBaAFHxakn5cWz6bDodG > fPsnjzSuQjsnMA0GCSqGSIb3DQEBBQUAA4IBAQAEPflk6cETjJjmtjOp4IuOsGgv > cI6OtLNvYXy9Y/LLILhuTwpTX7rtMiDGMCQMw+jWQhyoPnsytIeUcdaLyslX9Z/8 > jYl34j6sSc3IxwGDQUGmBXzPxjcOFdjSUT+lkre/P2VOaHG3Tj4m9hX+OHLh+bdg > Kej/eDyqNL7oRvFfh4uhYIuCMcpeoTGD57eQvQUvrPcc/q+JFQKvx08vl4crC4NM > B4P5+cdjAGn6ydD8+3rvekEc4JnkAXN/lPosEg+OP4+0m7aFQpAaqtYRmknbg/kZ > Ht2LCse1wFwGeMrxdfmL68CUsD+W/LiIfFJGrau7IlLBMdyHp8m93pi9dkUr > -----END CERTIFICATE----- > > > The CA certificate > > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 0 (0x0) > Signature Algorithm: sha1WithRSAEncryption > Issuer: C=GB, ST=Oxfordshire, O=Company, OU=IT, > CN=ldapserver.eng.mydomain.com/emailAddress=admin@mydomain.com > Validity > Not Before: Sep 29 09:48:17 2008 GMT > Not After : Sep 29 09:48:17 2011 GMT > Subject: C=GB, ST=Oxfordshire, O=Company, OU=IT, > CN=ldapserver.eng.mydomain.com/emailAddress=admin@mydomain.com > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > RSA Public Key: (2048 bit) > Modulus (2048 bit): > 00:a6:6e:3b:1f:87:e9:1a:c9:e9:5c:3a:b8:96:19: > af:c9:e7:41:87:72:76:55:a8:fc:db:3c:05:55:9c: > 25:8f:83:5b:35:05:9f:cb:7b:4e:9b:3a:84:98:60: > 46:d5:79:be:c1:4c:b5:ea:cd:79:2b:c2:33:86:05: > 67:98:e4:62:77:d7:cf:98:c3:52:93:6c:ba:1c:fc: > a3:f9:81:26:ea:d8:a1:56:cd:74:f5:47:fe:0f:8d: > 95:7a:b7:8b:14:25:e7:9d:e2:e7:46:a2:d6:90:4c: > 25:94:16:20:51:78:6a:68:da:e0:06:2c:45:4e:27: > c4:2b:8b:bc:a9:e2:fb:c5:c1:8b:9d:33:5f:e3:be: > d1:f5:53:9d:2b:0c:bf:2a:95:e6:57:29:5e:ef:ab: > 3a:e9:33:09:00:c3:7d:94:aa:a9:b4:3c:08:9d:e8: > e6:92:f2:60:03:ed:12:1d:df:81:9f:a7:d2:81:7f: > 3e:8b:fa:a4:01:ba:c1:49:1c:51:02:c6:54:3c:48: > 9a:3f:18:54:04:35:c4:e1:c7:12:f6:7a:26:7e:47: > 04:e6:f8:fc:ed:8c:2e:17:05:62:b6:73:9a:4e:52: > 10:17:92:52:38:3a:4d:2d:32:ab:76:c8:61:ab:36: > cd:52:f9:95:bb:87:63:ad:5d:d3:d0:f9:6f:06:a6: > 29:6f > Exponent: 65537 (0x10001) > X509v3 extensions: > X509v3 Basic Constraints: > CA:FALSE > Netscape Comment: > OpenSSL Generated Certificate > X509v3 Subject Key Identifier: > > 7C:5A:92:7E:5C:5B:3E:9B:0E:87:46:7C:FB:27:8F:34:AE:42:3B:27 > X509v3 Authority Key Identifier: > > keyid:7C:5A:92:7E:5C:5B:3E:9B:0E:87:46:7C:FB:27:8F:34:AE:42:3B:27 > > Signature Algorithm: sha1WithRSAEncryption > 2b:b9:65:09:2d:ff:c0:80:dd:e0:f4:d0:01:9a:87:b9:da:54: > d2:f1:e4:0a:56:0b:cf:31:55:97:9f:93:62:df:59:3d:11:5b: > 06:6c:e7:f9:56:9b:c8:e8:e0:77:54:12:5b:ca:98:f9:c7:fa: > c6:41:45:6d:14:31:2d:d6:19:a8:41:ba:89:55:5a:7f:5c:79: > 1b:05:36:d7:e4:00:7b:e7:ae:5e:56:74:12:f9:fa:ab:63:0f: > f6:8e:97:cc:53:d3:91:7e:4b:48:6e:15:27:bc:73:4a:68:1f: > ff:36:67:b2:fa:6b:38:40:0c:f2:99:5f:75:2a:4f:27:21:a8: > fb:b5:9a:c3:7a:05:a5:45:03:3f:cf:85:21:eb:42:69:23:af: > d5:b8:32:17:4e:a5:52:c2:3e:01:bd:1f:f2:1a:b6:f0:f8:8f: > d9:d0:70:30:08:39:37:42:84:42:67:27:74:16:be:e7:2d:0f: > 54:e8:3d:8b:6f:6c:76:a6:39:d9:df:e4:b9:33:9a:92:5b:3e: > b2:6a:8a:8f:2e:9c:3a:01:54:c7:3e:0e:f4:45:9c:bd:f6:39: > e9:8c:9d:95:60:e7:2a:10:f6:ac:4a:a2:b7:16:bf:06:44:76: > 4b:5d:51:5a:0b:82:b0:53:f6:4a:d7:04:f0:85:7e:34:c6:fc: > 50:1a:c4:b3 > -----BEGIN CERTIFICATE----- > MIIENjCCAx6gAwIBAgIBADANBgkqhkiG9w0BAQUFADCBnzELMAkGA1UEBhMCR0Ix > FDASBgNVBAgTC094Zm9yZHNoaXJlMSIwIAYDVQQKExlUb3VtYXogVGVjaG5vbG9n > eSBMaW1pdGVkMQswCQYDV1QLEwJJVDEeMBwGA1UEAxMVbWFnZ2llLmVuZy50b3Vt > YXouY29tMSkwJwYJKoZIhvcNAQkBFhpuaWNrLmthc3BhcmlkaXNAdG91bWF6LmNv > bTAeFw0wODA5MjkwOTQ4MTdaFw0xMTA5MjkwOTQ4MTdaMIGfMQswCQYDVQQGEwJH > QjEUMBIGA1UECBMLT3hmb3Jkc2hpcmUxIjAgBgNVBAoTGVRvdW1heiBUZWNobm9s > b2d5IExpbWl0ZWQxCzAJBgNVBAsTAklUMR4wHAYDVQQDExVtYWdnaWUuZW5nLnRv > dW1hei5jb20xKTAnBgkqhki39w0BCQEWGm5pY2sua2Fz5GFyaWRpc0B0b3VtYXou > Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApm47H4fpGsnpXDq4 > lhmvyedAh3J2Vaj82zwFVZwlj4NbNQWfy3tOmzqEmGBG1Xm+wUy16s15K8IzhgVn > mORid9fPmMNSk2y6HPyj+YEm6tihVs109Uf+D42VereLFCHnneLnRqLWkEwllBYg > UXhqaNrgBixFTifEK4u8qeL7xUGLnTNf477R9VOdKwy/KpXmVyle76s66TMJAMN9 > lKqptDwInejmkvJgA+0SHd+Bn6fSgX8+i/qkAbrBSRxRAsZUPEia3xhUBDXE4ccS > 9nomfkcE5vj87YwuFwVitnOZTlIQF5JSODpNLTKrdsHhqzbNUvmVu4djrV3T0Plv > BqYpbwIDAQABo3sweTAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NM > IEdlbmVyYXRlZC5DZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUfFqSflxbPpsOh0Z8+yeP > NK5COycwHwYDVR0jBBgwFoAUfFqSflxbPpsOh0Z8+yePNK5COycwDQYJKoZIhvcN > AQEFBQADggEBACu5ZQkt/8CA3eD00AGah7naVNLx5ApWC88xVZefk2LfWT0RWwZs > H/lWm8jo4HdUElvKmPnH+sZBRW0UMS3WGahBuolVWn9ceRsFNtfkAHvnrl5WdBL5 > +qtjD4aOl8xT05F+S0huFSe8c0poH/82Z7L6azhADPKZ73UqTychTPu1msN6BaVF > Az/PhSHrQmkj39W4MhdOpFLCPgG9H/IatvD4j9nQcDAIOTdChEJnJ3QWvuctD1To > PYtvbHamOdnf5LkzmpJbPrJiio8unDoBVMc+DvRFnL32OemMnzVg5yoQ9qxKorcW > vwZEdktdUVoLgrBT9krXBPCFfjTG/FAaxLM= > -----END CERTIFICATE----- > > and finally the server key, which I modified slightly be removing a > certificate request entry > > -----BEGIN RSA PRIVATE KEY----- > MIIEowIBAAKCAQEAxE1JzjWmgGfVxeouWrAPlqLeKMOX/F2dBVeuqNvUzZy7HU0s > QVFFDskXj6B9u6Be09ddpGTdI5pkrdx7SVqSaGUybAxQhIp1Jtp2f2UTFAoF617T > 9x6Jf6LYG0pGKO6YX/m9IYjfdly5jn5bCSll52unW19KmXd9bNFEfnp3Bf7cuW0r > 4ldjYymzy8ZoNbWB+u/uusBUPthwCvbJOXQh+HW5CIlqXuP+Hl43bCktEzW0fKpV > PsPEWc0I4e8hQykPgo+EffJltXku/Id8fcr7eu9UxDMg7fWKZN5gF2AH7vnqD5e/ > r2Ph5OiyFRtflf2tx4KMlPPk75Vj8NSo+EkTBQIDAQABAoIBAFkajAniKHXYrBxu > NCRODoVd4GG4huCyzXeDWXCkeG/sWLLwOMpdTW9ssBktvPXp0aFu/L6GWiqzBkg0 > 8HFXf2WLqduJq3K+NncwauFgy8wo0I8KOETPw7IABQA+MqKZyuilv8fdDTH43PFl > QYVjGTJ2lzzOgFow9unSA7k1dZluTeMyE+RzpVYwE/WSgsOFa7qYQnCXy0hlx85u > /SNU5383/v1cvrSghDCbZ2WrllHAerjUep1FNDounGkhiWj+JWUfddL7zYM+KVdJ > AKRaxeYo+UTAVa9rd9D8qgZo5oIJ6l53bvobkwcrVnAoYPxtzAjhcBhgtQjXSXrJ > YrHhKQECgYEAavUIAaT/XfHDXuXYMHnSf/ZgAqipOv36OPPnXnpg0yZbyLs/dgN6 > GYVBtvd3ugfQ3ZEUfOwYw2wVq6hItq6+lQRjL+G5IsoeyKJXGIpBdlr7Yhhes1gv > 4R5nGB97+F9kBVEmDephg0K++EeKRZMpzUgn1cBvBXrcfJsUc8OAFbUCgYEAy31q > k8HXBltJz7QQxmXLZogFkb0dxxXUrax202e6XsqroUpmUWx1n75TVnnP4QNH0Tqx > 8EQTDMZzQRHgFidwLAzhpI16Ex1fLfSw/lMQij7ojxtGp8LbC057dGpseBxwTPjP > I5dpdIl2Mt8HeH5qMiizRls1EcSu1RK9cPhOWhECgjEAtU+pFSwCoQKDIgU1+EE4 > nuJQEyOpO7qEH5RS5jaLJ/sdn/551TcwSdRgLuj5agea/VEq7ZyZgcC1GFZxLE6X > dejGubzLpBMpDrzBnS7EaRTbQ2YJATtfy7n6juduqSe/03eErOrLtQcoFjjP98zX > //Nd671gxXEyt/lTxrpeK5ECgYBFbIFq7awFkCmLgjxi46HUVj3ILgQ1wt3vbrKP > h4kPBAgwG+jyiJVMratTCnYAp5Td7i988EyrhB0YKxgPlt7vOGnXMSlf0hqB3ERy > UDaJY9MF1+FwJMuEfP8jhZeCFvm9WPmag/LHfoVj6rFqy35BpJ8dNsrRSA/5w837 > 98sLcQKBgBBfNJdPOGjgLZxLM5hXI88UkYFc3ppVh83SHSikKULO5d7wrWeQDR9V > u3t+sx8bl067E2dILPzTa9qLt3RO+GPCwOQMQUywNBh7jQ1BjaOg/4ctlJkjAdKo > x4hAG2dU5Z7iEob5AWpfv3+A5taS8P9RjI1O2jUwnTR84vqJtNx7 > -----END RSA PRIVATE KEY----- > > Any ideas would be welcome > > Best Regards > Nick > >

2 1

Questions about OpenLDAP for account authentication
by Phill Edwards 03 Oct '08

03 Oct '08

I have a linux server which provides a number of services such as samba, firewall, DNS, postfix, spam filtering etc to PCs on a small LAN. The client PCs on the LAN are Windows XP. I find it a pain when someone needs to change a password that you have to do it first on the PC, then make sure it's the same on the corresponding linux account and also for Samba. I thought I might use OpenLDAP so that there's only 1 password to change and was hoping I could use it to manage accounts. I've read a lot of HOWTOs but still have some questions. - Can I use an OpenLDAP frontend (eg JXplorer) and OpenLDAP to create new accounts on a linux machine, specify the group and have it create a new home dir etc (like when you run useradd)? - Does openldap replace the need to have the accounts in /etc/passwd? Once I've copied the existing linux accounts from /etc/passwd, should I delete them from /etc/passwd using userdel so that I don't have the account in two places? - I also want to use OpenLDAP to provide a common address book which will be used mainly by Outlook. I know that Outlook can query the LDAP address book, but can it also update it? It seems that there are lots of apps to query OpenLDAP but updating the entries is a little arcane. Regards, Phill

2 1

OpenLDAP 2.4.10 Import Errors
by Lydon, Mark 03 Oct '08

03 Oct '08

Hello, perhaps someone can help me with this issue, as I am an LDAP novice. I am migrating from an IBM Tivoli LDAP server to OpenLDAP 2.4.10 running under Solaris 10. I have the new service up and running, and am trying to export entries from old to new ldap servers using an LDAP Browser/Editor. There are additional schema entries to be considered, and these have been configured with a line in the slapd.conf file as follows; include /usr/local/etc/openldap/schema/npr.schema And npr.schema contains; objectClass ( 1.3.6.1.4.1.4203.1.4.6 NAME 'openbookmarks' DESC 'NPR GMIS Report Bookmark' MAY displayName AUXILIARY ) objectClass ( 1.3.6.1.4.1.4203.1.4.5 NAME 'vpnbookmarks' DESC 'NPR MDNS Report Bookmark' MAY displayName AUXILIARY ) objectClass ( 1.3.6.1.4.1.4203.1.4.4 NAME 'openscheduledreports' DESC 'NPR GMIS Scheduled Report' MAY displayName AUXILIARY ) objectClass ( 1.3.6.1.4.1.4203.1.4.3 NAME 'vpnscheduledreports' DESC 'NPR MDNS Scheduled Report' MAY displayName AUXILIARY ) objectClass ( 1.3.6.1.4.1.4203.1.4.2 NAME 'usergruas' DESC 'NPR User GRUAs' MAY displayName AUXILIARY ) objectClass ( 1.3.6.1.4.1.4203.1.4.7 NAME 'useraccounts' DESC 'NPR User Accounts' MAY displayName AUXILIARY ) objectClass ( 1.3.6.1.4.1.4203.1.4.0 NAME 'newaccntlist' DESC 'NPR User Account Lists' MAY displayName AUXILIARY ) attributetype ( 1.3.6.1.4.1.4203.1.4.0 NAME ( 'newaccntlist' ) SUP name ) attributetype ( 1.3.6.1.4.1.4203.1.4.7 NAME ( 'useraccounts' ) SUP name ) attributetype ( 1.3.6.1.4.1.4203.1.4.2 NAME ( 'usergruas' ) SUP name ) attributetype ( 1.3.6.1.4.1.4203.1.4.3 NAME ( 'vpnscheduledreports' ) SUP name ) attributetype ( 1.3.6.1.4.1.4203.1.4.4 NAME ( 'openscheduledreports' ) SUP name ) attributetype ( 1.3.6.1.4.1.4203.1.4.5 NAME ( 'vpnbookmarks' ) SUP name ) attributetype ( 1.3.6.1.4.1.4203.1.4.6 NAME ( 'openbookmarks' ) SUP name ) But when I run the import approx 1000 out of the 4000 entries are discarded with errors such as; Root error: [LDAP: error code 21 - vpnscheduledreports: value #0 invalid per syntax] 05:21:23 PM: Failed to synchronize entries Root error: [LDAP: error code 21 - vpnbookmarks: value #0 invalid per syntax] 05:21:24 PM: Failed to synchronize entries Root error: [LDAP: error code 21 - useraccounts: value #0 invalid per syntax] It is obviously complaining about the entries that use the additional scheme attributes, but I have no idea why. Any help is greatly appreciated.

2 4

Re: Shared Addressbook using LDAP
by Tarak Ranjan 03 Oct '08

03 Oct '08

--- Tarak Ranjan <contacttrm(a)yahoo.co.in> wrote: > > --- Tarak Ranjan <contacttrm(a)yahoo.co.in> wrote: > > > > > > > > Message: 3 > > > Date: Wed, 01 Oct 2008 09:49:53 +0200 > > > From: "Dieter Kluenter" <dieter(a)dkluenter.de> > > > Subject: Re: Shared Addressbook using LDAP > > > To: openldap-technical(a)openldap.org > > > Message-ID: <87y718hhzy.fsf(a)magenta.l4b.de> > > > Content-Type: text/plain; charset=iso-8859-1 > > > > > > Tarak Ranjan <contacttrm(a)yahoo.co.in> writes: > > > > > > > Hi List, > > > > I am configuring a shared addressbook for > > > > squirrelmail. > > > > but the problem is it's showing the only > single > > > email > > > > address of the user, using that email id i'm > > login > > > > into the webmail. > > > > > > > > here is my slapd.conf. > > > > > > > > include > /etc/openldap/schema/core.schema > > > > include > > /etc/openldap/schema/cosine.schema > > > > include > > > > /etc/openldap/schema/inetorgperson.schema > > > > allow bind_v2 > > > > pidfile /var/run/openldap/slapd.pid > > > > argsfile /var/run/openldap/slapd.args > > > > loglevel 256 > > > > access to * > > > > by self write > > > > by anonymous auth > > > > by users read > > > > access to > > > > > > > > > > dn.children="ou=addressbook,dc=mail,dc=example,dc=com" > > > > by self write > > > > by anonymous read > > > > by users read > > > [...] > > > > > > I presume that the access rules for > > > dn.children=ou=addressbook.. are > > > not taken by cut and paste from your slapd.conf > > > file, otherwise this > > > rules are not honored, as the rules have to be > > > written in a folded line. > > > With regard to your question, change the rule > > > dn.children=ou=addressbook... to > > > dn.subtree=ou=addressbook.. > > > If you want to protect the base entry > > > ou=addressbook, define something > > > like > > > access to > > > dn.base=ou=addressbook... > > > attrs=entry,children by ... > > > access to dn.children=ou=addressbook... by... > > > > > === message truncated === > > > > Hi List, > > after changing the dn.children=ou=addressbook... > to > > dn.subtree=ou=addressbook.. , i'm getting the same > > result. > > > > Only single address i'm getting, using the ID i'm > > logging in . > > > > /\ > > Tarak > > > > > please submit an example of your searchstring. > > -Dieter > > -- > Dieter Klünter | Systemberatung > http://www.dpunkt.de/buecher/2104.html > GPG Key ID:8EF7B6C6 > 53°08'09,95"N > 10°08'02,42"E > > > Hi List, > > [root@mail ~]# ldapsearch -x -b > 'ou=addressbook,dc=mail,dc=example,dc=com' > '(objectclass=*)' > # extended LDIF > # > # LDAPv3 > # base <ou=addressbook,dc=mail,dc=example,dc=com> > with > scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # addressbook, mail.example.com > dn: ou=addressbook,dc=mail,dc=example,dc=com > ou: addressbook > objectClass: top > objectClass: organizationalUnit > > # Tarak, addressbook, mail.example.com > dn: > cn=Tarak,ou=addressbook,dc=mail,dc=example,dc=com > cn: Tarak > givenName: Tarak Ranjan > sn: Mukherjee > mail: tarak.ranjan(a)example.com > objectClass: top > objectClass: inetOrgPerson > > # Amit, addressbook, mail.example.com > dn: cn=Amit,ou=addressbook,dc=mail,dc=example,dc=com > cn: Amit > givenName: Amit > sn: Sharda > mail: amit(a)example.com > objectClass: top > objectClass: inetOrgPerson > > # Anand, addressbook, mail.example.com > dn: > cn=Anand,ou=addressbook,dc=mail,dc=example,dc=com > cn: Anand > givenName: Anand > sn: Adkoli > mail: anand(a)example.com > objectClass: top > objectClass: inetOrgPerson > > /\ > Tarak > > Hi List, The problem is that , when i'm deleting the particular entry in LDAP, & after that when i logging in Webmail i m getting other addressbook entries. but when i'm creating entry like cn=John,cn=Tarak,ou=addressbook,dc=mail,dc=example,dc=com the entry is coming twice, i have 33 entry & if i make sub entry for those 33 entries , it's horrible it showing 66 times the same entry.. pleas guide where i m wrong Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/

2 1

autogroup error
by nooroon 03 Oct '08

03 Oct '08

hi, i'd like to use the autogroup module found in the contrib tree of the openldap sources. So I took sources from openldap.org and rebuilt openldap 2.4.11. I've also built manually autogroup.so, thanks to its makefile, and copied it with other ldap modules. Then I've followed the quick start user guide from openldap.org, to build the dc=example,dc=com tree. It's working fine with this simple configuration. In order to test the autogroup module, I have followed the README of this module, an dmodified my slapd.conf and my dyngroup.schema. Then my slapd starts correctly, but every request generates an error. Here is the error that can be seen in debug logs : ... ldap_read: want=8 error=Resource temporarily unavailable conn=0 op=1 do_search ... send_ldap_result: err=53 matched="" text="operation not supported within namingContext" seoverlay autogroupnd_ldap_response: msgid=2 tag=101 err=53 ... If i remove "overlay autogroup" and "autogroup-attrset groupOfURLs memberURL member" from slapd.conf, everythings works perfectly!! Does someone can help me to get autogroup work? thanks!

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical