Re: [ActiveDir] MMS 2003 and ADAM 2003

[Glenn Corbett]

Title: Message

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 ----- From: Joe To: [EMAIL PROTECTED] 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     -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Corbett Sent: Saturday, June 28, 2003 4:34 AM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] MMS 2003 and ADAM 2003 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 ----- From: Myrick, Todd (NIH/CIT) To: '[EMAIL PROTECTED]' 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 :)   Glenn   ----- Original Message ----- From: Rick Kingslan To: [EMAIL PROTECTED] 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   Windows 2003 EE SQL 2000 EE Visual Studio .NET 2003 Hardware   Makes Simple Sync look very attractive, but the MMS requirements do offer some tangible benefits.   Todd