Re: fetching information
Am Wed, 29 Jun 2011 19:44:41 -0300 schrieb Friedrich Locke friedrich.lo...@gmail.com: I am planing using openldap to fetch user/group information. Below my main tree there will be ou=people and ou=group, and below those the regular user or group information. It happens that a program (ypserv) will fetch information from tree binding as cn=ypserv just below my main tree. This binding should be authenticated, so what should cn=ypserv attributes be? What about access rules for it ? Thanks a lot for your time and cooperation. object class organizationalRole is a structural objectclass and only requires cn, while object class simpleSecurityObject is auxiliary and only provides userPassword. -Dieter -- Dieter Klünter | Systemberatung sip: 7770...@sipgate.de http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6
RE: pcache + back-sql
Can you point me to documentation about the pcache logging subsystem?
slapd -d pcache
Indeed, I can't find any mention of it in obvious places (slapo-pcache(5),
admin guide under pcache overlay, loglevel directive in slapd.conf(5) or
slapd-config(5)). I suggest you file a request for documentation update.
p.
I tried that and slapd didn't recognize it. Looking at the code (which I took
from HEAD
yesterday), I can't see any reference to a pcache logging level
(servers/slapd/bconfig.c):
static int
loglevel_init( void )
{
slap_verbmasks lo[] = {
{ BER_BVC(Any), (slap_mask_t) LDAP_DEBUG_ANY },
{ BER_BVC(Trace), LDAP_DEBUG_TRACE },
{ BER_BVC(Packets), LDAP_DEBUG_PACKETS },
{ BER_BVC(Args), LDAP_DEBUG_ARGS },
{ BER_BVC(Conns), LDAP_DEBUG_CONNS },
{ BER_BVC(BER), LDAP_DEBUG_BER },
{ BER_BVC(Filter), LDAP_DEBUG_FILTER },
{ BER_BVC(Config), LDAP_DEBUG_CONFIG },
{ BER_BVC(ACL), LDAP_DEBUG_ACL },
{ BER_BVC(Stats), LDAP_DEBUG_STATS },
{ BER_BVC(Stats2), LDAP_DEBUG_STATS2 },
{ BER_BVC(Shell), LDAP_DEBUG_SHELL },
{ BER_BVC(Parse), LDAP_DEBUG_PARSE },
#if 0 /* no longer used (nor supported) */
{ BER_BVC(Cache), LDAP_DEBUG_CACHE },
{ BER_BVC(Index), LDAP_DEBUG_INDEX },
#endif
{ BER_BVC(Sync), LDAP_DEBUG_SYNC },
{ BER_BVC(None), LDAP_DEBUG_NONE },
{ BER_BVNULL, 0 }
};
return slap_verbmasks_init( loglevel_ops, lo );
}
I can see lots of calls to Debug() in pcache.c, and with logging level set to
-1 I can see
these messages in the log file, so I'm happy that caching is working, but it
looks like
the pcache debug level is not fully implemented, or has been lost in a merge
somewhere.
Chris
RE: pcache + back-sql
Can you point me to documentation about the pcache logging subsystem? slapd -d pcache Indeed, I can't find any mention of it in obvious places (slapo-pcache(5), admin guide under pcache overlay, loglevel directive in slapd.conf(5) or slapd-config(5)). I suggest you file a request for documentation update. p. I tried that and slapd didn't recognize it. Looking at the code (which I took from HEAD yesterday), I can't see any reference to a pcache logging level (servers/slapd/bconfig.c): It is registered by the overlay itself as soon as it is initialized. p.
Re: Loading LDAP schema files into cn=config
On 29/06/11 18:05, Quanah Gibson-Mount wrote: Although I'm not sure exactly how this is going to work since elements of slapd.conf are still required to bootstrap the directory from LDAP .schema files. Hmmm. Zimbra puts cn=config in the same location as any other LDAP database we use (/opt/zimbra/data/ldap/, which has cn=config, hdb, and accesslog databases). Right - so the Debian guys have definitely got this wrong then :( As for the *.ldif schema, OpenLDAP ships both .ldif and .schema files for the schemas it has always shipped. If a project is not shipping a .ldif version, file a bug with the project (I did this for Amavis, for example). If you have your own schema, change your schema generation process to generate an LDIF formatted schema instead of the old .schema format. That's also what we did at Zimbra (In fact, we generate both .schema and .ldif versions of the ZCS schema). Whoa - wait second. Now I get it - so not only is slapd.conf deprecated, but also the distribution of .schema files. If we're supposed to be distributing schemas in .ldif format from now on, then the conversion problem just goes away. So I was missing something obvious after all... As a long-term follower of this project, can I just summarise what I believe the results of this thread are: 1) Distribution of .schema files is deprecated. Projects should be distributing .ldif files containing schema changes instead. 2) If a project is distributing a .schema file, ask them politely to move to .ldif format instead. If they refuse, you need to convert from .schema to .ldif yourself using slaptest. Finally, just as a general observation it's obvious that this message is NOT getting through to distributions and developers. I would advise that you add an explicit deprecation warning related to the distribution of .schema files with applications (as it's not clear that the .schema files are directly considered part of the configuration) to the main documentation and point people towards that when (like me) they start to ask questions. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs
Re: Loading LDAP schema files into cn=config
On Wednesday, 29 June 2011 16:15:54 Daniel Qian wrote:
On 11-06-29 9:26 AM, Mark Cave-Ayland wrote:
On 29/06/11 12:59, Howard Chu wrote:
Thanks for the response - this makes a bit more sense now. Just to
clarify another point: when you generate schemaConvert.conf, I guess
that you need to include *all* schemas in your current cn=config
matching the existing order, as well as the new one you are trying to
add?
Obviously the config file has to be valid; any schema that the ones
you're converting depend on must be loaded.
I understand that part; however when installing the packages for
Debian Squeeze the post-installation process preloads the following
schemas into cn=schema,cn=config:
{0}core
{1}cosine
{2}nis
{3}inetorgperson
So what I wanted to verify was that if I want to add a new
sirius-custom.schema file into the directory I would need to setup
schemaConvert.conf to look like this:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/sirius-custom.schema
The previous entries are required to ensure that the
sirius-custom.schema LDIF would be generated as {4}sirius-custom ready
for using ldapadd to load into the directory.
However when I then run:
mkdir config slaptest -f slapd.conf.tmp -F config
Then I get my {4}sirius-custom.ldif but the top lines look like this:
dn: cn={4}sirius-custom
...
cn: {4}sirius-custom
...which then means I still can't add it directly using ldapadd
without further processing.
Not sure if it is the same on Debian but on Fedora I only copied the
workplace output schema file (autofs.schema in my case) to
/etc/openldap/slapd.d/cn=config/cn=schema/ without modifying anything. I
restarted slapd after that and everything worked for me. Surprisingly
easy although I had to do a restart.
But, this isn't how it is intended to be used, and gets you into bad habits.
You should treat the config database as if it is any other database. The
closest you should get to manual changes to it is 'slapadd', just like hdb or
bdb etc.
You should just have been able to ldapadd the ldif file. And it wouldn't have
required a restart.
For example, in Mandriva we ship pre-converted ldif schema files, that can
just be ldapadd'ed.
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/openldap-extra-
schemas/current/SOURCES/
(viewvc seems to have changed, you used to be able to download the files raw
before, which made this more useful)
Yes, for this package I do manually remove the ordering from the DN/naming
attribute, purely to allow easy post-initial-configuration addition.
Regards,
Buchan
RE: pcache + back-sql
Can you point me to documentation about the pcache logging subsystem? slapd -d pcache Indeed, I can't find any mention of it in obvious places (slapo-pcache(5), admin guide under pcache overlay, loglevel directive in slapd.conf(5) or slapd-config(5)). I suggest you file a request for documentation update. p. I tried that and slapd didn't recognize it. Looking at the code (which I took from HEAD yesterday), I can't see any reference to a pcache logging level (servers/slapd/bconfig.c): It is registered by the overlay itself as soon as it is initialized. p. ok, thanks, that makes sense. Anyway, I'm happy that stuff is being cached. I have found a bug though, when using pcache and sssvlv together, which I'll raise in ITS. Chris
slapo-memberof across proxy
Hello list, With this type of setup, Client (A) - back_ldap Proxy (B) - syncrepl Slave (C) - Master (D) I have configured the memberof overlay on both (C) and (D). I am able to query both (C) and (D), either to specifically retrieve the memberof attribute or to perform a query which filter is based on the memberof attribute. All works fine with (C) and (D) If i issue the same type of queries from (A) to (B), i'm able to retrieve the memberof attribute alright *BUT* i cannot perform searches which contain the memberof attribute on the query filter. Does (B) need any special configuration so that back_ldap can cope with the memberof overlay available on the backend servers? Thanks in advance, Hugo Monteiro. -- fct.unl.pt:~# cat .signature Hugo Monteiro Email: hugo.monte...@fct.unl.pt Telefone : +351 212948300 Ext.15307 Web : http://hmonteiro.net Divisão de Informática Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa Quinta da Torre 2829-516 Caparica Portugal Telefone: +351 212948596 Fax: +351 212948548 www.fct.unl.ptap...@fct.unl.pt fct.unl.pt:~# _
RE: autofs wild cards
Hi Cris, My auto.home has * host:/export/ for user directories. When I use the automount migration tool the * is changed to / and I get the error: adding new entry cn=/,ou=auto.home,dc=domain,dc=com ldapadd: Naming violation (64) additional info: value of naming attribute 'cn' is not present in entry Is there a way to get the wild card to work or do I need to enter each user instead of using a wild card? Sorry for resurrecting an old post but I didn't see any responses. I used the LDIFs below to construction my automount OUs and for a wildcarded /home automount configuration. dn: ou=automount,dc=domain,dc=com objectClass: organizationalUnit ou: automount description: nss automount dn: ou=auto.master,ou=automount,dc=domain,dc=com ou: auto.master objectClass: top objectClass: automountMap dn: cn=/home,ou=auto.master,ou=automount,dc=domain,dc=com objectClass: automount automountInformation: ldap:ldap.domain.com:ou=auto.home,ou=automount,dc=domain,dc=com --timeout 300 cn: /home dn: ou=auto.home,ou=automount,dc=domain,dc=com ou: auto.home objectClass: top objectClass: automountMap dn: cn=/,ou=auto.home,ou=automount,dc=domain,dc=com objectClass: automount automountInformation: -rw,hard,intr nfsserv.domain.com:/export/home/ cn: / Regards, James This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp
bad credential
I upload the ldif file below into my openldap server:
dn: dc=ufv,dc=br
dc: ufv
objectclass: dcobject
objectclass: organization
o: Universidade Federal de Vicosa
dn: ou=group,dc=ufv,dc=br
ou: group
objectclass: top
objectclass: organizationalunit
dn: cn=its,ou=group,dc=ufv,dc=br
cn: its
objectclass: posixgroup
gidnumber: 1000
dn: cn=asd,ou=group,dc=ufv,dc=br
cn: asd
objectclass: posixgroup
gidnumber: 1001
memberuid: sioux
dn: cn=dba,ou=group,dc=ufv,dc=br
cn: dba
objectclass: posixgroup
gidnumber: 1002
memberuid: sioux
dn: cn=wbx,ou=group,dc=ufv,dc=br
cn: wbx
objectclass: posixgroup
gidnumber: 1003
dn: cn=alg,ou=group,dc=ufv,dc=br
cn: alg
objectclass: posixgroup
gidnumber: 1004
memberuid: sioux
dn: cn=djb,ou=group,dc=ufv,dc=br
cn: djb
objectclass: posixgroup
gidnumber: 1005
dn: cn=nofiles,ou=group,dc=ufv,dc=br
cn: nofiles
objectclass: posixgroup
gidnumber: 1006
dn: cn=qmail,ou=group,dc=ufv,dc=br
cn: qmail
objectclass: posixgroup
gidnumber: 1007
dn: cn=ftp,ou=group,dc=ufv,dc=br
cn: ftp
objectclass: posixgroup
gidnumber: 1008
dn: cn=src,ou=group,dc=ufv,dc=br
cn: src
objectclass: posixgroup
gidnumber: 1009
dn: cn=ord,ou=group,dc=ufv,dc=br
cn: ord
objectclass: posixgroup
gidnumber: 2000
dn: cn=adc,ou=group,dc=ufv,dc=br
cn: adc
objectclass: posixgroup
gidnumber: 2001
dn: cn=bod,ou=group,dc=ufv,dc=br
cn: bod
objectclass: posixgroup
gidnumber: 2002
dn: cn=frn,ou=group,dc=ufv,dc=br
cn: frn
objectclass: posixgroup
gidnumber: 2003
dn: ou=people,dc=ufv,dc=br
ou: people
objectclass: top
objectclass: organizationalunit
dn: uid=sioux,ou=people,dc=ufv,dc=br
uid: sioux
objectclass: organizationalrole
objectclass: posixaccount
cn: Gustavo Rios
uidnumber: 1000
gidnumber: 1000
homedirectory: /home/sioux
userpassword: {SASL}si...@ufv.br
loginshell: /bin/sh
Gecos: Gustavo V G Coelho Rios,,,
But when i try the command below, i get invalid credential
sioux@gustav$ ldapsearch -x -W -D 'uid=sioux,ou=people,dc=ufv,dc=br'
-b dc=ufv,dc=br
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
sioux@gustav$
And when i try:
$ ldapsearch -Y GSSAPI -b dc=ufv,dc=br
it works perfectly.
Any ideia about why it does not work ?
slaptest returns index attribute reqStart undefined
Hello list members, I am trying to setup ldap 2.4.23 on new FreeBSD 8.2 consumer server to replace a current system that is quite old. I have copied over the slapd.conf file and associated certs, etc from the production system and I'm able to get the server working using the sample slapd.conf and examples in the quick setup guide. When I run slaptest -f slapd.conf.artemis on the configuration file I copied over I get the error: slapd.conf.artemis: line 86: index attribute reqStart undefined slaptest: bad configuration file! Running the same test on the production server's slapd.conf produces no error at all. I've googled, RTFM and read man pages trying to get a clue as to what might be causing this, but I'm unable to unearth any leads that have helped so far. What I have tried is to copy the production *.bdb files over to the new server thinking that was the problem, I didn't try re-indexing those files (just read about slapindex late last night, so haven't tried that yet) I was also thinking that I might need to run slapcat on the production db's and then import the ldif file using slapadd (which I'm setting up to test shortly). Clearly I'm missing something, I'm hoping that someone here who is much more adept at LDAP can suggest some additional things to try. Below is what I think are the relevant portions of the slapd.conf file, which shows the section the slaptest complains about, the second section is our replication area which I believe is directly related to the replication process. database bdb suffix cn=accesslog directory /usr/local/var/db/openldap-accesslog rootdn cn=accesslog index default eq index entryCSN,objectClass,reqStart,reqResult,reqEnd overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 07+00:00 01+00:00 I'm trying to bootstrap my Sys Admin skills (after a 12 year absence) due to the sudden loss of my long time admin, with mixed results! Time will tell, appreciate any suggestions you might have to get me past this particular issue. Mike Greene Rock Island Technology Solutions, Inc. San Juan Islands, WA. 360-378-5884 x201
syncrepl rid question
I have multiple ldap servers using replication: one provider and multiple consumers. In my multiple consumers' slapd.conf, the replication rid is the same: syncrepl rid=123. I wonder if this is a problem. Should the rid for each consumer be unique? why? Thanks. Hai Tao
OpenLDAP mirror replication ldif format
Hi there, I recently installed a new Debian 6 and OpenLDAP to test the new ldif format configuration. The problem is that I do not have any base configuration to use slaptest to migrate my config to ldif format. My main concern is now to find a manual/tutorial, to be able to setup a mirror replication with ldif format, because all I can find is using the old slapd.conf. Can anyone point me somewhere, where I could find some help or give my a quick example ? Thanks in advance for any return, Sismon
Sendmail + LDAP
Hi, I experince some problems with setting up Sendmail with the LDAP database for virtual mail accounts. I believe, that the reason of my problem is in configuring dovecot-deliver, but nobody answers me in the dovecot-mailing list, so i've decided to post a message here What i have: - FreeBSD 8.2-RELEASE - sendmail (Version 8.14.4 with LDAP support installed from ports) - Dovecot LDA + dovecot (as pop3/imap) - 1.2.16 - openldap - 2.4.23 1. Following http://wiki.dovecot.org/LDA/Sendmail i've set up deliver as LDA. Everything worked fine. 2. Following http://wiki.dovecot.org/HowTo/DovecotOpenLdap i've set up Dovecot to work with tha ldap. Now i can authorize through the client or web interface and get to my maildir. 3. Now, i want my sendmail to accept mail for the account in LDAP database. sendmail.mc: ++ FEATURE(`local_procmail', `/usr/local/libexec/dovecot/deliver',`/usr/local/libexec/dovecot/deliver -d $u') MODIFY_MAILER_FLAGS(`LOCAL', `-f') .. define(`confLDAP_DEFAULT_SPEC', `-h localhost -b dc=mydomain,dc=ru -d cn=dovecot,ou=accounts,dc=mydomain,dc=ru -MLDAP_AUTH_SIMPLE -P /etc/mail/ldap_pass')dnl LDAPROUTE_DOMAIN(`mydomain.ru')dnl FEATURE(`ldap_routing', `null -TTMPF', `ldap -1 -TTMPF -v mail -k ((objectclass=posixaccount)(mail=%0))', `passthru')dnl .. MAILER(procmail) ++ After re-making the sendmail: ++ [root@test2 /etc/mail]# sendmail -bv -d60.1 test_u...@mydomain.ru map_lookup(dequote, test) = NOT FOUND (0) map_lookup(host, mydomain.ru) = mydomain.ru. (0) map_lookup(dequote, test_user) = NOT FOUND (0) map_lookup(ldapmra, test_u...@mydomain.ru) = test_u...@mydomain.ru (0) map_lookup(ldapmh, test_u...@mydomain.ru) = NOT FOUND (68) map_lookup(host, mydomain.ru) = mydomain.ru. (0) map_lookup(dequote, test_user) = NOT FOUND (0) map_lookup(virtuser, test_u...@mydomain.ru) = NOT FOUND (0) map_lookup(virtuser, @mydomain.ru) = NOT FOUND (0) test_u...@mydomain.ru... User unknown ++ It's the problem of the local delivery, i believe. Why? Because after sendmail getting an email it passes it to the LDA, which must check the LDAP (not the passwd!) database for the user, to which this email is send to. Are there some possibilities to solve this problem? Or, maybe there might be a problem in cofiguring the OpenLDAP? I appreciate any help... --- Best regards, Vasily Yakovlev
How to configure OpenLdap Client to work with Windows Active Directory
Hi, Can ldapsearch work with Windows AD via GSSAPI? Is there any special setting/software I need to do on the client side? On my Client system, I have Windows openldap client tools (ldapsearch etc). My Server system has Windows AD running. I was able to use Simple Authentication and it worked. ldapsearch.exe -H ldap://MPSD-EB01T3/ -b dc=test,dc=com -x I know Windows 2008 AD support GSSAPI. ldapsearch -H ldap://MPSD-EB01T3/ -xLLL -s base -b supportedSASLMechanisms dn: supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: GSS-SPNEGO supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: DIGEST-MD5 Now I tried to use GSSAPI and it failed. Is there anything special setting I need to do on the client side to make it work? ldapsearch -H ldap://MPSD-EB01T3/ -b cn=user1,dc=test,dc=com -W -U user1 -Y GSSAPI -d 3 ldap_url_parse_ext(ldap://MPSD-EB01T3/) ldap_create ldap_url_parse_ext(ldap://MPSD-EB01T3:389/??base) ldap_sasl_interactive_bind_s: user selected: GSSAPI ldap_int_sasl_bind: GSSAPI ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP MPSD-EB01T3:389 ldap_new_socket: 392 ldap_prepare_socket: 392 ldap_connect_to_host: Trying 192.168.1.30:389 ldap_pvt_connect: fd: 392 tm: -1 async: 0 ldap_int_sasl_open: host=MPSD-EB01T3 ldap_err2string ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: Unable to find a calback: 2
Re: OpenLDAP mirror replication ldif format
http://www.openldap.org/doc/admin24/replication.html Read that, but you're really better off reading the whole manual from front to back before moving forward. I used the above doc to set up replication, and I'm still fairly new to OpenLDAP. Also, you're better off learning to use cn=config rather than the slapd.conf setup. On Wed, Jun 29, 2011 at 12:17:10PM +0200, Simon Massart wrote: Hi there, I recently installed a new Debian 6 and OpenLDAP to test the new ldif format configuration. The problem is that I do not have any base configuration to use slaptest to migrate my config to ldif format. My main concern is now to find a manual/tutorial, to be able to setup a mirror replication with ldif format, because all I can find is using the old slapd.conf. Can anyone point me somewhere, where I could find some help or give my a quick example ? Thanks in advance for any return, Sismon
Re: Loading LDAP schema files into cn=config
On 29/06/2011 18:30, Mark Cave-Ayland wrote: On 29/06/11 16:56, Simone Piccardi wrote: Then I think you must be flamed too... But if you did so, then why just not to stay with slapd.conf? It still work and is far easier to understand and manage. Because slapd.conf is deprecated and going away in openldap 2.5. So I'd like to get familiar with it now before this happens :) I understood that this was not the case, but I can be wrong. And if yes I hope this decision could be reversed, but I'm not a developer so I can just state my uneasiness about such a choice. As I already said I'm just an old style Unix admin, and as such I don't like at all to be forced to use any kind of program different from just an editor to do a service configuration. Having text configuration files (that can be commented and put under a revision system) is a major strength for an Unix system, and giving it away is very bad. I can afford a restart or a reload in any of the tens of installation I have, but reworking the method we have to take trace of configuration changes made in production servers will be a real pain. I support the choice to make possible configuration change without restarting the service, what I do not support is the choice to remove the use of textual configuration files. Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
RE: sssvlv
When using the sssvlv overlay how does the client tell the server that the sort request can be thrown away, so that sort requests don't hang around until sssvlv-max or sssvlv-maxpercon are exceeded? There is no official mechanism for this. This is a flaw in the Sorting/VLV specification. For Paged Results you simply send a followup request with pagesize set to zero, but that doesn't apply for VLV. I believe in our current implementation, if you send a new Paged Results request on a connection that has VLVs outstanding, one of the VLVs will be aborted. Unfortunately, if you have multiple VLVs outstanding, there's no way to determine which one gets aborted. (Apparently this was overlooked when patching the overlay to allow multiple VLVs on a connection...) Thanks for the info. Is it the case that sort requests are associated with a particular connection? From my testing it seems that a sort request will remain active in the server evenif the client disconnects, which doesn't seem right. Chris
Re: slapo-memberof across proxy
Hello list, With this type of setup, Client (A) - back_ldap Proxy (B) - syncrepl Slave (C) - Master (D) I have configured the memberof overlay on both (C) and (D). I am able to query both (C) and (D), either to specifically retrieve the memberof attribute or to perform a query which filter is based on the memberof attribute. All works fine with (C) and (D) If i issue the same type of queries from (A) to (B), i'm able to retrieve the memberof attribute alright *BUT* i cannot perform searches which contain the memberof attribute on the query filter. Does (B) need any special configuration so that back_ldap can cope with the memberof overlay available on the backend servers? memberOf must be known to the proxy. This attribute is registered by slapo-memberof(5) during initialization, so all you need to do is load the overlay in the proxy's configuration, without instantiating it. p.
Re: Loading LDAP schema files into cn=config
On 30/06/2011 19:18, Quanah Gibson-Mount wrote: Again, I urge people to file bug reports etc with distributions when they find issues like these. I do this fairly often with Debian/Ubuntu. As I said I already filed a bug for Debian, is here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626911 That's about using /etc/ldap/slapd.d. I will not file any bugs about passing to .ldap files for schemas, because I think .schema files are far more readable, so they are still useful, and there is a clear way to get LDIF files from them where the reverse is not true. Regards Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
I cannot auth against SASL
Hi!
i am trying to authenticate binding the DN below and it works nicely.
dn: uid=grios,ou=people,dc=ufv,dc=br
uid: grios
objectclass: organizationalrole
objectclass: posixaccount
cn: Gustavo Rios
uidnumber: 2000
gidnumber: 2000
homedirectory: /home/grios
userpassword: {SSHA}dWhcPjgDn4EGb/FwGMYbxx7fIqAuXCN7
loginshell: /bin/sh
gecos: Gustavo V G C Rios,,,
But if i change userpassword attribute to {SASL}gr...@ufv.br it does
not work when i bind the same DN above.
Does anybody have an ideia about my mistaken ?
Thanks in advance.
i am desperated: authentication without success
Hi folks,
i am trying to search my base tree but i am not able to connect due to
invalid credentials (49). It seems very confusing because i am sure
i am using the correct password.
sioux@gustav$ ldapsearch -w $my_pass -D
uid=grios,ou=people,dc=ufv,dc=br -b 'dc=ufv,dc=br' -s one
ldap_bind: Invalid credentials (49)
sioux@gustav$
The entry's ldif whose rdn is uid=grios is:
dn: uid=grios,ou=people,dc=ufv,dc=br
uid: grios
objectclass: organizationalrole
objectclass: posixaccount
cn: Gustavo Rios
uidnumber: 2000
gidnumber: 2000
homedirectory: /home/grios
userpassword: {SASL}gr...@ufv.br
loginshell: /bin/sh
gecos: Gustavo V G C Rios,,,
I am monitoring heimdal kerberos log file and cyrus-sasl log file too.
Nothing is shown there. I DON'T really have any ideia on my mistaken.
May you please help me?
Kind regards.
Fried.
Re: i am desperated: authentication without success
--On Thursday, June 30, 2011 4:36 PM -0300 Friedrich Locke friedrich.lo...@gmail.com wrote: Hi folks, i am trying to search my base tree but i am not able to connect due to invalid credentials (49). It seems very confusing because i am sure i am using the correct password. sioux@gustav$ ldapsearch -w $my_pass -D uid=grios,ou=people,dc=ufv,dc=br -b 'dc=ufv,dc=br' -s one ldap_bind: Invalid credentials (49) This isn't a Kerberos SASL/GSSAPI bind. This is a simple bind. What is it you really want to do? --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration
Re: I cannot auth against SASL
--On Thursday, June 30, 2011 10:22 PM +0200 Dieter Kluenter die...@dkluenter.de wrote: Frankly, I don't understand what you are trying to do. You either bind by means of simple bind (which is DN and password), or by a sasl based strong bind. In order to use a strong bind you have several choices, either openldap's own sasl framework or an external mechanism that provides authentication. In order to use SASL authentication by means of openldap's sasl framework i.e. password and uid based credentials, the stored userPassword attribute value has to be cleartext, otherwise it is not possible to create an apropriate challenge. Not true with SASL/GSSAPI. In that case, there should be *no* userPassword attribute at all. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration
userPassword
What does
userPassword: {SASL}xxx@MY.DOMAIN
mean?
Thanks a lot.
simple binds
Is it possible to perform simple binds but looking up the entry's password in a kerberos server? Thanks in advance.
Re: simple binds
--On Thursday, June 30, 2011 7:22 PM -0300 Friedrich Locke friedrich.lo...@gmail.com wrote: Is it possible to perform simple binds but looking up the entry's password in a kerberos server? Please spend some time reading the OpenLDAP documentation. Your question here is clearly answered in the OpenLDAP Admin guide, section 14.5: http://www.openldap.org/doc/admin24/security.html --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration
Re: cn=config completely replacing slapd.conf
Quanah Gibson-Mount wrote: --On Thursday, June 30, 2011 11:46 AM -0400 David N. Blank-Edelman d...@ccs.neu.edu wrote: (taking this to a new thread) Sorry for such a vague question, but my (perhaps failing) memory is once upon a time there were still certain backends or overlays that couldn't yet be configured via cn=config and had to be specified in slapd.conf. Has 2.4 has already cleared up all of those legacy configuration requirements or is that a 2.5 goal? Thanks! It is a 2.5 goal. As of several months ago, only back-sql and back-meta remain incompatible. All of the overlays have already been converted. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: How to configure OpenLdap Client to work with Windows Active Directory
On 30/06/11 09:47 -0700, yen nguyen wrote: Yes. My client system is connected to the domain. I was able to obtain a valid ticket from the AD system. The kinit command ran ok. kinit us...@test.com I even ran gssclient and it ran ok with no error. gssclient -port 389 MPSD-EB01T3 LDAP/MPSD-EB01T3.TEST.COM hello The DN of my AD should be TEST.COM So what else do I need to do on the client system to use OpenLDAP client tools with -Y GSSAPI option ? Is there a ldap.conf configuration for windows openldap client tools? You need to have a Cyrus SASL GSSAPI mechanism installed on your client system, which OpenLDAP uses to perform the necessary GSSAPI authentication with the server. If you have 'pluginviewer' available on your system, it will tell you which sasl mechanisms you have available. For Cyrus documentation on windows builds, see: http://www.cyrusimap.org/docs/cyrus-sasl/2.1.23/windows.php Date: Thu, 30 Jun 2011 16:17:44 +0100 From: andrew.find...@skills-1st.co.uk To: nhan_...@hotmail.com CC: openldap-technical@openldap.org Subject: Re: How to configure OpenLdap Client to work with Windows Active Directory On Wed, Jun 29, 2011 at 05:41:26PM -0700, yen nguyen wrote: Can ldapsearch work with Windows AD via GSSAPI? Is there any special setting/ software I need to do on the client side? GSSAPI is normally a carrier for Kerberos tickets, so for this to work you will need to obtain a valid ticket for the AD service. This will involve connecting your client system to the Kerberos domain managed by the AD system. On my Client system, I have Windows openldap client tools (ldapsearch etc). My Server system has Windows AD running. I was able to use Simple Authentication and it worked. ldapsearch.exe -H ldap://MPSD-EB01T3/ -b dc=test,dc=com -x Without the -D and -w (or -W) options, this is just anonymous (un-authenticated) access. You can certainly use the OpenLDAP client tools with AD using simple authentication. The main problem is to find out what the DN of your AD account actually is. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | --- -- Dan White
Re: sssvlv
Chris Card wrote: When using the sssvlv overlay how does the client tell the server that the sort request can be thrown away, so that sort requests don't hang around until sssvlv-max or sssvlv-maxpercon are exceeded? There is no official mechanism for this. This is a flaw in the Sorting/VLV specification. For Paged Results you simply send a followup request with pagesize set to zero, but that doesn't apply for VLV. I believe in our current implementation, if you send a new Paged Results request on a connection that has VLVs outstanding, one of the VLVs will be aborted. Unfortunately, if you have multiple VLVs outstanding, there's no way to determine which one gets aborted. (Apparently this was overlooked when patching the overlay to allow multiple VLVs on a connection...) Thanks for the info. Is it the case that sort requests are associated with a particular connection? What does RFC2891 say? From my testing it seems that a sort request will remain active in the server evenif the client disconnects, which doesn't seem right. How are you determining that this is the case? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: cn=config completely replacing slapd.conf
Howard Chu wrote: As of several months ago, only back-sql and back-meta remain incompatible. All of the overlays have already been converted. Cool, it sounds like you folks have done a lot of work on this front. I'm still using back-meta. As soon as that joins the rest I'll convert my setups right over to cn=config. -- dNb
back-config backend support (Was: cn=config completely replacing slapd.conf)
Quanah Gibson-Mount wrote: --On Thursday, June 30, 2011 11:46 AM -0400 David N. Blank-Edelman d...@ccs.neu.edu wrote: (taking this to a new thread) Sorry for such a vague question, but my (perhaps failing) memory is once upon a time there were still certain backends or overlays that couldn't yet be configured via cn=config and had to be specified in slapd.conf. Has 2.4 has already cleared up all of those legacy configuration requirements or is that a 2.5 goal? Thanks! It is a 2.5 goal. As of several months ago, only back-sql and back-meta remain incompatible. All of the overlays have already been converted. On a related note: I'll do my best to spare time to port back-meta(5); I don't think I'll be able to port back-sql(5), nor to support it in the future. I'd like someone else to step in, unless we're fine with discontinuing it. p.
