"Security Chain"

I've been using a term called "Security Chain" to help customers, who have new or no IT folks, understand how Windows, Active Directory, and intra-combination thereof relate.

I.E. A local security group exists on the server as an abstraction point and an Active Directory group is a member of this local security group.  This membership establishes the security chain that allows security checks to walk up the chain.  First the local group, then the AD member group(s), then the members of the AD group(s), etc.

This seems to help them understand how security flows from the resource requested up the chain but I wonder if there is a better way to help them understand that membership is NOT bi-directional.  Meaning adding a local group as a member of the AD group is not the same as adding the AD group as a member of the local group.

How could "security chain" be improved?

I don't remember much about AD, but, if I recall correctly. It simply has Group Hierarchy and Custom Group. Group Hierarchy is strict, thus, needs to be enforced and structured religiously. Custom Group can contains multiple members and groups, thus, needs to be careful any security loophole it opens. Let me know if I missed anything. I don't remember local groups.

The only way I've ever found is to try an explain it in terms of the boundries of authority, especially when you start getting into complex multi-forest, multi-domain setups when the type of security groups in AD matter.

Usually though it's just better to explain in terms of 'If you want to do X, do the following ...' and manage all local security groups through 'Restricted Groups' in Group Policy. Most people only really have one or two basic scenarios that they're concerned about and trying to teach the intracacies of ever aspect of Windows security is just going to end up confusing them.

@AndyC: Amazingly most of our customers are multi-forest multi-domain setups yet their IT folks have trouble understanding security.  Sad.

Why not illustrate the concept with the venn diagram?

@JoshRoss: Like this crude thing.  The first venn diagram still suffers from the same problem as the links of a chain.  It appears bi-directional.  The second just doesn't convey very well.

2 hours ago, davewill wrote

@JoshRoss: Like this crude thing.  The first venn diagram still suffers from the same problem as the links of a chain.  It appears bi-directional.  The second just doesn't convey very well.

That's not a venn diagram. You're not portraying/modelling security as a series of set operations.

@W3bbo: I'm not convinced you could meaningfully explain the properties of security groups using a venn diagram anyway, it'd just get too complex. And trying to do it hierarchically is pointless, because security groups don't follow a strict hierarchy in their behaviours.

15 minutes ago, AndyC wrote

@W3bbo: I'm not convinced you could meaningfully explain the properties of security groups using a venn diagram anyway, it'd just get too complex. And trying to do it hierarchically is pointless, because security groups don't follow a strict hierarchy in their behaviours.

I still don't understand what the OP is trying to accomplish. If someone asked me to describe Windows security in an AD environment I'd just use simple bullet-points:

• A "User" is an identity that exists within the system that provides a context for doing something. You run Winword under the "Chris" User account so it has access to Chris' files. Windows services run under the "SYSTEM" identity and has root access.
• Actions happen under a User's credentials after it has been authenticated - which happens either locally on your machine, or against a central server, which is why you can log-on to any computer in the office (because they share the the same central authentication server) but you can't use your home computer's login details on our computers.
• "Objects" - such as your files and folders in the filesystem, or protected company services (CertSrv?) have an "Access Control List" which simply say "this user A can do x, and this user B can do y, but not z" and so on. If an object exists in a hierarchy (folders, registry keys, OUs, etc) then often that object's ACL is inherited by its children, unless a child explicitly defines a new ACL.
• Users themselves can be organised into Groups, which are collections of users and groups (it's type-recursive) - this simplifies Access Control Lists, so rather than adding every 'Employee' User to a shared folder's ACL, instead there would be a group called "Employees" and that entire group is added to the ACL.
• Trust relationships are for when different organisations want to allow other users access to their systems (and vice-versa).

That's pretty much it - I don't understand how this could be modelled as a "chain" or how security "flows" at all.

16 minutes ago, W3bbo wrote

*snip*

• Users themselves can be organised into Groups, which are collections of users and groups (it's type-recursive) - this simplifies Access Control Lists, so rather than adding every 'Employee' User to a shared folder's ACL, instead there would be a group called "Employees" and that entire group is added to the ACL.

The devil, as always, is in the details. Groups can be Server Local, Domain Local, Global or Universal. They can exist in different domains and the rules on membership and performance impact differ wildly depending on which type they are.

@AndyC:And, there are some funky rules about which groups can be members of which other groups.  It's super fun when you want employess (with AD accounts) and customers (without AD accounts) to use the same systems.

I'm seriously hoping that once single sign-on becomes more ubiquitous, we can get away from all of that funkiness. 

4 hours ago, W3bbo wrote

*snip*

I still don't understand what the OP is trying to accomplish.

*snip*

I'm trying to make the customer successful.

"Security Chain" is SOOOOO close.  I've tried the concept for a couple of years now and it brings them from zero to almost up to speed very quick.  There is just that last 5% of understanding that I want to conquer.

4 hours ago, AndyC wrote

The devil, as always, is in the details. Groups can be Server Local, Domain Local, Global or Universal. They can exist in different domains and the rules on membership and performance impact differ wildly depending on which type they are.

Exactly.  The complexity can run the gamut.

The "security chain" concept needs something more to help convey that it isn't equally bi-directional like the physical loops of a chain are.

Perhaps instead of a security chain, we need a security turnstile?

@kettch: Turnstile might turn off about 50% of the customers as memories of uncomfortable blows to the nether region come flooding back. 

Turnstile is one way but loses the linking between security objects.

10 minutes ago, davewill wrote

@kettch: Turnstile might turn off about 50% of the customers as memories of uncomfortable blows to the nether region come flooding back. 

Turnstile is one way but loses the linking between security objects.

A series of turnstiles then, with padded bars.

This is tricky. It seems like the best way is just to tell them that "this is the way it is" and try to explain the relationships without any metaphors. Otherwise you could be stuck trying to work your way through the tangled web of holes in whatever example you use.

@kettch: Tis tricky.  Going the extra bit is always tough.  No doubt.