PMDF System Manager's Guide
PMDF-REF-6.0

The attribute schema used by the sample acme.com site is based upon LDAP attributes, and is effectively a superset of the attributes used by the IDDS and MS Exchange LDAP directories, (though the IDDS objectClass attribute is omitted from the canonical schema). The canonical LDIF attributes are:

Canonical LDIF

attribute Description

DN Distinguished name: the attribute uniquely identifying this directory entry

cn Common name: the person's name

sn Surname: the person's family (last) name

uid User identifier/account name

mail E-mail address

telephoneNumber Telephone number

facsimileTelephoneNumber FAX telephone number

seeAlso Pointer to another LDAP entry relating to this person

userPassword Person's password

description A descriptive phrase

otherMailbox Another e-mail address for the person

MAPI-Recipient Whether the person is a MAPI (Microsoft) recipient

These canonical attributes are the same as the correspondingly named IDDS LDAP attributes, supplemented by any additional MS Exchange LDAP attributes such as MAPI-Recipient. Some additional IDDS attributes that we do not care to retain, such as lastModifiedTime and lastModifiedDate, are not canonical and will be discarded by the PMDF-DIRSYNC processing. All the canonical attributes except for MAPI-Recipient will be included for differencing. The MAPI-Recipient attribute, on the other hand, is excluded from differencing. The MAPI-Recipient attribute is propogated through so that entries from MS Exchange going back to MS Exchange will retain their original MAPI-Recipient attribute value, but the attribute is otherwise not used by the PMDF-DIRSYNC processing.

Canonical LDIF
attribute	Description
DN	Distinguished name: the attribute uniquely identifying this directory entry
cn	Common name: the person's name
sn	Surname: the person's family (last) name
uid	User identifier/account name
mail	E-mail address
telephoneNumber	Telephone number
facsimileTelephoneNumber	FAX telephone number
seeAlso	Pointer to another LDAP entry relating to this person
userPassword	Person's password
description	A descriptive phrase
otherMailbox	Another e-mail address for the person
MAPI-Recipient	Whether the person is a MAPI (Microsoft) recipient

The canonical attributes map naturally with the MS Exchange LDAP native attributes, as all joint attributes have the same format except for DN: the canonical DN attribute has the format of the IDDS DN attribute, so MS Exchange DN attributes must be converted between the canonical and MS Exchange native format. So for MS Exchange, the attribute mapping between MS Exchange attributes and canonical attributes is as follows:

MS Exchange native attribute Cook Canonical LDIF attribute

function of dn plus ou=exchange,o=acme,c=nz --> DN

all other attributes remain as is ||

Canonical LDIF attribute Serve MS Exchange native attribute

function of DN plus cn=recipients --> dn

all other attributes remain as is ||

For ALL-IN-1, the attribute mapping between native ALL-IN-1 attributes and canonical LDIF attributes is as follows:

ALL-IN-1 PROFILE native attribute Cook Canonical LDIF attribute

cn='fulname',ou=a1,o=Acme,c=NZ --> DN

fulname --> cn

surname1 --> sn

vmsuser --> uid

rfc822addr --> mail

phone --> telephoneNumber

Canonical LDIF attribute Serve ALL-IN-1 NETWORK native attribute

uid --> user

cn --> fulname

ou field of DN --> depart

mail --> rfc822addr

telephoneNumber --> phone

Additional native ALL-IN-1 attributes are discarded.

MS Exchange native attribute	Cook	Canonical LDIF attribute
function of dn plus ou=exchange,o=acme,c=nz	-->	DN
all other attributes remain as is \|\|

Canonical LDIF attribute	Serve	MS Exchange native attribute
function of DN plus cn=recipients	-->	dn
all other attributes remain as is \|\|

ALL-IN-1 PROFILE native attribute	Cook	Canonical LDIF attribute
cn='fulname',ou=a1,o=Acme,c=NZ	-->	DN
fulname	-->	cn
surname1	-->	sn
vmsuser	-->	uid
rfc822addr	-->	mail
phone	-->	telephoneNumber

Canonical LDIF attribute	Serve	ALL-IN-1 NETWORK native attribute
uid	-->	user
cn	-->	fulname
ou field of DN	-->	depart
mail	-->	rfc822addr
telephoneNumber	-->	phone

When thinking about recipe files, for concreteness it can be helpful to see samples of actual LDIF files; see Section 36.9.1.2 below.

Sample recipe files for cooking and serving IDDS are shown in Example 36-20 and Example 36-21 .

Example 36-20 Samplecook_idds.rcpfile

if ((explodedDN[4] != "exchange") && (explodedDN[4] != "a1")) 
 authoritative = 1 
template 
DN: 'dn' 
cn: 'cn' 
sn: 'sn' 
telephoneNumber: 'telephoneNumber' 
facsimileTelephoneNumber: 'facsimileTelephoneNumber' 
seeAlso: 'seeAlso' 
userPassword: 'userPassword' 
uid: 'uid' 
mail: 'mail' 
otherMailbox: 'otherMailbox' 
description: 'description' 
endtemplate

Example 36-21 Sampleserve_idds.rcpfile

tag = gettag(DN); 
if (tag[2]=="!") 
{ 
template 
dn: 'DN' 
endtemplate 
} 
else 
{ 
template 
dn: 'DN' 
objectClass: top 
objectClass: person 
objectClass: organizationalPerson 
objectClass: pilotObject 
objectClass: newPilotPerson 
objectClass: pmdfPerson 
objectClass: quipuObject 
cn: 'cn' 
sn: 'sn' 
telephoneNumber: 'telephoneNumber' 
facsimileTelephoneNumber: 'facsimileTelephoneNumber' 
seeAlso: 'seeAlso' 
userPassword: 'userPassword' 
uid: 'uid' 
mail: 'mail' 
otherMailbox: 'otherMailbox' 
description: 'description' 
endtemplate 
}

Sample recipe files for cooking and serving MS Exchange LDAP are shown in Example 36-22 and Example 36-23 .

Example 36-22 Samplecook_exchange.rcpfile

# 
#  the only real manipulation required here is with the dn 
# 
dn_bits = {"cn", explodeddn[2], "ou", "exchange", "o", "acme", "c", "nz"}; 
idds_dn = makedn(dn_bits); 
if (explodeddn[4] == "recipients") 
 authoritative = 1; 
 
template 
dn: 'idds_dn' 
cn: 'cn' 
sn: 'sn' 
telephoneNumber: 'telephoneNumber' 
facsimileTelephoneNumber: 'facsimileTelephoneNumber' 
seeAlso: 'seeAlso' 
userPassword: 'userPassword' 
uid: 'uid' 
mail: 'mail' 
otherMailbox: 'otherMailbox' 
MAPI-Recipient: 'MAPI_Recipient' 
authoritative: 'authoritative' 
endtemplate

Example 36-23 Sampleserve_exchange.rcpfile

# 
# Only real manipulation is converting the IDDS canonical dn back into 
# MS Exchange dn 
# 
dn_bits = {"cn",explodedDN[2],"cn","Recipients","ou","ACME-HQ","o","Acme"}; 
exchange_dn = makedn(dn_bits); 
tag = gettag(dn); 
settag(exchange_dn,tag); 
if (tag[2]=="!") 
{ 
template 
dn: 'exchange_dn' 
endtemplate 
} 
else 
{ 
template 
DN: 'exchange_dn' 
objectClass: organizationalPerson 
objectClass: person 
objectClass: top 
cn: 'cn' 
mail: 'mail' 
otherMailbox: 'otherMailbox' 
uid: 'uid' 
sn: 'sn' 
telephoneNumber: 'telephoneNumber' 
facsimileTelephoneNumber: 'facsimileTelephoneNumber' 
seeAlso: 'seeAlso' 
userPassword: 'userPassword' 
MAPI-Recipient: 'MAPI_Recipient' 
endtemplate 
}

Sample recipe files for cooking ALL-IN-1 PROFILE data and serving ALL-IN-1 NETWORK data are shown in Example 36-24 and Example 36-25 .

Example 36-24 Samplecook_a1.rcpfile

dn_parts = {"cn", fulname[1], "ou", "a1", "o", "acme", "c", "NZ"}; 
dn = makeDN(dn_parts); 
 
template 
DN: 'dn' 
cn: 'fulname' 
sn: 'surname1' 
uid: 'vmsusr' 
mail: 'rfc822addr' 
telephoneNumber: 'phone' 
authoritative: 1 
endtemplate

Example 36-25 Sampleserve_a1.rcpfile

depart = explodeddn[4]; 
template 
user: 'uid' 
fulnam: 'cn' 
depart: 'depart' 
rfc822addr: 'mail' 
phone: 'telephoneNumber' 
endtemplate

Previous | Next | Contents

PMDF System Manager's GuidePMDF-REF-6.0

PMDF System Manager's Guide
PMDF-REF-6.0