Check errors from Jexplore!
by Nguyen Quang Huy
Hi all!
Im Setup Openldapv2.x, Im setup following guide:
http://www.linuxmail.info/openldap-setup-howto/
Im connect from Jexplore to Openldap --> OK, I can open no-ip..vv, but I
open org --> error appear:
Im dont know check location..
Help me!
*************************************************
Nguyen Quang Huy
Add: Tang 4 - Trung Tâm Tin Hoc
So 8 Le Thai To - Hoan Kiem - Ha Noi
Mob: 0914-257-830
Tel: 04-9288858 ext 425
Fax: + 84 4 928 9213
Email: <mailto:quanghuy@vpb.com.vn> quanghuy(a)vpb.com.vn
LinQ: <mailto:kquanghuy@web.vpb.com.vn> quanghuy(a)web.vpb.com.vn
14 years, 6 months
Problem With postfix
by LITLE TUX
Hi peoples .... i'm tryng configure openldap with postfix but qhen try add
the below entry i receive next error:
gheorghe:~/difs # ldapadd -f base.ldif -x -D
cn=Administrator,dc=domain,dc=com-w 123456
adding new entry "relativeDomainName=@, ou=dns,dc=domain,dc=com"
ldap_add: Invalid syntax (21)
additional info: objectClass: value #0 invalid per syntax
My ldif file:
dn: relativeDomainName=@, ou=dns,dc=domain,dc=com
objectClass: dNSZone
relativeDomainName: @
zoneName: domain.com
dNSTTL: 3600
dNSClass: IN
sOARecord: ns3.domain.com. administrator.domain.com. 2001030201 3600 1800
604800 86400
nSRecord: ns3.domain.com.
mXRecord: 30 mail.domain.com.
My include schemas:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/samba3.schema
include /etc/openldap/schema/dnszone.schema
include /etc/openldap/schema/yast.schema
include /etc/openldap/schema/qmail.schema
include /etc/openldap/schema/postfix.schema
Any help is welcome...!!!!
Best Regards!
14 years, 6 months
Help: Slow LDAP search with high %iowait
by Victor
Hi ,
I did quite a bit reading and research before I send email to this list for help. If I have missed some basic concepts here, please execuse my ignorance. Thanks for your help and time in advance.
1. Summary
The initial search in my prototyping with OpenLDAP (slapd + BDB) seemed to be slow. What is the reason and How could I fix it?
2. Configuration
2.1 Environment
Linux CentOS, 1 hard disk (therefore unfortunately the BDB transaction logs and database files are written to the same disk), 120GB disk space (80% unused), 1GB RAM, reserved for this prototyping, OpenLDAP 2.3.39 with default BDB installation
2.2 slapd.conf (modified trivially for discussion purpose)
# global configuration
loglevel 0
# BDB
database bdb
suffix "dc=test,dc=dummy,dc=com"
rootdn "cn=Manager,dc=test,dc=dummy,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw secret
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /usr/local/var/openldap-data
#Other DB configuration
idlcachesize 60000
cachesize 20000
# Indices to maintain
# the indexes are to support search in first name, last name and email for both exact match and wild cards in the end
index objectClass eq
index gn pres,eq,sub
index sn pres,eq,sub
index mail pres,eq,sub
2.3 DB_CONFIG (for BDB)
set_cachesize 0 52428800 1
set_lg_bsize 2097512
set_flags DB_LOG_AUTOREMOVE
set_lg_regionmax 262144
2.4 Data setup
2 million records (users with gn, sn, email, mobile, street address, etc. in the BDB; all records are indexed using the index in the above slapd.conf; grouped by the first character of lastName. For example,
dn: ou=Z,dc=test,dc=dummy,dc=com
objectclass: organizationalUnit
ou: Z
Sample LDIF entry:
#Directory Entry
dn: uid=ABCDEFGHIJKLMNOPQRSTUVWXYZ123459,ou=F,dc=test,dc=dummy,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
uid: ABCDEFGHIJKLMNOPQRSTUVWXYZ123459
...... (details omitted)
3. Symptom/Problem
It was very slow in the first (fresh) search if I searched by wildcard firstname only like "Larry*" (which returned 478 entries/users). The response time was generally higher than 5 seconds Depending the count of records found, the response time might exceed 20 or even 50 seconds. During the search, the "iostat" result showed +95% %iowait, await was much higher that svctm, the device %util was over 96%. Here is the "iostat" output:
Time: 10:51:34 AM
avg-cpu: %user %nice %sys %iowait %idle
3.10 0.00 1.40 95.50 0.00
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
hda 0.00 2.90 64.94 65.33 1322.68 580.22 661.34 290.11 14.61 51.99 343.51 7.44 96.92
dm-0 0.00 0.00 64.94 72.53 1322.68 580.22 661.34 290.11 13.84 55.44 330.62 7.06 96.99
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
However, The subsequent search (using the exact search criteria) is much faster (within 200ms). I believe it is because of the cache.
I did a "db_stat -m" check and saw +90% cache hit rate (I guess it is normal?). The detailed output is in the attachment.
4. Questions
The "iostat" output showed obvious I/O bottleneck. Assuming I can't upgrade my hardware (for example, adding another disk specifically for writing transaction logs to), assuming I won't set a limit to the max number of entried returned, is there anything else I can do (typically BDB/slapd tuning or configuration) to make the fresh/first search much faster (say within 2 seconds for the worst case)? Did I do anything wrong? Please advise.
Thanks a lot!
Vic
14 years, 6 months
AW: Re: AW: Re: SASL bind with Kerberos: (was: Simple binds with SASL/GSSAPI (Resource temporarily unavailable))
by Hauke Coltzau
Hi Quanah,
thanks again for your answer.
> Did you make sure the GSSAPI module was installed with Cyrus-SASL? IIRC,
> it's a separate package under Ubuntu.
>
> p libgssapi2-heimdal
> - Heimdal Kerberos - GSSAPI support library
> p libsasl2-modules-gssapi-heimdal
> - Pluggable Authentication Modules for SASL (GSSAPI)
> p libsasl2-modules-gssapi-mit
> - Cyrus SASL - pluggable authentication modules (GSSAPI)
ii libsasl2-modules-gssapi-mit 2.1.22.dfsg1-18ubuntu2 \\
Cyrus SASL - pluggable authentication module
> > (b) saslauthd and SASL/GSSAPI are unrelated. I.e., you don't need to be
> > running saslauthd for SASL/GSSAPI to work.
> > Now I'm confused. I always understood the way to use
> > Kerberos authentication for accessing the ldap directory
> > to be:
> >
> > LDAP->SASL->Kerberos
> >
> > and that I have to fill the SASL part with something real,
> > like saslauthd. What did I miss here?
>
> SASL/GSSAPI uses the existing Kerberos ticket to auth a user to LDAP
>
> When using saslauthd, you do a simple bind to the LDAP server, which then
> connects to the KDC, gets a ticket, and auths the user.
>
> Two very different things. I.e., the first, the user already has authed to
> the KDC. In the second, they haven't.
I see the difference, but still have some questions:
- In the first approach, the user already has a TGT and asks the KDC for
a "ldap/fqdn@REALM-ticket"? This is done by ldapsearch, not by slapd? Hence, slapd
"only" needs access to its keytab to be able to decrypt the clients messages?
- And in the second one, the user provides username and password (plain), slapd converts
the username into a principle (user@REALM) and forwards this to saslauthd? So this should be
secured via TLS?
I'm just looking for a setup that restricts access to LDAP to authenticated users (except,
of course, information neccessary for authentication purposes). I need to use Kerberos
for authentication, because I want to use NFSv4.
There used to be a well-known howto for all this at http://www.bayour.com/LDAPv3-HOWTO.html
but the site is offline for some days now.
Thanks again for your help,
Hauke
--
14 years, 6 months
AW: Re: SASL bind with Kerberos: (was: Simple binds with SASL/GSSAPI (Resource temporarily unavailable))
by Hauke Coltzau
Hi Quanah,
thank you for your immediate reply.
(a) Which Kerberos implementation are you using?
MIT Kerberos 5 as shipped with Hardy (1.6.dfsg.3~beta1-2ubuntu1)
(b) saslauthd and SASL/GSSAPI are unrelated. I.e., you don't need to be
running saslauthd for SASL/GSSAPI to work.
Now I'm confused. I always understood the way to use
Kerberos authentication for accessing the ldap directory
to be:
LDAP->SASL->Kerberos
and that I have to fill the SASL part with something real,
like saslauthd. What did I miss here?
Thanks again,
Hauke
p.s.: ZCS fan here ;-)
--
14 years, 6 months
Simple binds with SASL/GSSAPI (Resource temporarily unavailable)
by Hauke Coltzau
Hi all,
I have a problem to make simple binds with authentication done by kerberos5.
I use OpenLDAP to store all user account information and have
everything set up so far that users can login:
$ su - testuser
Password:
$ klist
Ticket cache: FILE:/tmp/krb5cc_2000_yukVIJ
Default principal: testuser@REALM
Valid starting Expires Service principal
09/08/08 16:54:16 09/09/08 02:54:16 krbtgt/REALM@REALM
renew until 09/09/08 16:54:16
Kerberos 4 ticket cache: /tmp/tkt2000
klist: You have no tickets cached
$ id
uid=2000(testuser) gid=2000(dusers) groups=2000(dusers)
uid, gid,etc. have been successfully taken from the
LDAP directory.
But then, ldapsearch fails:
$ ldapsearch
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
$
Details:
========
Currently, the KDC and the LDAP-Server reside on the same host,
running Ubuntu 8.04 x64_64.
I made sure that principals exist for
<fqdn>@REALM
ldap/<fqdn>@REALM
host/<fqdn>@REALM
and exported them to /etc/krb5.keytab as well as
/etc/ldap/ldap.keytab, which is now owned by the openldap user.
# ktutil
ktutil: rkt /etc/krb5.keytab
ktutil: l
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
1 6 ldap/<fqdn>@REALM
2 6 ldap/<fqdn>@REALM
3 4 host/<fqdn>@REALM
4 4 host/<fqdn>@REALM
5 4 <fqdn>@REALM
6 4 <fqdn>@REALM
ktutil:
ktutil: clear
ktutil: rkt /etc/ldap/ldap.keytab
ktutil: l
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
1 6 ldap/<fqdn>@REALM
2 6 ldap/<fqdn>@REALM
3 4 host/<fqdn>@REALM
4 4 host/<fqdn>@REALM
5 4 <fqdn>@REALM
6 4 <fqdn>@REALM
# ll /etc/ldap/ldap.keytab
-rw------- 1 openldap openldap 512 2008-09-08 15:23 /etc/ldap/ldap.keytab
(Even tried 666, but that didn't change anything. If I move this file, slapd
complains, so I'm pretty sure it's actually been used)
Next, I set
START=yes
and
MECHANISMS="kerberos5"
in /etc/default/saslauthd, started saslauthd and tested:
# testsaslauthd -u testuser -p <secret>
0: OK "Success."
As recommended, I used sasl-sample-server and /-client to test the configuration
SASSL/GSSAPI <-> Kerberos:
# sasl-sample-client -s ldap -m GSSAPI -n <fqdn> (partial output)
service=ldap
Waiting for mechanism list from server...
Forcing use of mechanism GSSAPI
Choosing best mechanism from: GSSAPI
Using mechanism GSSAPI
Preparing initial.
Sending initial response...
C: ....
...
Username: testuser@REALM
SSF: 56
Waiting for encoded message...
recieved decoded message 'srv message 1'
sending encrypted message 'client message 1'
On the sample-server side, it's the same, 'client message 1' was successfully decoded.
Next thing I did was to add following lines to /etc/ldap/slapd.conf
sasl-secprops noplain,noactive,noanonymous
sasl-regexp uid=(.*),cn=<domain>,cn=gssapi,cn=auth ldap:///dc=...??sub?uid=$1
sasl-regexp uid=(.*),cn=<domain>,cn=gssapi,cn=auth uid=$1,dc=...
and created /usr/lib/sasl2/slapd.conf
mech_list: gssapi digest-md5 cram-md5 external
pwcheck_method: saslauthd
saslauthd_path: /var/run/saslauthd/mux
keytab: /etc/ldap/ldap.keytab
Then I chgrouped /var/run/saslauthd to openldap and gave g=rwx permissions to the
directory:
# ls -al /var/run/saslauthd/
total 0
drwxrwxr-x 2 root openldap 100 2008-09-08 16:36 .
drwxr-xr-x 15 root root 580 2008-09-08 12:13 ..
srwxrwxrwx 1 root root 0 2008-09-08 16:36 mux
-rw------- 1 root root 0 2008-09-08 16:36 mux.accept
-rw------- 1 root root 0 2008-09-08 16:36 saslauthd.pid.lock
But now, when trying ldapsearch on the same machine, it fails:
$ klist
Ticket cache: FILE:/tmp/krb5cc_2000_tA7220
Default principal: testuser@REALM
Valid starting Expires Service principal
09/08/08 16:33:05 09/09/08 02:33:05 krbtgt/REALM@REALM
renew until 09/09/08 16:33:05
09/08/08 16:33:46 09/09/08 02:33:05 ldap/<fqdn>@REALM
renew until 09/09/08 16:33:05
Kerberos 4 ticket cache: /tmp/tkt2000
klist: You have no tickets cached
$ ldapsearch
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
$
And on the server side:
# echo $KRB5_KTNAME
/etc/ldap/ldap.keytab
# slapd -d127 -h "ldap:///" -u openldap -g openldap
...
>>> dnPrettyNormal: <>
<<< dnPrettyNormal: <>, <>
do_bind: dn () SASL mech GSSAPI
==> sasl_bind: dn="" mech=GSSAPI datalen=583
SASL [conn=0] Failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Resource temporarily unavailable)
send_ldap_result: conn=0 op=1 p=3
send_ldap_result: err=80 matched="" text="SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Resource temporarily unavailable)"
send_ldap_response: msgid=2 tag=97 err=80
ber_flush2: 158 bytes to sd 13
...
and saslauthd is not contacted at all:
# saslauthd -d -a kerberos5
saslauthd[7243] :main : num_procs : 5
saslauthd[7243] :main : mech_option: NULL
saslauthd[7243] :main : run_path : /var/run/saslauthd
saslauthd[7243] :main : auth_mech : kerberos5
saslauthd[7243] :ipc_init : using accept lock file: /var/run/saslauthd/mux.accept
saslauthd[7243] :detach_tty : master pid is: 0
saslauthd[7243] :ipc_init : listening on socket: /var/run/saslauthd/mux
saslauthd[7243] :main : using process model
saslauthd[7244] :get_accept_lock : acquired accept lock
saslauthd[7243] :have_baby : forked child: 7244
saslauthd[7243] :have_baby : forked child: 7245
saslauthd[7243] :have_baby : forked child: 7246
saslauthd[7243] :have_baby : forked child: 7247
<no more output>
What did I do wrong this time ;-) ?
Best regards,
Hauke
--
14 years, 6 months
ldapadd of LDIF files with attribute 'apple-generateduid' not allowed [Resolved]
by Alexander Hartner
At it turns out the problem was with the objectClasses.
I should have used :
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: extensibleObject
Instead of
objectClass: top
objectClass: person
objectClass: inetOrgPerson
Adding the extra attributes to the objectClass resolved this problem.
Thanks for all your help.
Regards
Alex
On 21 Feb 2008, at 11:56, Alexander Hartner wrote:
> I am trying to import a simple LDIF file into OpenDirectory on OS X
> 10.5.2 Leopard Server.
>
> However when I issue the following ldapadd command I get an error :
>
> ldapadd -D [rootdn] -x -w [secretPassword] -f Import.ldif
>
> Error : 65 Object class violation"
> attribute 'apple-generateduid' not allowed
>
>
> I would have thought that I had specified apple-generateduid, but I
> didn't.
>
> This is my import file
> -----------BEGIN-----------
> # Alexander Hartner
> dn: cn=Alexander Hartner2,cn=people,dc=macbook-znet,dc=local
> objectClass: top
> objectClass: person
> objectClass: inetOrgPerson
> displayName: Alexander Hartner2
> cn: Alexander Hartner2
> givenName: Alexander
> sn: Hartner
> mail: alex(a)j2anywhere.com
> initials: A
> o: j2anywhere.com
> -----------END-----------
>
> I know this might not be the best forum for OS X support, but I am a
> bit stuck on this.
> Thanks in advance.
> Alex
>
>
>
14 years, 6 months
Re: RHEL 5 will not do TLS/SSL authentication
by Dat Duong
Does anyone have the answer to my problem?
thanks
----- Original Message ----
From: Dat Duong <datduong2000(a)yahoo.com>
To: Buchan Milne <bgmilne(a)staff.telkomsa.net>
Cc: openldap-technical(a)openldap.org
Sent: Wednesday, September 3, 2008 7:45:45 AM
Subject: Re: RHEL 5 will not do TLS/SSL authentication
The slapd.conf is on Solaris 10 machine. This is how I compiled from the source for Openssl and Openldap.
#cd openssl.0.98h
# ./config
shared
# make clean
# make
# make install
# cd openldap-2.4.11
# env
LD_LIBRARY_PATH="/usr/lib:/usr/local/lib:/usr/local/BerkeleyDB.4.2/lib:/usr/local/ssl/lib"
LDFLAGS="-L/usr/local/lib -L/usr/local/BerkeleyDB.4.2/lib
-L/usr/local/ssl/lib -R/usr/local/lib -R/usr/local/BerkeleyDB.4.2/lib
-R/usr/local/ssl/lib"
CPPFLAGS="-I/usr/local/include -I/usr/local/BerkeleyDB.4.2/include
-I/usr/local/ssl/include" ./configure --enable-bdb --enable-crypt
--with-tls --without-cyrus-sasl
# make depend
# make clean
----- Original Message ----
From: Buchan Milne <bgmilne(a)staff.telkomsa.net>
To: Dat Duong <datduong2000(a)yahoo.com>
Cc: openldap-technical(a)openldap.org
Sent: Wednesday, September 3, 2008 5:17:14 AM
Subject: Re: RHEL 5 will not do TLS/SSL authentication
On Wednesday 03 September 2008 09:49:54 Dat Duong wrote:
> I'm thinking, if the gnutls which installed by default, was causing the
> problem??
It doesn't matter if gnutls is installed, what matters is what OpenLDAP was
compiled against.
Now, you stated that you are using RHEL 5, and gave no other details of what
software you installed, so it would be logical to assume you are using only
the RHEL 5 packages. On RHEL 5, OpenLDAP 2.3.27 is compiled against openssl
0.9.8b. But, since you have some weird paths reflected in your slapd.conf
etc., maybe you have built your own software. If you have, you need to supply
the details thereof, or we are all wasting our time.
Regards,
Buchan
14 years, 6 months
Re: Help needed to set up N-way multimaster replication
by piyush joshi
I have added serverid 1 to first server and serverid 2 to secondserver and
rid=001 with syncrepl on both the server also added mirrormode true on both
node but now when i make changes to one server that is not reflected to
another one while before adding mirrormode true whenever i was trying to
make changes in dir it gives me error [ Sep 4 10:18:39 mail slapd[20141]:
conn=5 op=1 RESULT tag=103 err=53 text=shadow context; no update referral ]
So now no idea where I am wrong. Please help me ...
On Wed, Sep 3, 2008 at 6:25 PM, Miguel Jinez <miguel.jinez(a)gmail.com> wrote:
> Hello, maybe try with a mirrormode line, look the comments in red
>
> Migue
>
> 2008/9/3 piyush joshi <joy.piyush(a)gmail.com>
>
>
>> *Dear All,*
>> *I am using openldap-2.4.11 version and trying to use
>> N-way multimaster replication so that changes made to first server reflects
>> to second and* *vice versa but with my current set up if i use syncprov
>> overlay and syncrepl on both server then it doesn't allow me to make changes
>> in any ldap server but if i configure syncprov overlay on one server and
>> configure syncrepl on another server it allow me to make changes and as well
>> reflect the changes to another however still i can't make changes to second
>> ldap server my both server configuration is as follows. please let me know
>> what is wrong with this configuration or what all changes to be made
>> to running it.*
>>
>> Configuration on First LDAP Server
>>
>> allow bind_v2
>> include /usr/local/openldap/etc/openldap/schema/core.schema
>> include /usr/local/openldap/etc/openldap/schema/corba.schema
>> include /usr/local/openldap/etc/openldap/schema/cosine.schema
>> include /usr/local/openldap/etc/openldap/schema/nis.schema
>> include
>> /usr/local/openldap/etc/openldap/schema/inetorgperson.schema
>> pidfile /usr/local/openldap/var/run/slapd.pid
>> argsfile /usr/local/openldap/var/run/slapd.args
>> modulepath /usr/local/openldap/libexec/openldap
>> moduleload syncprov
>> password-hash {SSHA}
>> database hdb
>> suffix "dc=***,dc=com"
>> rootdn "cn=root,dc=***,dc=com"
>> rootpw {SSHA}yZkqhHmELfmUTsaQyfxgXBqq95gugTA4
>> directory /usr/local/openldap/var/openldap-data
>> index uid pres,eq
>> index cn,sn pres,eq,approx,sub
>> index objectClass eq
>> index entryCSN,entryUUID eq
>> syncrepl rid=001
>> provider=ldap://192.168.1.12
>> type=refreshAndPersist
>> retry="5 5 300 +"
>> searchbase="dc=***,dc=com"
>> attrs=*
>> binddn="cn=root,dc=***,dc=com"
>> credentials=secret
>>
> mirrormode true
>
>
>> overlay syncprov
>> syncprov-checkpoint 50 10
>> database monitor
>> loglevel 256
>>
>>
>> Configuration on Second LDAP Server
>>
>> allow bind_v2
>> include /usr/local/openldap/etc/openldap/schema/core.schema
>> include /usr/local/openldap/etc/openldap/schema/corba.schema
>> include /usr/local/openldap/etc/openldap/schema/cosine.schema
>> include /usr/local/openldap/etc/openldap/schema/nis.schema
>> include
>> /usr/local/openldap/etc/openldap/schema/inetorgperson.schema
>> pidfile /usr/local/openldap/var/run/slapd.pid
>> argsfile /usr/local/openldap/var/run/slapd.args
>>
>> modulepath /usr/local/openldap/libexec/openldap
>> moduleload syncprov
>> password-hash {SSHA}
>>
>> database hdb
>> suffix "dc=***,dc=com"
>> rootdn "cn=root,dc=***,dc=com"
>> rootpw {SSHA}9nbNE9l1rTvPCoU95zgo6vVoL3nMRzMI
>> directory /usr/local/openldap/var/openldap-data
>> index uid pres,eq
>> index cn,sn pres,eq,approx,sub
>> index objectClass eq
>> index entryCSN,entryUUID eq
>> syncrepl rid=001
>> provider=ldap://192.168.1.8
>> type=refreshAndPersist
>> retry="5 5 300 +"
>> searchbase="dc=***,dc=com"
>> attrs=*
>> binddn="cn=root,dc=***,dc=com"
>> credentials=secret
>> mirrormode true
>>
>
>
>> overlay syncprov
>> syncprov-checkpoint 50 10
>> database monitor
>> loglevel 256
>>
>>
>> Thanks Regards
>>
>> Piyush Joshi
>> 9415414376
>>
>>
>>
>>
>>
>>
>
>
--
Regards
Piyush Joshi
9415414376
14 years, 6 months
