Bill Lots of issues here, the ones I have used in the past include:
. By giving out a logon, you are allowing them to authenticate on your domain and thus access all resources open to "Domain Users". You are therefore relying on the security of your public-facing service (probably a webserver) to protect you from rogues. . How will you manage identity, to ensure that the person logging on is actually the person issued with the account? . How will you segregate and secure data accessible by internal users only? . How are you going to manage password changes? If you can't, you are taking a big risk with your corporate Domain. . If you are publishing an un-tunnelled authentication endpoint on the internet, then you are exposing yourself to a brute force attack, do you have policies/procedures in place to adequately combat this? . By handing out user accounts to non-employees, you are effectively excusing them from the IT Acceptable Use Policy as you can't enforce it on suppliers where you have no disciplinary sanctions to impose. . What is the business' appetite for risk? . If your business is processing personal data, you are obliged by law to adequately secure such data. It would be trivial to argue in court that giving out user accounts to non-staff contravenes this basic tenet. Why risk it? . If it became known that non-staff had access to internal systems in an insecure fashion, then the business' reputation could suffer. Users are far more privacy aware than they used to be. . If you are unable to demonstrate that data is secure and access auditable, then you are potentially contravening SarBox legislation and liable to who-knows what federal nastiness! It's probable that the amount of effort/expense required to adequately secure (and prove secure) your external users from your internal data exceeds the amount of effort/expense required to create a second domain - and the latter option involves significantly reduced risk to the infrastructure and corporate data. Of course, if this is likely to develop into a large solution, you might like to consider full federation, which is likely to cost more to set up, but less to manage in the longer term. HTH Cheers James James D. Stallard Enterprise Architect Leafgrove Limited -----Original Message----- From: listbou...@securityfocus.com [mailto:listbou...@securityfocus.com] On Behalf Of Stegman, Bill Sent: 26 January 2009 20:03 To: focus-ms@securityfocus.com Subject: customer user accounts and internal user accounts on same domain Hi, I'm trying to dissuade management from allowing user accounts to be created on the same domain as our company users for what I feel are obvious reasons, but when pressed for specific issues I'm at a bit of a loss. I cited reasons such as; A clear demarc between customer accounts and our own accounts Not giving any unnecessary rights due to inheritance, but rather having to apply the appropriate permissions rather than remove permissions to attain the desired result They want to extend a service we offer to our internal employees to a partner. I suggested creating an extranet and using accounts from a separate domain rather than our own, but there is additional overhead imposed by such as design.duh.but I'm hoping to throw out an established standard or something to help my argument. Thank you, Bill Stegman MCSE 2003, CCNP, CCSP, CCIP, INFOSEC, MCTS:Vista Network Engineer Crump Life Insurance Services 4250 Crums Mill Rd Harrisburg, PA 17112 Phone: 717.657.0789 Ext. 4202 Fax: 717.703.4947 CONFIDENTIALITY NOTICE: This message is intended to be viewed only by the listed recipient(s). It may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. Any dissemination, distribution or copying of this message is strictly prohibited without our prior written permission. If you are not an intended recipient, or if you have received this communication in error, please notify us immediately by return e-mail and permanently remove the original message and any copies from your computer and all back-up systems.
