Re: AD Schema Extension Question
- From: "Joe Kaplan" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 20 Nov 2007 23:01:38 -0600
The rangeUpper recommendation is mostly there as a safeguard to help protect
the directory. If you make it as small as you can get away with that still
allows the amount of data you actually plan to store, you help prevent
someone from accidentally or maliciously using their permissions to put more
data in your directory than you want or can handle. It is just a safety
valve.
Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"Oliver" <Oliver@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:6E595C08-B491-483A-9C6C-99B76B5F6129@xxxxxxxxxxxxxxxx
Mmm...sounds like (ADAM/sync) a bit of work there, and introduces another
layer of complexity. Might just stick with the modification of the AD
schema.
The rangeUpper values you mention are they implemented simply for
protection
and as a safeguard against directory bloat given that the app might get
ambitious and mess up the dir. with excessive amounts of data? Or is there
some other reasoning behind that..?
Anyway - your help has been invaluable, and has certainly spiked my
interest
in AD from a more programmatic POV... :)
thanks again!
"Joe Kaplan" wrote:
It could. You would need to have a user object in ADAM for each user in
AD
so there would be a place to actually put this attribute data which would
imply that you would set up some sort of ongoing sync mechanism. If for
whatever reason your eally didn't want this data in your main AD, that
would
be a reasonable way to solve that problem. The ADAM instances could be
deployed much more narrowly so that they could support only the
applications
that need this data.
On the other hand, if you envision having lots of applications that need
access to the same data and those apps might be deployed all over the
place
(but in the same locations that you have AD now), then AD might make a
better choice.
My instinct on this type of thing is that if the data is for more than
one
application and isn't going to make an impact on DIT size or replication
that is a major concern, I'd just put it in AD. Going through the
trouble
to set up ADAM, get sync working and get ADAM deployed and replicating
might
not be worth it. Your own requirements will help you balance these two
approaches and hopefully indicate which way is preferable. Other people
tend to like to avoid putting this stuff in AD and will go for the ADAM
approach first, so some of this is just disposition as to whether you
like
to extend the AD schema or not. :)
You could also put the data in SQL if you wanted to (or another LDAP
directory). It all depends on what you need.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
--
"Oliver" <Oliver@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:ADE39366-1CD4-45B8-878D-B87F0C579543@xxxxxxxxxxxxxxxx
Thanks very much for the response Joe - just the kind of suggestions i
was
looking for.
One other question though: could ADAM be used in a scenario such as
this?
Thanks again. :)
"Joe Kaplan" wrote:
From a pure schema perspective, this is a pretty standard thing to do.
Make
sure that an appropriate syntax for the datatype is being used
(probably
either octet string if storing data as binary or unicode string is
storing
as an encoded string). Also, make sure that rangeUpper is set
appropriately
to allow for the largest possible blob of data but doesn't allow
unbounded
data to be inserted. I also recommend setting schemaIDGUID on the
attributes being added so that they will be the same in every
directory
they
are imported into.
Unless you are doing linked attributes, there isn't a whole lot else
to
get
wrong.
Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
--
"Oliver" <Oliver@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:13B507CF-B17C-4E7F-B6ED-4320A8023BE2@xxxxxxxxxxxxxxxx
have a customer that wants to extend the schema to include an attrib
for
an
auxiliary class attached to the user class. The attribute will be
used
to
store compressed and encrypted XML code with logon..and is currently
used
to
store connection details for two applications - (its for an inhouse
SSO
app).
They have registered the OID etc..Just wondering if there was
anything
to
consider here? I was thinking DIT size/storage, replication
etc...but
is
there anything on the actual schema-side that may casue issues in
the
long
term? I did refer to some AD books for some guidance..and googled
but
nothing
(other than whats already mentioned here) really stood out.
rgds
O.
.
- Follow-Ups:
- Re: AD Schema Extension Question
- From: Oliver
- Re: AD Schema Extension Question
- References:
- AD Schema Extension Question
- From: Oliver
- Re: AD Schema Extension Question
- From: Joe Kaplan
- Re: AD Schema Extension Question
- From: Joe Kaplan
- Re: AD Schema Extension Question
- From: Oliver
- AD Schema Extension Question
- Prev by Date: Re: AD Schema Extension Question
- Next by Date: Re: How many objects in AD?
- Previous by thread: Re: AD Schema Extension Question
- Next by thread: Re: AD Schema Extension Question
- Index(es):
Relevant Pages
|
