OID selection for custom attributes

  • 82 Views
  • Last Post 03 May 2017
a-ko posted this 02 May 2017

So does anyone have recommendations or best practices on building out OID structure after you have an IANA PEN?

I know there are scripts out there that kind of randomly generate OIDs, but I am wondering if it'd be better to create a structure around OIDs (I see more use cases for it internally than just AD purposes) and I want some structure out of it.

I can't find a good best practice or even length limitations....

Current plan is

IANA.PEN.DEPARTMENT.APPLICATION/FUNCTION.OBJECTTYPE.OBJECT

I.e 1.3.6.1.4.1.XXXX.IT.ACTIVEDIRECTORY.CLASSES.MYCLASS

and ATTRIBUTES.MYATTRIBUTE

Any recommendations on this?

Get Outlook for iOS

Order By: Standard | Newest | Votes
barkills posted this 02 May 2017

Here is our documented approach:

https://itconnect.uw.edu/wares/msinf/design/schema/oids/

 

Of course, AD doesn’t allow you to define most of the schema/items listed there, but when I developed that I was covering all the bases for a directory

service in general.

 

Brian

 

show

bdesmond posted this 02 May 2017

I usually don’t nest it as much, e.g. 1.3.6.1.4.1.XXXXX.1.X is AD classes, .2.X is AD attributes. You could then just assign branches

incrementally unless you foresee this being really spread out in the organization then I can see why you would want what is in your structure.


 



Thanks,

Brian Desmond

 

(w) 312.625.1438 | (c) 312.731.3132



 

show

a-ko posted this 02 May 2017















GREAT info. Does anyone know if there are length limits? Should we just sequentially assign info?




I like the Department.Function structure because the plan is to also do things like certificate template extensions and such. And breaking that out kind of makes more logical grouping sense. 




But now the idea is. Do I just choose "1" for IT and "2" for "Security" etc? And so forth? Or do I randomize say 3 digits? Not sure on best practices around that...




Get Outlook for iOS








show

GuyTe posted this 03 May 2017

https://tools.ietf.org/html/rfc2578#section-3.5:





3.5

OBJECT IDENTIFIER values

 

 

   An OBJECT IDENTIFIER value is an ordered list of non-negative

   numbers.  For the SMIv2, each number in the list is referred to as a

   sub-identifier, there are at most

128 sub-identifiers in a value, and

   each sub-identifier has a maximum value of 2^32-1 (4294967295

   decimal).

 

   All OBJECT IDENTIFIER values have

at least two sub-identifiers, where

   the value of the first sub-identifier is one of the following well-

   known names:

 

        Value   Name

          0     ccitt

          1     iso

          2     joint-iso-ccitt

 

   (Note that this SMI does not recognize "new" well-known names, e.g.,

   as defined when the CCITT became the ITU.)

 

From AD perspective, the length of the OID is not really an issue: what is stored internally in the DIT is the ATTRTYP, which is a 32bit unsigned integer. The full OID is calculated

based on the OID prefix table (which is exposed also via prefixMap attribute on the Schema NC head) using the algorithm outlined at:

https://msdn.microsoft.com/en-us/library/cc228445.aspx



 

Guy

 

show

joe posted this 03 May 2017

The approach we've used is to use branch prefixes that have "somewhat" meaning values to help create some semantics in our management logic. So, for example my company purchased a branch that was originally intended for use within network infrastructure management. They control the allocations of the overall branch to other parts of the org. 
Since you are stuck with numbers, you'll likely need to have some type of published decode table somewhere if you want to add semantics to arbitrary values. Keeping the numbers simple is likely to be better. You probably don't want your OIDs looking like GUIDs if you can avoid that.
We decided to use "509" as a branch name for stuff relating to PKI/certificates and "500" for stuff related to directory. Underneath that, it is up to the individual teams who "own" those areas in the organization. The key is to allow enough flexibility to avoid collisions but to also try to keep the structure manageable. It is a fairly similar exercise to designing a DNS hierarchy and you may be able to apply similar principles (assuming you think the way your org manages DNS is as actually working for you).
I hope that helps a bit more.
Joe K.


show

Close