Re: Adding to Schema

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Thanks for the reply!

I will pass this information along.

"Joe Kaplan" wrote:

If you want to add the data to AD, then there is no real important
difference between creating your own attribute and using an existing one.
The advantage of creating your own is that you are ensured that no one else
will ever use it for anything else since no other software will be built to
manage it. You will need to provide your own tools to manage the data
though. If you were to use description for this, you could also use ADUC
(which has UI for description).

If you really don't want to put the data in AD, you might consider storing
it in ADAM and creating a sync setup to sync your AD users with objects in
ADAM that would basically be pointers to AD users. The apps that read and
write the data would be coded to access it from ADAM.

This solution, while not that complex, is more complex than adding the data
to AD. However, it minimizes any impact of this data to AD replication or
DIT size.

So, it depends on what you are trying to optimize for. Any of the solutions
may be appropriate for you.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
"tmpotvin" <tmpotvin@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:A906E0E2-D456-481B-826F-DD900F59576A@xxxxxxxxxxxxxxxx
Good Afternoon,
I've been trying to research the best option for this one....

We have a front end application that allows users to update their basic AD
information (Address, phone, etc...). This works nicely with no impact on
AD. We've been asked to look at adding an option for users to enter
information on their job responsibilities as well as what they're
currently
working on. The fields would be a max of 250 characters.

I would like to know if it's recommended to add this stuff as extended
attributes in to AD considering the data will never be the same and will
be
free text. The other thing is that will this make a difference if we're
running on a large domain with DCs in multiple countries.

If this is not recommended, then are there any other easy options for
associating this information with AD but not actually adding it to the
schema. This way, I can help to guide the developers in the right
direction.

Please let me know and thanks in advance for the Help!
T


.

Relevant Pages

  • Re: AD Schema Extension Question
    ... Might just stick with the modification of the AD schema. ... "Joe Kaplan" wrote: ... The ADAM instances could be ... Co-author of "The .NET Developer's Guide to Directory Services Programming" ...
    (microsoft.public.windows.server.active_directory)
  • Re: Adding to Schema
    ... If you really don't want to put the data in AD, you might consider storing it in ADAM and creating a sync setup to sync your AD users with objects in 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: 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: Incorrect LogonUserIdentity.Name
    ... "Joe Kaplan" wrote: ... Co-author of "The .NET Developer's Guide to Directory Services Programming" ... I'm uncertain why the server variables would be up to date but ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: ADFS app dev and org claim group mappings not working
    ... "Joe Kaplan" wrote: ... Co-author of "The .NET Developer's Guide to Directory Services Programming" ... I posted this in ADSI forum too because I just noticed a lot of ADFS ...
    (microsoft.public.windows.server.active_directory)