customer user accounts and internal user accounts on same domain

[Stegman, Bill]

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:  [phone]  Ext. 4202
Fax:      [phone]


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.

[suess13]

Most companies do allow vendor accounts,service accounts for remote vendor
support, etc. however Customer accounts are a different story. Look at a
University/College as a model. Students are usually in an isolated domain
with limited access to the employee network.

Who's going to clean up all old customer accounts.

Users will inherit all permissions associated with the domain users group.

Mention to them,the requirement for 42 or 90 ? day password changes a domain
wide setting applied to every user consistently and can not be changed
unless you are on a 2008 DC.

Talk to them about possible hacking attempts from,  privilege escalation,
denial of service accounts, if an external user can perform login attempts
against your internal domain controller, it would be easy to enumerate all
user accounts then systematically lock out or disable all of the user
accounts, in effect causing a denial of service. And I can do this sitting
on my couch from the house.

A DMZ Domain would be a better idea sounds like you already know that ,if
they are concerned with cost, look into virtualizing the domain controllers
with Vmware 3i it's free.

Also mention something about requiring a Microsoft cal license for every ad
user, legal fees etc, if they don't accept your ideas. BS them if you have
to as a fallback. It works in someplace and can be used as a last resort.

Sounds like your boss or upper management there are a bunch of "tools"

Good luck.

Jeff.


----- Original Message -----
From: "Stegman, Bill" <Bill.Stegman@...>
To: <focus-ms@...>
Sent: Monday, January 26, 2009 3:02 PM
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: [phone] Ext. 4202
Fax: [phone]


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.

[Davies, Alan (GE Money)]

Among many other reasons, having them in the same domain context as you
means they are part of your "Domain Users" which gives them full read access
to all of your AD and access to any "public" areas on file servers, etc. you
may have.

It depends how much management care, but I wouldn't want an external company
knowing exactly how our AD was planned out, how our sites were setup, what
our DNS looked like, where our "crown jewels" were, how we assigned security
permissions, etc.  And that's assuming you're actually perfect and don't
make any permissioning mistakes!  In case you're not perfect .. access to
confidential/DPA relevant data, etc. would be a definite issue - especially
outside the USA.  Could well land you with a regulatory fine if you haven't
shown due diligence and allow protected data to leak out of your company.




alan

-----Original Message-----
From: listbounce@... [mailto:listbounce@...] On
Behalf Of Stegman, Bill
Sent: 26 January 2009 20:03
To: focus-ms@...
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:  [phone]  Ext. 4202
Fax:      [phone]


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.

[James D. Stallard]

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: listbounce@... [mailto:listbounce@...] On
Behalf Of Stegman, Bill
Sent: 26 January 2009 20:03
To: focus-ms@...
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:  [phone]  Ext. 4202
Fax:      [phone]


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.

[marc.yaeger]

Assuming you're using an MS AD, I believe there's a configuration option
called Federated Services which is designed for a scenario such as yours
and might solve your problem.  I'm no AD expert, but from a hi level it
allows you to create an extended AD 'island' from which you and your
customers can share resources without granting access to or creating
objects within each other's internal domains.  Of course this assumes
you're both running AD and there's probably some cost involved, but your
management needs to understand that there are many security & privacy
issues associated with granting outside entities access to your internal
directory.



                                                                       
             "Davies, Alan (GE                                        
             Money)"                                                  
             <AlanJ.Davies@ge.                                          To
             com>                      "Stegman, Bill"                
             Sent by:                  <Bill.Stegman@...>,      
             listbounce@securi         <focus-ms@...>    
             tyfocus.com                                                cc
                                                                       
                                                                   Subject
             01/28/2009 01:12          RE: customer user accounts and  
             PM                        internal user accounts on same  
                                       domain                          
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       




Among many other reasons, having them in the same domain context as you
means they are part of your "Domain Users" which gives them full read
access
to all of your AD and access to any "public" areas on file servers, etc.
you
may have.

It depends how much management care, but I wouldn't want an external
company
knowing exactly how our AD was planned out, how our sites were setup, what
our DNS looked like, where our "crown jewels" were, how we assigned
security
permissions, etc.  And that's assuming you're actually perfect and don't
make any permissioning mistakes!  In case you're not perfect .. access to
confidential/DPA relevant data, etc. would be a definite issue - especially
outside the USA.  Could well land you with a regulatory fine if you haven't
shown due diligence and allow protected data to leak out of your company.




alan

-----Original Message-----
From: listbounce@... [mailto:listbounce@...] On
Behalf Of Stegman, Bill
Sent: 26 January 2009 20:03
To: focus-ms@...
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:  [phone]  Ext. 4202
Fax:      [phone]


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.

[Vega - Brunello Ivan]

Assuming you use AD, IMHO you could put internal users in an OU, and customers in another, at the same level whenever possible.
I saw this layout on almost all AD installation in the last few years, since let you segregate all customers accounts, maintain a single tree (or, at least just to branches of same tree) and get rid of inheritance.
Using this design (and a smart use of UPNSuffix LDAP attribute), you could even have your users authenticating as user@... and external authenticating as user@... .

Moving internal OU should not be a big issue, as far as you use standard AD-aware applications (e.g. exchange), but this should be planned carefully.
Beware of custom LDAP accesses (we had a couple of scripts using special LDAP queries).



My two cents

Ivan Brunello
System & Network Management

-----Messaggio originale-----
Da: listbounce@... [mailto:listbounce@...] Per conto di Stegman, Bill
Inviato: lunedì 26 gennaio 2009 21.03
A: focus-ms@...
Oggetto: 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:  [phone]  Ext. 4202
Fax:      [phone]


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.

[Omar Salvador Alcalá Ruiz]

Look at ISO27001 and CISSP certification. Control access will require you to correctly split personnel, and there are some topics for 3rd parties (how to get them in the network, guests management, logs, and so on), not to mention that this will imply an access to the directory.

HTH

OA

-----Original Message-----
From: listbounce@... [mailto:listbounce@...] On Behalf Of Stegman, Bill
Sent: Lunes, 26 de Enero de 2009 02:03 p.m.
To: focus-ms@...
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:  [phone]  Ext. 4202
Fax:      [phone]


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.

[Kevin Tunison]

On Mon, Jan 26, 2009 at 8:02 PM, Stegman, Bill <Bill.Stegman@...> wrote:
> 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.
>

The partner, if on a 2003 domain also, you can both upgrade your DCs
to 2003 R2 and utilize Federated Services.  It exists for this
specific reason (allowing a semi-trusted domain/partner access to
selected resources).  The whitepaper from MS is here:
http://www.microsoft.com/windowsserver2003/r2/identity_management/adfswhitepaper.mspx

Specific reasons?

Amount of time to run and verify a security audit in the event of a data breach.

Amount of time to set up individual VPNs for each of their users
(allowing a partner-connection without knowing who is on the other end
leaves no specific liability, they could easily hire hacker Joe and
not realize until the damage is done) on top of creating specific user
accounts.  I often hear the argument, we'll just give them their own
logins.. which quickly becomes shared login details in reality because
it's remembering more than one login.

Once ADFS is setup, it's no longer taking the time to create a new
domain account (which potentially costs CALs btw), but to grant
access.

Warm Regards,

Kevin Tunison MCSA, MCTS:SQL 2005
http://www.getbusinessconfident.com

[pryorda pryor]

This is what I would do personally... I would create a guest domain
thats like guest.yourdomain.com.... Then I would alias
'username@...' to username@...... This is
if I am understanding your correctly


On Thu, Jan 29, 2009 at 5:31 AM, Kevin Tunison <ktunison@...> wrote:

> On Mon, Jan 26, 2009 at 8:02 PM, Stegman, Bill <Bill.Stegman@...> wrote:
>> 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.
>>
>
> The partner, if on a 2003 domain also, you can both upgrade your DCs
> to 2003 R2 and utilize Federated Services.  It exists for this
> specific reason (allowing a semi-trusted domain/partner access to
> selected resources).  The whitepaper from MS is here:
> http://www.microsoft.com/windowsserver2003/r2/identity_management/adfswhitepaper.mspx
>
> Specific reasons?
>
> Amount of time to run and verify a security audit in the event of a data breach.
>
> Amount of time to set up individual VPNs for each of their users
> (allowing a partner-connection without knowing who is on the other end
> leaves no specific liability, they could easily hire hacker Joe and
> not realize until the damage is done) on top of creating specific user
> accounts.  I often hear the argument, we'll just give them their own
> logins.. which quickly becomes shared login details in reality because
> it's remembering more than one login.
>
> Once ADFS is setup, it's no longer taking the time to create a new
> domain account (which potentially costs CALs btw), but to grant
> access.
>
> Warm Regards,
>
> Kevin Tunison MCSA, MCTS:SQL 2005
> http://www.getbusinessconfident.com
>