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@xxxxxxxxxxxxx> 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@xxxxxxxx > Boulder, CO 80301 http://www.nwra.com > -- > 389 users mailing list > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
