I am facing an issue with the AD connector AfterModify script. We currently have the AfterModify script working fine for any modify operations but need to add a logic in the script where we would like to remove terminated users from any Outlook Calendar Invites they are part of. We have the PowerShell script to take care of that but, the AfterModify rule is not populating the sAMAccountName when the operation is Disable. I see the following error message:
Error: Item = → Message = Cannot bind argument to parameter ‘sAMAccountName’ because it is an empty string.
But, the value for sAMAccountName, location, and company are being populated when the account operation is Modify.
This happens because during a “Disable” operation, SailPoint doesn’t send all user attributes only a few essentials like the DN or UUID. That’s why your sAMAccountName is coming through empty, even though it’s available during a normal “Modify”.
You can fix it by fetching sAMAccountName (and other details) from the existing AD Link instead of relying on the incoming request attributes. The Link still holds all the user’s last known values.
Alternatively, you could update your PowerShell script to use a stable identifier like “DN” or “objectGUID”, which is always passed even during Disable.
Would you like me to show you a simple example of how to fet
Here is a basic a simle example on how you could fetch sAMAccountName from existing AD link.
// From rule context
SailPointContext ctx = ruleContext.getContext();
Application app = (Application) ruleContext.get(“application”);
AccountRequest ar = (AccountRequest) ruleContext.get(“accountRequest”);
// Fetch sAMAccountName from the existing AD Link
String sam = null;
Link link = LinkUtil.findLinkByNativeIdentity(ctx, app, ar.getNativeIdentity());
if (link != null) {
sam = (String) link.getAttribute(“sAMAccountName”);
}
// If not found, skip safely (prevents empty param errors)
if (Util.isEmpty(sam)) {
ruleContext.log("AfterModify: sAMAccountName not found for " + ar.getNativeIdentity());
return null;
}
// Use your existing script call, but pass the resolved sAMAccountName
String cmd = "C:\SailPoint\Scripts\EnableRemoteMailbox.ps1 "
+ “-sAMAccountName "” + sam + "" "
+ “-requestString '” + ar.toXml() + “'”;
ruleContext.exec(cmd);
Could you please let me know where would I be making this change? Would it be in the AfterModify Rule? Or would I be modifying the PowerShell script? In my current AfterModify rule, I am trying to get the different attributes from the requestObject. For example,
In the example I shared you don’t need to change your powershell script. Right now, your rule is trying to read all values from the requestObject.Attributes (which works for Modify but fails on Disable). The only part you need to adjust is how you get the sAMAccountName when it’s missing.
In the code example I shared earlier, the key section you should focus on is this part:
Link link = sailpoint.tools.LinkUtil.findLinkByNativeIdentity(ctx, app, ar.getNativeIdentity()); if (link != null) { sam = (String) link.getAttribute(“sAMAccountName”); }
That’s the logic that safely fetches sAMAccountName from the existing AD Link when the Disable operation doesn’t include it.
So as per @BCyr approach I can use the user’s Native Identity and replace it with sAMAccountName? Or do I need to populate the users sAMAccountName after getting his native identity?
It depends on what is the Account ID you defined in the account schema of the AD source and how the CN defined in the DN. If the AccountID is DN and the sAMAccountName is defined as CN in DN, then you need to split the sAMAccountName from the native identity by using split PowerShell command.
Irrespective of the case, I would do the search in AD by using Get-ADUser command and nativeIdentity value to get the sAMAccountName like below
You’ll need to populate the users sAMAccountName after getting his native identity from AfterModify rule. even though unique they are different attribute so you can’t directly replace them. You can pass the native identity to your powershell code from the AfterModify Rule
What are the user attributes available from SailPoint when the operation is disable? Could someone please confirm or direct me to any documentation that is available in this regards?
only changes will available in the plan. so if its just disable, then other than native identity nothing along with the operation to perform will be available.
you should see a block of code by default :
#debug line for testing
if($enableDebug) {
LogToFile(“Request object contents:”)
LogToFile($requestObject | Out-String)
}
if you enable debug mode, you should see what is available in your ps script.
