The "computerid" to add the specified Domain

Force the process (i.e., join the existing account or remove the binding)

The fully-qualified DNS name of the Domain to be used when adding the computer to the Directory (e.g. domain.ads.example.com).

Leaves the current domain (preserving the computer record in the directory).

The LDAP DN of the container to use for adding the computer. If this is not specified, it will default to the container "CN=Computers" within the domain that was specified. (e.g. "CN=Computers,DC=domain,DC=ads,DC=demo,DC=com"

Password to use in conjunction with the specified username.

Username of a Network account that has administrative privileges to add/remove this computer to/from the specified Domain

This flag determines whether the plugin allows authentication from any domain in the forest. When this is enabled, individual domains will not be visible, only "All Domains". If it is disabled, you will have the ability to select the specific domains that can authenticate to this computer. Enabled by default.

This feature is not described in the man page. Enable or disable generation of Kerberos authority

This specifies the attribute to be used for the GID of the group. By default, a group GID is generated from the Active Directory GUID of the group.

This specifies the attribute to be used for the GID of the user. By default, a GID is derived from the primaryGroupID of the user (typically Domain Users).

Use the listed groups to determine who has local administrative privileges on this computer.

This flag determines whether the plugin forces all home directories to be local to the computer (i.e. /Users/username)

This flag determines whether the plugin will enable mobile account support for offline logon.

This flag determines whether the plugin will warn the user when a mobile account is going to be created.

Sets the primary account username naming convention. By default it is set to "domain" naming which assumes no conflicting user accounts across all domains. If your Active Directory forest has conflicts setting this to "forest" will prefix all usernames with "DOMAIN\" to ensure unique naming between domains (e.g., "ADDOMAIN\user1"). Warning: this will change the primary name of the user for all logins. Changing this setting on an existing system will cause any existing homes to be unused on the local machine.

By default packet encryption is allowed but not required, but can be required or disabled (for example if debugging a problem). This ensures that the data to/from the server is encrypted and signed guaranteeing the content was not tampered with and cannot be seen by other computers on the network.

By default packet signing is allowed but not required, but can be required or disabled (for example if debugging a problem). This ensures that the data to/from the server is not tampered with by another computer before received it is received.

Set how often the computer trust account password should be changed (default 14 days).

Use the specified server for all Directory lookups and authentications. If the server is no longer available, it will fail-over to other servers.

This flag determines how a home directory is mounted on the desktop. By default SMB is used, but AFP can be used for use with Mac OS X Server or 3rd Party AFP solutions on Windows Servers

Restricts Dynamic DNS updates to specific interfaces (e.g., en0, en1, en2, etc.). To disable restrictions pass "" as the list.

Enable or disable mounting of the network home as a sharepoint.

Use the specified shell (e.g., "/bin/bash") if a shell attribute does not exist in the directory for the user logging into this computer. Use a shell value of "none" to disable use of a default shell, preserving values that are only specified in the directory.

This specifies the attribute to be used for the UID of the user. By default, a UID is generated from the Active Directory GUID.

This flag determines whether the plugin uses the UNC specified in the Active Directory when mounting the network home. If this is dis- abled, the plugin will look for Apple schema extensions to mount the home directory.

Array of Hashes containing the payload data for the profile. Each hash is a key/value store represnting the payload settings a given PayloadType.

* This content can be complicated to construct manually.
* Required Keys: PayloadIdentifier, PayloadType
* You should always include a unique PayloadIdentifier key/value
  for each Hash in the Array.
* You should always include an appropriate PayloadType key/value
  for each Hash in the Array.
* Other Payload keys (PayloadDescription, etc.) will be ignored.

Corresponds to the PayloadContent key.

String that describes what this profile does. Corresponds to the PayloadDescription key.

String displayed as the title common name for this profile. Corresponds to the PayloadDisplayName key.

String that describes the org that prodcued the profile. Corresponds to the PayloadOrganization key.

Bool: whether or not to allow the removal of the profile. Setting this to false means it can be removed. Don't blame me for the stupid double-negative name, blame Apple. Corresponds to the PayloadRemovalDisallowed key.

Name of the setup.

Setting this to true will explicitly define which users are permitted RemoteManagement privs. This means that any account not defined in the :users hash will have their privs revoked if present.

The privleges to use when the :allow_all_users bool is set to true.

Whether to enable ARD access for ALL local users of the machine.

Allow VNC guests to request permission?

Allow incoming WBEM requests over IP.

A list of directory groups allowed to access to the service.

Allow the special directory groups to be used.

Enable or disable legacy VNC support. Just a bad idea all around.

Enable or disable the ARD menu extra in the user's task bar.

A hash containing a username to privilege mapping.

The password used for VNC, stored as plain text! Thinking this is not a good idea? Yeah, me too. Don't use it.

Abstracts the Mac OS X kickstart command, allowing management of the Apple Remote Desktop features.

The name of the right or rule to be managed. Corresponds to key in Authorization Services. The key is the name of a rule. A key uses the same naming conventions as a right. The Security Server uses a rule's key to match the rule with a right. Wildcard keys end with a '.'. The generic rule has an empty key value. Any rights that do not match a specific rule use the generic rule.

Corresponds to allow-root in the authorization store. Specifies whether a right should be allowed automatically if the requesting process is running with uid == 0. AuthorizationServices defaults this attribute to false if not specified.

Corresponds to class in the authorization store; renamed due to 'class' being a reserved word in Puppet.

Corresponds to class in the authorization store; renamed due to 'class' being a reserved word in Puppet.

Corresponds to authenticate-user in the authorization store.

Boolean that indicates whether to grant a right based on the entitlement.

Boolean that indicates whether to grant a right based on the entitlement and if the user is a member of the Authorization Group (:group).

Boolean that indicates that the password should be extracted to the context.

A group which the user must authenticate as a member of. This must be a single group.

How large a subset of rule mechanisms must succeed for successful authentication. If there are 'n' mechanisms, then 'k' (the integer value of this parameter) mechanisms must succeed. The most common setting for this parameter is 1. If k-of-n is not set, then every mechanism --- that is, 'n-of-n' --- must succeed.

A sequence of suitable mechanisms to be evaluated. (Array)

Boolean require the caller to be signed by apple.

The rule(s) that this right refers to.

Whether the session owner automatically matches this rule or right. Corresponds to session-owner in the authorization store.

Whether the Security Server should mark the credentials used to gain this right as shared. The Security Server may use any shared credentials to authorize this right. For maximum security, set sharing to false so credentials stored by the Security Server for one application may not be used by another application.

The number of seconds in which the credential used by this rule will expire. For maximum security where the user must authenticate every time, set the timeout to 0. For minimum security, remove the timeout attribute so the user authenticates only once per session.

The number of tries allowed.

Boolean that indicates whether to grant a right base on the VPN entitlement and if the user is a member of the Authorization Group (:group).

Manage Mac OS X authorization database rules and rights.

Whether to overwrite the propertylist, or insert the specified data.

  This behaviour demands a detailed explanation, because it's not as simple
  as it sounds. First, a little about PropertyLists in general...

  As most OS X administrators are aware, PropertyLists usually take the
  form of a Dictionary, but they can actually be used to archive ANY of the
  primitive data types supported by ObjC: NSDictionary, NSArray, NSData,
  NSDate, NSString, etc.

  However, the thing that all PropertyLists have in common is that they may
  only ever contain a single root object.

  What does this mean? It means that if your Plist is storing an Integer,
  _that_ is the only value it can hold.

  Example:

    <plist version="1.0">
      <integer>1</integer>
    </plist>

  That is a valid PropertyList containing a single value.

  "But wait!" you say, "I know that I can have mutiple values in a
  PropertyList, just look at any of the files stored in
  /Library/Preferences."

  This is true, you can store as many values as you wish a in PropertyList,
  but just like plain old XML, you can only ever have ONE ROOT ELEMENT.

  This means that in order to store multiple values in a PropertyList, you
  will need to use a compound data type such as a <\dict> or an <\array>
  as the ROOT element.

  Example (dictionary):

    <plist version="1.0">
      <dict>
        <key>foo</key>
        <integer>99</integer>
        <key>bar</key>
        <integer>42</integer>
        <key>baz</key>
        <string>This is a string.</string>
      </dict>
    </plist>

  Example (array):

    <plist version="1.0">
      <array>
        <string>A string.</string>
        <string>Another string.</string>
        <integer>42</integer>
      </array>
    </plist>

  These complex data types allow you store multiple values as a single
  root object. In addition, you can also modify the elements in an Array or
  Dictionary without disturbing the remaining data.

  This is where the :method parameter for this Puppet Type comes into play.

  We use it to control two modes of operation for the creation and
  management of the PropertyList on disk:

  1. Replace (:replace)

  This is the default mode. In this mode, the data you specify in Puppet or
  another data source like Hiera, will be the only data in the Plist. It
  is absolute. If the Plist you are managing deviates in ANY way from the
  content specified in your Puppet resource, it will be overwritten.

  For example, let's say you are managing a Plist in /Library/Preferences
  (this is _not_ a good idea, see :providers documentation) named...

  com.apple.loginwindow.plist

  By managing this file in :replace mode, you are committed to managing the
  file in totality -- every key, every value. But, as we know, this file
  gets modified any time somebody logs in or out of the computer.

  This means that on any given Puppet run, this file is extremely likely to
  be reverted to the originally desired state.

  This is a good thing, if that's what you want, but chances are this
  behaviour is less than optimal (noisy and unnecessary).

  Maybe you only wish to manage particular keys/values inside the file???

  2. Insert (:insert)

  This is an optional mode and it must be expressly set in your resource
  declaration. Examine this Puppet code...

    # A Puppet Hash ("dictionary") containing a single key/value combo. In
    # this case, we want to control the value LoginwindowText and present
    # our users with a "special" message.
    $content = { LoginwindowText => 'A message to you, Rudy.' }

    # Here is our resource declaration, but notice that we have set the
    # :method parameter to :insert
    propertylist { '/Library/Preferences/com.apple.loginwindow.plist':
      ensure  => present,
      group   => 'staff',
      mode    => '0644',
      owner   => 'root',
      content => $content,
      method  => insert,
    }

  So, what does this accomplish?

  What we are in fact saying to Puppet is the following...

    "I want to make sure this file exists. If not, create it."
    "I want to make sure this file's owner, group and mode are set
    accordingly."
    "I want to make sure the content of this file is a dictionary that
     contains the key 'LoginwindowText' and that key has a value of...
     'A message to you, Rudy.'
     You can ignore the other portions of the file's content. Thanks."

  This is what :insert mode does. It inserts the content you define into
  the file leaving the other stuff unmolested.

  Of course, if you try to insert data and there is a mismatch between the
  root objects in the PropertyList, you will get an error. For example,
  let's say we tried the following...

    # A simple Puppet Array variable, full of Integers
    $content = [1, 2, 3, 4, 5]

    # Some non-essential params removed
    propertylist { '/Library/Preferences/com.apple.loginwindow.plist':
      content => $content,
      method  => insert,
    }

  Here, we know com.apple.loginwindow.plist exists -- it always does.
  We also know that it's root object is a <\dict> -- it always is.

  But we were careless and we have attempted to use an Array as the root
  object while in :insert mode. In :replace mode, this would work the
  contents of the file would be overwritten with the $content array
  destroying the integrity of the file and possibly destabilizing the
  system -- don't do this -- but it _would_ work.

  However, in :insert mode you would receive an error that looks like
  this...

    'Could not evaluate: no implicit conversion of Array into Hash'

  This means you tried to replace the root object (currently a <\dict>)
  with an <\array> and Puppet has stopped you. Thanks, Puppet.

  Now, this whole scenario is a bit far-fetched, but it does illustrate
  the need to be DECISIVELY AWARE of HOW and WHAT you are
  choosing to manage, so you can avoid errors (and poetntial disasters).

  There is one more intersting characteristic of managing PropertyLists
  that has to do with Arrays as root objects...

  Arrays are ordered lists.

    $content = [1, 2, 3, 4, 5]

  This array has 5 elements. Let's create a PropertyList with it.

    propertylist { '/Users/Shared/foo.plist':
      format  => xml,
      content => $content,
      method  => insert,
    }

  Ok, great. We should now have a PropertyList that looks like this...

    <plist version="1.0">
      <array>
        <integer>1</integer>
        <integer>2</integer>
        <integer>3</integer>
        <integer>4</integer>
        <integer>5</integer>
      </array>
    </plist>

  So, what if we want to delete a value? Let's say we want to remove the
  fourth element of the array...

    $content = [1, 2, 3, 5]

    propertylist { '/Users/Shared/foo.plist':
      format  => xml,
      content => $content,
      method  => insert,
    }

  Now let's inspect our PropertyList...

    <plist version="1.0">
      <array>
        <integer>1</integer>
        <integer>2</integer>
        <integer>3</integer>
        <integer>5</integer>
        <integer>5</integer>
      </array>
    </plist>

  What happened??? Do you see the problem?

  Let's break it down...

  1. We are in insert mode, this implies we are going to ignore extraneous
  data and only manage what we are told to.

  2. Arrays are ordered lists. The only thing unique about array elements
  is its index (ie. what order it is in).

  3. We shortened the $content array from 5 elements to 4 elements! When
  we did this, we essentially redefined what the first four elements of the
  root object Array should be and since we were in :insert mode, the
  leftover element got ignored -- even though it was a duplicate value!!!

  Weird as it may seem, this is how :insert mode operates on Arrays as root
  objects. You need to be aware of this behaviour.

  Luckily, most PropertyLists DO NOT use Arrays as root objects. Off the
  top my head I can only think of one that does and it is not something
  that can be managed as a file-on-disk. FTR: the output of
  /usr/sbin/system_profiler produces an XML PropertyList that uses an
  Array as the root object.

The path to the file to manage. Must be fully qualified.

The file's content, whole or in part as a Puppet data type.

  Plist content can be managed in whole or in part. Default mode is
  wholesale management -- see the :method documentation for exhaustive
  details.

  Usually, the most convenient of handling this is property is to jam
  the desired state into a Puppet variable and use that in the resource
  declaration. It's tidy.

  Example:

    $content = { LoginwindowText => 'A message to you, Rudy.' }

    propertylist { '/Library/Preferences/com.apple.loginwindow.plist':
      ensure  => present,
      method  => insert,
      content => $content,
    }

The PropertyList format the file should use, binary (default) or xml.

  CAUTION: Setting this parameter can cause undue resource modification
  during a Puppet run. Puppet will enforce the file format. If your
  selected format differs from what OS X expects it to be, you could get
  annoying conversion cycles.

Which group that should own the file. Argument should be a group name. Default is wheel.

  NOTE: The group name is NOT pre-validated.

The desired permissions for the file using standard four-digit octal notation.

The user to whom the file should belong. Argument should be a user name. Default is root.

  NOTE: The user name is NOT pre-validated.

The resource name.

Corresponds to the RecordName/name attribute.

How to handle membership in the users and nestedgroups arrays.

  A Boolean value that informs the provider whether to merge the
  specified members into the record, or replace them outright.

  This parameter controls the behavior of BOTH the users and nestedgroups
  arrays.

  By default, the users and nestedgroups arrays will be PURGED and replaced
  by whatever you specify in the resource (ie. strict => true).

  Still, this isn't always what you want. Sometimes, you simply want to
  ensure that the users/groups you specify in the resource are members, and
  ignore any other records in the list(s).

  To accomplish this, you can set the strict parameter to false.

  Default is :true (purge)

String that describes the group's purpose.

  Corresponds to the Comment/comment attribute.

  Default is :absent.

The numeric ID for the Group.

  Corresponds to the PrimaryGroupID/gid attribute.

  If you create a new group and do not specify a GID, one will be selected
  for you. However, this is not recommended as it cannot guarantee GID
  specification across a collection of machines. For example, if the same
  resource were applied to two different machines, the GID could not be
  guaranteed to be the same on both, unless you were to configure this
  parameter.

  By the same token, if you do specify a GID parameter, you must ensure
  that the GID will not collide with existing groups on the machine --
  especially built-ins.

  Default is :absent.

A list of groups you want nested inside the group.

  Corresponds to the NestedGroups/nestedgroups attribute.

  Note: this attribute lists membership according the record's GeneratedUID,
  not the record's' name like the user list.

  Membership is managed wholesale, that is, it's purged prior to
  modification unless you set strict => false.

  Please see the documentation on :strict _before_ using this feature.

  To specify nested groups, you pass an Array of:

  a) Group Names   (ie. "admin", "staff", etc.)
  b) GeneratedUIDs (ie. "ABCDEFAB-CDEF-ABCD-EFAB-CDEF00000050", etc.)
  c) A mix of both (ie. "ABCDEFAB-CDEF-ABCD-EFAB-CDEF00000050", "staff")

  When you provide a list of group names, the Macgroup type will attempt to
  resolve the record to its associated GeneratedUID. This is IMPORTANT to
  keep in mind when referring to external node records (ie. LDAP or AD). If
  it cannot resolve the record name to GeneratedUID, the Magroup type will
  generate a warning and _skip_ configuration of the unresolvable record.

  Like the user membership control, this "warn and continue" style of
  resource management is sub-optimal, but provides greater resilience
  during temporary outages.

  For this reason, it is recommended that you list nestegroups according to
  their respective GeneratedUIDs and NOT the record names as this will
  provide the greatest stability (and less log noise).

  Note: an empty list is not the same as an absent one. An absent list
  implies that the attribute is unmanaged, while an empty list _is_ managed
  and will create and empty list... Use caution.

  Default is :absent (no management)

Optional string value that declares the group's RealName.

  Corresponds to the RealName/realname attribute.

  Default is :absent.

The list of users you want added to the group.

  Corresponds to the GroupMembership/users attribute.

  Membership is managed wholesale, that is, it's purged prior to
  modification unless you set strict => false.

  Please see the documentation on :strict _before_ using this feature.

  To specify users, you pass an Array of user names. The provider will warn
  about an invalid user account, but it will apply the configuration
  anyway. This is to prevent temporary OpenDirectory or network outages
  from wreaking havoc with your Puppet config.

  Note: an empty list is not the same as an absent one. An absent list
  implies that the attribute is unmanaged, while an empty list _is_ managed
  and will create and empty list... Use caution.

  Default is :absent (no management)