Active Directory provisioning tidbits

[#1]

• Introduction
• Special attributes
• AC_NewParent Example
• AC_NewName Example
• Terminal services attributes
• Exchange provisioning – Connector scripts

Introduction

When provisioning to Microsoft Active Directory there are certain fields that have specific special values that must be assigned to them from your provisioning policy on your active directory application or provisioning policy on a rule in order to have the correct resulting value assigned inside the Active Directory server. The goal of this article is to identify these Active Directory fields that require specialized values and provide a reference for the values need to be assigned to these fields.

The SailPoint document “SailPoint IdentityIQ Direct Connectors Administration and Configuration Guide” introduces these fields in some light detail.  However this document does not provide example values for provisioning plans and leaves a bit up to “Experimentation” for the engineer implementing the solution in the field.  This article should make that engineer’s job a little bit easier.

Special attributes

The Active Directory has a couple of special attributes for managing scenarios such as “Renames” and “Moves” The attributes are as follows:

Attribute Name	Attribute Value
AC_NewName	New cn value for the given user ( Ex. CN=john.doe)
AC_NewParent	New ou value for user ( Ex. ou=example,dc=com,dc=us)

AC_NewParent Example

AccountRequest acct = new AccountRequest(AccountRequest.Operation.Enable,"ActiveDirectory",adLink.getNativeIdentity());

newParent = "ou=people,ou=newOu,ou=world,dc=exmaple,dc=com";

acct.add(new AttributeRequest("AC_NewParent",ProvisioningPlan.Operation.Set, newParent));

AccountRequest acct = new AccountRequest(AccountRequest.Operation.Enable,"ActiveDirectory",adLink.getNativeIdentity());

newParent = "ou=people,ou=newOu,ou=world,dc=exmaple,dc=com";

acct.add(new AttributeRequest("AC_NewParent",ProvisioningPlan.Operation.Set, newParent));

AC_NewName Example

attributeRequest.setName("AC_NewName");

String attributeValue = "cn="+identity.getLastname()+ "\\, "+identity.getFirstname()+" ("+identity.getAttribute("networkId")+")";

attributeRequest.setValue(attributeValue);

Terminal services attributes

In general setting an AD account attribute to null or “” (the empty string) will cause the API to call a .clear() method on the AD interface, clearing out any previous value for that field.

msNPAllowDialin – sending “NOT SET” (all caps, space in the middle, 7 characters long) will clear out this setting in AD.

msRADIUSCallbackNumber – specifying any value for this field causes the “msRADIUSServiceType” field to be set to 4.

IIQDisabled – sending “true” for this field (that is often not in the AD schema) causes the userAccountControl bit flag 0x0002 to be set high.

Setting pwdLastSet to "true" sets the AD attribute to 0.

Setting pwdLastSet to any other value sets the AD attribute to -1.

AllowLogon - this is set to a 32-bit conversion/truncation of the passed in value.

BrokenConnectionAction - When set to "End session" the value is set to 1.  It is set to 0 in all other circumstances.

ConnectClientDrivesAtLogon - this is set to a 32-bit conversion/truncation of the passed in value.

ConnectClientPrintersAtLogon - this is set a 32-bit conversion/truncation of the passed in value.

DefaultToMainPrinter - this is set a 32-bit conversion/truncation of the passed in value.

EnableRemoteControl - This is expecting one of the following strings:

"Disabled"

"Enabled, Require permission, Interact"

"Enabled, Interact"

"Enabled, Require permission, View"

"Enabled, View"

The comparison is done using a switch string so again assume that case matters.

When "Disabled" passed in the value is set to "0".

When "Enabled, Require permission, Interact" passed in the value is set to "1".

When "Enabled, Interact" passed in the value is set to "2".

When "Enabled, Require permission, View" passed in the value is set to "3".

When "Enabled, View" passed in the value is set to "4".

MaxConnectionTime - this is converted to minutes before being applied

MaxDisconnectionTime - this is converted to minutes before being applied

MaxIdleTime - this is converted to minutes before being applied

ReconnectionAction - When set to "From any client" this is set to "0" in AD, it is set to "1" in all other cases.

The following fields are passed through verbatim to Active Directory:

TerminalServicesHomeDirectory

TerminalServicesHomeDrive

TerminalServicesInitialProgram

TerminalServicesProfilePath

TerminalServicesWorkDirectory

BrokenConnectionAction - This is expecting a string value "End session"  if this is passed the

value is set to 1, else 0. The comparison for this string uses an Equals() method so assume case matters here

ReconnectionAction - This is expecting the string value "From any client" if this is passed the

value is set to 1, else 0. The comparison for this string uses an Equals() method so assume case matters here

msNPAllowDialin - The default schema type for this attribute is a string. It accepts the string representations of “true” ,”false”, or “Not Set”.

Exchange provisioning – Connector scripts

Type Name	Description
ConnectorBeforeCreate	Before script for create operation
ConnectorAfterCreate	After script for create operation
ConnectorBeforeModify	Before script for modify operation includes enable/disable, unlock
ConnectorAfterModify	After script for modify operation includes enable/disable, unlock
ConnectorBeforeDelete	Before script for delete operation
ConnectorAfterDelete	After script for delete operation

The thing to know with these hooks is that once setup, the rule will fire everytime. So your script must have some intelligence as to know when to take action and when not to. One thing you can do is use a valid Active Directory attribute to write flag data for your script to check. So for instance in the description field for AD you can write  a value of “doHomeFolder”. So in your PowerShell script you can have the script interrogate the Attribute Request value for description and decide based on the value whether or not to take action.

[derek_kuhnert]

Quick heads-up for anyone who may be referring to this for info on the listed terminal services attributes: I've found that on IIQ v8.1p3, those TerminalServices* attributes cause AD to return an error stating "The specified directory service attribute or value does not exist."

I saw in the AD direct connector guide that the supported way of handling terminal services attributes is to use the "TS_"-prefixed logical attributes listed in the guide. I'd recommend looking at the direct connector guide for your version of IIQ, since this may be version-specific.

[walker_pa]

@darylclaude_medina @david_lee @adam_hampton 

The documentation says you should use an "Attributes" map to modify the CN or move to another OU. The example in the document is this:

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE ProvisioningPlan PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<ProvisioningPlan>
   <AccountRequest application="AD App" nativeIdentity="CN=SampleUser,CN=Users,DC=Example,DC=Com" op="Disable">
    <Attributes>
     <Map>
         <entry key="AC_NewParent" value="OU=DsiabledUsers,DC=Example,DC=Com"/>
     </Map>
    </Attributes>
   </AccountRequest>
</ProvisioningPlan>

 Which I've found here: https://documentation.sailpoint.com/connectors/identityiq/active_directory/help/integrating_active_d...

The reason I am bringing this up is because setting AC_NewName in an "AttributeRequest" object causes the Perform Identity Request Maintenance task to mark the requested attribute as "Unverifiable/Not Verifiable" (in this case, AC_NewName) because it is not a true schema attribute.

We've been doing it as suggested in this article for years, but I am trying to prevent this unverifiable issue as it marks the overall request's completion status as "Incomplete" (along with other warnings/errors such as "Request completed with failures" and "This request timed out waiting for verification of one or more items."). This is obviously confusing from a support and end-user perspective, especially when the object gets renamed properly.

How can I rename objects in Active Directory AND not have errors in the Identity Request object due to lack of verification?