question regarding ACLs
by Kick, Claus
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
15 years, 1 month
openLDAP TLS APIs usage issue
by dhiraj.prasad＠tcs.com
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
15 years, 1 month
loglevel and logfile
by Ashraf Mohamed
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
15 years, 1 month
AW: StartTLS is not working
by Hauke Coltzau
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
------------------------------------
15 years, 1 month
Problem with usage of suffixmassage and meta database
by Padgett,Phil
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
15 years, 1 month
Re: Incorrect snippet in delta-syncrepl example in admin guide?
by Brad T Waldorf
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
15 years, 2 months
Re: Incorrect snippet in delta-syncrepl example in admin guide?
by Pierangelo Masarati
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
-----------------------------------
15 years, 2 months
rfc4523
by Gavin Henry
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.
15 years, 2 months
Using ACIs in our opensource project
by Faraz Khan
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
15 years, 2 months
Incorrect snippet in delta-syncrepl example in admin guide?
by Brad T Waldorf
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
15 years, 2 months
