4

I'm trying to find a list of Active Directory User Attributes that I can use for customization without having to extend the schema. We are using 2008R2 functional level.

I exported a list with powershell of all properties. But I don't know how to tell which are user-info that I can edit (such as displayname, phone, employee-id) and AD-Data that I shouldn't edit manually (dn,accountexpires). I can see some obvious ones from this list such as employee-id, extensionAttribute1-15.

Get-QADUser 'username' -IncludeAllProperties |  Get-Member -MemberType Properties

I have found a few websites that list all attributes, but none of them distinguish between user-info and AD-Data.

This Microsoft list divides properties up into Property sets: Public-Information, User-Logon etc. but still doesn't divide the list between user-info and AD-Data. It also doesn't include employee-id or the extensionAttribute1-15

Question: Does this list Active Directory User Attributes that I can use for customization exist? Thanks

Edit: Additional info: Our developers want to attach some info to all user accounts for a new application. The first example of the data they wanted to attach was employee-id. This field already exists in AD. I'm not opposed to extending the schema, I just don't want change things unnecessarily or to duplicate fields that already exist. If I can just give them a list, there might be fields with appropriate names that we can just use. If not, then I will extend the schema.

Reworded question: Which attributes can I use for my own purposes (eg. displayname, phone, employee-id) ? Which attributes should I leave alone (dn, lastModifiedDate, accountexpires)?

Gre
  • 85
  • 4
  • 13
  • 2
    Not entirely sure what you're asking. It's pretty much all editable. "dn" would be an exception, because that's basically the "path" to the object; to "edit" it, move the object into another OU. Account expires, however, is an attribute *you* set to tell AD when that user can no longer log into the domain. Things like sAMAccountName and userPrincipalName shouldn't be edited without coordination with the user, as that can result in not being able to login. It might be helpful if you're more specific about what type of customization you're looking to do? – DarkMoon Apr 04 '16 at 03:43
  • 2
    Except it's not all editable, not even close. There are plenty of constructed and back referenced attributes that can't be written to. There are other attributes that are only writable by AD. There are attributes that can be modified, but shouldn't be because they're commonly used for specific product features. – Ryan Bolger Apr 04 '16 at 03:53
  • 2
    Perhaps I was a bit to brief; SF's comment character limit forces too much brevity sometimes. I gave "dn" as an example of a non-editable (constructed) attribute. sAMAccountName and UPN are others that, while editable, normally shouldn't be changed. There are, as you say, a number of others; my point (which, re-reading my original comment, probably didn't come across well) was that without knowing more about what he's asking, it's hard to give him an answer. – DarkMoon Apr 04 '16 at 04:06
  • I have added some background info and reworded the question. – Gre Apr 04 '16 at 05:30

2 Answers2

6

The short answer is that there are only really a couple attributes that are intended for cosmetic metadata on a user account like description and info. Even the extensionAttributeX ones aren't really intended for your customization. They're part of the Exchange schema extensions and should be considered "reserved" if you're actually running Exchange.

A better question is why are you trying to avoid extending your schema? There's nothing inherently risky about doing it. If you have a valid use-case for adding business specific custom metadata on a particular class, come up with a logical attribute name, and add it. Maybe make sure your ldif file works the way you intend on a temporary throwaway DC that you bring up first. But ultimately, it's the only way to guarantee that nothing else will step on it or be affected by it.

If you're trying to avoid it because of political issues (your team doesn't manage AD and the AD team is averse to schema changes), it's still in your best interest to fight the good fight and make a business justification for the change (assuming you actually have a good business justification).

If your need is only temporary, then maybe just use something like description or info knowing that your user management teams might screw up the data accidentally. It's also possible some poorly written third party software might have the same idea though and conflict with yours.

You may also want to update your question with more specifics about the type of data you're trying to add. There may be existing attributes you could use that are intended for your purposes already.

Response to Edit: As you pointed out, there is already an employeeID attribute you could use. There's also an employeeNumber attribute as well. But again, the answer to the root of your question is that there is no definitive list of pre-existing writable attributes that no other software uses. The best way to do what you're trying to do is open up the properties dialog for a user in your domain, select the Attributes tab, change the filter to Show only writable attributes and scroll down looking for something that doesn't have any data in it yet that might fit your data definition. Then, google that particular attribute name to see what the attribute's intended purpose is and as a sanity check to see if anything you use in your environment also uses it.

Ryan Bolger
  • 16,472
  • 3
  • 40
  • 59
  • I have updated the question with more info on the data Im trying to save. – Gre Apr 04 '16 at 05:37
  • 1
    *there is no definitive list of pre-existing writable attributes that no other software uses.* - so very much this. @Gre you say you don't want to, but if you need a list of writable attributes that no other software uses then you need to extend the schema. Simple as that. – Rob Moir Apr 04 '16 at 18:33
  • `There's nothing inherently risky about doing it.`. When the schema is updated, clients must download the updated ADSI schema cache (about 3 MB). If an organization has a lot of clients with a low-speed connection to a remote domain controller, the additional utilization may saturate their connection if there are many concurrent logons. – Greg Askew Apr 04 '16 at 19:35
  • Thanks Ryan. I thought about this overnight and decided that the benefit of extending the schema would be so I can prefix the attribute with our company acronym, app name, field name. That way in 10 years when someone else is looking at it, they will know exactly what it was for and which application is using it. If I use existing attributes, then future admins will have to guess what might be using the field (which is the issue we are having now). Cheers. – Gre Apr 04 '16 at 22:57
  • 1
    It's a bit more work up front, but it sounds like the right solution for your situation. If you want to go the extra mile, you can register for a [Private Enterprise Number](http://pen.iana.org/pen/PenApplication.page) from IANA which will get you a publicly recognized OID for your organization to use with your schema extensions (rather than making one up or accidentally using someone else's). – Ryan Bolger Apr 05 '16 at 03:40
-1

I'm using info attribute as a custom field. And it works like a charm without changing the schema.

O. Peer
  • 45
  • 3