, 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.