OpenLDAP gives duplicate attributeType error

6,260

It looks as though the problem is that you have used the OID 1.3.6.1.1.1.1.2 to define two "different" attributes (really the same attribute twice), once in cn=config,cn=schema,cn={3}nis, and once in cn=config,cn=schema,cn={2}nis. OIDs referencing attributes must be unique.

I don't know what stage you're at in the process of migrating, here, but it looks like you might have imported the same schema twice somehow. If you just did some kind of migration you may want to try it again, taking care to migrate the schema just once.

If you had just converted a bunch of schema files to LDIFs for importing into cn=config,cn=schema, check that in the cn=config/cn=schema folder you do not have multiple entries for NIS (or any other schema component) there. I think you have files cn={2}nis.ldif and cn={3}nis.ldif; use diff to see that they are the same (or how they differ), merge them if necessary, and try importing (freshly) with only one of them present.

Share:
6,260

Related videos on Youtube

Zachary
Author by

Zachary

DevOps Engineer and Software Developer.

Updated on September 18, 2022

Comments

  • Zachary
    Zachary over 1 year

    I am setting up a login node and am using openLDAP from the repository on Ubuntu 14.04 and I am running into an issue of duplicate attributeTypes.

    The problem seems to lie in the "gecos" field attribute. when I try to run slapcat or slapadd or slapindex, I get this output:

    $ slapcat
    53ecd288 olcAttributeTypes: value #0 olcAttributeTypes: Duplicate attributeType: "1.3.6.1.1.1.1.2"
    53ecd288 config error processing cn={3}nis,cn=schema,cn=config: olcAttributeTypes: Duplicate attributeType: "1.3.6.1.1.1.1.2"
    slapcat: bad configuration file!
    

    And when I grep for 1.3.6.1.1.1.1.2 I get

    $ cd /etc/ldap/ && grep -r '1.3.6.1.1.1.1.2' *
    schema/nis.schema:attributetype ( 1.3.6.1.1.1.1.2 NAME 'gecos'
    schema/nis.ldif:olcAttributeTypes: ( 1.3.6.1.1.1.1.2 NAME 'gecos' DESC 'The GECOS field; th
    slapd.d/cn=config/cn=schema/cn={3}nis.ldif:olcAttributeTypes: {0}( 1.3.6.1.1.1.1.2 NAME 'gecos' DESC 'The GECOS field; th
    slapd.d/cn=config/cn=schema/cn={2}nis.ldif:olcAttributeTypes: {0}( 1.3.6.1.1.1.1.2 NAME 'gecos' DESC 'The GECOS field; th
    

    Needless to say, slapd fails to start.

    I don't know how I should go about troubleshooting this problem. When searching for this problem, I saw that people were having a similar problem when trying to use core.schema files from a different, older server. I have not used any files from a different server, and have not edited core.schema or any other core files, with the exception of ldap.conf and slapd.conf.

    Does anyone have insight into this problem? What can I do to fix it?

    • FooBee
      FooBee almost 10 years
      Are you writing a slapd.conf which references schema files? If yes, stop it, this is the old method, these days schemas are stored in the cn=config tree.
    • Zachary
      Zachary almost 10 years
      @SvW I'm really new here, but I really appreciate your answer. If this were reddit, you'd get upvoted. I am writing a slapd.conf. So is all the configuration set in cn=config? is there any use in a slapd.conf file?
    • FooBee
      FooBee almost 10 years
      Please read help.ubuntu.com/14.04/serverguide/openldap-server.html, they are doing a pretty good job of explaining this. IF you have more questions, come back. Also: Whenever you search for an OpenLDAP problem and find something about modifying slapd.conf, this is usually outdated. Lastly, you can upvote here. Proper answers like @FalconMomot's are obvious to upvote and result in reputation points, but if you hover the mouse over a commment, an upvote arrow appears as well (but doesn't grant rep changes).
  • Zachary
    Zachary almost 10 years
    It looks like the schemas were already defined in the cn=config tree and then included a second time in the now obsolete slapd.conf I took your advice and used a fresh install of the server and it seems to have worked! I can now authenticate.