openldap-technical

openldap-technical@openldap.org

5 participants
9991 discussions

AW: StartTLS is not working
by Hauke Coltzau 07 Oct '08

07 Oct '08

Hi Dat, first of all: Please send your questions to the list so that other users with the same problem can find the solution, too. To your problem: Please make sure that you have a correct value for your ServerCA's private key in your openssl.cnf. It should read something like this: [ ServerCA ] # Where is the base directory for the ServerCA dir = /usr/lib/ssl/ServerCA # Where is the ServerCA's certificate certificate = $dir/ServerCA.cert.pem # and where is the ServerCA's private key private_key = $dir/private/ServerCA.key.pem Without the private key, the ServerCA will not be able to sign your LDAP certificate. You will find more configuration hints for openssl.cnf in the tutorial. Hope this helps, Hauke -- ----- Ursprüngliche Mail ----- Von: "Dat Duong" <datduong2000(a)yahoo.com> An: "hauke coltzau" <hauke.coltzau(a)FernUni-Hagen.de> Gesendet: Dienstag, 7. Oktober 2008 09:06:07 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien Betreff: StartTLS is not working Hi Hauke, I read your instruction on how to create Root CA ...I have a hard time understanding the step. I have a question on how to sign the ldap server certificated using Server CA? I get an error message: bash-3.00# openssl ca -name ServerCA -in afldap01.req.pem -out afldap01.cert.pem Using configuration from /usr/local/ssl/openssl.cnf variable lookup failed for ServerCA::private_key 18908:error:0E06D06C:configuration file routines:NCONF_get_string:no value:conf_lib.c:329:group=ServerCA name=private_key Thanks Dat -- ------------------------------------ Fernuniversität in Hagen Lehrgebiet Kommunikationsnetze http://www.fernuni-hagen.de/kn Fon/Fax: +49 2331 987 -1142 / -353 ------------------------------------

1 0

Problem with usage of suffixmassage and meta database
by Padgett,Phil 06 Oct '08

06 Oct '08

I am attempting to use "database meta" to direct queries to either one of two backend databases. The queries come in in the form "cn=user1,dc=alpha,dc=ufl,dc=edu" or "cn=user2,dc=beta,dc=ufl,dc=edu". I have multible local databases alpha, beta, and prod. There are some accounts which have info in those databases and others which should be redirected to a campus active directory server. If I send in the requests as "cn=user1,dc=ufl,dc=edu", etc then both the local databases and the remote active directory one can service them. This works well. I would like to call them with the alpha, beta, or prod in the dn so that the appropriate local database is consulted but if there is no match then the active directory server is queried. I seem to be having problems with the suffixmassage directive since this does not seem to be working. Any help would be appreciated. Below is the relevent section of my slapd.conf file. Thanks. Phil database meta suffix "dc=ufl,dc=edu" uri "ldap://localhost:390/dc=alpha,dc=ufl,dc=edu" uri "ldap://localhost:390/dc=beta,dc=ufl,dc=edu" uri ldap://localhost:390/dc=prod,dc=ufl,dc=edu uri "ldap://ldap.ad.ufl.edu/dc=alpha,dc=ufl,dc=edu" acl-authcDN "cn=SVC-LDAP,OU=Service Accounts,OU=Departments,OU=UF,DC=ad,DC=ufl,DC=edu" acl-passwd 'ssssssssss' rewriteEngine on suffixmassage "dc=alpha,dc=ufl,dc=edu" "dc=ad,dc=ufl,dc=edu" lastmod off

1 0

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical