No way to exclude contractors from dynamic groups (employeeType not usable?)

Posted by CoffeeAndPowershell@reddit | sysadmin | View on Reddit | 20 comments

Just hit a pretty annoying limitation with dynamic groups.

There’s no straightforward way to exclude freelancers/contractors, because you can’t use the employeeType attribute in the rule.

So even if your directory is clean and employeeType is properly populated (Employee vs Contractor), it’s basically useless here. You end up relying on hacks like domains, departments, or random attributes… which isn’t great and definitely not scalable.

Am I missing something obvious, or is this just how everyone deals with it?

[-]

irish_guy@reddit

Security group for employees and contractors, add groups where they need to be?

[-]

CoffeeAndPowershell@reddit (OP)

That's actually the core of my issue : I can't create dynamic groups based on employeeType at all so I'd have to manage everything manually. With thousands of users already spread across groups by company, location, etc., that's just not feasible. The whole point is to avoid manual assignment at scale

[-]

irish_guy@reddit

If you have a list of who is a contractor or permanent employee then scripting something to add existing users should be simple, start with the onboarding flow to catch the user type first tho.

If you don't have a list of who's who then HR should?

[-]

CoffeeAndPowershell@reddit (OP)

Yes, I could run a script on-prem to either add users directly to a static group or backfill an extensionAttribute based on employeeType both would work. But that's the thing: employeeType already exists and is properly populated, so it feels wrong to maintain a parallel attribute just because Entra doesn't expose it in dynamic group rules. Just wanted to make sure I wasn't missing an obvious native way to use it before going the workaround route.

[-]

AppIdentityGuy@reddit

Does your employee numbering scheme not encode the fact that the user in question is a contractor? For example C123456789 is a contractor versus E123456789 is an FTE? I'm not trying to excuse EntraIds apparent lack of support for the attribute but just trying to spitball some ideas.

[-]

sryan2k1@reddit

"It just feels wrong" is basically in a nutshell. Your best bet is to set an attribute you can use with whatever on prem automation platform you're already using like Adaxes or whatever.

[-]

PowerShellGenius@reddit

OP already has this info flowing into AD, it is just in an attribute that cannot be used for dynamic groups.

[-]

Sajem@reddit

Yes, creating a dynamic group using EmployeeType is fully supported and if its not working then it is a problem with the query.

Common gotcha's are:

Incorrect syntax. missing quotes around the value
Correct case in the query. This is case sensitive
Check there are no white spaces in either the query or the EmployeeType field.

Is this a hybrid AD? If it is EmployeeType is not synced by Entra Connect by default and you'll need to add it to the synchronization rules

[-]

certifiedsysadmin@reddit

Have you personally seen it work? I've tried it in multiple tenants and it does not work. It's also not listed as a supported property for dynamic group membership on the doc page.

[-]

8492_berkut@reddit

Official Microsoft documentation doesn't list it as a supported property, and I tried to get it to work a few months back.

https://learn.microsoft.com/en-us/entra/identity/users/groups-dynamic-membership#supported-properties

[-]

CoffeeAndPowershell@reddit (OP)

Actually we have thousand of users in multiple countries and cities

[-]

sryan2k1@reddit

That's not what I asked.

[-]

30yearCurse@reddit

10 attributes..