Hey there! Let's break down your questions clearly—you're right to move away from repurposing CompanyName or Department for user type tagging, since those are intended for actual business organizational data. Here's what you should use instead:

1. Recommended Attributes for "User Type" Tagging #

The best choice depends on whether you're working with on-prem Active Directory (AD) or Azure Active Directory (AAD). Both have native or purpose-built attributes for this exact use case:

On-Premises Active Directory (AD) #

• employeeType: This is a native AD attribute designed specifically to describe a user's employment category (full-time, part-time, contractor, etc.). It’s perfect for repurposing to mark "special" vs "regular" users—way more semantically appropriate than hijacking Department or CompanyName.
• extensionAttribute1 to extensionAttribute15: AD includes 15 reserved custom attributes that Microsoft never uses for system purposes. Pick any one (e.g., extensionAttribute1) and set values like "SpecialUser" or "RegularUser" to categorize your users. No risk of conflicting with default AD behavior here.
• Avoid userAccountControl: While you could use unused flag bits here, this attribute controls critical account security settings (like account status, password requirements). Messing with it can break user access, so it’s not worth the risk for tagging user types.

Azure Active Directory (AAD) #

• Native userType: AAD has a built-in userType attribute that defaults to Member (internal users) or Guest (external users). The best part? You can set custom string values (e.g., "SpecialUser", "RegularUser") directly. This is the most native, low-friction option.
• employeeType: Just like in on-prem AD, this attribute exists in AAD and is semantically aligned with user categorization. Great if you want consistency across on-prem and cloud environments.
• extensionAttribute1 to extensionAttribute15: Same as AD, these are reserved custom attributes for your use. Perfect if you don’t need advanced categorization and want a simple, no-extra-cost solution.
• customSecurityAttributes (AAD Premium required): For more complex needs (like multi-dimensional tagging or linking attributes to permissions), this premium feature lets you create custom attribute sets and values. It’s highly flexible and integrates with AAD’s access management tools.

2. Why These Are Better Than CompanyName/Department #

Ditching your current workaround for these attributes gives you three big wins:

• Clearer semantics: Anyone looking at employeeType or userType will immediately understand it’s for user categorization, unlike Department which implies organizational structure.
• No business conflicts: CompanyName and Department change when users switch teams or your org restructures. These dedicated attributes stay stable regardless of business shifts.
• System compatibility: All these attributes are officially supported by AD/AAD APIs, PowerShell, and management tools—you won’t run into unexpected issues when automating or integrating with other systems.

内容的提问来源于stack exchange，提问作者Elvin Yang