No such object
by Richard smith
I'm trying to add the following to a new database.
I assume this is therefore an empty database.
I keep getting the error:
ldap_sasl_interactive_bind_s: No such object (32)
Thanks
[dir ~]#
[dir ~]# cat ldap_test_add_file
dn: dc=mydomainname,dc=name,dc=example,dc=com
dc: mydomainname
objectClass: top
objectClass: domain
[dir ~]#
[dir ~]#
[dir ~]#
[dir ~]# /usr/bin/ldapadd -ZZ -H "ldap://mydomainname.name.example.com" \
-D "uid=root,dc=mydomainname,dc=name,dc=example,dc=com" \
-W -f ldap_test_add_file
Enter LDAP Password: CORRECT pw given
ldap_sasl_interactive_bind_s: No such object (32)
[dir ~]#
[dir ~]#
from /etc/openldap/ldap.conf
URI ldap://xxx.xxx.xxx.xxx/
BASE dc=mydomainname,dc=name,dc=example,dc=com
from /etc/openldap/slapd.conf
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
security ssf=1 update_ssf=112 simple_bind=64
access to attrs=userpassword
by self=xw
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
database bdb
suffix "dc=mydomainname,dc=name,dc=example,dc=com"
rootdn "uid=root,dc=mydomainname,dc=name,dc=example,dc=com"
rootpw {SSHA}--------------------------------
directory /var/lib/ldap
# Indices to maintain for this database
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
---------------------------------
Yahoo! oneSearch: Finally, mobile search that gives answers, not web links.
15 years, 11 months
RE: upgrade from 2.2 to 2.3, LDIF file difference...
by Dan Denton
Thanks to all who replied. Evidently the order in which you include the
schemas makes a difference. After putting them in this order, it worked...
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
-----Original Message-----
From: CHANG Shuh [mailto:shuh.chang@gemalto.com]
Sent: Friday, October 05, 2007 3:08 PM
To: Dan Denton
Subject: RE: upgrade from 2.2 to 2.3, LDIF file difference...
Try some hints discussed from this link:
http://www.openldap.org/its/index.cgi/Software%20Bugs?id=4025
Best Regards,
Shuh Chang
Senior Systems Architect
Security, Network Identity
Gemalto
Tel: +1 512-257-3859
Fax: +1 512-257-3904
9442 Capital of Texas Highway North
Arboretum Plaza II, Suite 400
Austin, Texas 78759
shuh.chang(a)gemalto.com
www.gemalto.com
> -----Original Message-----
> From:
> openldap-software-bounces+schang=axalto.com(a)OpenLDAP.org
> [mailto:openldap-software-bounces+schang=axalto.com@OpenLDAP.o
> rg] On Behalf Of Dan Denton
> Sent: Friday, October 05, 2007 1:28 PM
> To: openldap-software(a)openldap.org
> Subject: upgrade from 2.2 to 2.3, LDIF file difference...
>
> Hello list,
>
> I've moved from a 2.2 installation to a 2.3.38 installation,
> and am having a problem loading one of my old LDIF files. The
> user in question was the only one I attempted to use the
> inetOrgPerson object class on, and the program seems to have
> a problem with it. When I attempt to import it, I get:
>
> modifying entry "cn=jjohnson,ou=users,dc=remitpro,dc=local"
> ldap_modify: Invalid syntax (21)
> additional info: objectclass: value #1 invalid per syntax
>
> In the FAQ-o-matic, there's mention of this issue and the OP
> was directed to a link pointing out what can cause it. For reference:
>
> http://www.openldap.org/faq/data/cache/648.html
>
> There's no whitespace at the end of each line, there's no
> empty attributes, and I've eliminated any characters that I
> thought might pose an issue. Any help is greatly appreciated.
>
> Here's the LDIF file:
>
> dn: cn=jjohnson,ou=users,dc=remitpro,dc=local
> objectclass: person
> objectclass: inetOrgPerson
> objectClass: posixAccount
> cn: jjohnson
> cn: Jim Johnson
> sn: Johnson
> uid: jjohnson
> userPassword: secret
> uidNumber: 513
> gidNumber: 513
> title: Lackey
> telephoneNumber: 4028610005
> mail: ddenton(a)remitpro.com
> gn: Jim
> displayName: Jim Johnson
> initials: JJ
> o: RemitPro Inc
> ou: users
> postalAddress: 3925 S 147th St
> postalCode: 68138
> l: Omaha
> st: NE
>
> Thanks in advance...
>
> P.S. - I've also tried using the syntax available at the
> following link, with no luck.
>
> http://ldap.akbkhome.com/index.php/objectclass/inetOrgPerson.html
>
>
15 years, 11 months
upgrade from 2.2 to 2.3, LDIF file difference...
by Dan Denton
Hello list,
I've moved from a 2.2 installation to a 2.3.38 installation, and am having a
problem loading one of my old LDIF files. The user in question was the only
one I attempted to use the inetOrgPerson object class on, and the program
seems to have a problem with it. When I attempt to import it, I get:
modifying entry "cn=jjohnson,ou=users,dc=remitpro,dc=local"
ldap_modify: Invalid syntax (21)
additional info: objectclass: value #1 invalid per syntax
In the FAQ-o-matic, there's mention of this issue and the OP was directed to
a link pointing out what can cause it. For reference:
http://www.openldap.org/faq/data/cache/648.html
There's no whitespace at the end of each line, there's no empty attributes,
and I've eliminated any characters that I thought might pose an issue. Any
help is greatly appreciated.
Here's the LDIF file:
dn: cn=jjohnson,ou=users,dc=remitpro,dc=local
objectclass: person
objectclass: inetOrgPerson
objectClass: posixAccount
cn: jjohnson
cn: Jim Johnson
sn: Johnson
uid: jjohnson
userPassword: secret
uidNumber: 513
gidNumber: 513
title: Lackey
telephoneNumber: 4028610005
mail: ddenton(a)remitpro.com
gn: Jim
displayName: Jim Johnson
initials: JJ
o: RemitPro Inc
ou: users
postalAddress: 3925 S 147th St
postalCode: 68138
l: Omaha
st: NE
Thanks in advance...
P.S. - I've also tried using the syntax available at the following link,
with no luck.
http://ldap.akbkhome.com/index.php/objectclass/inetOrgPerson.html
15 years, 11 months
ldappasswd question...
by Dan Denton
Hello list,
I've been halfway successful so far in setting up an ldap server, but have
run into issues when setting passwords using ldappasswd. The server is RHEL
4, running openldap-2.2.13-7.4E (server and clients) provided by RedHat.
I've successfully gotten the server listening, and have added entries to the
database, and can even access it from my outlook installation (browsing of
course).
When I run the following command on my ldap server, I get the following
output:
[root@TESTBED002 sbin]# ldappasswd -WS -D
'cn=root,ou=users,dc=remitpro,dc=local' jdoe -d 300
New password:
Re-enter new password:
Enter LDAP Password:
request 1 done
SASL/DIGEST-MD5 authentication started
request 2 done
Please enter your password:
request 3 done
ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80)
additional info: SASL(-13): user not found: no secret in database
The first two prompts seem pretty straightforward, in that it seems to be
asking for the user's new password. The second and third have me stumped. Is
the second password (LDAP Password) the bind password for the root user? If
so, by entering that, the result is being sent straight to the final error
message. If I hit enter (blank) at that prompt, I'm sent to the 'MD5'
prompt, and which point anything I enter gets me the final error message.
I know this is probably something obvious I'm missing, and I'm sure it's a
nube issue, but a day of banging my head against the wall (and searching
google, and the list archives) hasn't given me an answer I can use, or make
sense of.
Thanks in advance...
Danno
P.S. - here's what I think is the relevant part of my conf file, and a
listing from slapcat.
database bdb
suffix "dc=remitpro,dc=local"
rootdn "cn=root,dc=remitpro,dc=local"
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw secret
#rootpw {MD5}OT6nyd+82+aATLn5z2BfwQ==
dn: dc=remitpro,dc=local
objectClass: dcObject
objectClass: organization
o: Test Company
dc: remitpro
structuralObjectClass: organization
entryUUID: a4a2b22a-070d-102c-9eb8-90018c9f14f8
creatorsName: cn=root,dc=remitpro,dc=local
createTimestamp: 20071004213642Z
entryCSN: 20071004213642Z#000001#00#000000
modifiersName: cn=root,dc=remitpro,dc=local
modifyTimestamp: 20071004213642Z
dn: cn=root,dc=remitpro,dc=local
objectClass: organizationalRole
cn: root
structuralObjectClass: organizationalRole
entryUUID: a4ab3d28-070d-102c-9eb9-90018c9f14f8
creatorsName: cn=root,dc=remitpro,dc=local
createTimestamp: 20071004213642Z
entryCSN: 20071004213642Z#000002#00#000000
modifiersName: cn=root,dc=remitpro,dc=local
modifyTimestamp: 20071004213642Z
dn: ou=users,dc=remitpro,dc=local
objectClass: organizationalUnit
ou: users
structuralObjectClass: organizationalUnit
entryUUID: c8b22af6-070d-102c-9eba-90018c9f14f8
creatorsName: cn=root,dc=remitpro,dc=local
createTimestamp: 20071004213743Z
entryCSN: 20071004213743Z#000001#00#000000
modifiersName: cn=root,dc=remitpro,dc=local
modifyTimestamp: 20071004213743Z
dn: cn=jdoe,ou=users,dc=remitpro,dc=local
structuralObjectClass: organizationalPerson
entryUUID: b40f9524-070e-102c-9ebd-90018c9f14f8
creatorsName: cn=root,dc=remitpro,dc=local
createTimestamp: 20071004214418Z
objectClass: organizationalPerson
cn: jdoe
sn: Doe
userPassword:: c2VjcmV0
entryCSN: 20071004215535Z#000001#00#000000
modifiersName: cn=root,dc=remitpro,dc=local
modifyTimestamp: 20071004215535Z
dn: cn=bsmith,ou=users,dc=remitpro,dc=local
structuralObjectClass: organizationalPerson
entryUUID: fa14e16e-070e-102c-9ebe-90018c9f14f8
creatorsName: cn=root,dc=remitpro,dc=local
createTimestamp: 20071004214615Z
objectClass: person
objectClass: organizationalPerson
cn: bsmith
cn: Bob Smith
sn: Smith
userPassword:: c2VjcmV0
title: Lackey
telephoneNumber: 4028610005
entryCSN: 20071005144910Z#000001#00#000000
modifiersName: cn=root,dc=remitpro,dc=local
modifyTimestamp: 20071005144910Z
dn: cn=jjohnson,ou=users,dc=remitpro,dc=local
structuralObjectClass: inetOrgPerson
entryUUID: 6173c7e6-079e-102c-9ec4-90018c9f14f8
creatorsName: cn=root,dc=remitpro,dc=local
createTimestamp: 20071005145247Z
objectClass: person
objectClass: inetOrgPerson
objectClass: posixAccount
cn: jjohnson
cn: Jim Johnson
sn: Johnson
uid: jjohnson
userPassword:: c2VjcmV0
uidNumber: 513
gidNumber: 513
title: Lackey
mail: ddenton(a)remitpro.com
givenName: Jim
displayName: Jim Johnson
initials: JJ
roomNumber: IT
physicalDeliveryOfficeName: IT
homeDirectory: /home/jjohnson
entryCSN: 20071005151734Z#000001#00#000000
modifiersName: cn=root,dc=remitpro,dc=local
modifyTimestamp: 20071005151734Z
15 years, 11 months
Re: Index Generation Failed error
by Suhel Momin
On 10/4/07, Howard Chu <hyc(a)symas.com> wrote:
>
> Pierangelo Masarati wrote:
> > Suhel Momin wrote:
> >> I have made changes to keep log in memory using DB_LOG_INMEMORY flag.
> >> The log size is kept 10MB.
> >> Now when I try to add 64K entries, 65526 entries get added but 65527th
>
> >> entry always fails.
> >> The error I get is "Index Generation Failed".
> >> I tried to debug the issue and found that the cursor->c_del function
> in
> >> bdb_idl_insert_key fails returning an error code as
> DB_LOG_BUFFER_FULL.
> >>
> >> Am I missing something or is this a known problem?
> >> Do I need to do anything more while keeping logs in memory?
> >
> > Have you read Berkeley documentation about DB_LOG_INMEMORY? This is the
>
> > expected result of creating an in-memory buffer smaller than the size of
> > the largest transaction you want to create. Either use a larger buffer,
> > or write smaller chunks. And read the docs
> > <
> http://www.oracle.com/technology/documentation/berkeley-db/db/articles/in...
> >.
>
> In this case they cannot write smaller chunks, it's purely a function of
> how
> we generate indexes. When an index slot gets to about 65536 elements we
> delete
> that list and replace it with a 3-element range. This delete operation
> consumes a great deal of log space.
>
> The solution of course is to use a larger buffer.
>
I tried to make the value of BDB_IDL_LOGN to be 20 instead of 16. This
changes the value of
BDB_IDL_DB_MAX. It looks like this change has solved my problem of "index
generation failed" while keeping logs in memory.
Is this the right way to go about or should I still go with increasing the
buffer size for logs??
Regards,
Suhel
15 years, 11 months
Index Generation Failed error
by Suhel Momin
I have made changes to keep log in memory using DB_LOG_INMEMORY flag.
The log size is kept 10MB.
Now when I try to add 64K entries, 65526 entries get added but 65527th
entry always fails.
The error I get is "Index Generation Failed".
I tried to debug the issue and found that the cursor->c_del function in
bdb_idl_insert_key fails returning an error code as DB_LOG_BUFFER_FULL.
Am I missing something or is this a known problem?
Do I need to do anything more while keeping logs in memory?
Regards,
Suhel
15 years, 12 months
Re: test001-slapadd fail, please help !
by Le Trung Kien
Thank you all,
It's now ok !
The things I did as follow (certainly gained from your suggests):
- Overwrite subdiretories of /usr/local/ directory by corresponsive
subdirectories of /usr/local/BerkeleyDB.4.5/
- export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
- ./configure [options]
Now "make test" is in progress, and it passed test001-slapadd.
Again, thank you all for helping me in solving this problem.
Regards.
--
Le Trung Kien.
15 years, 12 months
test001-slapadd fail, please help !
by Le Trung Kien
Hi, I tried out some solutions at
http://www.openldap.org/faq/data/cache/345.html
but I still don't solve the make test fail : test001-slapadd
>>>>> Starting test001-slapadd ...
running defines.sh
Running slapadd to build slapd database...
Starting slapd on TCP/IP port 9011...
Using ldapsearch to retrieve all the entries...
./scripts/test001-slapadd: line 51: 2410 Segmentation fault $SLAPD -f
$CONF1 -h $URI1 -d $LVL $TIMING >$LOG1 2>&1
Waiting 5 seconds for slapd to start...
Waiting 5 seconds for slapd to start...
Waiting 5 seconds for slapd to start...
Waiting 5 seconds for slapd to start...
Waiting 5 seconds for slapd to start...
Waiting 5 seconds for slapd to start...
./scripts/test001-slapadd: line 53: kill: (2410) - No such process
ldapsearch failed (1)!
>>>>> ./scripts/test001-slapadd failed (exit 1)
I guess it comes from the incorrect install of BerkerleyDB, I have installed
two version of BerkerleyDB: 4.5 and 4.6 and they locate at
/usr/local/BerkerleyDB.4.5 and /usr/local/BerkerleyDB.4.6
After "make install" them, then configure OpenLDAP I receive compliant about
missing "db.h" file, then I copy subdirectories in
/usr/local/BerkerleyDB.4.6 to corresponsive subdirectories in /usr/local.
Then I have finished "make" OpenLDAP susscessful however "make test" failed.
Could you tell me how you install BerkerleyDB to work with Openldap ?
or tell me if my test failure came from the difference problems.
Help me, please.
Thank you.
--
Le Trung Kien.
15 years, 12 months
1.3.6.1.4.1.42.2.27.9.5.8 (Account Usability Control) supported?
by Alexander Skwar
Hello.
I'd like to know if the "Account Usability Control"
(oid=1.3.6.1.4.1.42.2.27.9.5.8) is supported by OpenLDAP.
I ran:
--($:~)-- ldapsearch -h winds06 -p 389 -b '' -s base '(objectClass=*)' supportedControl
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectClass=*)
# requesting: supportedControl
#
#
dn:
supportedControl: 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 1.3.6.1.4.1.4203.1.10.1
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.2.826.0.1.334810.2.3
supportedControl: 1.2.826.0.1.3344810.2.3
supportedControl: 1.3.6.1.1.13.2
supportedControl: 1.3.6.1.1.13.1
supportedControl: 1.3.6.1.1.12
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
According to this, the required control isn't listed. Is
this just because of a misconfiguration of my OpenLDAP
2.3.35 server? Some other server implements that, but I'd
rather like to use OpenLDAP instead of this other server,
as OpenLDAP is available for more platforms.
One source of information I found is at
http://www.willeke.com:9080/wikildap/Wiki.jsp?page=DefinitionAccountUsabi...
Because of the non-standard port of this server, I'm copying
the information:
The account usability control provides a pair of
request and response controls that can be used to
determine whether a user account may be used for
authenticating to the server.
The request control has an OID of 1.3.6.1.4.1.42.2.27.9.5.8
and does not include a value. It should only be
included in search request messages.
The corresponding response control has an OID of
1.3.6.1.4.1.42.2.27.9.5.8 (the same as the request
control), and it will be included in any search
result entry messages for a search request that
includes the account usability request control.
The value for the account usability response control
will be encoded as follows:
ACCOUNT_USABLE_RESPONSE ::= CHOICE {
is_available [0] INTEGER, -- Seconds before expiration --
is_not_available [1] MORE_INFO }
MORE_INFO ::= SEQUENCE {
inactive [0] BOOLEAN DEFAULT FALSE,
reset [1] BOOLEAN DEFAULT FALSE,
expired [2] BOOLEAN DEFAULT_FALSE,
remaining_grace [3] INTEGER OPTIONAL,
seconds_before_unlock [4] INTEGER OPTIONAL }
If the user account is available, then the control
will include the number of seconds until the user's
password expires, or -1 if password expiration is
not enabled. If the user's account is not available,
then the control will provide the reason it is
unavailable.
This control is required to get password less logins to work.
Thanks a lot,
Alexander
15 years, 12 months
Question about attribute name
by Rana Biswas
Hi,
When I add an attribute named "cm.host" in my OpenLDAP schema, I
get an invalid name error.
The attribute I added is:
attributeType ( 2.5.4.2.2 NAME 'cm.host'
DESC 'host name'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
I am getting the following error: Invalid NAME: "cm.host"
Does this mean attribute in OpenLDAP schema cannot have dot in attribute name
or I am doing something wrong.
Is there any way around, I cannot change the schema and our
application depend on this data.
Thanks in advance.
Regards,
Rana Biswas
15 years, 12 months
