|
Just a few thoughts to
add since so many others already have given you great answers: -
I’ve heard that any
changes to an network which has production status in a clinic, pharma-manufacturer
or supplier will endanger FDA-approval -
I know that many clinical “devices”
are specialized workstations which are controlling a devices, such as modern
x-rays. They do have network access and may be member of a domain to provide doctors
with x-rays a.s.o. Sounds like your manufacturer is talking about such devices and is
concerned that a change in a GPO which is affecting his “appliance”
might break it’s functionality, e.g. putting certain signing or
encryption policies in place, but the workstation talks to it’s hardware
via proprietary SMB … I just wanted to throw this into discussion – if we are
talking about such devices/appliances I’d also prefer a different domain
or even forest to manage them, or want to know very closely what the
requirements are and keep an extra eye on those machines. Don’t put lives
at jeopardy b/c of a misconfigured GPO. Gruesse - Sincerely, Ulf B. Simon-Weidner Profile &
Publications: http://mvp.support.microsoft.com/profile=""> From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Figueroa, Johnny 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 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. :) -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Grillenmeier, Guido 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 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 |
- RE: [ActiveDir] Vendor Domain Ulf B. Simon-Weidner
- RE: [ActiveDir] Vendor Domain Figueroa, Johnny
- RE: [ActiveDir] Vendor Domain Grillenmeier, Guido
