[389-users] Support for apple OS X schema?

[Paul Robert Marino]

its been a long time since I played with this but generally you can
exclude the apple version of the field, because if its not included in
the mapping on the Apple client then the client will ignore it.
I did this back in 2002 with a SuSE Open Exchange server running
OpenLDAP and ran into more conflicts than you did. The trick is you
need to make a custom mapping on the clients. there is an XML file for
each of the standard templates. You can Apple directory template as a
start to write your own template, but I cant remember the names of
them off the top of my head.
As far as the fields be warned just because you have the fields
doesn't mean the admin tools will work out of the box, most of them
will not function with a non apple directory server, however they are
fairly easy to generate. most of the apple policy fields contain
base64 encoded XML files. also those XML files can contain fields with
more base64 encoded XML files. What I use to do is generate examples
and on local workstations, dump the local database via the command
line tools, and write template driven scripts to generate custom LDIF
based on what I revere engineered from them.

Ill look at some of my old external hard drives this weekend. I may
have copies of some of the scripts or some of my old notes on the
subject on one of them assuming they still spin up.

Oh and on Redhat like versions of linux there are several tools to
generate uuids like the uuid command and the uuidgen command. the
question is does apple leave them raw or or encode them as base64. I
havent looked at thier implementations for nearly a decade but they
use to be overly base64 happy.


On Thu, Jan 3, 2013 at 12:57 PM, Orion Poplawski <orion at cora.nwra.com> wrote:
> On 01/03/2013 08:37 AM, Rich Megginson wrote:
>>
>> On 12/27/2012 03:49 PM, Orion Poplawski wrote:
>>>
>>> On 12/27/2012 03:26 PM, Orion Poplawski wrote:
>>>>
>>>> Has any work been done towards supporting Apple OS X ldap schema in 389?
>>>> It
>>>> seems like this is the latest OpenLDAP schema for Apple:
>>>>
>>>>
>>>> http://opensource.apple.com/source/OpenLDAP/OpenLDAP-208.1/OpenLDAP/servers/slapd/schema/apple.schema
>>>>
>>>>
>>>>
>>>> Does anyone know of tools that would populate the various apple specific
>>>> entries like apple-generateduid?
>>>>
>>>> Thanks!
>>>>
>>>
>>> For what it is worth - I ran it through ol-schema-migrate.pl and got the
>>> attached file.  But doesn't work:
>>>
>>> Starting dirsrv:
>>>     cora-ldap2...[27/Dec/2012:15:43:01 -0700] attr_syntax_create - Error:
>>> the SUBSTR matching rule [caseExactIA5SubstringsMatch] is not compatible
>>> with the syntax [1.3.6.1.4.1.1466.115.121.1.24] for the attribute
>>> [apple-birthday]
>>> [27/Dec/2012:15:43:01 -0700] dse_read_one_file - The entry cn=schema in
>>> file
>>> /etc/dirsrv/slapd-cora-ldap2/schema/99apple.ldif (lineno: 1) is invalid,
>>> error code 20 (Type or value exists) - attribute type lastLoginTime: Does
>>> not match the OID "1.3.6.1.1.1.1.35". Another attribute type is already
>>> using the name or OID.
>>>
>>> The first looks like incompatibility between:
>>>
>>>   EQUALITY generalizedTimeMatch
>>>   SUBSTR caseExactIA5SubstringsMatch
>>
>>
>> Right.
>>
>>>
>>> but I'm not familiar with this.
>>>
>>> lastLoginTime is in 60acctpolicy.ldif:
>>>
>>> ## lastLoginTime holds login state in user entries (GeneralizedTime
>>> syntax)
>>> attributeTypes: ( 2.16.840.1.113719.1.1.4.1.35 NAME 'lastLoginTime'
>>>   DESC 'Last login time'
>>>   SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
>>> directoryOperation
>>>   X-ORIGIN 'Account Policy Plugin' )
>>
>>
>> Arg.  This is the problem of using non-standard schema (both in Apple's
>> case
>> and in our case).  Both Apple and 389 defined the lastLoginTime attribute,
>> and
>> unfortunately they are different.
>>
>> I suppose you could just remove 60acctpolicy.ldif from your schema
>> directory
>> if you want to use the Apple schema.  But then you won't be able to use
>> the
>> Account Policy Plugin to keep track of last login time and account
>> expiration.
>
>
> If I go this route I'll likely just use a small subject of the Apple schema.
>
>
>
> --
> Orion Poplawski
> Technical Manager                     303-415-9701 x222
> NWRA, Boulder Office                  FAX: 303-415-9702
> 3380 Mitchell Lane                       orion at nwra.com
> Boulder, CO 80301                   http://www.nwra.com
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users