[389-users] using uid rather then cn in the binddn

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dumbo Q wrote:
> Thanks.  I tried that, but now it tells me
> ldapmodify: Object class violation (65)
>         additional info: missing attribute "cn" required by object 
> class "inetOrgPerson"
>
> Being that the entry has a 'cn', I guess this means that somewhere I 
> have it setup where dn requires the cn to be in it ???  Anythoughts
Are you still specifying "deleteOldRDN: 1"?  As I mentioned, you 
shouldn't be doing that as it will delete the old RDN value from the 
entry, which is your "cn".  Since "cn" is required by the 
"inetOrgPerson" objectclass, this is an objectclass violation.  Try 
specifying "deleteOldRDN: 0".
>
>
>
> ------------------------------------------------------------------------
> *From:* Nathan Kinder <nkinder at redhat.com>
> *To:* General discussion list for the 389 Directory server project. 
> <fedora-directory-users at redhat.com>
> *Sent:* Monday, June 22, 2009 4:30:53 PM
> *Subject:* Re: [389-users] using uid rather then cn in the binddn
>
> Dumbo Q wrote:
> > Erg.    I thought I had it but it's something is blocking me from 
> doing this update. Can anyone help me find where my constraint is?
> >
> <snip>
> >
> > [root at rhds ~]# ldapmodify -x -W -D cn=DirectoryManager
> > dn: cn=testy,ou=users,ou=people,dc=mydomain,dc=com
> > changetype: modify
> > newRDN: uid=testy
> > deleteOldRDN: 1
> >
> > modifying entry "cn=testy,ou=users,ou=people,dc=mydomain,dc=com"
> > ldapmodify: Object class violation (65)
> >        additional info: attribute "newRdn" not allowed
> You need to perform a "modrdn" operation instead of a regular modify.  
> Try the above, but change your "changetype" to "modrdn".  You may also 
> find that you don't want to delete the old RDN from the entry, 
> particularly if that is the only "cn" value present in your entry.  
> Doing so would cause an objectclass violation since "cn" is likely 
> required for the objectclass you are using.
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > --
> > 389 users mailing list
> > 389-users at redhat.com <mailto:389-users at redhat.com>
> > https://www.redhat.com/mailman/listinfo/fedora-directory-users
> > 
>
> --
> 389 users mailing list
> 389-users at redhat.com <mailto:389-users at redhat.com>
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
> ------------------------------------------------------------------------
>
> --
> 389 users mailing list
> 389-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>   




[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux