Exporting AD User Attributes

[JasonT77]

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

[#2 · Accepted solution]

@JasonT77 

Hi, Jason.

There's two possibilities here:

1. You've misspelled the attribute names in your "Select-Object" statement; and/or
2. The account you're using does not have permission to read those attributes (which includes if the attributes are marked as confidential.)

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:

1. The attribute really holds no value for that object; and/or
2. The account you're querying with does not have permission to read that attribute; and/or
3. The attribute is marked as confidential.

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.

Cheers,

Lain

[#3]

@LainRobertson 

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.

[#4]

It turns out that even though I'm logged in as a domain admin, when I opened PowerShell I didn't "run as administrator" *facepalm*.
Though it's weird that I managed to pull one of the attributes for one user

[#5]

@JasonT77 

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.

Cheers,

Lain

[#6]

@JasonT77 

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:

1. You have opened the PowerShell session with your Domain Admin account; and
2. You did not use "Run as administrator".

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?

1. Log onto your workstation - not a domain controller;
2. Shift key + right-click the PowerShell icon in the Start menu or taskbar;
3. Choose "run as a different user";
4. Use your Domain Admin account.

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.

Cheers,

Lain