shadowLastChange missing after update

List overview All Threads
Download

newer

older

S/Mime configuration

Import base64 info

Maria McKinley

6 Mar 2013 6 Mar '13

5:52 p.m.

Hi there,

I recently changed from the slapd.conf configuration to the slapd.d configuration. Everything seemed to go reasonably well, but for some reason the shadowLastChange attribute was missing from all of the people. When I try to add it back in, I get:

ldap_add: Object class violation (65) additional info: no objectClass attribute

but, I seem to have the schema and objectClasses for ShadowLastChange:

annette:~# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=schema,cn=config "(objectClass=olcSchemaConfig)" dn dn: cn=schema,cn=config

dn: cn={0}core,cn=schema,cn=config

dn: cn={1}cosine,cn=schema,cn=config

dn: cn={2}nis,cn=schema,cn=config

dn: cn={3}inetorgperson,cn=schema,cn=config

dn: cn={4}misc,cn=schema,cn=config

maria@mimi:~/sysadmin$ ldapsearch -xLLL "uid=jd" dn: uid=jd,ou=people,dc=example,dc=com objectClass: top objectClass: posixAccount objectClass: shadowAccount objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: inetLocalMailRecipient cn: Jochen Ditterich shadowMax: 365 gidNumber: 100 uid: jd homeDirectory: /home/jd mailRoutingAddress: jd@example.com uidNumber: 1025 sn: Ditterich shadowWarning: 7 mailLocalAddress: jd mail: jd@example.com loginShell: /bin/bash

Anyone have any idea what might be going on? What am I missing?

thanks, maria

Attachments:

attachment.htm (text/html — 1.9 KB)

Show replies by date

Maria McKinley

7 Mar 7 Mar

3:38 p.m.

On Wed, Mar 6, 2013 at 5:52 PM, Maria McKinley mariak@mariakathryn.netwrote:

...

Hi there,

I recently changed from the slapd.conf configuration to the slapd.d configuration. Everything seemed to go reasonably well, but for some reason the shadowLastChange attribute was missing from all of the people. When I try to add it back in, I get:

ldap_add: Object class violation (65) additional info: no objectClass attribute

but, I seem to have the schema and objectClasses for ShadowLastChange:

annette:~# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=schema,cn=config "(objectClass=olcSchemaConfig)" dn dn: cn=schema,cn=config

dn: cn={0}core,cn=schema,cn=config

dn: cn={1}cosine,cn=schema,cn=config

dn: cn={2}nis,cn=schema,cn=config

dn: cn={3}inetorgperson,cn=schema,cn=config

dn: cn={4}misc,cn=schema,cn=config

maria@mimi:~/sysadmin$ ldapsearch -xLLL "uid=jd" dn: uid=jd,ou=people,dc=example,dc=com objectClass: top objectClass: posixAccount objectClass: shadowAccount objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: inetLocalMailRecipient cn: Jochen Ditterich shadowMax: 365 gidNumber: 100 uid: jd homeDirectory: /home/jd mailRoutingAddress: jd@example.com uidNumber: 1025 sn: Ditterich shadowWarning: 7 mailLocalAddress: jd mail: jd@example.com loginShell: /bin/bash

Anyone have any idea what might be going on? What am I missing?

thanks, maria

So, I got past that error message (had an error in my change file), but now things are even stranger. When I got it right, I got the following message:

add shadowLastChange: 15771 modifying entry "uid=jd,ou=people,dc=example,dc=com" ldap_modify: Constraint violation (19) additional info: attribute 'shadowLastChange' cannot have multiple values

That's strange. So, maybe it thinks it already has that attribute. let's see what happens if we try to modify it instead of add it:

replace shadowLastChange: 15771 modifying entry "uid=jd,ou=people,dc=example,dc=com" modify complete

Huh, well that seemed to have worked. Let's see what the value is now.

annette:~# ldapsearch -x "uid=jd" shadowLastChange # extended LDIF # # LDAPv3 # base <dc=example,dc=com> (default) with scope subtree # filter: uid=jd # requesting: shadowLastChange #

# jd, people, example.com dn: uid=jd,ou=people,dc=example,dc=com

# search result search: 2 result: 0 Success

# numResponses: 2 # numEntries: 1

Um, so where is it? Help!

thanks, maria

devzero2000

10:50 p.m.

Sorry for the top posting.

iirc, in ldapv3 the right thing to search is the subschemaSubentry attribute, as a base, of the rootDSE object.

Hth

2013/3/7, Maria McKinley mariak@mariakathryn.net:

...

Hi there,

I recently changed from the slapd.conf configuration to the slapd.d configuration. Everything seemed to go reasonably well, but for some reason the shadowLastChange attribute was missing from all of the people. When I try to add it back in, I get:

ldap_add: Object class violation (65) additional info: no objectClass attribute

but, I seem to have the schema and objectClasses for ShadowLastChange:

annette:~# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=schema,cn=config "(objectClass=olcSchemaConfig)" dn dn: cn=schema,cn=config

dn: cn={0}core,cn=schema,cn=config

dn: cn={1}cosine,cn=schema,cn=config

dn: cn={2}nis,cn=schema,cn=config

dn: cn={3}inetorgperson,cn=schema,cn=config

dn: cn={4}misc,cn=schema,cn=config

maria@mimi:~/sysadmin$ ldapsearch -xLLL "uid=jd" dn: uid=jd,ou=people,dc=example,dc=com objectClass: top objectClass: posixAccount objectClass: shadowAccount objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: inetLocalMailRecipient cn: Jochen Ditterich shadowMax: 365 gidNumber: 100 uid: jd homeDirectory: /home/jd mailRoutingAddress: jd@example.com uidNumber: 1025 sn: Ditterich shadowWarning: 7 mailLocalAddress: jd mail: jd@example.com loginShell: /bin/bash

Anyone have any idea what might be going on? What am I missing?

thanks, maria

-- Inviato dal mio dispositivo mobile

Michael Ströder

11:53 p.m.

devzero2000 wrote:

...

iirc, in ldapv3 the right thing to search is the subschemaSubentry attribute, as a base, of the rootDSE object.

In general each part of the DIT could have its own subschema subentry! So you have to read attribute subschemaSubentry in the entry for which you want to determine the schema. Not many schema-aware clients are doing this though.

Ciao, Michael.

Maria McKinley

8 Mar 8 Mar

2:06 p.m.

On Thu, Mar 7, 2013 at 11:53 PM, Michael Ströder michael@stroeder.comwrote:

...

devzero2000 wrote:

...
iirc, in ldapv3 the right thing to search is the subschemaSubentry attribute, as a base, of the rootDSE object.

In general each part of the DIT could have its own subschema subentry! So you have to read attribute subschemaSubentry in the entry for which you want to determine the schema. Not many schema-aware clients are doing this though.

Ciao, Michael.

Thanks, but I don't think this is my problem. I think it is a permission problem. It use to be that if I used

ldapsearch -x "uid=jd"

I would get all entries except the userPassword and shadowLastChange, but if I used:

ldapsearch -x -W -D "cn=admin,ou=roles,dc=example,dc=com" "uid=jd"

I would get everything, including the userPassword and shadowLastChange. Neither one show up now. Here are my permissions for these two attributes:

olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou s auth by dn="cn=admin,dc=shadlenlab,dc=columbia,dc=edu" write by * none

So, it looks like no one has read permissions for either attribute, if I am reading this correctly. I don't need to read the userPassword, but I do need to be able to read shadowLastChange. Can someone help me understand how to change olcAccess so that admin can read shadowLastChange using ldapmodify? I am finding the documentation on this extremely opaque.

thanks, maria

Maria McKinley

11 Mar 11 Mar

2:54 p.m.

Hello,

Just looking for a sanity check. Here is what I have now:

olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=example,dc=com" write by * none

olcAccess: {1}to dn.base="" by * read

olcAccess: {2}to * by self write by dn="cn=admin,dc=example,dc=com" write by * read

Here is what I think I want:

olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=example,dc=com" write by * none

olcAccess: {1}to attrs=shadowLastChange by * read

olcAccess: {2}to dn.base="" by * read

olcAccess: {3}to * by self write by dn="cn=admin,dc=example,dc=com" write by * read

Here is the file I think I should use to accomplish this:

changetype: modify

delete: olcAccess

olcAccess: {1}

add: olcAccess

olcAccess: {1}to attrs=shadowLastChange by * read

delete: olcAccess

olcAccess: {2}

add: olcAccess

olcAccess: {2}to dn.base="" by * read

add: olcAccess

olcAccess: {3}to * by self write by dn="cn=admin,dc=example,dc=com" write by * read

And, of course, before I do this I will shutdown ldap, slapcat a backup, and restart. Does this look right?

thanks,

maria

4057

Age (days ago)

4061

Last active (days ago)

openldap-technical@openldap.org

5 comments

3 participants

tags (0)

participants (3)

devzero2000
Maria McKinley
Michael Ströder