Question on Active Directory Schema Expansion

  • Thread starter Thread starter Will
  • Start date Start date
W

Will

We are thinking of moving to a more secure authentication scheme using
fingerprint technology from digitalPersona. The digitalPersona
server-side product runs on each Active Directory server, and it requires an
Active Directory schema expansion. Unfortunately, to try out their demo
you must do this expansion, and if you reject the product the schema
expansion cannot be undone.

Is this something that should concern me, or are such schema expansions
likely to be harmless and have few unintended side-effects later?
 
Generally you're ok with stuff like this as they have thoroughly tested
their extensions. If it is truly an extension and not a modification you
should be OK.

HOWEVER...

I would strongly suggest doing this in a test environment. You never want
to use your production systems as a test or as a tech Toyland.
 
You absolutely need to be concerned about schema updates. The newsgroups and
corporations have lots of stories of people being screwed over by poor Schema
extensions.

You will want to check the schema updates for properly registered OIDs and
LinkIDs and schema name prefixs, etc. If you want, post the LDIF file use for
the extension to the newsgroup and people can look it over to see if they see
something that could cause an issue now or later.

At the very least, you should test the schema updates in test and QA environments.


joe
 
Generally, it is recommended that you do an extension on a derivative class
rather than doing this on one of the AD base classes. Talk with your vendor
to see if this is an option.

--
Ryan Hanisco
MCSE, MCDBA
FlagShip Integration Services
Chicago, IL
 
I am not sure I completely agree with that. There really isn't much harm in
adding attributes to an existing base class or using aux classes and then
dynamically (or if it applies to all objects of that class statically) adding
the aux class to the base class.

joe
 
Hi Joe,

I find it a lot safer to make a derivative of Users to something like
Employees and then make changes to the derivative. At the very least, it may
be a good way to test extensions before all objects are modified.

You are right in that there aren't usually problems with this. Its just that
I work in banking and Fortune 500 clients and they have surprisingly little
sense of humor for problems, so it is best to be 100% sure of something
before hitting production. Also, given the fact that the target audience is
people who are learning about schema extensions or doing them for the first
time, I wouldn't want to encourage extension of live objects if the
alternative isn't specifically difficult.

I hope that makes a bit of sense and better frames that response. You'll
find support for that position in both the WROX and Microsoft ADSI books,
although common practice may have changed in the last few years.


--
Ryan Hanisco
MCSE, MCDBA
FlagShip Integration Services
Chicago, IL
 
Yep I understand the reluctance of large companies, especially financials. All
of my experience in the last 10 years has been in Fortune 50 or bigger,
primarily Fortune 5 (I'm in southeast Michigan so I will let you guess several
of the Fortune 5 I have done a lot of work for) all of which tend to have
banking or trading divisions. Now I am out of ops and doing consulting for one
of the big service companies but still working on Fortune 50 type clients
usually trying to clean up the directory or figure out what is wrong with the
Exchange/AD interfaces.

It tends to be good to keep the environments as simple as possible so that
applications from vendors can easily work without much modification and so that
the masses of internal developers around the world for the companies don't all
have to be taught the special ways to do it inside of the orgs so they can
easily take any class anywhere to get basic AD knowledge and apply it. They (the
vendor apps and internal developers) will be expecting to be using user and
contact and computer and OU and inetorgperson objects, especially for creations.

Any schema changes need to be made in the lab and thoroughly tested there. The
lab should consist of multiple DCs and replication of the changes should be
checked carefully as some problems become more obvious on replication. Prior to
doing an actual live production forest update of a schema I tend to recommend
sucking off the live production domains onto DCs and stick them in a segregated
room cut off from the rest of the network and apply the changes there and see
how they impact the production schema (because you never truly know). Once that
is known to be good, then you follow the same procedure you used in test for
updating the schema in production and things should go very well. Exceptions
that will obviously be different in the real world is convergence time and if
you have are doing PAS updates in a 2K environment you will have full
replication for the GCs (which you usually can't mirror in test unless you have
a giant test environment) and when you have index builds which can slow things
down a little as well. I recall the first schema update we did for one of the
Fortune 5 companies that MS told us would be done in about 90 minutes because
that is what it took in the lab they mocked up for it... It really took around
18 hours. We smacked out onsite MS folks around quite a bit for that one.

Further, people should be checking the OIDs of adds they are making to the
schema as well as checking for registered prefix names and registed linkids if
any of the attributes being added are linked (preferably if using linked
attribuets and the forest is 2K3 or better they are using autolinking and you
don't have to worry about linkids).

Schema updates are generally safe. They are unsafe when people are being
foolhardy and not up to speed with what they are messing with or the vendors
from whom they are taking schema changes from aren't up to speed.

joe
 
Back
Top