There was no real reason for a separate domain, other than
it simplified the vendor's support. We ended up creating an OU and delegating
administration to it.
Thanks.... I promised I would get back to you
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Thursday, July 20, 2006 5:46
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Vendor Domain
I completely understand.
If a vendor is actively and completely supporting this
application for you ***as a service*** then patching, etc should be something
that you specify the requirements for in the actual contract with the vendor
with penalties, etc associated with it for non-compliance. You should not
have to touch any of it because you shouldn't even have the ability to touch any
of it - that is what the service model is about.
If this is a vendor telling you to create a new
domain/forest that you in any way shape or form have to support for their app, I
would tell them they better have a really amazing explanation because all
of the tables are already against them and if the extra domain/forest gets
pushed through you immediately tell, not ask, the people requiring the
application what it is going to cost to get the extra resources to support the
extra domain/forest - including all licenses for monitoring and other third
party tools needed to properly support the environment.
Again, if this is just an application and application
support, you tell the vendor where it goes. If this a service, then listen
carefully to the vendor as they may have a good point and if you force them to
deviate there will be a premium at the minimum associated with it. A new
Domain/Forest for a service model should be a black box to you.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Figueroa, Johnny
Sent: Thursday, July 20, 2006 8:23 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Vendor Domain
Joe, I can not comment on the specifics just yet
as IT has not actually met with the vendor yet. We received the
requirements and when I read about the separate domain with a trust to our own,
I started to try and build a case for NOT. As I had mentioned earlier.
I will try to keep an open mind on the whole thing but if
every medical vendor came in and asked for their own domain we would have quite
a mess. You then end up with problems like patch compliance, virus definitions
you can not verify or having to provide for some form of isolation of these
environments while allowing them to be functional. This last part turns into
administration overhead and dollars that we try to push back to the vendor, not
always successfully depending on how much the application is needed.
Vendor supported environments inside your own can be a post
all of its own that goes on forever. How many vendors say they will take care of
their devices and you wake up one day only to find out that you are under attack
from one of those vendor "supported" devices. It could be a virus as we have had
happened to us or a misbehaving AV application on the same devices you don't
have admin access to that renders several DFS servers inaccessible with high CPU
usage.
We will try to get to the bottom of it as usual, the devil
is in the details. I promised to report back since many of you have taken the
time to provide your thoughts on the matter.
Thanks
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Thursday, July 20, 2006 1:55
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Vendor Domain
My first reaction is that that is pretty nebulous and hazy.
I don't think they can compare whatever it is they do to a respirator and have
validity, I think that would be talking apples and olive pits.
Overall it sounds like a move to reduce support and
troubleshooting costs by having a known fixed environment in which their app
will run. It could even mean that they have bad decisions (and coding) in the
software itself that has hard requirements to that specific layout so they don't
have to code for a more generic setup.
Certainly the concern that AD may not be stable is a valid
one from a vendor doing managed service support standpoint as it is something I
have encountered in the field myself. More environments than not that I
have walked into to deploy Exchange the AD folks thought AD was perfectly fine
and were surprised when Exchange dragged their DCs under water and I have to go
through their design and figure out what exactly isn't optimal (hint usually the
disk subsystems - stop using mirrors damnit). But if the
customer is willing to accept that risk as a caveat to the support model then
the vendor should be able to support it. This can and usually should have some
level of impact on costing and possibly support levels and penalties (if they
exist). It is cheaper to run support on a fixed known setup than it is to
support something you didn't design and can't exercise control over. You as a
customer would need to accept that as well. But it really comes back to whether
the product will work in a generic environment at all and if the vendor is
willing to put in the time to figure out their exposure and write the
contract (and bill) to suitably cover for it.
Taking this back to an Exchange example which is more
familiar to many folks. Take the example where you want email and you bring
someone in to create and run an Exchange service for you. You aren't managing or
supporting it, it is all them, you simply give them the requirements. If
they have a cookie cutter separate domain/forest solution it is something they
have worked out and tested and understand and can best support. In general I
think it is better for you and think it is good for you to strongly
consider allowing them to run it that way because of the issues with
Exchange and the resulting administration mess. It is tough to fight it because
there aren't a lot of options outside of Exchange with the features people
want... If you have strong feelings against that separate
forest and want the vendor to forgo their own design, which does
happen, they can and usually will run it from your forest however you
have got to expect cost increases. You are basically telling the
respirator company (to use that bad analogy) that you want the respirator to
work in an entirely different way than the product you picked out of the
catalog.
The prices increases are to cover real costs incurred by
the vendor to cover a changed support model and cover for the extra
design work that they would need to be involved in to support your
environment. In addition, you would need to accept the caveats on
service that they may need to put into place to protect themselves from lawsuits
that are actually the fault of something they don't control. An example would
be any issues that end up having a root cause back in the AD that you
control releases them from SLA penalties and allows them to charge back costs
associated with it. A specific example is say where you have company A running a
mail service for you out of your directory and you allow local site admins to
have extensive control over their users and one of the admins decided to give
himself a 10GB quota and then uses it and kills the free space on the Exchange
server causing the vendor to scramble resources to cover for the resulting
issues. That absolutely needs to be charged back to the company and not the
vendor. Even if you have separate groups in the same company running AD and
Exchange those are things that get fights going over because the Exchange team
is budgeted to cover Exchange issues and the AD team is budgeted to cover AD
issues and some person who wasn't involved with either breaks one.
So those examples are primarily from the standpoint
that the vendor is doing all of that support. If the vendor is just coming
in to build something for you and you will be supporting it, it is all about
what you want which is why you will tend to see a different viewpoint on this
between folks doing managed services and folks just doing consulting and
implementation. There are long term considerations for managed services that
consulting won't be around to worry about.
And to toss in a few random thoughts... On the positive
side if you deside to dump that app later, it is quite easy to snip it off and
not have stuff to cleanup in your "real" forest but on the negative side if the
vendor goes out of business you could be in a bad way and end up trying to find
out how to bust into that forest so you can support it.
So how much do you know about this actual application and
vendor? How many customers have you spoken with that are currently using it and
are they all configured the same way? Is the vendor going to be running that
environment for you and if so how important is it that they do? Do you know
about any schema requirements or anything else that you might be screaming about
later and saying you don't want near your forest? Will the application run off
of an ADAM instance instead of a full blown forest?
joe
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Figueroa, Johnny
Sent: Thursday, July 20, 2006 3:46 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Vendor Domain
Thank you all.
The vendor in question is bringing in a medical solution.
Here is the response from the vendor so far. Mind you that we have lots of
medical device solutions that exist in our domain, the FDA card is played as a
blanket so you stop asking questions... we ran into the same issue with
security patches. "why can't I patch that device?". When we've looked at these
FDA regulations in the past it turned out that there was more liability by not
patching.
From the vendor:
"Let
me start by thanking you for considering our support model and continuing to
pursue supporting it in your organization. Our designers have architected
the system to comply with Microsoft’s best practices. We have implemented our
own XXXX.local domain in an effort to provide solid system integrity founded on
Kerberos authentication and a single sign-on experience for your
clinicians.
Our system relies heavily on the integrity of the Active Directory
structure. We have integrated the launching of services and control of processes
using this Microsoft recommended model.
It has been our experience that relying on a hospital’s Active Directory structure is a dependency that has opened our customer’s up to liabilities for the integrity of our XXXX regulated medical device. I liken the servers to a respirator. Having an outside person, no matter how qualified, work on a respirator would be a concern from a clinical standpoint. We have witnessed Group Policies applied to servers in a more open environment. This is a liability we do not want to expose our business partners to. Any change, no matter how minute to our system, would endanger our validation and designation as a XXX regulated medical device and would open you to failing FDA auditing."
Thanks
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of joe
Sent: Thursday, July 20, 2006 12:12
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Vendor Domain
Sent: Thursday, July 20, 2006 12:12
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Vendor Domain
I would tend to agree except in the case of Exchange, I am
ALL FOR Exchange being run in a separate single domain forest, it solves an
incredible number of problems such as the GC/NSPI problems as well as
administrative isolation, etc. The exception there is if Exchange is deployed in
a decentralized fashion out to all of the sites you already have DCs at, at
that point, you probably want to fight with the issues with it in the main
forest.
The biggest complaint I have seen for running a separate
Single Domain Forest for Exchange is around provisioning and quite frankly, that
really isn't all that involved and doesn't necessarily need a full blown
MIIS/IIFP solution. It depends on what data is needed where. If you
need all of the GAL info in the main NOS forest as well as the Exchange forest
then you looking more into metadat sync tools unless your provisioning is all
being handled through a centralized mechanism and then that can be used to send
the info in both directions and actual tie between the domains for syncing isn't
necessarily required.
But if this isn't Exchange, I would be curious to hear the
details of the app and why they want a separate forest. Most vendors if they
told me they did it in a stupid way that had that requirement I would beat and
tell them to fix it. With MSFT and Exchange, that only works a little bit.
:)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido
Sent: Thursday, July 20, 2006 2:32 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Vendor Domain
I think everyone would be conceptually opposed - would be
good to hear the vendor's reasoning for this.
What does the app do?
What benefit do you have from running their app in a
speparate (single domain) forest?
I can think of many downsides, but if the app is supposed
to protect really sensitive data (isolation scenario), this may potentially be
the reason for them to demand a separate forest. Certainly not, if the same
folks manage both forests though... So pls. aks them for more details -
doesn't hurt to understand their thinking.
/Guido
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Figueroa, Johnny
Sent: Wednesday, July 19, 2006 8:09 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Vendor Domain
We are a 2003 Forest
with an empty root domain and a single child domain. We have a vendor looking to
bring in a product that utilizes its own domain and has a one way trust to our
domain.
I do not know
anything about the product yet but I am almost conceptually opposed to these
vendor domains. I am looking for pros and cons... really ammunition to say
no.
Thanks
Johnny Figueroa
Supervisor Network Operations & Support
Network Services
Banner Health
Voice (602) 747-4195
Fax (602) 747-4406
WARNING: This message, and any attachments, are intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or employee/agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of the communication is strictly prohibited. If you receive this communication in error, please notify us immediately
Supervisor Network Operations & Support
Network Services
Banner Health
Voice (602) 747-4195
Fax (602) 747-4406
WARNING: This message, and any attachments, are intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or employee/agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of the communication is strictly prohibited. If you receive this communication in error, please notify us immediately
