AD orchestration using SID

​@DanielRuff  not sure if you use local ad but I had to start somewhere :) 

​@Medic1334 

I had a few customers run into this issue when their SAMAccountName did not match the part of their email address before the "@" symbol. Because of that, we moved away from this logic and switched to "Get User by Email", using the SID for any follow-up automation instead. I'm not sure whether this action was only available in Entra ID or if it was also available in on-premises Active Directory.

I hope I'm not mixing up any of the terminology, as I'm not very familiar with all the AD concepts such as UPN, sAMAccountName, and similar attributes.

For a few automations, you need to use PowerShell instead of the built-in AD orchestration activities. For example, when we created an automation to set the "Change password at next logon" flag, that option was not available in the local AD orchestration activities when I last worked on a similar automation a few years ago.

Hope that helps.

Thanks, I wasn’t clear in my idea, it’s about when you synchronize users from local AD to Firstservice. 

Unfortunately, I can’t help much with that particular use case. The default synchronization using the Network Discovery Probe has always worked reliably for us, so we haven’t had to implement an alternative approach.

I’m just fishing for votes ;) 

Perhaps you create a requester forget that mirrors your user deletion from AD? This will ensure the user is always up to date.

AD sync should deactivate user when suspended from AD which should also prevent showing up in searches and assignment of inventory.

The Server do not delete/forget requesters. So, if the customer deletes the user and later a new user with same SAMAccount and e-mail comes in the server will just update the requester in FS.

Should be easy enough to run a powershell script. I believe you are on an MSP, so if you could get their active directory team to give you an export of deleted users before they pull the trigger, then you could run it against that list. 

Or generate a integrations user for the org that has their AD syncing in and create a quick powershell API interaction script that they can run before they delete out of AD.

Of course there are some security challenges with doing this, but it would be an option to help you guys out. The last couple of times I've asked Chet gpt to do things for me. I had zero problems with the script as a whole, but I've also used it for a ton so it might be more tuned for me than others 🙂

We have this EXACT issue.

I encountered it about 4 years ago originally and it affects email or sAMAccount name

• 1 Jan 2023: User John Smith joins: sAMAccount = SmithJoh, email = John.Smith@xxx is created and syncs into Freshservice as a new requester
• 1 Jan 2024: User John Smith leaves
• 1 March 2024: AD account for John Smith is deleted.  Freshservice requester deactivated per probe setting.  (We have it set to on delete, not on disable)
• 1 Jan 2025: User John Smith joins (and is a totally different person:  sAMAccount = SmithJoh, email = John.Smith@xxx is created.   I can’t remember the probe outcome of this, but suffice to say it’s not what is wanted.

Therefore we initially went with changing the users email address after leaving but before deletion:

• 1 Jan 2023: User John Smith (staff ID 123) joins: sAMAccount = SmithJoh, email = John.Smith@xxx is created and syncs into Freshservice as a new requester
• 1 Jan 2024: User John Smith leaves
• 1 Feb 2024: email address changed to smithjon.123@xxx
• 1 March 2024: AD account for John Smith is deleted.  Freshservice requester deactivated per probe setting.  (We have it set to on delete, not on disable)
• 1 Jan 2025: User John Smith (staff ID 456) joins (and is a totally different person:  sAMAccount = SmithJoh, email = John.Smith@xxx is created.   Probe does NOT reactivate requester, but it DOES change postal address, employee ID etc of the deactivated requester!

We therefore implemented a policy whereby we never reused sAMAccount either, and everything was fine for years.

Roll on 2026 and we are merging with a parent company who are replacing our user creation system.  They have a policy where they claim to never reuse a leavers email address (I am skeptical), but they DO reuse sAMAccount!   I therefore have a large number of new users being created using sAMAccount names from users that left previously.  This is causing new staff to not appear as requesters, whilst lots of deactivated requesters are suddenly getting new addresses, managers, departments etc.  If the new staff send a ticket in via email, the system then creates them as a new requester, due to the email they are sending from not existing in the system; and hopefully the system then updates them with the correct information (manager, department etc) at the next probe run.

I am now desperately waiting on our HR systems team to complete setup of Workday to Entra sync, so I can remove the probe and sync via Entra instead.  Entra uses email address or External ID to sync rather than sAMAccount name. The main difference here though is that the sAMAccount that the probe uses does not seem to be visible within Freshservice.  I am thinking its possibly stored only in the probe database on the server, whereas the ExternalID is visible via API.

However, I recently found out that even if you use Azure SCIM, it doesn't actually use the email address, or the external ID to perform updates.  When a new user is created/added to scope it checks for matches on email address or external ID.  If it find no matches it creates a new requester.   If you then edit that requester in Freshservice (via API) and change their email address/blank the external ID field, if the Azure user is updated, it will still update the requester in Freshservice, as the Azure application stores the requester ID value, and uses that to make a direct injection, rather than having to perform a search