Hi,

i am trying to add a new schema to my openldap-server (2.4.23 on a debian squezze machine). Here is the vacation.schema which is activated in /etc/ldap/slapd.conf

attributetype ( 1.3.6.1.4.1.39116.1.1.11
NAME 'vacationActive'
SINGLE-VALUE
EQUALITY booleanMatch
DESC 'A flag, for marking the user as being away'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
attributetype ( 1.3.6.1.4.1.39116.1.1.12
NAME 'vacationInfo'
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
DESC 'Absentee note to leave behind, while on vacation'
EQUALITY octetStringMatch )
attributetype ( 1.3.6.1.4.1.39116.1.1.13
NAME 'vacationStart'
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
DESC 'Beginning of vacation'
EQUALITY octetStringMatch )
attributetype ( 1.3.6.1.4.1.39116.1.1.14
NAME 'vacationEnd'
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
DESC 'End of vacation'
EQUALITY octetStringMatch )
attributetype (1.3.6.1.4.1.39116.1.1.15
NAME 'vacationForward'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256}
DESC 'Where to forward mails to, while on vacation' )
#
# Objects start here
#
objectclass ( 1.3.6.1.4.1.39116.1.2.10 NAME 'vacation'
SUP top AUXILIARY
DESC 'Users vacation status information'
MUST vacationActive
MAY ( vacationInfo $ vacationStart $ vacationEnd $ vacationForward ) )

The users have the rights to modify their vacation attributes.
But when i try to activate vacation with a user the following errors occur in the logs:

16-Dec-2011 11:20:29] Could not add new values to attribute vacationActive: Object class violation: LDAP_OBJECT_CLASS_VIOLATION (65):
[16-Dec-2011 11:20:29] Could not modify entry: Could not add new values to attribute vacationActive: Object class violation: LDAP_OBJECT_CLASS_VIOLATION: (1000):

These are the error-logs from roundcube (webmail, works fine with some plugins)
But the vacation plugin isnt properly working, because of the vacation ldap attributes.


The logs of the ldap server show the following to this error:

conn=1221 op=4 MOD dn="cn=admin,dc=domain,dc=de"
slapd[14608]: conn=1221 op=4 MOD attr=vacationActive
serv slapd[14608]: slap_queue_csn: queing 0xb58969b6 20111216110200.012914Z#000000#000#000000
serv slapd[14608]: Entry (cn=ldapadmin,dc=folkwang-hochschule,dc=de), attribute 'vacationActive' not allowed
serv slapd[14608]: entry failed schema check: attribute 'vacationActive' not allowed
serv slapd[14608]: conn=1221 op=4 RESULT tag=103 err=65 text=attribute 'vacationActive' not allowed


Has anybody an idea what is missing in my config or my schema?

Thanks in advance.

Andi

Hi,

My guess is that your openldap uses the new cn=config instead of slapd.conf, so the schema you've added is not actually read by openldap
Take a look at this howto (step 2), that is similar to what you're trying to achieve.

Regards

Thanks for the advice. It seems that its like you say. I gonna try this step out and report news here.

Now i followed the step 2 and tried to
ldapadd -x -D cn=admin,cn=config -W -f cn\=\{6\}vacation.ldif
Enter LDAP Password:
ldap_bind: Invalid credentials (49)

Then i found somewhere that i have to add "admin" to make changes on the schema.
I did it also, like its described on this site
http://ubuntuforums.org/showthread.php?t=1515119

But when i try to modify the schema like this
ldapadd -Y EXTERNAL -H ldapi:/// -f config.ldif - dont works
At last i made the changes described in the article above manually in the /etc/ldap/cn\=config/olcDatabase\=\{0\}config.ldif

dn: olcDatabase={0}config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=admin,cn=config
olcRootPW: {SSHA}Secret
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: 46b43100-b692-1030-89be-cbe1073d381b
creatorsName: cn=config
createTimestamp: 20111209091652Z
entryCSN: 20111209091652.472369Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20111209091652Z

Then it is also not working with
ldapadd -x -D cn=admin,cn=config -W -f cn\=\{6\}vacation.ldif

Error: invalid credentials.
Now iam stuck with modifying the schema.
How can add this admin who can change the schema?
Any hints?

i have another admin on a bdb{1} database who is configured as rootDN for dc=company,dc=org.
But when i try to
ldapadd -x -D cn=admin,dc=company,dc=org -W -f cn\=\{6\}vacation.ldif
it ends up with "unsufficient access"

Any idea?

That should have worked. Anyway, you can copy the olcRootPW from olcDatabase\=\{1\}bdb.ldif (this is the password of cn=admin,dc=company,dc=org) and use that for the admin of cn=config. You should pay attention, if there is a single or double colon after olcRootPW (i.e. olcRootPW: blah, or olcRootPW:: blah)
Of course you need to restart slapd

Regards

Ok, i copied the data of the olcRootDN and olcRootPW from olcDatabase\=\{1\}bdb.ldif
to /etc/ldap/cn\=config/olcDatabase\=\{0\}config.ldif and modified it.

So it looks like this:
dn: olcDatabase={0}config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=admin,cn=config
olcRootPW:: Secret
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: 46b43100-b692-1030-89be-cbe1073d381b
creatorsName: cn=config
createTimestamp: 20111209091652Z
entryCSN: 20111209091652.472369Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20111209091652Z

With this new data i entered the command
slapcat -f schema.convert -F ldif.out/ -n0
where schema.convert is filled with:
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/hisldap.schema
include /etc/ldap/schema/ppolicy.schema
include /etc/ldap/schema/vacation.schema

and after this command the directory ldif.out has following entries:
drwxr-x--- 3 root root 4096 19. Dez 15:49 cn=config
-rw------- 1 root root 863 19. Dez 15:42 cn=config.ldif

and cn=config has

drwxr-x--- 2 root root 4096 19. Dez 15:42 cn=schema
-rw------- 1 root root 33161 19. Dez 15:42 cn=schema.ldif
-rw------- 1 root root 513 19. Dez 15:42 olcDatabase={0}config.ldif
-rw------- 1 root root 525 19. Dez 15:42 olcDatabase={-1}frontend.ldif

Well, now i am wondering that the olcDatabase={0}config.ldif which is in the ldif.outdirectory looks like:
dn: olcDatabase={0}config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by * none
olcAddContentAcl: TRUE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=config
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: 69f167a8-be9b-1030-9584-13aa6ad30339
creatorsName: cn=config
createTimestamp: 20111219144226Z
entryCSN: 20111219144226.372525Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20111219144226Z

Shouldn't look this file like the original
/etc/ldap/cn\=config/olcDatabase\=\{0\}config.ldif ???

Because the error "invalid credentials" continues when i execute
ldapadd -x -D cn=admin,cn=config -W -f cn\=\{6\}vacation.ldif

Hmm, is the modification of the admin-account really valid with my manual entry?
With this i am not really sure.

I only start play openldap 2.4 at RHEL few days ago.
For RHEL, LDAPS is configured as default. I also encounter ldap_bind: Invalid credentials (49)

For my case, i don't need LDAPS, so I disabled at global config and manage to authenticate

/etc/sysconfig/ldap
SLAPD_LDAPS=no

Why? I told you just to use the olcRootPW value of olcDatabase\=\{1\}bdb.ldif, so both passwords for DNs "cn=admin,cn=config" and "cn=admin,dc=company,dc=org" are the same. I guess you already know the password of cn=admin,dc=company,dc=org

Nope, slapcat converts schema.convert to the ldif needed so you can add it in cn=config.

Are you sure about the password you entered wen you installed openldap?

I've tested on my openldap (installed from source and it works


Anyway, if you have no data in your openldap, you can uninstall it, and reinstall. According to the link I've posted above, both passwords should be the same. Quoting from step 2: