I'm not very familiar with AD and have done no administration of it. Please excuse any incorrect terminology or possible conflicting/incorrect claims about AD. I'm attempting to gather data in a C# application to control access based on AD groups, etc. and am having problems with determining whether a user is enabled or not.
We have users that fall into two categories. Internal staff (using the default primary group which I believe is "Domain Users") and staff of a partner organization that use a custom primary group ("Domain User Custom"). This may or may not have anything to do with the problem I'm dealing with, but I'm including it in case it's related.
Based on this SO Question I assume that the .Enabled property on the UserPrincipal is not always reliable. In my particular case, this holds true, since users I have tested with in both the Domain Users group and the Domain User Custom group always show false, whether they are disabled or not. My own user account (in Domain Users) is the only one so far that has it set properly. I also tried checking the UserAccountControl flags from the DirectoryEntry and all users (except mine) return NULL, so I can't check for the AccountDisabled (0x2) flag.
I've also tried an LDAP query to find all users who are disabled (UserAccountControl:1.2.840.113556.1.4.803:=2) but users in Domain User Custom are not included - however Domain Users are present in this search.
I had my operations team move one of the disabled accounts out of Domain User Custom into Domain Users just to see if it would populate the UserAccountControl flags, but it did not.
How can I either determine the enabled status of all users or get the UserAccountControl flags to be populated?
Additional notes - I am not using my personal credentials to authenticate with the DC, I have a dedicated login/password for reading from AD. I am running Visual Studio 2019 in administrator mode.
Active Directory (and traditionally LDAP directories in general) supports per-attribute access controls. The userAccountControl attribute in AD is grouped under "Account Restrictions" Extended Right, and the default ACL for 'User' objects only allows a very limited set of entities to read those attributes1 – if my understanding is correct, this only includes members of "Pre-Windows 2000 Compatible Access" and "RAS and IAS Servers" groups (and of course Domain/Enterprise Admins). The membership of the entry being read is generally irrelevant, the membership of your account is what matters.
1 A fresh AD domain still has Authenticated Users blanket-added to "Pre-Windows 2000 Compatible Access", but general best practices recommend removing that entry as soon as possible and only adding specific members as needed (hence "very limited set of entities").
So you have to discuss this with your domain admins.
(For example, if your program needs access to various attributes, the dedicated account could be added to "Pre-Windows 2000 Compatible Access", which seems to still be the MS-approved method despite the historical name of this group (not to mention being the easiest method), or if the domain admins think this grants too much 'read' access, they might add you to the other group or define custom ACLs. Mass-changing ACLs on every single entry seems a pain in AD, but moving the attribute to a different Extended Right is easily doable.)