RE: [ActiveDir] Vendor Domain
Ha, that was easy J From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Figueroa, Johnny Sent: Friday, August 04, 2006 1:21 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Vendor Domain 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 shouldnot 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 reallyamazing 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. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm 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 asIThas 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
RE: [ActiveDir] Vendor Domain
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 joeSent: Thursday, July 20, 2006 5:46To: ActiveDir@mail.activedir.orgSubject: 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 shouldnot 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 reallyamazing 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. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Figueroa, JohnnySent: Thursday, July 20, 2006 8:23 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Vendor Domain Joe, I can not comment on the specifics just yet asIThas 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 joeSent: Thursday, July 20, 2006 1:55To: ActiveDir@mail.activedir.orgSubject: 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
RE: [ActiveDir] Vendor Domain
Just a few thoughts to add since so many others already have given you great answers: - Ive 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 its functionality, e.g. putting certain signing or encryption policies in place, but the workstation talks to its hardware via proprietary SMB I just wanted to throw this into discussion if we are talking about such devices/appliances Id 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. Dont put lives at jeopardy b/c of a misconfigured GPO. Gruesse - Sincerely, Ulf B. Simon-Weidner Profile Publications:http://mvp.support.microsoft.com/profile=""> Weblog: http://msmvps.org/UlfBSimonWeidner Website: http://www.windowsserverfaq.org From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Figueroa, Johnny Sent: Thursday, July 20, 2006 9: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 Microsofts best practices. We have implemented our own .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 hospitals Active Directory structure is a dependency that has opened our customers up to liabilities for the integrity of our 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 aXXX 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 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 outto 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 dependson what data isneeded 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 Sent: Thursday, Ju
RE: [ActiveDir] Vendor Domain
Will the application run off of an ADAM instance instead of a full blown forest? That was going through my mind as well - why would the vendor want to use a NOS AD for his application? Again, there must be some reason for this. joe makes great points rgd. the support issues of an application which is fully integrated into the NOS AD, but is managed by a different team - possibly the vendor himself. So knowledge about the planned support model will certainly help to discuss justification of a separate forest. Clearly, that should include management of that extra forest itself (who is responsible for backing up that forest and ensuring operation of the DCs etc.). /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Thursday, July 20, 2006 10:55 PMTo: ActiveDir@mail.activedir.orgSubject: 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 whereyou 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 considerallowing 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 forestand wantthe vendorto forgo their own design, which does happen, they can and usually willrun it from your forest however you havegot 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 vendorto cover a changed support model and cover for the extra design work that they would need to be involved into support your environment.In addition, you would need toaccept 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 beany issues that end up having a root cause back in theAD 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
Re: [ActiveDir] Vendor Domain
Figueroa, Johnny wrote: 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. Hmm, I can't imagine product which requires separated domain to work. If they want to deploy it in this way they should have some serious justification, as additional domain incorporates additional administrative tasks for You, hardware etc. As I assume Your vendor would probably like also to have full domain admin rights there? For me, if it is in this way it should be considered as security threat also. Before going further in discarding this requirement try to talk with them and understand why they want to deploy separated domain - I'm sure that the reason which lies beneath it can be archived in other way by delegation etc. -- Tomasz Onyszko http://www.w2k.pl/blog/ - (PL) http://blogs.dirteam.com/blogs/tomek/ - (EN) List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
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, JohnnySent: Wednesday, July 19, 2006 8:09 PMTo: ActiveDir@mail.activedir.orgSubject: [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 FigueroaSupervisor Network Operations SupportNetwork ServicesBanner HealthVoice (602) 747-4195Fax (602) 747-4406WARNING: 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
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 outto 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 dependson what data isneeded 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, GuidoSent: Thursday, July 20, 2006 2:32 PMTo: ActiveDir@mail.activedir.orgSubject: 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, JohnnySent: Wednesday, July 19, 2006 8:09 PMTo: ActiveDir@mail.activedir.orgSubject: [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 FigueroaSupervisor Network Operations SupportNetwork ServicesBanner HealthVoice (602) 747-4195Fax (602) 747-4406WARNING: 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
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 Microsofts best practices. We have implemented our own .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 hospitals Active Directory structure is a dependency that has opened our customers up to liabilities for the integrity of our 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 aXXX regulated medical device and would open you to failing FDA auditing." Thanks From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Thursday, July 20, 2006 12:12To: ActiveDir@mail.activedir.orgSubject: 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 outto 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 dependson what data isneeded 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, GuidoSent: Thursday, July 20, 2006 2:32 PMTo: ActiveDir@mail.activedir.orgSubject: 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, JohnnySent: Wednesday, July 19, 2006 8:09 PMTo: ActiveDir@mail.activedir.orgSubject: [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 FigueroaSupervisor Network Operations SupportNetwork ServicesBanner HealthVoice (602) 747-4195Fax (602) 747-4406WARNING: This message, and any attachments, are intended only for the use of the individual or entity to w
RE: [ActiveDir] Vendor Domain
So theyre blowin a lot of smoke to disguise their actual thought process: You are a liability we do not want to expose our servers to. We do not believe you to be capable of managing an Active Directory environment, and therefore we put in our own stuff without giving you the passwords. That way you cant screw something up. Personally I would be offended. Professionally I would question whether they are any more qualified to manage my AD than I am. Kevin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Figueroa, Johnny Sent: Thursday, July 20, 2006 2: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 Microsofts best practices. We have implemented our own .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 hospitals Active Directory structure is a dependency that has opened our customers up to liabilities for the integrity of our 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 aXXX 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 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 outto 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 dependson what data isneeded 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 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
RE: [ActiveDir] Vendor Domain
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, JohnnySent: Thursday, July 20, 2006 3:46 PMTo: ActiveDir@mail.activedir.orgSubject: 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 Microsofts best practices. We have implemented our own .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 hospitals Active Directory structure is a dependency that has opened our customers up to liabilities for the integrity of our 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 aXXX regulated medical device and would open you to failing FDA auditing." Thanks From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Thursday, July 20, 2006 12:12To: ActiveDir@mail.activedir.orgSubject: 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 outto 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 dependson what data isneeded 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, GuidoSent: Thursday, July 20, 2006 2:32 PMTo: ActiveDir@mail.activedir.orgSubject: 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: [EM
RE: [ActiveDir] Vendor Domain
Joe, I can not comment on the specifics just yet asIThas 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 joeSent: Thursday, July 20, 2006 1:55To: ActiveDir@mail.activedir.orgSubject: 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 whereyou 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 considerallowing 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 forestand wantthe vendorto forgo their own design, which does happen, they can and usually willrun it from your forest however you havegot 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 vendorto cover a changed support model and cover for the extra design work that they would need to be involved into support your environment.In addition, you would need toaccept 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 beany issues that end up having a root
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 shouldnot 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 reallyamazing 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. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Figueroa, JohnnySent: Thursday, July 20, 2006 8:23 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Vendor Domain Joe, I can not comment on the specifics just yet asIThas 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 joeSent: Thursday, July 20, 2006 1:55To: ActiveDir@mail.activedir.orgSubject: 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) t
