Joe,
(this is a bit rambling. My apologies, its
Sunday *grin*)
We really cant stop them from bring up ADAM
directories (since it can be run on their workstations if required).
However, we have very strong commitments from the application managers and the
CIO, that any modifications to the production AD system must first be approved
by the directory team, the infrastructure team, and IT security. We are
incredibly strict about production AD mods, and basically nothing "silly" has
gotten through yet (it helps when people on all three of those teams do have
some apps dev background, and can see through any FUD that's the apps dev
team put up).
As for hunting for instances, yes we regularly
scan the network for "weird" applications (part of our software licensing
compliance), and do ask questions if we detect software or applications we
don't know about. We do have a commitment regarding any AD environments,
that only the directory team can bring them up, so no "rogue" AD environments
exist.
We have some dev only environments as well
(including AD), however the directory management side is performed by the same
team that looks after prod, so silly requests don't get through. Mostly
these requests are around schema modification, however we have been able to
press other fields into service, or point out other ways the requests can be
done without hacking the schema. We also have strict guidelines on the
use of pre-production code (like Beta's of Exchange, Sharepoint, AD, W2k3
etc), and can literally pull out beta software when new versions appear, or if
some critical problem is located.
As for standards, the main one is ensuring that
the backup team (to ensure that the systems they are developing can be DR'd),
the security team (ensuring that the thing can be secured and that sufficient
logging is built into the app), the infrastructure team (to correctly allocate
hardware resources), and the directory team (for directory / authentication
requirements) are all consulted during the initial planning phases, and get
regular updates during the development lifecycle (long sentence that
one).
This is probably the best weapon, to make sure
your prod management teams are consulted right from the beginning, and there
is a signoff process for the design from the above teams. Therefore
there shouldn't be any real surprises when the thing goes from dev to test to
prod. We use the same prod team to manage the test / pre-prod
environments, so we find out well before the thing gets near
production.
We also don't support production applications
running anywhere OTHER than the prod forest. Again, this stance needs
commitment from the highest levels in the organisation, otherwise you are just
banging your head against the wall. Once you can convince the CEO / CIO
/ CTO etc that the management team is not there to make life miserable for the
dev teams, but to provide a functional and supportable environment for the
organisation and your customers (and do know what they are talking about),
things become a lot easier.
Also having a strict change-control process in
place for production helps, as any changes to the prod environment require
signoff from the change control board (which includes the above teams, senior
management, and the application owners). Its easy to just pressure the
AD team if such controls aren't in place, however trying to push changes via a
change control board means they have to convince a lot of people that it "is a
good thing".
Our inter-team communication is also good, so if
they try and "sneak" an app into prod on the non-prod environment, the AD team
always finds out about it. A key requirement is that all production
applications require a DR plan which involves the backup team (who double
check with the AD and infrastructure teams that's everything is
above-board).
Initially the apps dev guys weren't particularly
happy with some of the constraints, however over time we have shown that we
aren't the bad guys, and are willing to manage many aspects of their systems
(leaving them free to work on newer, cooler things), provided we know about
it, and can support it.
I've worked in a number of organisations with
varying degrees of the above controls, but most of it boils down to commitment
from the senior levels of the organisation that your support teams are there
to ensure everything keeps running, and if they say no, there is usually a
good reason. Once your input is valued by the organisation, a lot of the
other controls start to fall into place.
*phew*
G.
----- Original Message -----
Sent: Saturday, June 28, 2003 11:38
PM
Subject: RE: [ActiveDir] MMS 2003 and
ADAM 2003
Do
you have a method of searching for the AD/AMs or otherwise preventing
developers from spinning them up and using them without your knowledge in a
production way?
My
general experience is that if you allow developers to just do what they want
to do, they will set things up in a way that do not josh with your
production environment and will expect you to change your production
environment to support their application on their timeline. Usually you find
this out in too short of a time frame to fix the app that they wrote and the
changes too unique to their app to change your global AD deployment so they
end up going live on their dev environment.
We
have a "dev only" AD that initially came up on Beta3 W2K that was supposed
to go away within a few months of the production forest coming up in 2000
but is still functioning as a production environment now in 2003 with
tremendous migration pains trying to pull the apps off of it. It is still
there because apps slipped from dev to prod without any real fine line, the
pilots just got bigger and bigger until it was too big and too needed to
make the jump.
Also that brings up the question of whether or not companies are
publishing AD programming/application guidelines and if so, is anyone
willing to share what they have? As more and more people look at using our
centralized authentication environment we are getting lots of requests for
"how do we do it" especially from Java and UNIX environments. So we are
looking at trying to publish guidelines but that is sort of like extra work
on top of everything else.
joe
Todd,
I agree.
My point was that our apps dev guys are
looking into integrating with AD for some of the corporate apps.
ADAM lets us deploy very quickly a "lookalike" of our AD
infrastructure (users, etc) and let them play to their hearts content
without requiring us to continuiously set up and pull down a "real" AD
forest. When the time comes for them to integrate with the "real"
AD, we then setup a pre-prod forest for them to play with.
Lets them work out the kinks in their
software without hassling us every couple of days, and saves on the
hardware costs of multiple AD forests (minimum 2 DCs for each
instance).
For real corporate applications, we only
provide a single directory, AD.
Glenn
----- Original Message -----
Sent: Saturday, June 28, 2003 11:29
AM
Subject: RE: [ActiveDir] MMS 2003
and ADAM 2003
I would
encourage organizations to consider a registry for Adam's or LDAP type
directories. You don't want to end up with the same mess NT 4
domains created for applications. I would find out if the
application does authentication via the directory, and if it does,
encourage the developers to use an infrastructure Single Sign On
product.
Just my humble
opinion.
Todd
-----Original
Message-----
From:
Glenn Corbett [mailto:[EMAIL PROTECTED]
Sent: Friday, June 27,
2003 8:54 PM
To:
[EMAIL PROTECTED]
Subject: Re: [ActiveDir] MMS 2003
and ADAM 2003
ADAM is
also good for those applications that want to start doing some AD
integration functionality without actually having to set up an AD
forest.
Makes
us Infrastructure guys nice and happy, don't have to keep setting up and
pulling down AD forests every week or so for the apps dev guys
:)
-----
Original Message -----
Sent: Friday, June 27, 2003
11:38 PM
Subject: RE: [ActiveDir] MMS 2003
and ADAM 2003
IMHO, ADAM is
the more exciting of the two. Granted MMS is nice in what it
does (been working with it on and off for a while) but ADAM is really
a special product in what you can do with it. For those of you
that want to integrate your application, but don't want to go to the
time expense and trouble of integrating AD or directory sevices (e.g.
LDAP) into the app natively, ADAM could be your
answer.
Other
solutions abound - from simple services to security
uses.
Rick
Kingslan MCSE, MCSA, MCT
Microsoft MVP - Active
Directory
Associate Expert
Expert Zone -
www.microsoft.com/windowsxp/expertzone
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Myrick, Todd
(NIH/CIT)
Sent:
Friday, June 27,
2003 7:24
AM
To:
'[EMAIL PROTECTED]';
[EMAIL PROTECTED]
Subject: [ActiveDir] MMS 2003 and
ADAM 2003
I
just got word that MMS 2003 and ADAM 2003 are shipping the week of
July 3rd.
Now
to afford the server requirements to run MMS 2003.
Requirements for MMS
2003
Makes
Simple Sync look very attractive, but the MMS requirements do offer
some tangible benefits.
