getting DN from client with GSSAPI bind?
by Kenneth Rogers
Hi,
After a successful GSSAPI binding, is there an easy way to get the DN
for that user from the server?
KR
--
"Linux doesn't exist." -- Kieren O'Shaghnessy (Director of SCO Australia)
13 years, 11 months
backend-meta usage
by Stephen Agar
I have an LDAP server with a base "o=company, c=us". There is another
server which controls "ou=people,o=company,c=us", so in slapd.conf i have
the following:
database bdb
suffix "o=company,c=US"
rootdn "cn=Manager,o=company,c=US"
rootpw *******
directory /usr/var/openldap-data
# Indices to maintain
index objectClass eq
index ou,cn,uid eq,pres,sub
#meta test
database meta
suffix "ou=people,o=company,c=US"
uri "ldap://directory.company.com/ou=People,o=company,c=US"
When I try to start slapd, I get: /etc/openldap/slapd.conf: line 84:
<suffix> namingContext "o=company,c=US" already served by a preceding bdb
database serving namingContext "o=company,c=US". Am I misusing meta? Can I
not proxy binds/lookups to specific OUs to a secondary LDAP? I understand
what the message is saying, but don't think I understand the proper use of
meta.
For example, I have an ou=groups that contains "groupofnames" and the
members of those groups are like "uid=123456,ou=people,o=company,c=us". So I
want ou = groups owned on my server, then the when specific members try to
bind, they are proxied to this external LDAP server that serves
ou=people,o=company,c=us and contains their uids and passwords. Am I going
about this the wrong way? Is there a way to accomplish what im trying to do?
Thanks in advance...
--stephen
13 years, 11 months
meta backend config problem
by Julien Oix
hi everyone,
I made a previous post, but noone answered, so I try again :)
I'm trying to deploy a meta directory using the OpenLdap meta backend.
I'm using the slapd Etch Debian package, version 2.3.27-1
when my target server includes the next ACL, eveything is fine, I can
retrieve any data by the meta directory using ldapsearch, it works fine
##
access to attrs=userPassword
by dn="cn=admin,dc=toto,dc=fr" write
by anonymous auth
by self write
by * none
and
access to *
by dn="cn=admin,dc=toto,dc=fr" write
by * read
##
but I want only authentified connections (no anonymous bind, if i'm
right) to have read access, so I change the ACL like that
##
access to attrs=userPassword,shadowLastChange
by dn="cn=admin,dc=toto,dc=fr" write
by anonymous auth
by self write
by * none
and
access to *
by dn="cn=admin,dc=toto,dc=fr" write
by self read
by anonymous auth
by * none
##
So, for this target, i'm adding the acl-authcDN and acl-passwd
directives to the meta directory, with the target's rootdn and rootpw
values, in order to enable ACL checking and matching (in that case, the
write privilege for dn="cn=admin,dc=toto,dc=fr")
giving this in the meta backend conf
##
database meta
suffix "dc=meta-ufr-info-p7,dc=jussieu,dc=fr"
uri "ldap://localhost:389/dc=meta-ufr-info-p7,dc=jussieu,dc=fr"
suffixmassage "dc=meta-ufr-info-p7,dc=jussieu,dc=fr" "dc=toto,dc=fr"
acl-authcDN "cn=admin,dc=toto,dc=fr"
acl-passwd "xxxxx"
##
But at this moment, I can't retrieve any data anymore, as I perform an
ldapsearch by the meta directory ....
Is there anything wrong in my conf ?
the slapd-meta man page says about acl-authcDN directives : "it is
supposed to have read access on the target server to attributes used
on the proxy for acl checking."
what does that mean exactly ? :)
Thanks.
--
Julien Oix
UFR d'Informatique - Université Paris Diderot
Bureau 5C01 (5ème étage)
175 rue du Chevaleret
75013 PARIS
Tel : +33 (0) 144 278 504
Mobile : +33 (0) 664 392 207
---------------------------------------------
http://www.gnu.org/philosophy/no-word-attachments.html
13 years, 11 months
change tracelevel programatically
by Lukacs David
Hello!
I'm using slapd (version 2.2.6) with a custom backend. I've tried
to implement a feature to change the trace level triggered by some
events. I used the following piece of code to do this (found it
originally in log.c):
slap_debug = newTraceLevel;
lutil_set_debug_level( "slapd", slap_debug );
ber_set_option(NULL, LBER_OPT_DEBUG_LEVEL, &slap_debug);
ldap_set_option(NULL, LDAP_OPT_DEBUG_LEVEL, &slap_debug);
ldif_debug = slap_debug;
Although it works at the first glance, i get strange segfaults
later on mostly from `backend.c'. For example in:
int backend_check_referrals( Operation *op, SlapReply *rs )
when checking on `op->o_bd->be_chk_referrals'
or
int backend_connection_destroy( Connection *conn )
when checking on `backends[i].be_connection_destroy'
The code to change trace level is called from the backend when an
operation is started. Does anybody know the appropriate way of
change tracing programatically?
Thanks for the help in advance.
Regards,
David
___________________________________________________________
"Diszlexiás-e a gyerekem?" - 25 kérdéses gyorsteszt
(hálás lesz utána, akármi is az eredmény!)
http://ad.adverticum.net/b/cl,1,6022,133103,204265/click.prm
13 years, 11 months
Error using TLS
by Iñaki
Hi, this is my first post to the list.
I get an error when trying to run slapd with TLS options. I've looked a lot
and sincerely don't know what I'm doing wrong.
I use Debian Sarge.
These are the steps I follow to create and configure the TLS certificate:
1) Create a directory ssl:
#> mkdir /etc/ldap/ssl
#> cd /etc/ldap/ssl
2) Generate a private/public key:
#> /usr/lib/ssl/misc/CA.pl -newreq
Generating a 1024 bit RSA private key
.++++++
...................................++++++
writing new private key to 'newreq.pem'
Enter PEM pass phrase: *****
Verifying - Enter PEM pass phrase: *****
Country Name (2 letter code) [AU]:ES
State or Province Name (full name) [Some-State]:Vizcaya
Locality Name (eg, city) []:Barakaldo
Organization Name (eg, company) [Internet Widgits Pty Ltd]:domain.net
Organizational Unit Name (eg, section) []:debian
Common Name (eg, YOUR name) []:debian.domain.net
Email Address []:ibc@domain.net
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Request (and private key) is in newreq.pem
3) Remove the password from the unique "newreq.pem" created:
#> openssl rsa -in newreq.pem -out key.pem
Enter pass phrase for newreq.pem: *****
writing RSA key
4) Edit the certificate to remove the key and rename:
#> vi newreq.pem
[...]
#> mv newreq.pem cert.pem
5) Change permissions for the key:
#> chmod 600 key.pem
6) Now I have the cetificate and the key:
#> ls -l
-rw-r--r-- 1 root root 708 2007-01-23 21:35 cert.pem
-rw------- 1 root root 887 2007-01-23 21:35 key.pem
7) Configure slapd.conf:
----------------
TLSCipherSuite HIGH
TLSCertificateFile /etc/ldap/ssl/cert.pem
TLSCertificateKeyFile /etc/ldap/ssl/key.pem
----------------
8) Save and restart slapd:
#> /etc/init.d/slapd restart
Stopping OpenLDAP: slurpd slapd.
Starting OpenLDAP: running BDB recovery, slapd - failed.
The operation failed but no output was produced. For hints on what went
wrong please refer to the system's logfiles (e.g. /var/log/syslog) or
try running the daemon in Debug mode like via "slapd -d 16383" (warning:
this will create copious output).
9) The syslog says:
Jan 23 21:38:20 debian slapd[2339]: @(#) $OpenLDAP: slapd 2.2.23 (May 30 2005
08:52:42) $
^I@pulsar:/home/torsten/packages/openldap/openldap2.2-2.2.23/debian/build/servers/slapd
Jan 23 21:38:20 debian slapd[2339]: bdb_db_init: Initializing BDB database
Jan 23 21:38:20 debian slapd[2339]: main: TLS init def ctx failed: -1
Jan 23 21:38:20 debian slapd[2339]: slapd stopped.
Jan 23 21:38:20 debian slapd[2339]: connections_destroy: nothing to destroy.
Could you tell me why this error occurs? I've read in many sites about those
exact steps to configure TLS in OpenLDAP but it doesnt' work for me.
Thanks in advance for any help.
Regards.
--
Iñaki Baz Castillo
13 years, 11 months
olcTLSCipherSuite?
by Eric Irrgang
Does the TLSCipherSuite directive translate to anything in cn=config?
I'm not seeing anything when I convert my slapd.conf file and the server
doesn't seem to be interpreting the directive "TLSCipherSuite HIGH:MEDIUM"
the way I would expect. That is, to only allow high and medium strength
connections while trying to negotiate high-strength first.
--
Eric Irrgang - UT Austin ITS Unix Systems - (512)475-9342
13 years, 11 months
cn=include
by Eric Irrgang
Are olcInclude attributes in cn=config honored as per the Admin Guide
section 5.2.2 or is that documentation misleading?
--
Eric Irrgang - UT Austin ITS Unix Systems - (512)475-9342
13 years, 11 months
Re: OpenLDAP issues when connecting over SSL
by Kurt D. Zeilenga
At 03:44 PM 1/21/2007, Jean-Yves Avenard wrote:
>On 1/22/07, Kurt D. Zeilenga <Kurt(a)openldap.org> wrote:
>>Given other clients seem to work well using ldaps://,
>>it seems more likely that this particular client is
>>not properly configured or is otherwise flawed.
>
>Unfortunately, I have no play on how to configure this client as this
>is one major one !
You might ask on a list supporting the particular client you
are using how to configure this client to secure LDAP with TLS
(SSL).
>Actually, two quite common do not work with OpenLDAP over SSL :(
>But they will work fine over a non encrypted link
>
>>I guess that the client is configured to use ldap://server:636
>>not ldaps://server:636.
>That was my guess also.
>I there anything I can do on the server side to get over the flaw of
>broken clients ?
If the client doesn't support securing LDAP with TLS (SSL),
either by using ldaps:// or by using ldap:// with Start TLS,
there is nothing the server can do to change that. You
can configure the server to support ldap:// on port 636 instead
of ldaps:// if you want, but I don't recommend doing so.
Kurt
13 years, 11 months
deferring operation: too many executing
by Sepp
Hello,
sorry when this is a FAQ. What is the exact meaning of:
connection_input: conn=4412677 deferring operation: too many executing
and what could be done against it ?
Thanks
Sepp
13 years, 11 months
WARNING: No dynamic config support for overlay ppolicy? - SOLVED
by Errol Neal
>>Your "overlay ppolicy" clause is in the wrong place. Look at the
>>test022 example more carefully, and read the
You were ABSOLUTELY RIGHT! Very happy - thank you very much. I reworked
my slapd.conf file paying attention to test022 and my password policies
are working now. Thank you very much Howard!
But whats up with the error regarding dynamic overlays at start up?
13 years, 11 months
