Marin Marinov
Guest
|
 Posted:
Fri Nov 11, 2005 9:50 pm Post subject:
Re: Trying to understand what is what... |
|
|
<snip>
Hi Robert;
Let me take a stab at it ;)
* Schema - contains the formal declaration of "what" can exist in Active
Directory (including parameters, allowed associations, value types,
etc.) Something has to "say" how exactly "things" in Active Directory
should look like otherwise it will be chaos and lack of standardization.
Think of it as your box of hundreds of cookie cutters each of which is a
unique from the rest.
* Class - defined in the schema; a representation of the parameters of a
real world object, device, service, etc. Think of it as a cookie cutter
(again, each class is unique in some aspect from the others). For
example, the class Person is a formal declaration of a real world entity
- a human ;)
* Attribute - defined in the schema and linked with at least one class;
has type (string, integer, Boolean, etc.) and defines a particular
property of a class. In the cookie cutter context, this could be the
tail of a lion-shaped cookie cutter form. For the Person class, for
example, you would have a "name" attribute.
* Object - an actual "materialization" of a class. The class and
attributes cannot be used by themselves - they just "define" the
parameters of the respective entity. The entity becomes "alive" when an
"instance of a class" is created and its attributes are populated with
actual values. Active Directory can then use and manipulate this
"object". In the cookie cutter context, this is your actual cookie which
you have cut with one of the cookie cutters. Now, to be more precise,
this would be one heck of a high-tech cookie cutter since obviously an
attribute (depending on its type) could have different values for
different objects so the tail part of a lion-shaped cookie cutter has to
be adjustable in size ;) In the Person case, the object would have
attributes such as a particular name that make it unique within a
certain scope.
Hope this gave you a different perspective on the AD schema and helped
you gain more understanding of this at first very confusing matter.
Disclaimer: Needless to say this is a hiiiiighly simplified view of
these topics and there are a ton of IF's, SOMETIMES's, WHEN's and simply
other things I skipped ;)
--
Cheers,
Marin Marinov
MCT,MCSE,MCSE:Security,MCP+I
-
This posting is provided "AS IS" with no warranties, and confers no
rights.
"True knowledge exists in knowing that you know nothing."
Socrates |
|
Ace Fekay [MVP]
Guest
|
| Posted:
Sat Nov 12, 2005 1:50 am Post subject:
Re: Trying to understand what is what... |
|
|
In news:MPG.1ddea6badfc6fa5d9898ec@msnews.microsoft.com,
Marin Marinov <marin-online@hotmail.ca> made this post, which I then
commented about below:
| Quote: | snip
Hi Robert;
Let me take a stab at it ;)
* Schema - contains the formal declaration of "what" can exist in
Active Directory (including parameters, allowed associations, value
types, etc.) Something has to "say" how exactly "things" in Active
Directory should look like otherwise it will be chaos and lack of
standardization. Think of it as your box of hundreds of cookie
cutters each of which is a unique from the rest.
* Class - defined in the schema; a representation of the parameters
of a real world object, device, service, etc. Think of it as a cookie
cutter (again, each class is unique in some aspect from the others).
For example, the class Person is a formal declaration of a real world
entity - a human ;)
* Attribute - defined in the schema and linked with at least one
class; has type (string, integer, Boolean, etc.) and defines a
particular property of a class. In the cookie cutter context, this
could be the tail of a lion-shaped cookie cutter form. For the Person
class, for example, you would have a "name" attribute.
* Object - an actual "materialization" of a class. The class and
attributes cannot be used by themselves - they just "define" the
parameters of the respective entity. The entity becomes "alive" when
an "instance of a class" is created and its attributes are populated
with actual values. Active Directory can then use and manipulate this
"object". In the cookie cutter context, this is your actual cookie
which you have cut with one of the cookie cutters. Now, to be more
precise, this would be one heck of a high-tech cookie cutter since
obviously an attribute (depending on its type) could have different
values for different objects so the tail part of a lion-shaped cookie
cutter has to be adjustable in size ;) In the Person case, the object
would have attributes such as a particular name that make it unique
within a certain scope.
Hope this gave you a different perspective on the AD schema and helped
you gain more understanding of this at first very confusing matter.
Disclaimer: Needless to say this is a hiiiiighly simplified view of
these topics and there are a ton of IF's, SOMETIMES's, WHEN's and
simply other things I skipped ;)
|
Excellent Marin!
Maybe if I can throw my two cents in:
Active Directory is based on the X.500 directory service implemented in
1982, refined a bit in 1984, then again with the standardized version that
came out in 1988 by the CCITT (now known as the ITU). A few companies came
out with their own products that conform with this industry standard. Banyon
Vines was the first in 1985 based on the original implementation, but not
the standardized version, with their product called "Street Talk." Then I
think MIT was the next one with NIS (Network Information Services), if I
remember correctly, and this worked on other Unix flavors as well (not
Linux). This was based on the ISO model and used DAP to search the objects
in the tree. Kind of cumbersome, but it worked. Then of course Novell came
out with their product, NDS, based on this as well. Of course there were
other refinements to X.500 by the ITU during the 90's. Then LDAP came out as
a "Lightweight X.500" service based on TCP/IP instead of the ISO model.
Microsoft decided to use LDAP to be the basis of AD and using Kerberos for
the authentication method. Then Microsoft decided to store the services
locations of AD services in DNS and base the domain design principle on DNS
and use the newly introduced industry standard SRV records to store these
service locations and find the machines that hold those services. DNS is a
great repository that made it simpler to locate objects and services in AD.
That's why it bugs me when people out there that don't do their research
that state that Microsoft stole AD from NDS. I hear it all the time from
students that have worked with Novell for years. I guess brainwash comes to
mind. I like to hold an open mind to anything, including software and
operating system vendors and their products, and learn about how they were
designed and what they were based on. AD is just Microsoft's product based
on an industry standard, just as Novell based NDS on the same standard, as
well as Netscape LDAP services and Cold Fusion LDAP services, etc. They are
all interoperable for that reason.
Anyway, about AD objects, the way I explain it to students, is the Schema is
a definition library that states or defines Classes. Classes are the
definition of the type of objects that can be created and what attributes
those objects can have, whether the attributes are mandatory or optional.
Theer are User Classes, Computers, etc. Say we create a user object, then we
need to define at the time of creation the mandatory attributes, such as
display name, logon name, etc. Then there are option attributes, such as
phone number, zip code, etc.
Then I take it a step further with an analogy of McDonald's Big Mac.
Remember the song? Two all beef patties, special sauce, lettuce, cheese,
pickles, onions on a sesame seed bun. But what is the Big Mac? Basically
it's a hamburger with a bunch of attributes added. So we can say the Class
Object called 'hamburger' contains two mandatory attributes, beef and the
bun. Then there are bunch of attributes associated with this class object
that can be added. We can then define a Child Class object called the Big
Mac that contains a certain combination of attributes that make up the child
class called the Big Mac. Then they have the Bacon Cheeseburger, which
contains certain attributes that make up that child object.
Make sense?
Keep in mind all the attributes in the Schema do not map to all objects, but
the Schema is the repository for all objects and their attributes.
Here's more on Active Directory's inner workings and a history of X.500 and
LDAP:
A History of Directory Standards:
http://www.daasi.de/staff/norbert/thesis/html/node4.html
History of X.500 - Slide #10:
http://www.symlabs.com/Training/LDAP30J/ldap30j_mod1_10.html
Introduction to Directories and LDAP:
http://www.symlabs.com/Training/LDAP30J/IX-1.html
Understanding Active Directory Services:
http://www.awprofessional.com/articles/article.asp?p=101405&seqNum=5
X.500:
http://www.computerhope.com/jargon/x/x500.htm
Talking about cheeseburgers just made me hungry... Now I'm off to Wendy's.
Why them over McD's? It's closer and I like Wendy's Bacon Cheddar Mushroom
Melt double meat....
:-)
--
Ace
This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.
If this post is viewed at a non-Microsoft community website, and you were to
respond to it through that community's website, I may not see your reply
unless that website posts replies back to the original Microsoft forum.
Therefore, please direct all replies ONLY to the Microsoft public newsgroup
this thread originated in so all can benefit or ensure the web community
posts it back to the original forum.
Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft MVP - Windows Server Directory Services
Microsoft Certified Trainer
Infinite Diversities in Infinite Combinations.
================================= |
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in