Jul 25 2023 06:14 PM
Jul 25 2023 06:14 PM
I'm using PowerShell to export selected attributes of all our users in a specific OU in AD. It's mostly working but for some reason several attributes aren't exporting correctly. The personalPager attribute is coming out empty, as are 2 custom attributes we've created call pronouns and conditionalimages. Anyone know what's going wrong here?
get-aduser -filter * -Properties * -SearchBase "OU=Standard Users,OU=Users,OU=Organisation,DC=wdea,DC=local" | select GivenName, Surname, DisplayName, Title, Department, EmailAddress, telephoneNumber, MobilePhone, Office, StreetAddress, City, State, PostalCode, Country, pronouns, personalPager, conditionalimages | export-csv -path c:\temp\export-all.csv
Jul 25 2023 07:52 PMSolution
There's two possibilities here:
To check point 1 isn't a problem, run just the first part of your statement:
get-aduser -filter * -Properties * -SearchBase "OU=Standard Users,OU=Users,OU=Organisation,DC=wdea,DC=local"
If you see the attributes listed with values, then you've simply made a typo in the Select-Object clause.
If you see the attributes listed but without value(s), then either:
Obviously, I can't check if your custom attributes are marked as confidential, but the default for personalPager is that it's not marked as confidential, so I'm inclined to think it's point 2 (permissions of the querying account) above.
Jul 25 2023 09:29 PM
Thanks for the response. The account I'm logged in as is a domain admin. The weird part is that personalPager and conditionalimages returned blank columns in the exported CSV but pronouns has a value listed for 1 user, but not the others.
Jul 25 2023 09:53 PM
Jul 25 2023 11:54 PM
Yeah, okay, so that is why you had a permissions issue on some of those attributes.
If you don't click "run as administrator", then the logon token submitted by the running process does not include the SIDs for privileged groups such as Domain Admins, Enterprise Admins, etc.
So, option 2 explains that part.
However, your observation that:
Though it's weird that I managed to pull one of the attributes for one user
Is not actually weird at all.
The overwhelming majority of attributes are readable by all authenticated users. I actually use my completely unprivileged account to perform perhaps 95+ per cent of my administration (which only requires read access) as part of the security concept of "least privileged access".
Each attribute has its own ACL (the security list of permissions controlling who can read what), meaning the attributes you cannot read simply don't feature common groups like Authenticated Users, Domain Users, Users, etc.
There's nothing intrinsically wrong with that, either.
Jul 26 2023 12:02 AM
As one last aside, the issue you observed is only relevant if you're running the script directly on the domain controller.
If you run the same script remotely, say, from your workstation from a PowerShell session where:
Then you will find the script works, unlike when you do the same thing directly on the domain controller.
This is expected as your privileged groups are only removed from your local process. The privileged groups are included in any remote, over-the-network calls, which is why this latter scenario works just fine.
What does this look like in practice?
This will open a new PowerShell window on your workstation that is not running with local administration privileges, and if you run the script in here, it will work just fine.
We're well outside of the topic of PowerShell now, but figured it was still worth a quick shout-out.