Hello,
I am starting out with openldap and I don't know it that much. I got the error mentioned in the title when trying to add an object class, which is apparently a very common one per my google searches. I've read that common causes are:
* extraneous white space (especially trailing white space) * improperly encoded characters (LDAPv3 uses UTF-8 encoded Unicode) * empty values (few syntaxes allow empty values)
This is the object class file I am trying to add, I picked it as an example on some website, to have something minimal and make it easier to test:
# cat exObjectClasses.ldif dn: cn=schema changetype: modify add: objectClasses objectClasses: ( 2.16.840.1.113730.3.2.2.9 NAME 'blogger' DESC 'Someone who has a blog' SUP inetOrgPerson STRUCTURAL MAY blog )
I've checked if there was any trailing spaces at the end with the following:
# cat -vte exObjectClasses.ldif dn: cn=schema$ changetype: modify$ add: objectClasses$ objectClasses: ( 2.16.840.1.113730.3.2.2.9$ NAME 'blogger'$ DESC 'Someone who has a blog'$ SUP inetOrgPerson STRUCTURAL$ MAY blog )$
I've made sure the file is UTF-8:
# iconv -f ASCII -t UTF-8 exObjectClasses.ldif > exObjectClasses.ldif.utf8
And I don't think there are any empty values defined in the LDIF file. So when I type this command, I still have the "invalid per syntax error:
# ldapmodify -x -W -H "ldaps://127.0.0.1" -D cn=Manager,dc=modelsolv,dc=com -f exObjectClasses.ldif Enter LDAP Password: modifying entry "cn=schema" ldap_modify: Invalid syntax (21) additional info: objectClasses: value #0 invalid per syntax
This is the content of the /etc/openldap/slapd.conf file:
# cat slapd.conf # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. #
include /etc/openldap/schema/corba.schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/duaconf.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/java.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/collective.schema
# Allow LDAPv2 client connections. This is NOT the default. allow bind_v2
# Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org
pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules # - modulepath is architecture dependent value (32/64-bit system) # - back_sql.la overlay requires openldap-server-sql package # - dyngroup.la and dynlist.la cannot be used at the same time
# modulepath /usr/lib/openldap # modulepath /usr/lib64/openldap
# moduleload accesslog.la # moduleload auditlog.la # moduleload back_sql.la # moduleload chain.la # moduleload collect.la # moduleload constraint.la # moduleload dds.la # moduleload deref.la # moduleload dyngroup.la # moduleload dynlist.la # moduleload memberof.la # moduleload pbind.la # moduleload pcache.la # moduleload ppolicy.la # moduleload refint.la # moduleload retcode.la # moduleload rwm.la # moduleload seqmod.la # moduleload smbk5pwd.la # moduleload sssvlv.la # moduleload syncprov.la # moduleload translucent.la # moduleload unique.la # moduleload valsort.la
# The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by running # /usr/libexec/openldap/generate-server-cert.sh. Your client software may balk # at self-signed certificates, however. TLSCACertificatePath /etc/openldap/certs TLSCertificateFile ""OpenLDAP Server"" TLSCertificateKeyFile /etc/openldap/certs/password
# Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING!
# enable on-the-fly configuration (cn=config) database config access to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * none
# enable server status monitoring (cn=monitor) database monitor access to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.exact="cn=Manager,dc=my-domain,dc=com" read by * none
####################################################################### # database definitions #######################################################################
database bdb suffix "dc=modelsolv,dc=com" checkpoint 1024 15 rootdn "cn=Manager,dc=modelsolv,dc=com" # 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 {crypt}ijFYNcSNctBYg
# The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. 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
# Replicas of this database #replogfile /var/lib/ldap/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/ldap-master.example.com@EXAMPLE.COM
I was able to add a few entries in LDAP so far. So I know I am able to reach the server, the connection is fine, and LDAP is somewhat functional. But I can't modify the schema with objectclasses.
Is there anything obvious that I am doing wrong? Do you have any recommendation for debugging further?
Regards, Jimmy Royer
2013/2/28 Jimmy Royer jimmy.royer@modelsolv.com:
Hello,
I am starting out with openldap and I don't know it that much. I got the error mentioned in the title when trying to add an object class, which is apparently a very common one per my google searches. I've read that common causes are:
- extraneous white space (especially trailing white space)
- improperly encoded characters (LDAPv3 uses UTF-8 encoded Unicode)
- empty values (few syntaxes allow empty values)
This is the object class file I am trying to add, I picked it as an example on some website, to have something minimal and make it easier to test:
# cat exObjectClasses.ldif dn: cn=schema changetype: modify add: objectClasses objectClasses: ( 2.16.840.1.113730.3.2.2.9 NAME 'blogger' DESC 'Someone who has a blog' SUP inetOrgPerson STRUCTURAL MAY blog )
I've checked if there was any trailing spaces at the end with the following:
# cat -vte exObjectClasses.ldif dn: cn=schema$ changetype: modify$ add: objectClasses$ objectClasses: ( 2.16.840.1.113730.3.2.2.9$ NAME 'blogger'$ DESC 'Someone who has a blog'$ SUP inetOrgPerson STRUCTURAL$ MAY blog )$
I've made sure the file is UTF-8:
# iconv -f ASCII -t UTF-8 exObjectClasses.ldif > exObjectClasses.ldif.utf8
And I don't think there are any empty values defined in the LDIF file. So when I type this command, I still have the "invalid per syntax error:
# ldapmodify -x -W -H "ldaps://127.0.0.1" -D cn=Manager,dc=modelsolv,dc=com -f exObjectClasses.ldif Enter LDAP Password: modifying entry "cn=schema" ldap_modify: Invalid syntax (21) additional info: objectClasses: value #0 invalid per syntax
This is the content of the /etc/openldap/slapd.conf file:
# cat slapd.conf # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. #
include /etc/openldap/schema/corba.schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/duaconf.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/java.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/collective.schema
# Allow LDAPv2 client connections. This is NOT the default. allow bind_v2
# Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org
pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules # - modulepath is architecture dependent value (32/64-bit system) # - back_sql.la overlay requires openldap-server-sql package # - dyngroup.la and dynlist.la cannot be used at the same time
# modulepath /usr/lib/openldap # modulepath /usr/lib64/openldap
# moduleload accesslog.la # moduleload auditlog.la # moduleload back_sql.la # moduleload chain.la # moduleload collect.la # moduleload constraint.la # moduleload dds.la # moduleload deref.la # moduleload dyngroup.la # moduleload dynlist.la # moduleload memberof.la # moduleload pbind.la # moduleload pcache.la # moduleload ppolicy.la # moduleload refint.la # moduleload retcode.la # moduleload rwm.la # moduleload seqmod.la # moduleload smbk5pwd.la # moduleload sssvlv.la # moduleload syncprov.la # moduleload translucent.la # moduleload unique.la # moduleload valsort.la
# The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by running # /usr/libexec/openldap/generate-server-cert.sh. Your client software may balk # at self-signed certificates, however. TLSCACertificatePath /etc/openldap/certs TLSCertificateFile ""OpenLDAP Server"" TLSCertificateKeyFile /etc/openldap/certs/password
# Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING!
# enable on-the-fly configuration (cn=config) database config access to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * none
# enable server status monitoring (cn=monitor) database monitor access to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.exact="cn=Manager,dc=my-domain,dc=com" read by * none
####################################################################### # database definitions #######################################################################
database bdb suffix "dc=modelsolv,dc=com" checkpoint 1024 15 rootdn "cn=Manager,dc=modelsolv,dc=com" # 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 {crypt}ijFYNcSNctBYg
# The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. 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
# Replicas of this database #replogfile /var/lib/ldap/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/ldap-master.example.com@EXAMPLE.COM
I was able to add a few entries in LDAP so far. So I know I am able to reach the server, the connection is fine, and LDAP is somewhat functional. But I can't modify the schema with objectclasses.
Is there anything obvious that I am doing wrong? Do you have any recommendation for debugging further?
Hi,
you can't update schema by acting on cn=subschema branch, this is readonly.
As your are using the old slapd.conf file, you need to create a .schema file and include it in slapd.conf.
If you want to update schema with LDIF file, change from slapd.conf to cn=config configuration method.
Clément.
Regards, Jimmy Royer
Jimmy Royer wrote:
Hello,
I am starting out with openldap and I don't know it that much. I got the error mentioned in the title when trying to add an object class, which is apparently a very common one per my google searches. I've read that common causes are:
- extraneous white space (especially trailing white space)
- improperly encoded characters (LDAPv3 uses UTF-8 encoded Unicode)
- empty values (few syntaxes allow empty values)
This is the object class file I am trying to add, I picked it as an example on some website, to have something minimal and make it easier to test:
# cat exObjectClasses.ldif dn: cn=schema changetype: modify add: objectClasses objectClasses: ( 2.16.840.1.113730.3.2.2.9 NAME 'blogger' DESC 'Someone who has a blog' SUP inetOrgPerson STRUCTURAL MAY blog )
I've checked if there was any trailing spaces at the end with the following:
# cat -vte exObjectClasses.ldif dn: cn=schema$ changetype: modify$ add: objectClasses$ objectClasses: ( 2.16.840.1.113730.3.2.2.9$ NAME 'blogger'$ DESC 'Someone who has a blog'$ SUP inetOrgPerson STRUCTURAL$ MAY blog )$
I've made sure the file is UTF-8:
# iconv -f ASCII -t UTF-8 exObjectClasses.ldif > exObjectClasses.ldif.utf8
Redundant. 7-bit ASCII is already valid UTF-8. And if you had any stray 8-bit ASCII characters in there, they obviously would be erroneous and should be deleted, not converted to UTF-8.
Most likely you trimmed too many spaces. Read the ldif(5) manpage.
Also, cn=schema is not a user modifiable entry in OpenLDAP. If you want to add new schema you must add it to cn=schema,cn=config.
Seems like, given that you haven't mentioned cn=config, you're probably using a pretty old version of OpenLDAP as well.
And I don't think there are any empty values defined in the LDIF file. So when I type this command, I still have the "invalid per syntax error:
# ldapmodify -x -W -H "ldaps://127.0.0.1" -D cn=Manager,dc=modelsolv,dc=com -f exObjectClasses.ldif Enter LDAP Password: modifying entry "cn=schema" ldap_modify: Invalid syntax (21) additional info: objectClasses: value #0 invalid per syntax
I was able to add a few entries in LDAP so far. So I know I am able to reach the server, the connection is fine, and LDAP is somewhat functional. But I can't modify the schema with objectclasses.
Is there anything obvious that I am doing wrong? Do you have any recommendation for debugging further?
Regards, Jimmy Royer
This is the version of openldap I use:
# /usr/sbin/slapd -V @(#) $OpenLDAP: slapd 2.4.23 (Aug 8 2012 16:29:21) $ mockbuild@c6b10.bsys.dev.centos.org:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd
I followed an LDAP installation walkthrough for centos 6.3. It did not mention the slapd.conf. I copied the slapd.conf manually from an installation directory after some googling. Because I needed to configure the rootdn and rootpw values. It worked and I assumed it was OK. But I guess I should configure these values elsewhere and get rid of slapd.conf?
On Thu, Feb 28, 2013 at 10:24 AM, Howard Chu hyc@symas.com wrote:
Jimmy Royer wrote:
Hello,
I am starting out with openldap and I don't know it that much. I got the error mentioned in the title when trying to add an object class, which is apparently a very common one per my google searches. I've read that common causes are:
- extraneous white space (especially trailing white space)
- improperly encoded characters (LDAPv3 uses UTF-8 encoded Unicode)
- empty values (few syntaxes allow empty values)
This is the object class file I am trying to add, I picked it as an example on some website, to have something minimal and make it easier to test:
# cat exObjectClasses.ldif dn: cn=schema changetype: modify add: objectClasses objectClasses: ( 2.16.840.1.113730.3.2.2.9 NAME 'blogger' DESC 'Someone who has a blog' SUP inetOrgPerson STRUCTURAL MAY blog )
I've checked if there was any trailing spaces at the end with the following:
# cat -vte exObjectClasses.ldif dn: cn=schema$ changetype: modify$ add: objectClasses$ objectClasses: ( 2.16.840.1.113730.3.2.2.9$ NAME 'blogger'$ DESC 'Someone who has a blog'$ SUP inetOrgPerson STRUCTURAL$ MAY blog )$
I've made sure the file is UTF-8:
# iconv -f ASCII -t UTF-8 exObjectClasses.ldif > exObjectClasses.ldif.utf8
Redundant. 7-bit ASCII is already valid UTF-8. And if you had any stray 8-bit ASCII characters in there, they obviously would be erroneous and should be deleted, not converted to UTF-8.
Most likely you trimmed too many spaces. Read the ldif(5) manpage.
Also, cn=schema is not a user modifiable entry in OpenLDAP. If you want to add new schema you must add it to cn=schema,cn=config.
Seems like, given that you haven't mentioned cn=config, you're probably using a pretty old version of OpenLDAP as well.
And I don't think there are any empty values defined in the LDIF file. So when I type this command, I still have the "invalid per syntax error:
# ldapmodify -x -W -H "ldaps://127.0.0.1" -D cn=Manager,dc=modelsolv,dc=com -f exObjectClasses.ldif Enter LDAP Password: modifying entry "cn=schema" ldap_modify: Invalid syntax (21) additional info: objectClasses: value #0 invalid per syntax
I was able to add a few entries in LDAP so far. So I know I am able to reach the server, the connection is fine, and LDAP is somewhat functional. But I can't modify the schema with objectclasses.
Is there anything obvious that I am doing wrong? Do you have any recommendation for debugging further?
Regards, Jimmy Royer
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
--On Thursday, February 28, 2013 10:31 AM -0500 Jimmy Royer jimmy.royer@modelsolv.com wrote:
This is the version of openldap I use:
# /usr/sbin/slapd -V @(#) $OpenLDAP: slapd 2.4.23 (Aug 8 2012 16:29:21) $
mockbuild@c6b10.bsys.dev.centos.org:/builddir/build/BUILD/openldap-2.4.23 /openldap-2.4.23/build-servers/servers/slapd
I followed an LDAP installation walkthrough for centos 6.3. It did not mention the slapd.conf. I copied the slapd.conf manually from an installation directory after some googling. Because I needed to configure the rootdn and rootpw values. It worked and I assumed it was OK. But I guess I should configure these values elsewhere and get rid of slapd.conf?
Hi Jimmy,
You need to learn how to use cn=config. I would also strongly advise against using the centos packages, there are multiple known problems with them. Try http://ltb-project.org/wiki/download#openldap as an alternative to the broken bits shipped by rhel/centos.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org