| Author | Messages | |
chaselton
Posts:78
 | | 11/10/2009 2:31 PM |
| Hello,
I'm working at a location that runs LDAP alongside of Active Directory, and there's a desire to extend the Active Directory schema with two, possibly more, auxiliary classes that currently exist in LDAP.
Has anyone done this before, and if so, are there any potential drawbacks, other than that the extensions will be permanent? Any considerations we should take into account?
Thanks,
CJH
| | | |
| rwilper
Posts:37
| | 11/10/2009 4:08 PM |
| This is a common question that worries people usually overmuch. The "you cannot back the changes out", while true, should not be as scary as it is.
The important considerations to iron out are really
1) Make sure you assign unique OIDs (get a stem reserved if you need to)
2) Be sure about the data type for the attributes (and single/multivalue)
3) Name your attributes/classes to be unique - an organization-specific prefix is usually used.
Other things to think about the attributes/data are
1) Should the new attributes be indexed?
2) Should the new attributes be replicated to the global catalog?
3) Should ACLs be changed to reflect the new data
4) If there is a huge amount of data/a lot of changes, then how will this affect the size of the database/replication
Since these classes already exist most of this is probably thought through already.
One thing to note is that schema objects can be deactivated, renamed, and otherwise modified once they are in - unless they come from the "system" schema. The only thing that I have found cannot be changed is object type and data type- changing an OID is hard and I am not sure it is supported, but I have done it, YMMV.
-Ross
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Cynthia Haselton
Sent: Tuesday, November 10, 2009 6:29 AM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Extending Schema w/Auxiliary Classes
Hello,
I'm working at a location that runs LDAP alongside of Active Directory, and there's a desire to extend the Active Directory schema with two, possibly more, auxiliary classes that currently exist in LDAP.
Has anyone done this before, and if so, are there any potential drawbacks, other than that the extensions will be permanent? Any considerations we should take into account?
Thanks,
CJH
| | | |
| barkills
Posts:201
| | 11/10/2009 4:34 PM |
| There is another design consideration to take into account when implementing an auxiliary class. It has to do with schema design, but it has more to do with how you plan to make use of your new class.
Typically, Microsoft and other vendors (the recently released Apple AD schema jumps to mind) leverage auxiliary classes explicitly via inheritance. In other words, the auxiliary class is "inherited" by creating an object of a structural class that explicitly references the auxiliary class. This approach is used to "extend" a finite number of existing classes. There is another approach. The alternative is "dynamic auxiliary" where you can add an auxiliary class to *any* structural class *after* an object of that class has been created. So going back to the recently released Apple AD schema, you might add the apple-user auxiliary to a group object. That isn't Apple's intention, as they explicitly add it as an auxiliary on the user structural class, and it wouldn't be especially useful, but it is possible.
This alternative approach is sometimes useful, especially when you are working in a delegated AD, and you need to control when a particular auxiliary class is instantiated. Imagine that you don't want every user object to get the apple-user auxiliary class, because delegated administrators could make use of features that would cause problems (and there are some real reasons why you wouldn't want to allow apple-user on some users). Instead, you want to retain control of which users are extended with the apple-user auxiliary class. In that case, you would NOT want to not explicitly add the apple-user auxiliary class to the user class's schema definition. Instead, you'd just add the apple-user class, with a defaultSecurityDescriptor that ensured only you could add it. There are valid alternative solutions here too. For example, you could modify the defaultSecurityDescriptor on the attributes in the apple-user class, retaining the ability to populate them, without throwing away the inherited auxiliary approach.
Another thing to consider ...
________________________________
From: activedir-owner@mail.activedir.org [activedir-owner@mail.activedir.org] On Behalf Of Wilper, Ross A [rwilper@stanford.edu]
Sent: Tuesday, November 10, 2009 8:06 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Extending Schema w/Auxiliary Classes
This is a common question that worries people usually overmuch. The “you cannot back the changes out”, while true, should not be as scary as it is.
The important considerations to iron out are really
1) Make sure you assign unique OIDs (get a stem reserved if you need to)
2) Be sure about the data type for the attributes (and single/multivalue)
3) Name your attributes/classes to be unique – an organization-specific prefix is usually used.
Other things to think about the attributes/data are
1) Should the new attributes be indexed?
2) Should the new attributes be replicated to the global catalog?
3) Should ACLs be changed to reflect the new data
4) If there is a huge amount of data/a lot of changes, then how will this affect the size of the database/replication
Since these classes already exist most of this is probably thought through already.
One thing to note is that schema objects can be deactivated, renamed, and otherwise modified once they are in - unless they come from the “system” schema. The only thing that I have found cannot be changed is object type and data type- changing an OID is hard and I am not sure it is supported, but I have done it, YMMV.
-Ross
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Cynthia Haselton
Sent: Tuesday, November 10, 2009 6:29 AM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Extending Schema w/Auxiliary Classes
Hello,
I’m working at a location that runs LDAP alongside of Active Directory, and there’s a desire to extend the Active Directory schema with two, possibly more, auxiliary classes that currently exist in LDAP.
Has anyone done this before, and if so, are there any potential drawbacks, other than that the extensions will be permanent? Any considerations we should take into account?
Thanks,
CJH
| | | |
| barkills
Posts:201
| | 11/10/2009 4:43 PM |
| Two more things:
http://msdn.microsoft.com/en-us/library/ms677964(VS.85).aspx is a decent place to read more about AD schema design.
You can also learn quite a bit from looking at AD schema samples until you understand everything in them. For AD schema samples, grab any Windows Server or Exchange Server CD, and hunt for the *.ldf files. Microsoft tends to break them up into a hundred files, so you should find quite a few. You might also look at classes you are familiar with and see how they were adapted to AD. For example, in the Higher Ed sector, eduPerson is a very common object class used in non-AD LDAP directory servers. I've got an AD adaptation of that class here: http://www.netid.washington.edu/documentation/eduPersonSchema.aspx
and I know Indiana University has a slight derivation from my adaptation out there on the internet somewhere too.
________________________________
From: Brian Arkills
Sent: Tuesday, November 10, 2009 8:33 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Extending Schema w/Auxiliary Classes
There is another design consideration to take into account when implementing an auxiliary class. It has to do with schema design, but it has more to do with how you plan to make use of your new class.
Typically, Microsoft and other vendors (the recently released Apple AD schema jumps to mind) leverage auxiliary classes explicitly via inheritance. In other words, the auxiliary class is "inherited" by creating an object of a structural class that explicitly references the auxiliary class. This approach is used to "extend" a finite number of existing classes. There is another approach. The alternative is "dynamic auxiliary" where you can add an auxiliary class to *any* structural class *after* an object of that class has been created. So going back to the recently released Apple AD schema, you might add the apple-user auxiliary to a group object. That isn't Apple's intention, as they explicitly add it as an auxiliary on the user structural class, and it wouldn't be especially useful, but it is possible.
This alternative approach is sometimes useful, especially when you are working in a delegated AD, and you need to control when a particular auxiliary class is instantiated. Imagine that you don't want every user object to get the apple-user auxiliary class, because delegated administrators could make use of features that would cause problems (and there are some real reasons why you wouldn't want to allow apple-user on some users). Instead, you want to retain control of which users are extended with the apple-user auxiliary class. In that case, you would NOT want to not explicitly add the apple-user auxiliary class to the user class's schema definition. Instead, you'd just add the apple-user class, with a defaultSecurityDescriptor that ensured only you could add it. There are valid alternative solutions here too. For example, you could modify the defaultSecurityDescriptor on the attributes in the apple-user class, retaining the ability to populate them, without throwing away the inherited auxiliary approach.
Another thing to consider ...
________________________________
From: activedir-owner@mail.activedir.org [activedir-owner@mail.activedir.org] On Behalf Of Wilper, Ross A [rwilper@stanford.edu]
Sent: Tuesday, November 10, 2009 8:06 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Extending Schema w/Auxiliary Classes
This is a common question that worries people usually overmuch. The “you cannot back the changes out”, while true, should not be as scary as it is.
The important considerations to iron out are really
1) Make sure you assign unique OIDs (get a stem reserved if you need to)
2) Be sure about the data type for the attributes (and single/multivalue)
3) Name your attributes/classes to be unique – an organization-specific prefix is usually used.
Other things to think about the attributes/data are
1) Should the new attributes be indexed?
2) Should the new attributes be replicated to the global catalog?
3) Should ACLs be changed to reflect the new data
4) If there is a huge amount of data/a lot of changes, then how will this affect the size of the database/replication
Since these classes already exist most of this is probably thought through already.
One thing to note is that schema objects can be deactivated, renamed, and otherwise modified once they are in - unless they come from the “system” schema. The only thing that I have found cannot be changed is object type and data type- changing an OID is hard and I am not sure it is supported, but I have done it, YMMV.
-Ross
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Cynthia Haselton
Sent: Tuesday, November 10, 2009 6:29 AM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Extending Schema w/Auxiliary Classes
Hello,
I’m working at a location that runs LDAP alongside of Active Directory, and there’s a desire to extend the Active Directory schema with two, possibly more, auxiliary classes that currently exist in LDAP.
Has anyone done this before, and if so, are there any potential drawbacks, other than that the extensions will be permanent? Any considerations we should take into account?
Thanks,
CJH
| | | |
| DonH
Posts:65
| | 11/10/2009 5:30 PM |
| To be clear, the first mechanism you describe (having aux classes inherited
through a structural class) is there only because I misread the X.500 spec
in the mid-1990s and managed to convince everyone else at Microsoft that my
misreading was correct. It was later pointed out to me that I was a bozo,
but by that point it was too late and dependencies locked us into shipping
that way. We added the "dynamic auxiliary" mechanism (i.e., the way X.500
and LDAP actually specify it to work), but the old interpretation lingers.
My apologies to all involved for the unnecessary confusion.
Don Hacherl
_____
From: activedir-owner@mail.activedir.org
[mailto:activedir-owner@mail.activedir.org] On Behalf Of Brian Arkills
Sent: Tuesday, November 10, 2009 8:33 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Extending Schema w/Auxiliary Classes
There is another design consideration to take into account when implementing
an auxiliary class. It has to do with schema design, but it has more to do
with how you plan to make use of your new class.
Typically, Microsoft and other vendors (the recently released Apple AD
schema jumps to mind) leverage auxiliary classes explicitly via inheritance.
In other words, the auxiliary class is "inherited" by creating an object of
a structural class that explicitly references the auxiliary class. This
approach is used to "extend" a finite number of existing classes. There is
another approach. The alternative is "dynamic auxiliary" where you can add
an auxiliary class to *any* structural class *after* an object of that class
has been created. So going back to the recently released Apple AD schema,
you might add the apple-user auxiliary to a group object. That isn't Apple's
intention, as they explicitly add it as an auxiliary on the user structural
class, and it wouldn't be especially useful, but it is possible.
This alternative approach is sometimes useful, especially when you are
working in a delegated AD, and you need to control when a particular
auxiliary class is instantiated. Imagine that you don't want every user
object to get the apple-user auxiliary class, because delegated
administrators could make use of features that would cause problems (and
there are some real reasons why you wouldn't want to allow apple-user on
some users). Instead, you want to retain control of which users are extended
with the apple-user auxiliary class. In that case, you would NOT want to not
explicitly add the apple-user auxiliary class to the user class's schema
definition. Instead, you'd just add the apple-user class, with a
defaultSecurityDescriptor that ensured only you could add it. There are
valid alternative solutions here too. For example, you could modify the
defaultSecurityDescriptor on the attributes in the apple-user class,
retaining the ability to populate them, without throwing away the inherited
auxiliary approach.
Another thing to consider ...
_____
From: activedir-owner@mail.activedir.org
[activedir-owner@mail.activedir.org] On Behalf Of Wilper, Ross A
[rwilper@stanford.edu]
Sent: Tuesday, November 10, 2009 8:06 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Extending Schema w/Auxiliary Classes
This is a common question that worries people usually overmuch. The "you
cannot back the changes out", while true, should not be as scary as it is.
The important considerations to iron out are really
1) Make sure you assign unique OIDs (get a stem reserved if you need
to)
2) Be sure about the data type for the attributes (and
single/multivalue)
3) Name your attributes/classes to be unique - an organization-specific
prefix is usually used.
Other things to think about the attributes/data are
1) Should the new attributes be indexed?
2) Should the new attributes be replicated to the global catalog?
3) Should ACLs be changed to reflect the new data
4) If there is a huge amount of data/a lot of changes, then how will
this affect the size of the database/replication
Since these classes already exist most of this is probably thought through
already.
One thing to note is that schema objects can be deactivated, renamed, and
otherwise modified once they are in - unless they come from the "system"
schema. The only thing that I have found cannot be changed is object type
and data type- changing an OID is hard and I am not sure it is supported,
but I have done it, YMMV.
-Ross
From: activedir-owner@mail.activedir.org
[mailto:activedir-owner@mail.activedir.org] On Behalf Of Cynthia Haselton
Sent: Tuesday, November 10, 2009 6:29 AM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Extending Schema w/Auxiliary Classes
Hello,
I'm working at a location that runs LDAP alongside of Active Directory, and
there's a desire to extend the Active Directory schema with two, possibly
more, auxiliary classes that currently exist in LDAP.
Has anyone done this before, and if so, are there any potential drawbacks,
other than that the extensions will be permanent? Any considerations we
should take into account?
Thanks,
CJH
| | | |
| listmail
Posts:822
| | 11/10/2009 5:32 PM |
| Are you saying you slap a defaultSecurityDescriptor on an aux class and use
that to control who can add the aux class to an instantiated object? That
isn't going to work. Been a while since I have played with it, but the only
defaultSD that will come into play is the one for the class of the object
being instantiated. In order to prevent someone from adding the aux class,
you would have to prevent them from writing to the objectclass attribute of
the instantiated object and if they have rights to create an object, they
can add that aux class right during object instantiation. Only way around
that is to take away the ability to instantiate objects. Or I guess.
possibly. never tried this, but try to modify the ACL on the schema
definition of the aux class so the person can't even see the schema object
for the class.
Another issue with dynamic aux classes is that some apps, primarily ADSI
based apps will not properly understand the attributes associated with the
object since it won't know to pull the aux objectclass attributes (I believe
due to the schema caching underpinnings). At least that was always an issue,
I have pointed it out a few times so maybe it is fixed in the later versions
of ADSI. Plus unfortunately a lot of people just don't get dynamic aux
classes.
Personally I think dynamic aux classes are great but then again I rarely
write any ADSI code (or .NET code dependent on ADSI) and I also "get" them.
More people are just more comfortable with static aux classes bound to the
specific objectclass you care about or further up the chain. That can also
be a pain thought too because that aux class then doesn't show up in the
list of objectclasses for the object which sometimes you may actually want.
joe
--
O'Reilly Active Directory Fourth Edition -
http://www.joeware.net/win/ad4e.htm
From: activedir-owner@mail.activedir.org
[mailto:activedir-owner@mail.activedir.org] On Behalf Of Brian Arkills
Sent: Tuesday, November 10, 2009 11:33 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Extending Schema w/Auxiliary Classes
There is another design consideration to take into account when implementing
an auxiliary class. It has to do with schema design, but it has more to do
with how you plan to make use of your new class.
Typically, Microsoft and other vendors (the recently released Apple AD
schema jumps to mind) leverage auxiliary classes explicitly via inheritance.
In other words, the auxiliary class is "inherited" by creating an object of
a structural class that explicitly references the auxiliary class. This
approach is used to "extend" a finite number of existing classes. There is
another approach. The alternative is "dynamic auxiliary" where you can add
an auxiliary class to *any* structural class *after* an object of that class
has been created. So going back to the recently released Apple AD schema,
you might add the apple-user auxiliary to a group object. That isn't Apple's
intention, as they explicitly add it as an auxiliary on the user structural
class, and it wouldn't be especially useful, but it is possible.
This alternative approach is sometimes useful, especially when you are
working in a delegated AD, and you need to control when a particular
auxiliary class is instantiated. Imagine that you don't want every user
object to get the apple-user auxiliary class, because delegated
administrators could make use of features that would cause problems (and
there are some real reasons why you wouldn't want to allow apple-user on
some users). Instead, you want to retain control of which users are extended
with the apple-user auxiliary class. In that case, you would NOT want to not
explicitly add the apple-user auxiliary class to the user class's schema
definition. Instead, you'd just add the apple-user class, with a
defaultSecurityDescriptor that ensured only you could add it. There are
valid alternative solutions here too. For example, you could modify the
defaultSecurityDescriptor on the attributes in the apple-user class,
retaining the ability to populate them, without throwing away the inherited
auxiliary approach.
Another thing to consider ...
_____
From: activedir-owner@mail.activedir.org
[activedir-owner@mail.activedir.org] On Behalf Of Wilper, Ross A
[rwilper@stanford.edu]
Sent: Tuesday, November 10, 2009 8:06 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Extending Schema w/Auxiliary Classes
This is a common question that worries people usually overmuch. The "you
cannot back the changes out", while true, should not be as scary as it is.
The important considerations to iron out are really
1) Make sure you assign unique OIDs (get a stem reserved if you need
to)
2) Be sure about the data type for the attributes (and
single/multivalue)
3) Name your attributes/classes to be unique - an organization-specific
prefix is usually used.
Other things to think about the attributes/data are
1) Should the new attributes be indexed?
2) Should the new attributes be replicated to the global catalog?
3) Should ACLs be changed to reflect the new data
4) If there is a huge amount of data/a lot of changes, then how will
this affect the size of the database/replication
Since these classes already exist most of this is probably thought through
already.
One thing to note is that schema objects can be deactivated, renamed, and
otherwise modified once they are in - unless they come from the "system"
schema. The only thing that I have found cannot be changed is object type
and data type- changing an OID is hard and I am not sure it is supported,
but I have done it, YMMV.
-Ross
From: activedir-owner@mail.activedir.org
[mailto:activedir-owner@mail.activedir.org] On Behalf Of Cynthia Haselton
Sent: Tuesday, November 10, 2009 6:29 AM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Extending Schema w/Auxiliary Classes
Hello,
I'm working at a location that runs LDAP alongside of Active Directory, and
there's a desire to extend the Active Directory schema with two, possibly
more, auxiliary classes that currently exist in LDAP.
Has anyone done this before, and if so, are there any potential drawbacks,
other than that the extensions will be permanent? Any considerations we
should take into account?
Thanks,
CJH
| | | |
| barkills
Posts:201
| | 11/10/2009 5:46 PM |
| Yes, that's what I was saying, and yes, you are right that wasn't correct. Only the structural class defaultSecurityDescriptor matters.
Thanks for catching that. 
I wonder why I don't see my 2nd post about an hour ago on this thread yet ...
________________________________
From: activedir-owner@mail.activedir.org [activedir-owner@mail.activedir.org] On Behalf Of joe [listmail@joeware.net]
Sent: Tuesday, November 10, 2009 9:29 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Extending Schema w/Auxiliary Classes
Are you saying you slap a defaultSecurityDescriptor on an aux class and use that to control who can add the aux class to an instantiated object? That isn’t going to work. Been a while since I have played with it, but the only defaultSD that will come into play is the one for the class of the object being instantiated. In order to prevent someone from adding the aux class, you would have to prevent them from writing to the objectclass attribute of the instantiated object and if they have rights to create an object, they can add that aux class right during object instantiation. Only way around that is to take away the ability to instantiate objects. Or I guess… possibly… never tried this, but try to modify the ACL on the schema definition of the aux class so the person can’t even see the schema object for the class.
Another issue with dynamic aux classes is that some apps, primarily ADSI based apps will not properly understand the attributes associated with the object since it won’t know to pull the aux objectclass attributes (I believe due to the schema caching underpinnings). At least that was always an issue, I have pointed it out a few times so maybe it is fixed in the later versions of ADSI. Plus unfortunately a lot of people just don’t get dynamic aux classes.
Personally I think dynamic aux classes are great but then again I rarely write any ADSI code (or .NET code dependent on ADSI) and I also “get” them. More people are just more comfortable with static aux classes bound to the specific objectclass you care about or further up the chain. That can also be a pain thought too because that aux class then doesn’t show up in the list of objectclasses for the object which sometimes you may actually want.
joe
--
O'Reilly Active Directory Fourth Edition - http://www.joeware.net/win/ad4e.htm
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Brian Arkills
Sent: Tuesday, November 10, 2009 11:33 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Extending Schema w/Auxiliary Classes
There is another design consideration to take into account when implementing an auxiliary class. It has to do with schema design, but it has more to do with how you plan to make use of your new class.
Typically, Microsoft and other vendors (the recently released Apple AD schema jumps to mind) leverage auxiliary classes explicitly via inheritance. In other words, the auxiliary class is "inherited" by creating an object of a structural class that explicitly references the auxiliary class. This approach is used to "extend" a finite number of existing classes. There is another approach. The alternative is "dynamic auxiliary" where you can add an auxiliary class to *any* structural class *after* an object of that class has been created. So going back to the recently released Apple AD schema, you might add the apple-user auxiliary to a group object. That isn't Apple's intention, as they explicitly add it as an auxiliary on the user structural class, and it wouldn't be especially useful, but it is possible.
This alternative approach is sometimes useful, especially when you are working in a delegated AD, and you need to control when a particular auxiliary class is instantiated. Imagine that you don't want every user object to get the apple-user auxiliary class, because delegated administrators could make use of features that would cause problems (and there are some real reasons why you wouldn't want to allow apple-user on some users). Instead, you want to retain control of which users are extended with the apple-user auxiliary class. In that case, you would NOT want to not explicitly add the apple-user auxiliary class to the user class's schema definition. Instead, you'd just add the apple-user class, with a defaultSecurityDescriptor that ensured only you could add it. There are valid alternative solutions here too. For example, you could modify the defaultSecurityDescriptor on the attributes in the apple-user class, retaining the ability to populate them, without throwing away the inherited auxiliary approach.
Another thing to consider ...
________________________________
From: activedir-owner@mail.activedir.org [activedir-owner@mail.activedir.org] On Behalf Of Wilper, Ross A [rwilper@stanford.edu]
Sent: Tuesday, November 10, 2009 8:06 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Extending Schema w/Auxiliary Classes
This is a common question that worries people usually overmuch. The “you cannot back the changes out”, while true, should not be as scary as it is.
The important considerations to iron out are really
1) Make sure you assign unique OIDs (get a stem reserved if you need to)
2) Be sure about the data type for the attributes (and single/multivalue)
3) Name your attributes/classes to be unique – an organization-specific prefix is usually used.
Other things to think about the attributes/data are
1) Should the new attributes be indexed?
2) Should the new attributes be replicated to the global catalog?
3) Should ACLs be changed to reflect the new data
4) If there is a huge amount of data/a lot of changes, then how will this affect the size of the database/replication
Since these classes already exist most of this is probably thought through already.
One thing to note is that schema objects can be deactivated, renamed, and otherwise modified once they are in - unless they come from the “system” schema. The only thing that I have found cannot be changed is object type and data type- changing an OID is hard and I am not sure it is supported, but I have done it, YMMV.
-Ross
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Cynthia Haselton
Sent: Tuesday, November 10, 2009 6:29 AM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Extending Schema w/Auxiliary Classes
Hello,
I’m working at a location that runs LDAP alongside of Active Directory, and there’s a desire to extend the Active Directory schema with two, possibly more, auxiliary classes that currently exist in LDAP.
Has anyone done this before, and if so, are there any potential drawbacks, other than that the extensions will be permanent? Any considerations we should take into account?
Thanks,
CJH
| | | |
| EricGustafson
Posts:42
| | 11/10/2009 10:11 PM |
| No go. Put it on \\omgfs1\library$<file:///\\omgfs1\library$> and send him a link.
File sharing 101.
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Don Hacherl
Sent: Tuesday, November 10, 2009 12:28 PM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Extending Schema w/Auxiliary Classes
To be clear, the first mechanism you describe (having aux classes inherited through a structural class) is there only because I misread the X.500 spec in the mid-1990s and managed to convince everyone else at Microsoft that my misreading was correct. It was later pointed out to me that I was a bozo, but by that point it was too late and dependencies locked us into shipping that way. We added the "dynamic auxiliary" mechanism (i.e., the way X.500 and LDAP actually specify it to work), but the old interpretation lingers My apologies to all involved for the unnecessary confusion.
Don Hacherl
________________________________
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Brian Arkills
Sent: Tuesday, November 10, 2009 8:33 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Extending Schema w/Auxiliary Classes
There is another design consideration to take into account when implementing an auxiliary class. It has to do with schema design, but it has more to do with how you plan to make use of your new class.
Typically, Microsoft and other vendors (the recently released Apple AD schema jumps to mind) leverage auxiliary classes explicitly via inheritance. In other words, the auxiliary class is "inherited" by creating an object of a structural class that explicitly references the auxiliary class. This approach is used to "extend" a finite number of existing classes. There is another approach. The alternative is "dynamic auxiliary" where you can add an auxiliary class to *any* structural class *after* an object of that class has been created. So going back to the recently released Apple AD schema, you might add the apple-user auxiliary to a group object. That isn't Apple's intention, as they explicitly add it as an auxiliary on the user structural class, and it wouldn't be especially useful, but it is possible.
This alternative approach is sometimes useful, especially when you are working in a delegated AD, and you need to control when a particular auxiliary class is instantiated. Imagine that you don't want every user object to get the apple-user auxiliary class, because delegated administrators could make use of features that would cause problems (and there are some real reasons why you wouldn't want to allow apple-user on some users). Instead, you want to retain control of which users are extended with the apple-user auxiliary class. In that case, you would NOT want to not explicitly add the apple-user auxiliary class to the user class's schema definition. Instead, you'd just add the apple-user class, with a defaultSecurityDescriptor that ensured only you could add it. There are valid alternative solutions here too. For example, you could modify the defaultSecurityDescriptor on the attributes in the apple-user class, retaining the ability to populate them, without throwing away the inherited auxiliary approach.
Another thing to consider ...
________________________________
From: activedir-owner@mail.activedir.org [activedir-owner@mail.activedir.org] On Behalf Of Wilper, Ross A [rwilper@stanford.edu]
Sent: Tuesday, November 10, 2009 8:06 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Extending Schema w/Auxiliary Classes
This is a common question that worries people usually overmuch. The "you cannot back the changes out", while true, should not be as scary as it is.
The important considerations to iron out are really
1) Make sure you assign unique OIDs (get a stem reserved if you need to)
2) Be sure about the data type for the attributes (and single/multivalue)
3) Name your attributes/classes to be unique - an organization-specific prefix is usually used.
Other things to think about the attributes/data are
1) Should the new attributes be indexed?
2) Should the new attributes be replicated to the global catalog?
3) Should ACLs be changed to reflect the new data
4) If there is a huge amount of data/a lot of changes, then how will this affect the size of the database/replication
Since these classes already exist most of this is probably thought through already.
One thing to note is that schema objects can be deactivated, renamed, and otherwise modified once they are in - unless they come from the "system" schema. The only thing that I have found cannot be changed is object type and data type- changing an OID is hard and I am not sure it is supported, but I have done it, YMMV.
-Ross
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Cynthia Haselton
Sent: Tuesday, November 10, 2009 6:29 AM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Extending Schema w/Auxiliary Classes
Hello,
I'm working at a location that runs LDAP alongside of Active Directory, and there's a desire to extend the Active Directory schema with two, possibly more, auxiliary classes that currently exist in LDAP.
Has anyone done this before, and if so, are there any potential drawbacks, other than that the extensions will be permanent? Any considerations we should take into account?
Thanks,
CJH
| | | |
| chaselton
Posts:78
| | 11/11/2009 7:43 PM |
| Thanks for the helpful info; I haven't had time to carefully parse through all of it, however when I do and if I have questions I'll definitely return here.
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Brian Arkills
Sent: Tuesday, November 10, 2009 11:42 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Extending Schema w/Auxiliary Classes
Yes, that's what I was saying, and yes, you are right that wasn't correct. Only the structural class defaultSecurityDescriptor matters.
Thanks for catching that.
I wonder why I don't see my 2nd post about an hour ago on this thread yet ...
________________________________
From: activedir-owner@mail.activedir.org [activedir-owner@mail.activedir.org] On Behalf Of joe [listmail@joeware.net]
Sent: Tuesday, November 10, 2009 9:29 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Extending Schema w/Auxiliary Classes
Are you saying you slap a defaultSecurityDescriptor on an aux class and use that to control who can add the aux class to an instantiated object? That isn't going to work. Been a while since I have played with it, but the only defaultSD that will come into play is the one for the class of the object being instantiated. In order to prevent someone from adding the aux class, you would have to prevent them from writing to the objectclass attribute of the instantiated object and if they have rights to create an object, they can add that aux class right during object instantiation. Only way around that is to take away the ability to instantiate objects. Or I guess... possibly... never tried this, but try to modify the ACL on the schema definition of the aux class so the person can't even see the schema object for the class.
Another issue with dynamic aux classes is that some apps, primarily ADSI based apps will not properly understand the attributes associated with the object since it won't know to pull the aux objectclass attributes (I believe due to the schema caching underpinnings). At least that was always an issue, I have pointed it out a few times so maybe it is fixed in the later versions of ADSI. Plus unfortunately a lot of people just don't get dynamic aux classes.
Personally I think dynamic aux classes are great but then again I rarely write any ADSI code (or .NET code dependent on ADSI) and I also "get" them. More people are just more comfortable with static aux classes bound to the specific objectclass you care about or further up the chain. That can also be a pain thought too because that aux class then doesn't show up in the list of objectclasses for the object which sometimes you may actually want.
joe
--
O'Reilly Active Directory Fourth Edition - http://www.joeware.net/win/ad4e.htm
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Brian Arkills
Sent: Tuesday, November 10, 2009 11:33 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Extending Schema w/Auxiliary Classes
There is another design consideration to take into account when implementing an auxiliary class. It has to do with schema design, but it has more to do with how you plan to make use of your new class.
Typically, Microsoft and other vendors (the recently released Apple AD schema jumps to mind) leverage auxiliary classes explicitly via inheritance. In other words, the auxiliary class is "inherited" by creating an object of a structural class that explicitly references the auxiliary class. This approach is used to "extend" a finite number of existing classes. There is another approach. The alternative is "dynamic auxiliary" where you can add an auxiliary class to *any* structural class *after* an object of that class has been created. So going back to the recently released Apple AD schema, you might add the apple-user auxiliary to a group object. That isn't Apple's intention, as they explicitly add it as an auxiliary on the user structural class, and it wouldn't be especially useful, but it is possible.
This alternative approach is sometimes useful, especially when you are working in a delegated AD, and you need to control when a particular auxiliary class is instantiated. Imagine that you don't want every user object to get the apple-user auxiliary class, because delegated administrators could make use of features that would cause problems (and there are some real reasons why you wouldn't want to allow apple-user on some users). Instead, you want to retain control of which users are extended with the apple-user auxiliary class. In that case, you would NOT want to not explicitly add the apple-user auxiliary class to the user class's schema definition. Instead, you'd just add the apple-user class, with a defaultSecurityDescriptor that ensured only you could add it. There are valid alternative solutions here too. For example, you could modify the defaultSecurityDescriptor on the attributes in the apple-user class, retaining the ability to populate them, without throwing away the inherited auxiliary approach.
Another thing to consider ...
________________________________
From: activedir-owner@mail.activedir.org [activedir-owner@mail.activedir.org] On Behalf Of Wilper, Ross A [rwilper@stanford.edu]
Sent: Tuesday, November 10, 2009 8:06 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Extending Schema w/Auxiliary Classes
This is a common question that worries people usually overmuch. The "you cannot back the changes out", while true, should not be as scary as it is.
The important considerations to iron out are really
1) Make sure you assign unique OIDs (get a stem reserved if you need to)
2) Be sure about the data type for the attributes (and single/multivalue)
3) Name your attributes/classes to be unique - an organization-specific prefix is usually used.
Other things to think about the attributes/data are
1) Should the new attributes be indexed?
2) Should the new attributes be replicated to the global catalog?
3) Should ACLs be changed to reflect the new data
4) If there is a huge amount of data/a lot of changes, then how will this affect the size of the database/replication
Since these classes already exist most of this is probably thought through already.
One thing to note is that schema objects can be deactivated, renamed, and otherwise modified once they are in - unless they come from the "system" schema. The only thing that I have found cannot be changed is object type and data type- changing an OID is hard and I am not sure it is supported, but I have done it, YMMV.
-Ross
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Cynthia Haselton
Sent: Tuesday, November 10, 2009 6:29 AM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Extending Schema w/Auxiliary Classes
Hello,
I'm working at a location that runs LDAP alongside of Active Directory, and there's a desire to extend the Active Directory schema with two, possibly more, auxiliary classes that currently exist in LDAP.
Has anyone done this before, and if so, are there any potential drawbacks, other than that the extensions will be permanent? Any considerations we should take into account?
Thanks,
CJH
| | | |
|
|