3.2.5.1.4 Generating Managed Object Data

This section describes the process for populating the object data attribute of a managed object entry. The object data contains a base64-encoded string representing a serialized managed object. Section 2.2.2.2.10 defines the schema for various managed objects used in this protocol. A managed object consists of an object header as defined in section 2.2.2.2.12, a body which varies with each managed object type, and a signature part as defined in section 2.2.2.2.13. The process for populating managed object data has three steps.

Step 1: Populate Managed Object Header

The managed object header contains information about the object and the domain managing the object.

Section 2.2.2.2.9 defines the schema for the management domain information contained in the header. The management domain information is identical for all managed objects in that domain. The content for the management domain information references the management domain and the management server entry specified in the abstract data model.

Section 2.2.2.2.12 defines the schema for the managed object header. The attribute values differ for each managed object as defined in the following tables:

Account Services Policy

Component Update Policy

Data Recovery Policy

Device Policy

Domain Trust Policy Object

Identity Object

Identity Policy Object

PassphrasePolicy

Step 2: Populate Managed Object Body

There are two types of managed objects: a policy object and an identity object. A management server administrator sets the content for a policy object, while a member entry defined in the abstract data model provides the data for an identity object.

Managed objects are stored in managed object collections as defined in the abstract data model. Each entry in the collection contains object data representing the managed object. Any changes to a policy or a member attribute MUST result in an updated managed object data.

Account Services Policy

Section 2.2.2.2.10.1 defines the schema for this managed object.

Component Update Policy

Section 2.2.2.2.10.2 defines the schema for this managed object.

If the component update policy is set to "Allow", the client is allowed for component updates over the Internet. If the policy is set to "Deny", the client is not allowed for component updates. If the policy is set to "Local", the client is allowed for component updates on the local system.

Data Recovery Policy

Section 2.2.2.2.10.3 defines the schema for this managed object. Any changes to the policy attribute or management domain's data recovery certificate MUST result in an updated managed object data.

Device Policy

Section 2.2.2.2.10.4 defines the schema for this managed object.

Domain Trust Policy

Section 2.2.2.2.10.5 defines the schema for this managed object. Each policy MUST contain one item to establish a cross-domain trust relationship. Multiple domain trust policies MUST be used to establish cross-domain trust relationships with more than one domain. Any changes to the management domain's name or certified authority name MUST result in an updated managed object data.

Identity

Section 2.2.2.2.10.6 defines the schema for this managed object. This managed object represents a member entry as defined in the abstract data model. The data for generating this managed object is provided by the management domain, members, relay server sets, and relay server entries specified in the abstract data model. Any changes to the member attributes or relay server provisioning MUST result in an updated managed object data. Instructions for populating the identity template are given in the following table:

XPath	Description
/fragment/ManagedObject/Body/IdentityTemplate	Identity template element.
/fragment/ManagedObject/Body/IdentityTemplate/@Flags	MUST be one of the following values: 1: Valid member if the member status is active or pending. 3: Disabled member if the member status is disabled.
/fragment/ManagedObject/Body/IdentityTemplate/ManagementDomainMigration	This element MUST be present if and only if the member's migration status is true .
/fragment/ManagedObject/Body/IdentityTemplate/ManagementDomainMigration/@ServerURL	MUST be member's migration server URL .
/fragment/ManagedObject/Body/Contact	Contact element containing signed information about the member VCARD, relay and presence server assignments, and management domain information.
/fragment/ManagedObject/Body/Contact/VCard	vCard element.
/fragment/ManagedObject/Body/Contact/VCard/@Data	This base64 encoded UTF-8 string contains the member's VCARD data in the following format:  BEGIN:VCARD  VERSION:2.1  CS:UTF-8  FN: [[- FN -]]  N:[[- N -]]  EMAIL;PREF;INTERNET:[[- EMAIL -]]  TITLE:[[- ORG Title -]]  ORG:[[- ORG -]]  ADR;POSTAL;WORK:[[- ORG ADDRESS -]]  TEL;WORK;VOICE:[[- ORG PHONE NUMBER -]]  TEL;PAGER:[[- ORG CELL PHONE NUMBER -]]  TEL;WORK;FAX:[[- ORG FAX NUMBER -]]  END:VCARD  [[- FN –]]: Member's full name. [[- Email -]]: E-mail address of the member.  [[- N -]] : If first name and last name are present, this field MUST be created by concatenating the first name, comma, and last name. If only the last name is present, this field MUST represent the last name. [[- ORG TITLE -]]: Member's title. [[- ORG -]]: Name of the organization the member belongs to. [[- ORG ADDRESS-]]: MUST be created by concatenating  the member's Org Street 1, comma, Org Street 2, comma, Org City, comma, Org State, comma, Org Postal Code, comma, and Org Country. [[- ORG PHONE NUMBER -]]: Member's business phone number. [[- ORG CELL PHONE NUMBER -]]: Member's business cell phone number. [[- ORG FAX NUMBER -]]: Member's business fax number. VCARD is extensible by client; server will only process the preceding fields.
/fragment/ManagedObject/Body/Contact/RelayDevices	This element and sub elements represent relay servers provisioned to the member. Member's relay server set provides the information for this element.
/fragment/ManagedObject/Body/Contact/RelayDevices/RelayDevice	There MUST be a relay device element for each relay server associated with member's relay server set. The sequence number (RSG Sequence) of the relay server governs the order of relay devices.
/fragment/ManagedObject/Body/Contact/RelayDevices/RelayDevice/@AuthorizationToken	MUST be the member's Pre-authentication token.
/fragment/ManagedObject/Body/Contact/RelayDevices/RelayDevice/@Certificate	MUST be the Relay Server's SSTP certificate
/fragment/ManagedObject/Body/Contact/RelayDevices/RelayDevice/@URL	MUST be the Relay Server's device URL.
/fragment/ManagedObject/Body/Contact/PresenceDevices	This element and sub elements represent relay servers provisioned to the member. The member's relay server set provides the information for this element. PresenceDevices and RelayDevices MUST specify the same devices in the same order. Each element of these lists MUST be the identical URL, Certificate, and AuthorizationToken as the corresponding element of the other list.
/fragment/ManagedObject/Body/Contact/PresenceDevices/PresenceDevice	There MUST a presence server device element for each relay server associated with the member's relay server set. The sequence number (RSG Sequence) of the relay server governs the order of presence server devices.
/fragment/ManagedObject/Body/Contact/PresenceDevices/PresenceDevice/@URL	MUST be the Relay Server's device URL.
/fragment/ManagedObject/Body/Contact/PresenceDevices/PresenceDevice/@Certificate	MUST be the Relay Server's SSTP certificate.
/fragment/ManagedObject/Body/Contact/PresenceDevices/PresenceDevice/@AuthorizationToken	MUST be the member's Pre-authentication token.
/fragment/ManagedObject/Body/Contact/CustomFields	This element MUST only be present for a member who has finished the enrollment process.
/fragment/ManagedObject/Body/Contact/CustomFields/@_95_95Affiliation	MUST be the member's affiliation attribute as defined in section 3.2.5.1.5.
/fragment/ManagedObject/Body/Contact/CustomFields/@_95_95_95Affiliation_95Flags	This value MUST be 0x4000000.
/fragment/ManagedObject/Body/Origin	This element MUST be present for a member who has finished the enrollment process. The element data is copied from the member's contact security.
/fragment/ManagedObject/Body/Origin/ManagementDomain	This element MUST be present for a member who has finished the enrollment process. The element data is copied from the member's contact security.
/fragment/ManagedObject/Body/Contact/Certificate	This element MUST be present for a member who has finished the enrollment process and the management domain is not using Enterprise PKI.
/fragment/ManagedObject/Body/Contact/Certificate/@ExpirationDate	MUST be the certificate expiration date in milliseconds since midnight 01/01/1970.
/fragment/ManagedObject/Body/Contact/Certificate/@SignerAddress	MUST be the server URL of the management server.
/fragment/ManagedObject/Body/Contact/Certificate/@SignerKeyHash	The value MUST be the SHA1 hash of the DER-encoded signature public key from the domain certificate.
/fragment/ManagedObject/Body/Contact/Certificate/@Signature	The management server MUST implement the following rules to generate the signature: The contact element MUST only contain the following elements: vCard element CustomFields element Origin element ManagementDomain element Certificate element Serialize contact element as XML, with UTF-8 encoding and sorted attributes. Compute the SHA1 hash of the serialized contact element. Generate the signature by signing the SHA1 hash with the signature private key from the domain's certificate using the RSA algorithm.

Identity Policy

Section 2.2.2.2.10.7 defines the schema for this managed object.

Passphrase Policy

Section 2.2.2.2.10.8 defines the schema for this managed object. The management server MUST implement the following rules for constructing the "vector" attribute value:

• The value MUST be a comma-separated list of integers.

• Each integer's string representation MUST be between 1 and 9 characters long.

• The final integer MUST not have anything after it (such as no comma after the final integer).

• The client uses the number of failed logon attempts as an index into this array of integers. Negative elements of this array are ignored for this purpose.

• Integer values MUST be positive, nonzero, and monotonically increase.

• Each value specifies the delay in seconds that the client waits before allowing the next logon attempt after a failed attempt.

• If the number of failed logon attempts exceeds the size of the vector, the last positive entry is used.

• Negative integer values are allowed as follows:

  • Each negative value MUST occur no more than once.

  • A value of -1 specifies that the client is to lockout the account (once the number of failed logon attempts is greater than the index of this value). If the value -1 is present in a list, it MUST be the last value in the list.

  • A value of -3 specifies that the client SHOULD display a message about delay because of failed logon attempts (once the number of failed logon attempts is greater than the index of this value).

  • All other negative values are reserved and MUST not be used.

Step 3: Securing the Managed Object

Section 2.2.2.2.13 defines the content of the security element. Instructions for populating the security element are given in the following table: