AW: Re: AW: openldap and TLS certificates
by Hauke Coltzau
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
>
>
15 years, 2 months
Questions about OpenLDAP for account authentication
by Phill Edwards
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
15 years, 2 months
OpenLDAP 2.4.10 Import Errors
by Lydon, Mark
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.
15 years, 2 months
Re: Shared Addressbook using LDAP
by Tarak Ranjan
--- 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/
15 years, 2 months
autogroup error
by nooroon
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!
15 years, 2 months
samba: Active Directory support requires ldap_initialize
by Wayne Rasmussen
Having a problem with openldap-2.4.11 for use with Samba-3.2.4 and am
looking for help fixing the issue.
system info:
uname -m = sun4u
uname -r = 5.9
uname -s = SunOS
uname -v = Generic_118558-25
#building openldap
CC=gcc
#echo $CC
#exit
CPPFLAGS="-I/usr/local/include -I/usr/local/ssl/include
-I/usr/local/BerkeleyDB.4.2/include -I/usr/local/include/sasl"
LDFLAGS="-L/usr/local/lib -L/usr/local/ssl/lib
-L/usr/local/BerkeleyDB.4.2/lib"
export CC CPPFLAGS LDFLAGS
#
CFLAGS='-D_AVL_H'
export CFLAGS
#
./configure --enable-bdb
make depend
make install
#end building openldap
#build samba
make clean
./configure --with-ldap --with-acl-support --with-ads --with-pam
--with-winbind --with-krb5=/usr/local
#####make
#####make install
#end build samba
The configure script fails with the following:
checking for LDAP support... yes
checking ldap.h usability... yes
checking ldap.h presence... yes
checking for ldap.h... yes
checking lber.h usability... yes
checking lber.h presence... yes
checking for lber.h... yes
checking for ber_tag_t... yes
checking for ber_scanf in -llber... yes
checking for ber_sockbuf_add_io... yes
checking for LDAP_OPT_SOCKBUF... yes
checking for LBER_OPT_LOG_PRINT_FN... yes
checking for ldap_init in -lldap... yes
checking for ldap_set_rebind_proc... yes
checking whether ldap_set_rebind_proc takes 3 arguments... 3
checking for ldap_initialize... no
checking whether LDAP support is used... yes
checking for Active Directory and krb5 support... yes
checking for ldap_initialize... (cached) no
configure: error: Active Directory support requires ldap_initialize
15 years, 2 months
Conditionals in LDAP
by Tom Cooper
Hi all,
I am fairly new to OpenLDAP and I was requested to set up the following:
We have ADSL users to authenticate on freeradius which reads the user
info via an OpenLDAP server. Now when the user has used a certain amount
of data he must be flagged as blocked. His connection is disconnected
and upon reconnection he is assigned a different IP address with
restricted connectivity untile he tops up his account. I can see that
his information needs to be changed in LDAP to maybe assign him to a
different uid, something like this:
uid=xxxxxx,dc=radius,dc=example,dc=com (Original)
changed to
uid=xxxxxx,dc=blocked,dc=radius,dc=example,dc=com.
My question is now how do I accomplish this, because on the client side
he will still try to authenticate as
uid=xxxxxx,dc=radius,dc=example,dc=com and I can not control what
credentials are sent?
Is it maybe better accomplished from freeradius than from LDAP? The
record needs to be changed in LDAP for our admin portal to make use of
this to check the client's status.
Regards,
To read FirstRand Bank's Disclaimer for this email click on the following address or copy into your Internet browser:
https://www.fnb.co.za/disclaimer.html
If you are unable to access the Disclaimer, send a blank e-mail to
firstrandbankdisclaimer(a)fnb.co.za and we will send you a copy of the Disclaimer.
15 years, 2 months
OpenLDAP back-sql ldap_add error:53
by Arun NAIR
Hey Guys,
When I try to add the base ldif file i get the error mentioned below.
Please help me out with this. its really urgent.
Regards,
Arun Nair
*This is my base domain ldif file:*
dn: dc=abc,dc=corp
ou: rootobject
description: LDAP Admin
objectClass: top
objectClass: dcObject
objectClass: organizationalUnit
dc: abc
description: ABC Corp
dn: ou=People,dc=abc,dc=corp
ou: People
description: users of abc corp
objectClass: organizationalUnit
*Complete debug log of ldapadd:*
[root@centserver mysql]# ldapadd -x -D "cn=root,dc=abc,dc=corp" -W -f
/tmp/abc.corp.ldif -d 1
ldap_create
Enter LDAP Password:
ldap_bind
ldap_simple_bind
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP centserver.abc.corp:389
ldap_new_socket: 4
ldap_prepare_socket: 4
ldap_connect_to_host: Trying 127.0.0.1:389
ldap_connect_timeout: fd: 4 tm: -1 async: 0
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({i) ber:
ber_flush: 46 bytes to sd 4
ldap_result ld 0x99156e8 msgid 1
ldap_chkResponseList ld 0x99156e8 msgid 1 all 1
ldap_chkResponseList returns ld 0x99156e8 NULL
wait4msg ld 0x99156e8 msgid 1 (infinite timeout)
wait4msg continue ld 0x99156e8 msgid 1 all 1
** ld 0x99156e8 Connections:
* host: centserver.abc.corp port: 389 (default)
refcnt: 2 status: Connected
last used: Thu Oct 2 20:34:46 2008
** ld 0x99156e8 Outstanding Requests:
* msgid 1, origid 1, status InProgress
outstanding referrals 0, parent count 0
** ld 0x99156e8 Response Queue:
Empty
ldap_chkResponseList ld 0x99156e8 msgid 1 all 1
ldap_chkResponseList returns ld 0x99156e8 NULL
ldap_int_select
read1msg: ld 0x99156e8 msgid 1 all 1
ber_get_next
ber_get_next: tag 0x30 len 12 contents:
read1msg: ld 0x99156e8 msgid 1 message type bind
ber_scanf fmt ({eaa) ber:
read1msg: ld 0x99156e8 0 new referrals
read1msg: mark request completed, ld 0x99156e8 msgid 1
request done: ld 0x99156e8 msgid 1
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_free_connection 0 1
ldap_free_connection: refcnt 1
ldap_parse_result
ber_scanf fmt ({iaa) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
adding new entry "dc=abc,dc=corp"
ldap_add_ext
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush: 151 bytes to sd 4
ldap_result ld 0x99156e8 msgid 2
ldap_chkResponseList ld 0x99156e8 msgid 2 all 1
ldap_chkResponseList returns ld 0x99156e8 NULL
wait4msg ld 0x99156e8 msgid 2 (timeout 100000 usec)
wait4msg continue ld 0x99156e8 msgid 2 all 1
** ld 0x99156e8 Connections:
* host: centserver.abc.corp port: 389 (default)
refcnt: 2 status: Connected
last used: Thu Oct 2 20:34:46 2008
** ld 0x99156e8 Outstanding Requests:
* msgid 2, origid 2, status InProgress
outstanding referrals 0, parent count 0
** ld 0x99156e8 Response Queue:
Empty
ldap_chkResponseList ld 0x99156e8 msgid 2 all 1
ldap_chkResponseList returns ld 0x99156e8 NULL
ldap_int_select
read1msg: ld 0x99156e8 msgid 2 all 1
ber_get_next
ber_get_next: tag 0x30 len 56 contents:
read1msg: ld 0x99156e8 msgid 2 message type add
ber_scanf fmt ({eaa) ber:
read1msg: ld 0x99156e8 0 new referrals
read1msg: mark request completed, ld 0x99156e8 msgid 2
request done: ld 0x99156e8 msgid 2
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 2, msgid 2)
ldap_free_connection 0 1
ldap_free_connection: refcnt 1
ldap_parse_result
ber_scanf fmt ({iaa) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
ldap_perror
ldap_add: Server is unwilling to perform (53)
additional info: operation not permitted within namingContext
ldap_free_connection 1 1
ldap_send_unbind
ber_flush: 7 bytes to sd 4
ldap_free_connection: actually freed
15 years, 2 months
AW: openldap and TLS certificates
by Hauke Coltzau
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
--
------------------------------------
Fernuniversität in Hagen
Lehrgebiet Kommunikationsnetze
http://www.fernuni-hagen.de/kn
Fon/Fax: +49 2331 987 -1142 / -353
------------------------------------
15 years, 2 months
Re: Shared Addressbook using LDAP
by Tarak Ranjan
--- 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
Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/
15 years, 2 months