This article is part of the Identity and Access Management Security School lesson on authentication. Visit the Authentication lesson page for more learning resources.
When management wants to roll out a strong authentication system across a heterogeneous IT environment, security adminstrators face the challenge of effectively weaving an authentication plan into diverse directories such as LDAP, Microsoft Active Directory and Novell NDS. In this tip, we look at taking a large strategic authentication plan and putting it into tactical implementation, examining issues like the benefits of multiple LDAP corporate directories, using group policies at the directory level, and the use of tiered groups to best control internal and external user access.
LDAP (lightweight directory access protocol) has become nearly ubiquitous in enterprises. The first question the engineering staff usually asks is, "Should we create more than one LDAP directory?" While a single directory responds more quickly to requests, the common practice is to have several directory structures. For example, you would have the "enterprise LDAP directory" and it would work in conjunction with several other sub-directories. The first and most common of these is the border directory, which publishes internal IDs to the outside world or external business partner IDs internally, or both. Next are the application-specific directories, optimized for application-specific uses. Many large enterprises have existing operating system-specific directories, such as Novell and Microsoft, which reside in an "operating system" subdirectory created under the LDAP directory. Lastly, an enterprise may deploy several small organizational unit or departmental directories that serve specific departmental functions.
The LDAP either serves as or under an umbrella or metadirectory structure -- a directory of directories. A metadirectory structure typically uses registries that store and reconcile identifiers (users, groups…). The directories themselves then hold additional information about all of the items stored in the registries. Most metadirectory products today include an end user registration service.
When deploying an LDAP structure, there are several points to consider. First, make the people database space as flat as possible. If complete flatness is not possible, the user ID (UID) should still be unique across the entire structure, so moving UIDs will not pose a threat. However, while flat schemas help with some aspects of directory management, they limit the use of inheritance and group policy objects. Lastly, strongly consider the use of LDAP chaining. This is the ability of a central directory to pass client requests to distributed directories. This also assists LDAPv2 clients in finding distributed information and permits safe access through firewalls.
Storing group information
In general, we view storing group information as to how groups are to be used. Typically this is broken down into two philosophical camps: dynamic and static groups. Dynamic groups include groups as a schema attribute for individuals and are usually created using an LDAP search URL. Static groups are created as a separate entry within the overall directory hierarchy, and store group memberships as attributes. Both approaches provide benefits to varying activities, such as determining membership or group creation. Whichever you choose, keep a close eye on the effects that groups may have on directory performance.
Overall, groups should be stored in the same namespace as the user accounts. But, the drawback to this methodology is the potential depletion of names within the namespace. Therefore, another possibility is to form group names by appending an end user name with a group-specific tag and then creating and managing the more commonly-used groups centrally.
Using tiered groups
Best practices for using tiered groups to control user access normally dictate that you:
- Keep the group structure as simple as possible.
- Do not nest OUs or groups more than a few (typically less than 10) layers deep.
- Keep the number of groups to a minimum.
- Apply policies to groups through "flow down" filtering. Set the policy near the top group and allow it to pass down to the groups below it (versus setting this control at each layer individually).
- Stay away from simply deleting and re-creating groups on the fly, because each group identifier is unique and this will create a synchronization nightmare.
So overall, it is truly possible to take the "big plan" and make it work in your enterprise. Of course it would assist this process greatly if the strategists invite the engineer to the planning table before the plan is decided. Take a good look at using LDAP in your enterprise, and make judicious use of group policies and a tiered group layout to create an effective authentication schema.
About the author
Tom Bowers, CISSP, PMP and a Certified Ethical Hacker, is a well known expert on the topics of ethical hacking, penetration testing and protection of the global enterprise. He is the vice president of the Philadelphia chapter of Infragard, the second largest chapter in the country with more than 600 members. Additionally, he serves as manager of information security operations for a fortune 100 pharmaceutical company, where his areas of expertise include risk assessment and leading information protection teams for 120 offices globally. Bowers is a technical editor of Information Security magazine and a regular speaker at events like Information Security Decisions.
|IAM SCHOOL HOME||AUTHENTICATION LESSON HOME||AUTHENTICATION WEBCAST||AUTHENTICATION PODCAST|