Configuring DNS and LDAP Clients
Two other common naming services used in Solaris environments are DNS and LDAP. Both services are industry standards and not specific to Solaris. Even though Solaris can function as DNS and LDAP servers, the Sun Certified System Administrator exams focus on setting up only DNS and LDAP clients. Therefore, an overview of each service will be provided, as well as details on setting up the respective clients.
Understanding DNS
DNS is the name resolution service developed explicitly for the Transmission Control Protocol/ Internet Protocol (TCP/IP) networking protocol suite. Developed in the mid-1980s, DNS was designed to replace the antiquated and cumbersome method of using hosts files to resolve computer names to IP addresses. Whereas other naming services discussed in this chapter, such as NIS, NIS+, and LDAP, can do much more than just resolve names and addresses, that's all DNS does. DNS is the only name resolution method used on the Internet, but it can work in smaller, local area networks as well.
Solaris 9 can function as both a DNS server and a DNS client. DNS is designed in such a way that different software platforms can be clients and servers to each other. For example, a Windows-based client can use a Solaris DNS server and vice versa. There shouldn't be any problems, as long as both computers understand TCP/IP.
DNS zones of authority are logically organized into domains, much like NIS+ domains. Each domain has a hierarchical domain name, such as sun.com or sybex.com, and computers within the domain take their name from their parent, such as docs.sun.com or www.sybex.com. The master server contains a list of computers and their IP addresses within the domain. DNS domains can also have backup servers and caching-only or stub servers. All DNS servers are configured to resolve computer names to IP addresses and can ask each other for information.
To run DNS, a Solaris server uses the in.named daemon. Information about computers in the domain is stored in a series of files on the DNS server. These files are similar to the /etc/ hosts file but contain more information. Most DNS implementations follow the Berkeley Internet Name Domain (BIND) standard. Solaris 9 supports BIND version 8.2.4.
Configuring DNS Clients
Before configuring your DNS clients, make sure that you have access to at least one DNS server. If you are providing Internet-based DNS services, you are required to have at least two DNS servers up and running.
Setting up Solaris to be a DNS client is a relatively simple two-step process. First, you need to have a local /etc/resolv.conf file configured. This file is also called the resolver. Second, you must configure the /etc/nsswitch.conf file to look for a DNS server.
If your computer does not have a resolv.conf file, you can create one. Use touch /etc/ resolv.conf or whatever method of file creation you prefer. The resolv.conf file needs to have two types of information: the domain name and DNS servers to query. The format of the file will be like this:
domain domainname nameserver IP_address
A computer in the pinkeel.com domain might have a resolv.conf file that looks like this:
# /etc/resolv.conf domain pinkeel.com ; local name servers nameserver 10.0.0.34 nameserver 10.0.0.35 ;other name servers nameserver 192.168.32.2 nameserver 192.168.32.3
The computer will try the name servers in the listed order. If the first name server cannot resolve the query, the second one will be tried, and so forth, until one of the name servers returns an IP address to match the requested host name. Lines that begin with a semicolon (;) are comments and are not parsed by the computer.
After your resolv.conf file is configured, you need to edit the nsswitch.conf file to look for the DNS server. Because DNS has a single purpose, to resolve host names to IP addresses, there is only one line in your nsswitch.conf file that you need to configure. It begins with hosts:.
You will want to modify the line to look something like this:
hosts: dns [NOTFOUND=return] files
The computer with this line will ask the DNS server to resolve host names first, and then attempt to use a local hosts file. If your network is using NIS or NIS+, you can also enter those naming services on this line, such as:
hosts: dns [NOTFOUND=return] nis files
In this case, DNS will be queried first, followed by NIS, and then the local hosts file. If none of the sources can resolve the name, the name resolution process will fail. If you're trying to access a website or another local computer, you will not be able to do so by the computer's host name.
Understanding LDAP
The newest naming service to be included with Solaris is the Lightweight Directory Access Protocol (LDAP). LDAP was originally developed as a directory service, meaning that it held objects and attributes. You can think of LDAP as a telephone book, but one that has not only the user's name, address, and phone number, but also that person's birth date, identification number, children's names, and a slew of other information. In this example, the person would be considered an object, and the information bits would be properties of that object.
Since its original development, LDAP has expanded to take on the role of a naming service as well as a simple resource locator. Like DNS and NIS+, LDAP uses a hierarchical naming structure to classify objects within its organization, also called a domain or a namespace. LDAP naming is based on the Internet standard X.500 naming system. The top level of the LDAP organizational tree often represents a country but can also represent a company name. The second layer in the organization can represent states within the country, or divisions within an organization, and so forth. The LDAP tree, known as the Directory Information Tree (DIT), can be adapted to fit any organization.
One of the big advantages of using LDAP is its scope. LDAP gives you the ability to include and classify a large number of objects into one database, reducing the need to manage several databases. Also, LDAP allows for frequent database synchronizations between servers (the term lightweight implies that it doesn't produce a lot of network overhead by itself), and LDAP is supported by a variety of hardware and software platforms and vendors.
On the downside, pre-Solaris 8 clients are not supported by the current version of LDAP. Also, an LDAP server cannot be its own client. Therefore, you need at least two LDAP servers if you want all computers on your network to use LDAP. Finally, setting up LDAP is more complex than setting up NIS, NIS+, or DNS.
| Note | Sun is planning on phasing out NIS+ in favor of LDAP. There are tools available to help in the migration of NIS+ to LDAP in Solaris 9. For more information, see www.sun.com/directory/nisplus/transition.html. |
Solaris 9 can function as an LDAP server through the iPlanet Directory Server software, bundled with Solaris 9.
Configuring LDAP Clients
As is the case with any other client-server service, in order to get your LDAP clients to work properly, you need an LDAP server. Only Solaris 8 and Solaris 9 systems can be LDAP clients. To function as an LDAP client, the following are required:
-
The client's domain must be serviced by an LDAP server, and at least one LDAP server must be up and running.
-
The client's domain name must be set in the local /etc/defaultdomain file.
-
The nsswitch.conf file needs to be configured to point to the LDAP server. (The nsswitch.ldap template is provided for this purpose.)
-
The client needs to be configured with the required parameters (LDAP client profile).
-
The ldap_cachemgr service needs to be running on the client.
Solaris 9 comes with a utility called ldapclient, which sets up all required client parameters, including modifying the nsswitch.conf file. You can run ldapclient in two modes: profile and manual. Either option configures the necessary parameters. It's recommended, though, that you set up a client profile on the LDAP server and then use this profile to configure your clients with ldapclient. This will greatly reduce the amount of time needed to set up LDAP clients on your network.
Another reason to set up clients by using a profile is that if you change profile parameters on the LDAP server, the correct parameters will be pushed to the LDAP clients. If you set up LDAP clients manually, their parameters are stored in local cache files and are not updated by the server.
Table 15.6 lists the profile attributes in a client profile. These attributes can be configured on the LDAP server by using idsconfig.
| Attribute | Description |
|---|---|
| cn | The profile name. You must provide a profile name. |
| preferredServerList | The IP address of one or more preferred servers to connect to. The servers in this list are tried, in order, before those in the defaultServerList. At least one server must be provided in the preferredServerList or the defaultServerList. |
| defaultServerList | The IP address of one or more default LDAP servers to connect to, in order of preference (separate multiple server addresses with spaces). |
| defaultSearchBase | The base object (DN) used to provide a relation from which to locate well-known containers. |
| defaultSearchScope | Defines the scope of a database search by an LDAP client. |
| authenticationMethod | Specifies the authentication method to be used by the client. The default is none. Other options are simple, sasl/digest-MD5, sasl/cram-MD5, tls:simple, tls:sasl/digest-MD5, and tls:sasl/ cram-MD5. |
| credentialLevel | The type of credentials the client should use to authenticate with the LDAP server. The default is anonymous, and the other choice is proxy, if you're using a proxy server. |
| serviceSearchDescriptor | Defines how and where a client should search for a naming database. For example, which point(s) in the DIT the client should search in. |
| serviceAuthenticationMethod | Authentication method used by a client for the specified service. This authentication is service specific, but if no value is present, it will default to the value in authenticationMethod. |
| attributeMap | Attribute mappings used by the client. |
| objectclassMap | Object class mappings used by the client. |
| searchTimeLimit | Maximum number of seconds the client should search for an object before timing out. The default is 30 seconds. |
| bindTimeLimit | Maximum number of seconds a client should try binding with a server before timing out. The default is 30 seconds. |
| followReferrals | Indicates whether a client should follow an LDAP referral. The default is TRUE, and the other option is FALSE. |
| profileTTL | Number of seconds between refreshes of the client profile from the LDAP server. Refreshes are handled by ldap_cachemgr. The default is 43,200 seconds, or 12 hours. If the value is set to 0, the client profile will never be refreshed. |
In addition to the profile attributes listed in Table 15.6, four local client attributes can be set locally through the ldapclient command. They are listed in Table 15.7.
| Attribute | Description |
|---|---|
| domainName | Specifies the client's domain name. You must specify a value for the client's domain name. |
| proxyDN | The distinguished name of the client's proxy server. If the proxy option is specified in credentialLevel, the proxyDN must also be specified. |
| proxyPassword | The password for the proxy server. |
| certificatePath | The directory on the local computer containing the certificate databases. If the client is using Transport Layer Security (TLS) as an authentication method, then this attribute needs to be configured. The default is /var/ldap. |
If you've never worked with LDAP before, the list of attributes, not to mention the LDAP terminology, can be quite confusing. Fortunately, for the test, you're not going to be required to know explicit details about each of these attributes, nor will you be asked how to set up an iPlanet Directory Server.
To set up an LDAP client by using the default profile on the LDAP server (10.0.0.44), you could use the following command:
# ldapclient init 10.0.0.44
That command will work only if either the credential level is set to anonymous or the authentication method is set to none. If your LDAP server has several profiles, or you want to specify other attributes, the -a switch is used. Look at the following example:
# ldapclient init -a profileName=eng -a domainName=sushi.pinkeel.com 10.0.0.44
This command instructs the LDAP client to use the eng profile, set the domain name to sushi.pinkeel.com, and use the 10.0.0.44 LDAP server.
Manually configuring an LDAP client requires a lot of typing because you need to manually enter all attributes that you want to set. For example, assume that you want to set up an LDAP client manually. The credential level is set to proxy, the authentication method is sasl/ digest-MD5, and you do not want the client to follow LDAP referrals. The LDAP server is 10.0.0.44, and LDAP services are running on port 33888. Here is the command you would use (the command is broken across lines for readability):
# ldapclient manual -a credentialLevel=proxy \ -a authenticationMethod=sasl/digest-MD5 \ -a proxyPassword=abracadabra \ -a proxyDN=cn=proxy1,ou=profile,dc=sushi,dc=pinkeel,dc=com \ -a defaultSearchBase=dc=sushi,dc=pinkeel,dc=com \ -a domainName=sushi.pinkeel.com \ -a followReferrals=false \ -a preferredServerList=10.0.0.44:33888
That's one long command to set up an LDAP client.
| Tip | When configuring authentication, know that the TLS methods encrypt both the password and the session, whereas the non-TLS methods might encrypt the password, but not the session. |
After you have configured your LDAP client, you can use the ldapclient list command to display your LDAP parameters. The ldapclient mod command enables you to modify parameters.
If you no longer want your computer to be an LDAP client, use the ldapclient uninit command. This will restore your client's name service to what it was before the LDAP client was initiated.
Using getent
Earlier in this chapter, you learned of a way to look in the NIS maps for a specific piece of information by using the ypcat and ypmatch commands. There is another command you can use, and it works with all of the naming services: getent.
The syntax for getent is simple:
# getent database key
If you wanted to search the passwd database for the user qdocter, you would use the following command:
# getent passwd qdocter qdocter:6uoVIHZIxXiVI:100:10:author:/home/qdocter:/bin/ksh
The getent command can be used to look in local files and LDAP databases as well.
 |
You have been the network administrator at your company for nearly two years. During those two years, you have used local /etc files for name resolution. Several of your users need access to multiple computers, and keeping their configuration properly maintained can be a nightmare. And when you add computers to the network, you must reconfigure the hosts file on each computer to recognize the new additions. You've developed scripts to help automate the process, but it's still not a pleasant experience. Now that your network is growing, you're not sure if you can handle all of the work. Hiring an assistant is not within the budget. Surely there has to be a solution.
Of course, there is. You need to eliminate the need for using local /etc files for your naming service. Using local /etc files is fine on very small networks but is too cumbersome and antiquated for most implementations. You need to choose a naming service. Possibilities are DNS, NIS, NIS+, and LDAP.
If your network is attached to the Internet, then DNS is a solid choice for part of your naming service solution. DNS can handle resolving Internet-based names as well as local computer names. If you're not attached to the Internet, though, then although DNS will work, it would be better to choose a single naming service that can handle all of your networking needs, such as NIS, NIS+, or LDAP.
In terms of ease, NIS is the easiest to set up and maintain. It is, however, the oldest and provides little security. NIS+ is a good choice, as it provides security and isn't much harder to set up than is NIS. The only "problem" with NIS+ is that Sun is phasing it out in favor of LDAP. So, you could choose LDAP. It has the reputation as being the most difficult to properly configure, but with a little time, you're likely to become an LDAP expert (and deserve a significant raise!).
Even if you do implement a solution by using DNS and another naming service, using two services isn't going to be a significant issue, as NIS, NIS+, and LDAP all work well in conjunction with DNS.
Whatever solution you decide to implement, do it fast. It's time to get into the modern era of computing and out of the Stone Age.
|
|
|
EAN: 2147483647
Pages: 194