Making changes to Provisioning global user attributes do not propagate to the associated ADS Account’s samAccountName and/or userPrincipalName even though the account had an account template with correct rulestrings set in the eTADSuserPrincipalName (i..e User logon name) field and the eTADSsAMAccountName (i.e. User logon name pre-Windows 2000) field. Is that expected?
The product is currently working as designed. The product is not coded to propagate changes to those fields (eTADSuserPrincipalName and/or eTADSsAMAccountName).
Older C++ based connectors that run within the C++ Connector Server (i.e. im_ccs) rely on Parser Table definition files (i.e. PTT files) which are compiled with the product and cannot be modified by users which dictate attribute behaviors.
If you run the following command you can see how attributes are coded to be handled:
Open a cmd.exe prompt and cd to the Provisioning Server’s Data folder
Run ..\bin\dumpptt –f –t adsparse.ptt –of adsparse-full.txt
Run notepad.exe adsparse-full.txt
Search for both of the following entries in adsparse-full.txt and note that isPropagationAllowed is set to no for both of the fields:
ATTRIBUTE (LDAP Name) eTADSAccount::eTADSuserPrincipalName
ATTRIBUTE (LDAP Name) eTADSAccount::eTADSsAMAccountName
So this design decision is why the Provisioning global user value is not propagated to the AD account when it is modified.
While the user modify propagation to account cannot be relied upon, the AD account itself can have the eTADSsAMAccountName and/or the eTADSuserPrincipalName fields updated if modified directly on the ADS Account object instead. This could be done via the Provisioning Manager, an etautil command, an ldap command, or from the IM layer via an account level modify or via a PX Policy that is doing an account level modify.