I wanted to expose additional attributes to the Unique Resource Data for an Active Directory target. Turns out, for Active Directory, you CAN. For other targets, you can’t.
Generally, the attributes you see are the attributes that the connector supports. The one connector you provided in your example is the only that has away to add attributes. Please review this part of the documentation for the specifics. In the “Configuring Workflows with the Enterprise Provisioning Suite Administration Manager” see page 510.
Extending the Connector to Support Additional Auxiliary Attributes You can add support for additional auxiliary attributes for use in the provisioning platform for the create/add actions, by editing the file /Program Files/Courion Corporation/CourionService/ADAuxAttrs.XML
You can define whether the attribute added is “virtual” and just used to collect data or whether it is actually going to be used to SET and GET values on the AD domain target.
A backup copy of ADAuxAttrs.XML was made, and the file was modified to this:
<!– Add your auxiliary attributes here…
Set the XML attribute “provision” to “yes” to make this auxiliary attribute active during the provisioning process (AD connector will Set/Get this attr).
Set the XML attribute “provision” to “no” to make this auxiliary attribute a placehold that acts as a simple data collector for the workflow (AD connector will ignore this attr).
socialSecurityNumber
simpleDataCollectorAttribute
–>
Company
mailNickname
msExchHideFromAddressLists
msExchHomeServerName
homeMDB
This had the desired effect of exposing the attributes so that they could be set. Note that each value must explicitly be entered.
However – it appears that a valid value MUST be passed to active directory – otherwise an error message is generated. Even for those attributes that we do not want to set – for instance, users who do not get a valid email address.
In the case of the msExchHideFromAddressLists, a follow up email from Courion reveals another concern:
If you set it as a Boolean, then the workflow will try to apply the value “on” or “off”.
A Google search revealed that for the LDAP representation of that attribute it expects TRUE or FALSE.
This error message indicates that the LDAP layer rejected the value.
Error 0x8007200b: The attribute syntax specified to the directory service is invalid. — Extended Error — LDAP Provider : 00000057: LdapErr: DSID-0C090A85, comment: Error in attribute conversion operation, data 0, vece
The Google search revealed that a value of “NOT SET” is also accepted. That might help the accounts that don’t have it.
I haven’t configured that specific attribute in ADAUXATTRS.XML, so some trial and error may be need.
Therefore, the following parameters are being handled like this:
mailNickname Set to SAMAccountName for all users
msExchHideFromAddressLists Not being manipulated until the yes/no true/false issue can be resolved
msExchHomeServerName Set to the home server for the user, based on last name, IF they get an email. If they do not get an email address, setting it to “Not Set”
homeMDB Set to the homeMDB for the user, based on last name, IF they get an email. If they do not get an email address, setting it to “Not Set”
UPDATE ==========
If you put the msExchHideFromAddressLists as TEXT, and type in either TRUE or FALSE (as text), it works. You would expect it to accept a boolean, but it does not.
Dan's Tips 