[Date Prev][Date Next]
RE: ldapd vs. slapd
--On Wednesday, April 18, 2012 08:57:20 AM -0700 "Richards, Toby" <firstname.lastname@example.org> wrote:
Yes. I have one of those free subdomains (org.org), so mine is toby.org.org.
Something is definitely wrong. I've been scouring the Internet for
documentation and tutorials. I finally broke down, and downloaded a GUI LDAP
tool. Actually, I've tried several including jxplorer and LDAP
Administration Tool, but I like the one by Jarek Gawor best:
Anyway, the GUI isn't even working. It gives me errors that it can't read
dc=toby,dc=org,dc=org. It errors and fails when I try to add a user. I'm not
sure what could be wrong with my conf files. They're pretty much set up with
all the defaults except with my own realm instead of dc=example,dc=com.
Am I supposed to do something between editing the conf files/starting slapd
and adding users?
What do you get when you try a base dn search, i.e.
% ldapsearch -h your-host -x -b '' -s base +
From: Bill MacAllister [mailto:email@example.com]
Sent: Wednesday, April 18, 2012 8:52 AM
To: Richards, Toby; Brandon Hume; firstname.lastname@example.org
Subject: RE: ldapd vs. slapd
--On Wednesday, April 18, 2012 08:19:29 AM -0700 "Richards, Toby"
So I've followed the suggestion to have only the objectClass
Now I'm told that there's no such object. My LDIF file:
Did you really mean to have dc=org twice?
cn: Toby Richards
Result: ldap_add: No such object (32)
[mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Brandon
Sent: Tuesday, April 17, 2012 9:16 AM
Subject: Re: ldapd vs. slapd
On 04/17/12 12:47 PM, Richards, Toby wrote:
The above doesn't work. It says that top/account isn't a valid chain.
What happens if you leave out "account"? It's a structural
objectclass and is likely conflicting with inetOrgPerson.
If you check cosine.schema, you'll see the objectclass "account" as
being meant for a computer account. You're essentially adding an
entry that says it's for a person *and* a computer. (A cyborg,
maybe?) LDAP wants clear lines of inheritance.
Infrastructure Delivery Group, Stanford University