Rights are granted within a tree via an ACL. An ACL can be applied to any object. ACLs applied to leaf objects affect that leaf object only. ACLs applied to a container type object can optionally be allowed to flow down ("inherit") to subordinate objects. In general, we only apply ACLs to container objects, and they generally are also marked for inheritance. As an example, for the local administrator of a department to manage their objects, we set up the UaMgr OrgRole, make them an occupant of the OrgRole, and assign an ACL giving the UaMgr object rights to the OU (container) object representing their department. For a local admin that manages more than one department, a single ACL at a parent OU may be established, or the ACLs on multiple OUs, depending on what is necessary.
Some part of a directory entity. Some attributes are exposed and useful to the user themselves. Other attributes may be internal housekeeping information that the user may not need to know about, and may or may not even be able to see. Your password, for example, is not readable by anybody, though it is an attribute. The date your password expires is something you can read, but can't change. Somebody with more access than what you have can both read and change the date your password expires
This is the name of the object. Locally, this is referred to as a "login ID". It can also be called an "account".
These are branching objects in the tree and can contain other types of objects. Tree can contain Organization. Organization can contain Organizational Unit. Organizational Unit can contain other Organizational Unit and leaf objects.
The "current working container", in a similar sense to the "current working directory" of DOS or UNIX. If your current context is ou=InfoSvc,ou=GenAdmin,ou=DK,o=NIU, then you can refer to the CN of an object in the current context and get what you wanted.
This is similar to the file system current working directory where you can refer to only the file name within the current directory. Relative paths (..\..\dir\file.ext) are possible, but confusing, as are absolute (\dir\dir\file.ext) paths.
You primarily see "context" in reference to logging in. If the client has a current context set, then the user only needs to provide the object name (cn=a02dag1) to log in.
"Contextless", then, refers to things that reduce the need to understand context. To log in, the client requires the fully qualified name of the User object that is logging in. Since the average user does not want to type "cn=a02dag1.cn=InfoSvc.cn=InfoTech.ou=GenAdmin,ou=DK.ou=NIU" to log in every morning, providing a service that resolves a (unique) cn=a02dag1 for them in the background makes this easier for them and us.
This is the fully qualified name of the object, including all parent container objects above it.
So, you may have something like CN:a02dag1, and DN:cn=a02dag1,ou=InfoSvc,ou=InfoTech,ou=GenAdmin,ou=DK,ou=NIU
An object type that represents a collection of people. Users can be members of Groups. Group memberships are not hierarchical, so that Users from various containers can all be members of the same Group.
(User, Group, Printer, etc.) These are non-branching objects in the tree. They represent an entity, generally something you can touch or kick, or a collection of somethings you can touch or kick. A leaf object exists inside one and only one Container object.
A directory entity. Objects represent things. Think of your "account" as the object. The individual bits of data stuck on your account (first name, last name, full name, date of birth, current password, passwords you've used, when your password will expire, etc.) are attributes of the object.
An object intended to indicate an organization within a Tree. In our case, O=NIU. We have only one.
An object similar to a Group in that it represents a collection of one or more people. Generally, we use OrgRole objects to delegate responsibility and access control within the Tree. For historical purposes, the User Account Manager (UaMgr) OrgRole is the one that we delegate access control to, at the highest level container object that is appropriate. The other canonical OrgRole here is Workstation Manager (WsMgr), which delegates control for the ZENWorks workstation management functions. One person could be occupants of both UaMgr and WsMgr OrgRoles, or the person that is doing overall management (UaMgr) may wish to delegate management of workstations to a subordinate (WsMgr).
An object intended to represent some subset of an Organization. We have OU objects representing our campus locations (DK = DeKalb, RF = Rockford, HE = Hoffman Estates, OB = Oakbrook, LT = Lorado Taft) as well as divisions (GenAdmin) and departments (InfoSvc). Other OU objects may indicate delegation of responsibility or collections of certain types of objects (ZENWorks workstation objects).
We are using Profile objects to hold user login scripts. The object name User$Log_Dat is historically the one that we are using for all users in a container for their login script. It could be named something else, but all of the code written to create users assumes that it will find a Profile named User$Log_Dat to use as the login script.
The highest level grouping. All objects in the system are subordinate to and contained by, the Tree (NIU).
An object type that represents a person.