openldap-technical October 2008

openldap-technical@openldap.org

59 participants
63 discussions

question regarding ACLs
by Kick, Claus 07 Oct '08

07 Oct '08

Hello all, Since there is some time, I figured I rectify our openldap configuration and use proper ACLs. We are using the following version on Solaris 10: [xxxx:/opt/csw/libexec]$ ./slapd -V @(#) $OpenLDAP: slapd 2.3.39 (Feb 22 2008 18:51:52) $ asmoore@ra Our user subtree is organized as shown below: o=suffix ou=people,o=suffix uid=kdz,ou=people,o=suffix uid=hyc,ou=people,o=suffix ou=removed_accounts,ou=people,o=suffix uid=abcd,ou=removed_accounts,ou=people,o=suffix uid=efgh,ou=removed_accounts,ou=people,o=suffix Basically, I want a getent passwd not to list entries below ou=removed_accounts,ou=people,o=suffix, for a client application still considers the removed accounts as users (it probably searches the whole subtree). I read the documentation for 2.3: http://www.openldap.org/doc/admin23/slapdconfig.html#Access%20Control <http://www.openldap.org/doc/admin23/slapdconfig.html> And found this: The scope can be either base, one, subtree, or children. Where base matches only the entry with provided DN, one matches the entries whose parent is the provided DN, subtree matches all entries in the subtree whose root is the provided DN, and children matches all entries under the DN (but not the entry named by the DN). So, I figured that an ACL (no global ACLs any longer) like this access to dn.one="ou=People,o=suffix" by * write Should hide the removed accounts and only show the active ones. But it does not, it still contains all the children of ou=removed_accounts,ou=people,o=suffix And of ou=people,o=suffix Using dn.base="ou=People,o=suffix" by * write Works as expected and getent passwd not return any ldap users, solely the /etc/passwd users. The client system in question is a Solaris 10 machine, I have kept the client configuration unchanged for the tests so far: NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_SERVERS= 127.0.0.1 NS_LDAP_SEARCH_BASEDN= o=suffix NS_LDAP_SEARCH_TIME= 90 NS_LDAP_CACHETTL= 0 There are only two other ACLs in place: 1. access to dn.one="ou=Group,o=siemensmedical.com" by * write This one works fine, getent group returns all the groups it should return and the changes can be done as well. 2. access to dn.subtree="ou=Roles,o=siemensmedical.com" by * write This one works fine as well, it returns the role structure as requested and changes work as well. Where am I making a mistake? Best regards, Claus

2 3

openLDAP TLS APIs usage issue
by dhiraj.prasad＠tcs.com 07 Oct '08

07 Oct '08

Hello, I have configured LDAP server on linux with TLS support and was able to fetch data from it using the ldapsearch utility. However, when i tried to do this searching via code i got following errors: Error at Server Side: slap_listener_activate(10): >>> slap_listener(ldaps://) connection_get(15): got connid=47 connection_read(15): checking for input on id=47 TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write certificate request A TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(15): got connid=47 connection_read(15): checking for input on id=47 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(15): TLS accept failure error=-1 id=47, closing connection_closing: readying conn=47 sd=15 for close connection_close: conn=47 sd=15 Error at Client side: [root@localhost LDAP1]# ./ldapSearch ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost.localdomain:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 127.0.0.1:636 ldap_connect_timeout: fd: 3 tm: -1 async: 0 TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 19, subject: /C=IN/ST=MH/O=TCS/OU=EIS/CN=localhost.localdomain/emailAddress=dhiraj.prasad(a)tcs.com, issuer: /C=IN/ST=MH/O=TCS/OU=EIS/CN=localhost.localdomain/emailAddress=dhiraj.prasad(a)tcs.com TLS certificate verification: Error, self signed certificate in certificate chain TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect. ldap_err2string Error in ldap_start_tls_s -1:Can't contact LDAP serverTest..1 ldap_bind_s ldap_simple_bind_s ldap_sasl_bind_s ldap_sasl_bind ldap_send_initial_request ldap_send_server_request Test..2: -1 ldap_err2string Failure of LDAP bind -1-Can't contact LDAP server [root@localhost LDAP1]# Snippet of client code for TLS support used by Me: ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, &version ); ldap_set_option(ld, LDAP_OPT_X_TLS_CACERTFILE, "/root/cacert.pem"); ldap_set_option(ld, LDAP_OPT_X_TLS_CERTFILE, "/usr/local/etc/openldap/ldap.client.pem"); ldap_set_option(ld, LDAP_OPT_X_TLS_KEYFILE, "/usr/local/etc/openldap/ldap.client.key.pem"); ldap_set_option(ld, LDAP_OPT_REFERRALS , LDAP_OPT_ON); val = LDAP_OPT_X_TLS_ALLOW; ldap_set_option (ld, LDAP_OPT_X_TLS, &val); status = ldap_start_tls_s(ld, NULL, NULL); Please let me know as to what is missing in my code that is triggering the above errors. Also if there are any sample TLS client code, please let me know where can i get it. Thanks, Dhiraj Kumar Prasad Tata Consultancy Services Mailto: dhiraj.prasad(a)tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Outsourcing ____________________________________________ =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you

1 0

loglevel and logfile
by Ashraf Mohamed 07 Oct '08

07 Oct '08

hi, I am trying to turn on debugging for slapd and direct the debug output to a specific file on OpenLDAP 2.4.11 on linux without using syslog. I tried using slapd.conf; configured logfile and loglevel. And the only way I could get it working is by passing in the -d option to slapd. It does not seem to use the loglevel/logfile values if I don't pass in the -d option. I also tried using slapd.d. I am able to set olcLogLevel but I can't set olcLogFile. It won't even let me add it to the config. Ideas? Thanks much. Ashraf

2 1

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical October 2008