I’ve got exactly the same problem. But investigating further it seems to me that LDAP does not even read the configuration file /etc/openldap/slapd_macosxserver.conf.

Symptom: Changes in the “access to”-statements in /etc/openldap/slapd_macosxserver.conf cannot be verified in the running server.

After some unsuccessful tests I deliberately entered a syntax-error in slapd_macosxserver.conf and restarted slapd by issuing the command killall -HUP slapd. The logfile shows that the process is indeed restarted, ps shows that slapd now has got a different process-id. But there is no indication of the syntax-error in any of the logfiles.

I did ‘touch timestamp’ in /etc/openldap:

[code]
-rw——-@ 1 root wheel 10944 Aug 28 09:18 slapd_macosxserver.conf
-rw——-@ 1 root wheel 1964 Aug 28 09:18 slapd.conf
drwxr-xr-x 141 root wheel 4794 Aug 28 09:18 ..
-rw-r–r– 1 root wheel 0 Aug 28 09:19 timestamp
drwxr-xr-x 16 root wheel 544 Aug 28 09:19 .
[/code]

and then killall -HUP slapd. Surprise slapd_macosxserver.conf is not read!!! :

[code]
-rw——-@ 1 root wheel 1964 Aug 28 09:18 slapd.conf
drwxr-xr-x 141 root wheel 4794 Aug 28 09:18 ..
-rw-r–r– 1 root wheel 0 Aug 28 09:19 timestamp
-rw-r–r–@ 1 root wheel 73 Aug 28 09:19 rootDSE.ldif
-rw-r–r– 1 root wheel 300 Aug 28 09:19 ldap.conf
drwxr-xr-x 16 root wheel 544 Aug 28 09:19 .
[/code]

finally find . -anewer timestamp confirms and adds a lot of information
[code]
/ldap.conf
./rootDSE.ldif
./slapd.d/cn=config
./slapd.d/cn=config/cn=include{0}.ldif
./slapd.d/cn=config/cn=include{1}.ldif
./slapd.d/cn=config/cn=include{2}.ldif
./slapd.d/cn=config/cn=include{3}.ldif
./slapd.d/cn=config/cn=include{4}.ldif
./slapd.d/cn=config/cn=include{5}.ldif
./slapd.d/cn=config/cn=include{6}.ldif
./slapd.d/cn=config/cn=include{7}.ldif
./slapd.d/cn=config/cn=include{8}.ldif
./slapd.d/cn=config/cn=schema
./slapd.d/cn=config/cn=schema/cn={0}core.ldif
./slapd.d/cn=config/cn=schema/cn={1}cosine.ldif
./slapd.d/cn=config/cn=schema/cn={2}nis.ldif
./slapd.d/cn=config/cn=schema/cn={3}inetorgperson.ldif
./slapd.d/cn=config/cn=schema/cn={4}misc.ldif
./slapd.d/cn=config/cn=schema/cn={5}samba.ldif
./slapd.d/cn=config/cn=schema/cn={6}fmserver.ldif
./slapd.d/cn=config/cn=schema/cn={7}apple.ldif
./slapd.d/cn=config/cn=schema/cn={8}slapd_macosxserver.ldif
./slapd.d/cn=config/cn=schema/cn={9}customschema.ldif
./slapd.d/cn=config/cn=schema.ldif
./slapd.d/cn=config/olcDatabase={-1}frontend.ldif
./slapd.d/cn=config/olcDatabase={0}config.ldif
./slapd.d/cn=config/olcDatabase={1}bdb
./slapd.d/cn=config/olcDatabase={1}bdb/olcOverlay={0}unique.ldif
./slapd.d/cn=config/olcDatabase={1}bdb/olcOverlay={1}dynid.ldif
./slapd.d/cn=config/olcDatabase={1}bdb/olcOverlay={2}dynid.ldif
./slapd.d/cn=config/olcDatabase={1}bdb/olcOverlay={3}dynid.ldif
./slapd.d/cn=config/olcDatabase={1}bdb/olcOverlay={4}dynid.ldif
./slapd.d/cn=config/olcDatabase={1}bdb/olcOverlay={5}dynid.ldif
./slapd.d/cn=config/olcDatabase={1}bdb/olcOverlay={6}dynid.ldif
./slapd.d/cn=config/olcDatabase={1}bdb/olcOverlay={7}nestedgroup.ldif
./slapd.d/cn=config/olcDatabase={1}bdb.ldif
./slapd.d/cn=config.ldif
[/code]

Can anybody summorize how apple’s slapd configures itsself?

Can anybody explain me how to limit the read access of certain user’s attributes?

Greetings
Klaus

After investigating this more, it would not appear to be very straight forward to achieve this. If you create a new test OD (open Directory) account and make it a limited admin, then have a look at the updated/new olcAccess entries, you will see something similar to :

[code]
olcAccess: {3}to dn.onelevel=”cn=groups,dc=my,dc=od,dc=com” a
ttrs=apple-mcxflags,apple-mcxsettings by dynacl/idattr/APPLYTO:635DF24E-E00A
-4C72-9DFD-BDE9A78F505D.exact=AE04147C-41BD-4B86-99E9-0DC14332ABB0 write by
set=”user/uid & [cn=admin,cn=groups,dc=my,dc=od,dc=com]/memb
erUid” write by sockurl=”ldapi://%2Fvar%2Frun%2Fldapi” write by dn.exact=”c
n=my.od.com$,cn=computers,dc=my,dc=od,dc=com”
write by * read

[/code]

where [b]635DF24E-E00A-4C72-9DFD-BDE9A78F505D[/b] is the apple-generateduid of the group whose attributes that user is allow to change
and [b]AE04147C-41BD-4B86-99E9-0DC14332ABB0[/b] is the apple-generateduid of the user able to write the apple-mcxflags and apple-mcxsettings attributes

So…. I tried to create a new ACL for a computer list so that same user would be able to write the apple-mcxflags and apple-mcxsettings attributes using the following acl:

[code]
olcAccess: {27}to dn.onelevel=”cn=computer_lists,dc=my,dc=od,dc=com” attrs=apple-mcxflags,apple-mcxsettings
by dynacl/idattr/APPLYTO:8F0F2D81-E1B9-4830-B4AB-2F854FA74422.exact=AE04147C-41BD-4B86-99E9-0DC14332ABB0 write
by set=”user/uid & [cn=admin,cn=groups,dc=my,dc=od,dc=com]/memberUid” write
by sockurl=”ldapi://%2Fvar%2Frun%2Fldapi” write
by dn.exact=”cn=its-macmgr.my.od.com$,cn=computers,dc=my,dc=od,dc=com” write
by * read

[/code]

where [b]8F0F2D81-E1B9-4830-B4AB-2F854FA74422[/b] is the apple-generateduid of the computer list I want to user to be able to change the apple-mcxflags and apple-mcxsettings attributes of
and [b]AE04147C-41BD-4B86-99E9-0DC14332ABB0[/b] is the apple-generateduid of the user able to write the apple-mcxflags and apple-mcxsettings attributes of that group

But whenever I try to add this to OD via workgroup manager (using the all records inspector) I get an error (eDSAttributeNotFound -14134) and when I try to use a directory editor (apache directory studio) I get an LDAP error 80.

Anyone else got any suggestions on this??

By the way the 3rd edition of Open_Directory_Admin_v10.5 removes any reference to Configuring Record Privileges.. must have been put in the too hard basket??