|
Use
adfind -sc sdump
or
adfind -sc sdump:csv
to dump a schema suitable for comparison with say
Windiff
I am
pretty sure it captures all of the critical info and it definitely maintains the
order of the attributes so you don't have to worry about the text analyzer
resyncing when lines are out of order...
The
output for the first command looks like
dn:CN=account,<SCHEMA>
>adminDescription: The account object class is used to define entries representing computer accounts. >adminDisplayName: account >attributeID: <NOT SET> >attributeSecurityGUID: <NOT SET> >attributeSyntax: <NOT SET> >auxiliaryClass: <NOT SET> >cn: account >defaultHidingValue: TRUE >defaultObjectCategory: CN=account,<SCHEMA> >defaultSecurityDescriptor: D:(A;;RPWPCRCCDCLCLOLORCWOWDSDDTDTSW;;;DA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLORC;;;AU) >description: <NOT SET> >extendedCharsAllowed: <NOT SET> >governsID: 0.9.2342.19200300.100.4.5 >isDefunct: <NOT SET> >isMemberOfPartialAttributeSet: <NOT SET> >isSingleValued: <NOT SET> >lDAPDisplayName: account >linkID: <NOT SET> >mAPIID: <NOT SET> >mayContain: uid >mayContain: host >mayContain: ou >mayContain: o >mayContain: l >mayContain: seeAlso >mayContain: description >mustContain: <NOT SET> >objectClass: top >objectClass: classSchema >objectClassCategory: 1 >oMSyntax: <NOT SET> >possSuperiors: organizationalUnit >possSuperiors: container >rangeLower: <NOT SET> >rangeUpper: <NOT SET> >rDNAttID: cn >schemaIDGUID: {2628A46A-A6AD-4AE0-B854-2B12D9FE6F9E} >searchFlags: <NOT SET> >showInAdvancedViewOnly: TRUE >subClassOf: top >systemAuxiliaryClass: <NOT SET> >systemFlags: <NOT SET> >systemMayContain: <NOT SET> >systemMustContain: <NOT SET> >systemOnly: FALSE >systemPossSuperiors: <NOT SET> The
output for the second command looks like (well it looks pretty ugly here but is
great for scripts...)
"dn","adminDescription","adminDisplayName","attributeID","attributeSecurityGUID","attributeSyntax","auxiliaryClass","cn","defaultHidingValue","defaultObjectCategory","defaultSecurityDescriptor","description","extendedCharsAllowed","governsID","isDefunct","isMemberOfPartialAttributeSet","isSingleValued","lDAPDisplayName","linkID","mAPIID","mayContain","mustContain","objectClass","objectClassCategory","oMSyntax","possSuperiors","rangeLower","rangeUpper","rDNAttID","schemaIDGUID","searchFlags","showInAdvancedViewOnly","subClassOf","systemAuxiliaryClass","systemFlags","systemMayContain","systemMustContain","systemOnly","systemPossSuperiors"
"CN=account,CN=Schema,CN=Configuration,DC=pg,DC=com","The account object class is used to define entries representing computer accounts.","account","<NOT SET>","<NOT SET>","<NOT SET>","<NOT SET>","account","TRUE","CN=account,<SCHEMA>","D:(A;;RPWPCRCCDCLCLOLORCWOWDSDDTDTSW;;;DA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLORC;;;AU)","<NOT SET>","<NOT SET>","0.9.2342.19200300.100.4.5","<NOT SET>","<NOT SET>","<NOT SET>","account","<NOT SET>","<NOT SET>","uid;host;ou;o;l;seeAlso;description","<NOT SET>","top;classSchema","1","<NOT SET>","organizationalUnit;container","<NOT SET>","<NOT SET>","cn","{2628A46A-A6AD-4AE0-B854-2B12D9FE6F9E}","<NOT SET>","TRUE","top","<NOT SET>","<NOT SET>","<NOT SET>","<NOT SET>","FALSE","<NOT SET>" "CN=Account-Expires,CN=Schema,CN=Configuration,DC=pg,DC=com","Account-Expires","Account-Expires","1.2.840.113556.1.4.159","{4C164200-20C0-11D0-A768-00AA006E0529}","2.5.5.16","<NOT SET>","Account-Expires","<NOT SET>","<NOT SET>","<NOT SET>","<NOT SET>","<NOT SET>","<NOT SET>","<NOT SET>","<NOT SET>","TRUE","accountExpires","<NOT SET>","<NOT SET>","<NOT SET>","<NOT SET>","top;attributeSchema","<NOT SET>","65","<NOT SET>","<NOT SET>","<NOT SET>","<NOT SET>","{BF967915-0DE6-11D0-A285-00AA003049E2}","16","TRUE","<NOT SET>","<NOT SET>","16","<NOT SET>","<NOT SET>","FALSE","<NOT SET>" "CN=Account-Name-History,CN=Schema,CN=Configuration,DC=pg,DC=com","Account-Name-History","Account-Name-History","1.2.840.113556.1.4.1307","<NOT SET>","2.5.5.12","<NOT SET>","Account-Name-History","<NOT SET>","<NOT SET>","<NOT SET>","<NOT SET>","<NOT SET>","<NOT SET>","<NOT SET>","<NOT SET>","FALSE","accountNameHistory","<NOT SET>","<NOT SET>","<NOT SET>","<NOT SET>","top;attributeSchema","<NOT SET>","64","<NOT SET>","<NOT SET>","<NOT SET>","<NOT SET>","{031952EC-3B72-11D2-90CC-00C04FD91AB1}","0","TRUE","<NOT SET>","<NOT SET>","16","<NOT SET>","<NOT SET>","FALSE","<NOT SET>" for
the curious, the -sc sdump shortcut simply combines the following
switches
Selected Switches
-f (name=*) -oao <NOT SET> -po -replacedn _schema;_config -s one -sc sdump -schema -sort name Selected Attributes
adminDescription adminDisplayName attributeID attributeSecurityGUID attributeSyntax auxiliaryClass cn defaultHidingValue defaultObjectCategory defaultSecurityDescriptor description extendedCharsAllowed governsID isDefunct isMemberOfPartialAttributeSet isSingleValued lDAPDisplayName linkID mAPIID mayContain mustContain objectClass objectClassCategory oMSyntax possSuperiors rangeLower rangeUpper rDNAttID schemaIDGUID searchFlags showInAdvancedViewOnly subClassOf systemAuxiliaryClass systemFlags systemMayContain systemMustContain systemOnly systemPossSuperiors As for
the reason for all of this....
I
think I would keep the schemas specific to their uses. If you end up putting the
full schemas everywhere and you don't actually need the attributes who is
to say someone doesn't start using those unused attributes in some of the
directories and thinking that is valid to do? You may not think you are in the
business of protecting and maintaining those attributes and find out from some
business application owner that you now actually are... If something is
available and people can't get at it, expect them to use it at some point.
I
would have a validation LDAP instance somewhere owned by the overall Schema
owners that has all of the attributes defined so that you know you don't have
collisions etc when adding something new. Also if you do that, you can be aware
of everything that is out there so you don't maybe duplicate something. I would
then put in objects that represent the directories and slap in a custom FL/BL to
link those objects to schema classes and attributes so you can quickly ascertain
what attributes/classes are used in what directories and what directories use
what classes and attributes.
joe
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Thursday, September 14, 2006 5:06 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Handling different schemas - managing & maintaining updates The
AD schema analyzer is quite useful for comparing schemas to find missing
attributes and classes (and to export them to LDIF so as to allow an import to
the target schema). Note however, that it doesn’t find differences at the
level of properties you have set for your schema objects, for example it doesn’t
find the difference in the searchFlags for an attribute that exists in both
schemas. As
such you need to know how close you want your schema to match and likely need to
an exact compare either using custom scripts or LDIF dumps of the complete
schema coupled with text-compare tools. In
general I would want to question what your goal is – like Al I am assuming you
want to make the schema more manageable. Basically a convenience so you don’t
have to worry about managing and documenting the differences. That’s quite
different from a technical necessity, where you may need to fully replicate all
objects in your AD along with all attributes (except the ones managed by the
system) – in this case, you may need to keep your schemas fully in
sync. I
would not much discuss the security with respect to the Schema classes and
attributes stored in the different Forest schemas – I would not say that there
is much of a risk in knowing you have XYZ attributes defined in either schema.
The discussion is much more relevant as to which data do you plan to replicate
between the two? Let’s assume you are storing sensitive data in one of
your forests, for example, you may store the social security number of your
employees in a company specific attribute called “MyCompany-Employee-SSN”, and
you have even done everything to hide this data from normal read access (i.e.
you’ve configured it as a confidential attribute). Do you want this data
to be replicated to the other forests? If not, then I would also not
suggest to add the special schema attribute to your other forests schema, since
this way you hinder it from being synced by accident (not saying you couldn’t
sync it elsewhere). If
later there is a necessity to replicate the data across to the other forest(s)
you could add a simple procedure in your ITIL processes that would ensure that
the target schemas need to be updated appropriately prior to replicating the
data. /Guido From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Al Mulnick Yep, the schema analyzer would be
a good tool to have hold of. On 9/13/06, Joe Kaplan <[EMAIL PROTECTED]>
wrote: I like this advice as well. In terms of some of
the nuts and bolts of how |
