4:26 p.m.
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/serve...
Does anyone know of tools that would populate the various apple specific
entries like apple-generateduid?
Thanks!
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
4:49 p.m.
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/serve...
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
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' )
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
5:49 p.m.
New subject: UUIDs
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/serve...
Does anyone know of tools that would populate the various apple specific
entries like apple-generateduid?
Thanks!
One of the things pushing me down this road is that with Mountain Lion,
apparently accessing certain System Prefences would crash if the user didn't
have a "GeneratedUID" attribute. See this for details:
https://discussions.apple.com/message/2070212
This highlights the crazy balkanization with LDAP that drives me bonkers. So
the idea of every user having a UUID (which is what GeneratedUID is) seems
like a reasonable idea and might be useful in general for all users. But we
end up with an "apple-user" schema with an "apple-generateduid"
attribute that
will clearly be apple specific.
Apparently there is an RFC for an "entryUUID" attribute:
http://tools.ietf.org/html/rfc4530
Which seems like an interesting idea. Did this get anywhere?
Apparently there is an opends plugin:
http://docs.oracle.com/cd/E19476-01/821-0507/entry-uuid-plugin.html
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
9:37 a.m.
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/serve...
>
>
>
> 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.
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
11:57 a.m.
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/serve...
>>
>>
>>
>> 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(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
5:57 p.m.
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(a)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/serve...
>>>
>>>
>>>
>>> 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(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
4123
days inactive
4131
days old
389-users@lists.fedoraproject.org
5 comments
3 participants
participants (3)
-
Orion Poplawski -
Paul Robert Marino -
Rich Megginson