What is a Federated Name Service? In a nutshell, it is a service that is organized by types of reference information such as in a library. There are books in the library of all different types. You select the book off the shelf that best suits your needs. As well, the information is different that data that would be stored in a database, though the data in a Federated Name Service is stored in a database on the back end. This data is generally written once and read many times. There are many guides over what and how to implement LDAP directory services. This article talks mainly about how to leverage LDAP in access control in a network of open system hosts with multiple user and admin groups in the enterprise.
Federated name services have evolved through the years. Currently LDAP is the current protocol driven service that has replaced legacy services such as NIS and NIS+. Though the subject at hand is relative to open systems, I will write another article over managing LDAP services on Microsoft's Active Directory that can also services open systems.
Areas for design beyond account and user groups, are for common maps such as host registration supporting Kerberos or for registering MAC addresses that can be used as a reference point for imaging a host and setting the hostname. Another common use is for central definition of automount maps. Depending on how one prefers to manage the directory tree, organizing separate trees that support administration centers that house shared data made the most sense to me with all accounts and groups stored in a separate, non-location based tree.
A challenge with open systems and LDAP is how to manage who can log in where. For instance, you don't want end users to log into a server when they only need to consume a port based service delivered externally to that host. Possibly on a server, you may need to see all the users of that community but not allow them to login. This form of "security" can be managed simply by configuring both the LDAP client and the LDAP directory to match on a defined object's value.
To provide an example, let's suppose our community of users comprised of Joe, Bob, Mary, and Ellen. Joe is the site administrator and should have universal access to all hosts. Bob is member of the marketing team where Mary is an application administrator for the marketing team and Ellen is a member of the accounting team.
On the LDAP directory, you'll need to use an existing object class/attribute or define a new one that will be used to give identity to the "access and identity rights". If you are leveraging off of an existing defined attribute, that attribute has to be defined as a multi-value attribute since one person may need to be given multiple access identities. For the sake of this discussion, let's say we add a custom class and the attribute "teamIdentity" to handle access and identity matching that is also added to the user objects (user objects can be configured to include multiple object classes as long as they have a common attribute such as cn).
On the client side, you will be creating a configuration to bind and determine which name service maps will be used out of the directory service. As a part of the client configuration, you can create an LDAP filter that is used when client queries the directory service to only return information that passes the filter criteria. So included in mapping what directory server and what the basedn and leaf for making a concise query into the directory should be, you append a filter that designates further filters a single or multiple matches on an attribute/value pair. For user configuration, there are two configuration types to define: user and shadow databases. The "user" is used to configure for "who should be visible as a user" on the host. The "shadow" is used to configure for who can actually login directly to the host. When the NSS service operates locally on the host, its local database cache will contain the match of users according to the common data values matched between the directory server and the client configuration and filter object/attribute/values. The challenge here is more on functional design around what values are created and for what purpose do they serve. Another custom class may be wise to put definition and ultimately control around what attribute values can be added to the user object. Unless you create definition and rules in your provisioning process, any value (intended, typo, etc.) can be entered.
To bring together this example, let's suppose that this is the directory definition and content around our user community:
Let's say we have these servers configured as such:
|Server (LDAP Client)||Purpose||Client Filter - Passwd||Client Filter - Shadow|
Here is how each user defined in the directory server will be handled on the client host:
|Server (LDAP Client)||Identifiable as a User||Able to Login|
|host02||Joe, Bob, Mary||Joe, Mary|
Notice that for host03, there was a "teamIdentity=accounting-sme" defined as part of the filter. Since Ellen exists in the directory service with the attribute "accounting-user" assigned, she will be visible as a user, but not able to login. Conversely, if there was a user in the directory service configured for the "teamIdentity=accounting-sme", they would not be able to log in since you have to be identifiable as a user before you can authenticate. One last observation, John is configured for "teamIdentity=marketing". Since that value is not configured in the client filter, John will not be identifiable or able to login to host02.
For more information over the LDIF syntax see https://docs.oracle.com/cd/E19424-01/820-4811/fnyth/index.html. For more information over client configuration, you'll have to dig that out of the administration documentation for your particular platform/distro.