Hi all,  Thank you very much for all that have help, both on list and off the list. Seems a good reading on what each class offer would do me good. The uid attribute is included in the inetOrgPerson. The moment I added that class to my root dn, the error seized and things have been cool so far. See below:

<br>dn: cn=admin,ou=people,dc=afsat,dc=com<br>uid: sysadmin<br>cn: admin<br>sn: LDAP administrator<br>userPassword:: YWRtaW4=<br>objectClass: person<br>objectClass: inetOrgPerson<br><br> If someone around here can explain from the top of their head the necessity of these two database, sasldb and kdb, the former for DIGEST-MD5 and the later for gssapi, I would be very grateful.  I assume all the authentication data are held

by ldap back end, bdb for fedora default install, so what the two database do is beyond my grasp at the moment.<br><br>Thanks a lot<br>William<br><div><span class="gmail_quote">On 17 Jan 2007 12:38:32 -0500, <b class="gmail_sendername">

Tim Writer</b> <<a href="mailto:tim-s/rLXaiAEBtBDgjK7y7TUQ@public.gmane.org">tim-s/rLXaiAEBtBDgjK7y7TUQ@public.gmane.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">"Kihara Muriithi" <

<a href="mailto:william.muriithi-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org">william.muriithi-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org</a>> writes:<br><br>> Thanks Tim<br>> On 17 Jan 2007 01:07:32 -0500, Tim Writer <<a href="mailto:tim-s/rLXaiAEBtBDgjK7y7TUQ@public.gmane.org">tim-s/rLXaiAEBtBDgjK7y7TUQ@public.gmane.org</a>> wrote:

<br>><br>> > > ## Build the people ou.<br>> > > dn: ou=people,dc=afsat,dc=com<br>> > > ou: people<br>> > > objectClass: organizationalUnit<br>> ><br>> > Hmmm. There's no "objectClass: top" which is unusual.

<br>><br>> I re-did it again and inserted objectClass top as you had suggested.<br>> Unfortunately, the problem persisted. Judging from a google search, I have<br>> noticed its a common thing to do, but it left me scratching my head. Why put

<br>> "top" on more than one root schema? Shouldn't we have just one root?<br><br>Are you confusing the root of the LDAP tree with the root of the object<br>class hierarchy (schema)? You can only have one rootdn but you can have

<br>many classes derived from the root class (top).<br><br>> > This was inserted successfully by slapadd tool. I then restarted openldap<br>> > > and attempted populating it will user extracted from /etc/passwd file

<br>> > and<br>> > > that is when I hit my first problem. The migration tool produced a ldif<br>> > file<br>> > > of the following format.<br>> > > dn: uid=wmuriithi,ou=people,dc=afsat,dc=com

<br>> > > uid: wmuriithi<br>> > > cn: William Muriithi<br>> > > objectClass: account<br>> > > objectClass: posixAccount<br>> > > objectClass: top<br>> > > objectClass: shadowAccount

<br>> ><br>> > Hmmm. I'm not sure why you would have object classes account and<br>> > posixAccount. Also, it's usual to have object class inetOrgPerson for<br>> > e-mail etc. support.<br>>

<br>> The data was automatically generated by an ldap migration tool, so I never<br>> gave it alot of thought. I just assumed they were correct<br><br>It's been a while since I've used them (migration tools) but, as I recall,

<br>they can be used in a number of ways and they may have to be<br>modified. There are many ways to setup LDAP and so the tools aren't<br>universal. They're more of a starting point and you may have to nurse them

<br>a bit, i.e. modify them to remove unwanted fields and add missing fields.<br><br>> > Attempting to feed this data to ldap lead to this error<br>> > > adding new entry "cn=William Muriithi,dc=afsat,dc=com"

<br>> > > ldap_add: Object class violation (65)<br>> > >         additional info: attribute 'uid' not allowed<br>> ><br>> > You appear to have a schema problem.<br>><br>><br>> Thats my  feeling also.  I googled alot on how other people out there do it,

<br>> but it appear very different and don't work for me. I am suspecting this is<br>> because  people out there install from source, while I am working with<br>> fedora binary rpms.<br><br>Hmmm. I've installed from rpms on SUSE and using apt on Debian. It

<br>shouldn't be necessary to install from source.<br><br>> And, while I was on it, I noticed an error on above<br>> insertion, but the solution didn't help. See below<br>> adding new entry "uid=wmuriithi,ou=people,dc=afsat,dc=com"

<br>> ldap_add: Object class violation (65)<br>>         additional info: attribute 'uid' not allowed<br>><br>> > Would this field exist on the output below?<br>> ><br>> > No, because you haven't shown a user, 

i.e. an entry within the people ou. > > If you showed a user, it should have a uid. > > > I am not sure if I understood you well, but I did I querry from what I > assumed you were conveying above, and I still couldn't see the uid field.

What I meant is that the uid won't exist for the query you showed. If LDAP is setup correctly, it _should_ exist for users but I didn't expect it to exist in your case due to the problem you're describing.

<br><br>> See the search below:-<br>>  # ldapsearch -x -b "ou=people,dc=afsat,dc=com"<br>> # extended LDIF<br>> #<br>> # LDAPv3<br>> # base <ou=people,dc=afsat,dc=com> with scope subtree<br>

> # filter: (objectclass=*)<br>> # requesting: ALL<br>> #<br>><br>> # people, <a href="http://afsat.com">afsat.com</a><br>> dn: ou=people,dc=afsat,dc=com<br>> ou: people<br>> objectClass: top<br>> objectClass: organizationalUnit

<br>><br>> # wmuriithi, people, <a href="http://afsat.com">afsat.com</a><br>> dn: cn=wmuriithi,ou=people,dc=afsat,dc=com<br>> cn: wmuriithi<br>> sn: Muriithi<br>> userPassword:: bWFrYXU=<br>> objectClass: person

<br>><br>> # search result<br>> search: 2<br>> result: 0 Success<br>><br>> # numResponses: 3<br>> # numEntries: 2<br>><br>><br>> --<br>> > tim writer <<a href="mailto:tim-s/rLXaiAEBtBDgjK7y7TUQ@public.gmane.org">

tim-s/rLXaiAEBtBDgjK7y7TUQ@public.gmane.org</a>>                                  starnix inc.<br>> > 647.722.5301                                      toronto, ontario, canada<br>> > <a href="http://www.starnix.com">http://www.starnix.com

</a>              professional linux services & products<br>> > --<br>> > The Toronto Linux Users Group.      Meetings: <a href="http://gtalug.org/">http://gtalug.org/</a><br>> > TLUG requests: Linux topics, No HTML, wrap text below 80 columns

<br>> > How to UNSUBSCRIBE: <a href="http://gtalug.org/wiki/Mailing_lists">http://gtalug.org/wiki/Mailing_lists</a><br>> ><br>><br>> Thank you a lot for your help<br>> William<br><br>--<br>tim writer <

<a href="mailto:tim-s/rLXaiAEBtBDgjK7y7TUQ@public.gmane.org">tim-s/rLXaiAEBtBDgjK7y7TUQ@public.gmane.org</a>>                                  starnix inc.<br>647.722.5301                                      toronto, ontario, canada<br><a href="http://www.starnix.com">http://www.starnix.com

</a>              professional linux services & products<br>--<br>The Toronto Linux Users Group.      Meetings: <a href="http://gtalug.org/">http://gtalug.org/</a><br>TLUG requests: Linux topics, No HTML, wrap text below 80 columns

<br>How to UNSUBSCRIBE: <a href="http://gtalug.org/wiki/Mailing_lists">http://gtalug.org/wiki/Mailing_lists</a><br></blockquote></div><br>