Re: AD Schema Extension Question

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.






.

Relevant Pages

  • Re: Adding to Schema
    ... "Joe Kaplan" wrote: ... ADAM that would basically be pointers to AD users. ... Co-author of "The .NET Developer's Guide to Directory Services Programming" ...
    (microsoft.public.windows.server.active_directory)
  • Re: AD/ADAM Create User (VB.Net)
    ... The important thing to know about ADAM is that out of the box, ... limited schema and a ton of flexibility that AD doesn't have. ... Joe Kaplan-MS MVP Directory Services Programming ... Co-author of "The .NET Developer's Guide to Directory Services Programming" ...
    (microsoft.public.windows.server.active_directory)
  • Re: AD Schema Extension Question
    ... As far as information regarding recommendations on schema extensions goes, ... "Joe Kaplan" wrote: ... Co-author of "The .NET Developer's Guide to Directory Services Programming" ... The ADAM instances could be ...
    (microsoft.public.windows.server.active_directory)
  • Re: Changing ADAM user password
    ... configuration tweaks that need to be done before ADAM is usable. ... Joe Kaplan wrote: ... Co-author of "The .NET Developer's Guide to Directory Services Programming" ... DirectoryEntry changeEntry = new DirectoryEntry(ldapPath, userID, ...
    (microsoft.public.windows.server.active_directory)
  • Re: ADAM Schema Import Error
    ... I think hiding them is a good thing, as that schema ... Co-author of "The .NET Developer's Guide to Directory Services Programming" ... the user object in ADAM is not bindable as it does not implement either a ... Run ADSchemaAnalyzer load the exchange extended schema from the DC ...
    (microsoft.public.windows.server.active_directory)