solaris 9 student guide part 2 sa299 phần 7 ppsx

Performing Smartcard Administration To set a new PIN: a Select the PIN Configuration tab b Enter the new PIN, and click Change The Change PIN: Enter PIN window appears, as shown in Figure 12-23 Figure 12-23 Change PIN: Enter PIN c d Enter the current PIN The default (current) PIN is set to $$$$java Click OK To modify the user profiles: a Click the User Profiles tab Currently the dtlogin application is the only available and supported application Therefore, the profile name must be dtlogin b Type dtlogin in the User Profile Name field c Add a valid user name and password for this card d Click Set to update the user profile Performing Smartcard Authentication Copyright 2002 Sun Microsystems, Inc All Rights Reserved Enterprise Services, Revision A 12-23 Performing Smartcard Administration Note – Users can change their own PIN using the SmartCard Console The Set User Profile: Enter PIN window appears, as shown in Figure 12-24 Figure 12-24 Set User Profile: Enter PIN Window e Enter a PIN for the user profile Caution – Do not forget the new PIN You cannot modify the current information on the card without the PIN f 12-24 Click OK in the Set User Profile: Enter PIN window Click OK Advanced System Administration for the Solaris™ Operating Environment Copyright 2002 Sun Microsystems, Inc All Rights Reserved Enterprise Services, Revision A Performing Smartcard Administration Activating Smartcard Operations The Smartcard is now configured and ready to use Next, you must activate the application configured for that Smartcard on the client When you activate a Smartcard, you use The Desktop Configuration Dialog window and its four tabs: q Cards/Authentications – Displays the current cards and the authentication scheme used by the desktop q Defaults – Lets you set defaults from a list of available resources for the desktop These resources include the Smartcards, Card Reader, and type of Authentication q Timeouts – Modify functionality q Options – Modify functionality To activate Smartcard operations: In the SmartCard Console window, click the OCF Clients icon The available clients appear, as shown in Figure 12-25 Figure 12-25 SmartCard Console Window Double-click the Desktop icon Performing Smartcard Authentication Copyright 2002 Sun Microsystems, Inc All Rights Reserved Enterprise Services, Revision A 12-25 Performing Smartcard Administration The Cards/Authentications Used by Desktop window appears, as shown in Figure 12-26 Figure 12-26 Cards/Authentications Used by Desktop Window Select PayFlex in the Smart Cards Used field Note – When you click PayFlex, two fields, Pin and User Pin, appear in the right pane Do not modify these fields 12-26 Click Add Because the current status of the Desktop’s Smartcard capabilities is shown as Inactive, select Activate Desktop’s SmartCard capabilities Advanced System Administration for the Solaris™ Operating Environment Copyright 2002 Sun Microsystems, Inc All Rights Reserved Enterprise Services, Revision A Performing Smartcard Administration Select the Defaults tab The Default Resources for Desktop window appears, as shown in Figure 12-27 In this window, you can specify a specific card and reader or select the default that is set for the OCF Server Figure 12-27 Default Resources for Desktop Window Click OK to continue Performing Smartcard Authentication Copyright 2002 Sun Microsystems, Inc All Rights Reserved Enterprise Services, Revision A 12-27 Performing Smartcard Administration Configuring Smartcard Removal Options You use the Timeouts and Options tabs of the Desktop Configuration window to modify the desktop Smartcard functionality In other words, you are configuring the behavior of the desktop when the card is removed from the reader In the Timeouts tab, as shown in Figure 12-28, there are three sliders: q Card Removal Timeout – The number of seconds that the desktop waits after a Smartcard is removed before locking the screen q Reauthentication Timeout – The number of seconds that the Reauthentication Screen is displayed q Card Removal Logout Wait Timeout – The number of seconds that the desktop waits for a Smartcard to be reinserted before the desktop displays the Reauthentication screen If the card is not reinserted in that amount of time, the user is logged out Figure 12-28 Desktop Timeouts Configuration Tab 12-28 Advanced System Administration for the Solaris™ Operating Environment Copyright 2002 Sun Microsystems, Inc All Rights Reserved Enterprise Services, Revision A Performing Smartcard Administration The Options tab, as shown in Figure 12-29, has two options: q Ignore Card Removal – When selected, removing the Smartcard does not invoke a lock screen or logout q Reauthenticate After Card Removal – When selected, the Reauthentication Screen is immediately launched when the Smartcard is removed When not selected, the Reauthentication Screen is controlled by the Card Removal Logout Wait parameter set in the Timeouts tab Figure 12-29 Options Tab Performing Smartcard Authentication Copyright 2002 Sun Microsystems, Inc All Rights Reserved Enterprise Services, Revision A 12-29 Performing Smartcard Administration To test whether you have successfully configured and activated the Smartcard, complete the following steps: Remove the card from the card reader Exit your current login session The Display Locked Screen window, as shown in Figure 12-30, appears Figure 12-30 Display Locked Screen Insert the card into the card reader Enter your login PIN Your new session starts 12-30 Advanced System Administration for the Solaris™ Operating Environment Copyright 2002 Sun Microsystems, Inc All Rights Reserved Enterprise Services, Revision A Troubleshooting Smartcard Operations Troubleshooting Smartcard Operations The following sections provide some procedures for troubleshooting Smartcard operations Enabling Debugging The OCF Server in the SmartCard Console, shown in Figure 12-31, generates a text-formatted log file You set server debug levels and the OpenCard tracing level to record the necessary information for debugging and reporting problems to technical support Figure 12-31 Smartcard Console To enable optional debugging using the SmartCard Console: Select the OCF Server from the Navigation pane Double-click the icon representing the local system Performing Smartcard Authentication Copyright 2002 Sun Microsystems, Inc All Rights Reserved Enterprise Services, Revision A 12-31 Troubleshooting Smartcard Operations The OCF Server Administration window appears, as shown in Figure 12-32 Figure 12-32 OCF Server Administration Window To indicate the level of debugging you want, use the OCF Debug Level slider To indicate the trace level you want, use the OpenCard Trace Level slider If necessary, change the default debug file /var/run/ocf.log in the OCF Debug File Location field 12-32 Select the Debug tab Click OK to make the changes Advanced System Administration for the Solaris™ Operating Environment Copyright 2002 Sun Microsystems, Inc All Rights Reserved Enterprise Services, Revision A Exercise Summary Exercise Summary ! ? Discussion – Take a few minutes to discuss the experiences, issues, or discoveries that you had during the lab exercises Experiences q Interpretations q Conclusions q 13-52 q Applications Advanced System Administration for the Solaris™ Operating Environment Copyright 2002 Sun Microsystems, Inc All Rights Reserved Enterprise Services, Revision A Module 14 Using Name Services Objectives Name services centralize shared information on a network There are several services that store and provide access to this information Upon completion of this module, you should be able to: q Describe the name service concept q Describe the name service switch file q Configure the name service cache daemon (nscd) q Get name service information The following course map shows how this module fits into the current instructional goal Setting Up Name Services Using Configuring Name Name Services Service Clients Configuring the Network Information Service (NIS) Figure 14-1 Course Map 14-1 Copyright 2002 Sun Microsystems, Inc All Rights Reserved Enterprise Services, Revision A Introducing the Name Service Concept Introducing the Name Service Concept The original text-based UNIX® name service was developed for standalone UNIX systems and was then adapted for network use While UNIX operating systems still support and use this text-based name service, it is not appropriate for large, complex networks The name service concept uses domains, which are defined as a collection of network points or addresses The concept of a name service centralizes the shared information in a network A single system, the name server, maintains the information previously maintained on each individual host The name servers provide information such as host names, Internet Protocol (IP) addresses, user names, passwords, and automount maps Note – Local text files are never completely replaced by name services, for example, the /etc/hosts file Other hosts in the name service domain (called clients), request the information from the name server This name server system responds to clients, and translates, or resolves their requests from its memory-based (cached) or disk-based databases Figure 14-2 shows one possible name service scenario Later, this module describes alternatives to this scenario Name Server Client # ! Database "  /etc/nsswitch.conf Local File /etc/hosts Figure 14-2 Name Service Scenario 14-2 Advanced System Administration for the Solaris™ Operating Environment Copyright 2002 Sun Microsystems, Inc All Rights Reserved Enterprise Services, Revision A Introducing the Name Service Concept The basic process is as follows: The client requires administrative data to be accessed due to some process request The client references its local name service switch file to determine the possible name service sources to search The name service switch file instructs the client to first search the local file for the information When the information is not located in the local files, the client’s name service switch file redirects the search to a network name server The name server searches its database and locates the information The name server returns the information to its requesting client The name service concept provides the following benefits: q A single point of administration for name service data q Consistent name service information for systems within the domain q All clients have access to changed data q Assurance that clients not miss updates In a file-based scheme, updates distributed by using File Transfer Protocol (FTP) could be missed if a host was down or off the network when the changes were propagated q Secondary servers prevent a single-point-of-failure While a single master server is all that is required, the name service scheme allows for the creation of secondary servers (sometimes referred to as slaves or replicas) These secondary servers maintain a copy of the master server’s database, receive changes and updates to the database from the master, and participate in client query resolution Therefore, they not only overcome a single point-of-failure, but they also play a role in improved name service performance by balancing the workload of answering client requests among multiple systems Using Name Services Copyright 2002 Sun Microsystems, Inc All Rights Reserved Enterprise Services, Revision A 14-3 Introducing the Name Service Concept Domain Name System (DNS) Domain Name System (DNS) is an Internet-wide naming system for resolving host names to IP addresses and IP addresses to host names DNS supports name resolution for both local and remote hosts, and uses the concept of domains to allow hosts with the same name to coexist on the Internet The collection of networked systems that use DNS is referred to as the DNS namespace The DNS namespace is divided into a hierarchy of domains A DNS domain is a group of systems Each domain is usually supported by two or more name servers, a master name server, and one or more slave name servers Each server implements DNS by running the in.named daemon On the client’s side, DNS is implemented through the kernel’s resolver The resolver library resolves users’ queries The resolver queries a name server, which then returns either the requested information or a referral to another DNS server Figure 14-3 shows that the DNS namespace for the Internet begins with the root (.) domain and includes all subdomains, each of which is headed by a top-level domain Nameless root edu com acme aus mil sun eng uk corp solaris solaris.corp.sun.com Figure 14-3 DNS Domain Structure 14-4 Advanced System Administration for the Solaris™ Operating Environment Copyright 2002 Sun Microsystems, Inc All Rights Reserved Enterprise Services, Revision A Introducing the Name Service Concept The top-level domains are administered by various organizations, all of which report to the governing authority called the Internet Corporation for Assigned Names and Numbers (ICANN) Administration of the lower-level domains is delegated to the various organizations that are registered domain name members within the top-level domain The top-level domain that you choose can depend on which one best suits the needs of your organization Large organizations tend to use the organizational domains, while small organizations or individuals often choose to use a country code Everything below the connection to the domain falls into a zone of authority maintained by the connection to the domain For example, everything below sun.com resides within the zone of authority for Sun Microsystems, Inc and is, therefore, maintained by Sun Microsystems, Inc The DNS name servers store the host and IP address information in files called zone files The /etc/rc2.d/S72inetsvc script starts the DNS process during the boot process if the configuration files are available Network Information Service (NIS) Network Information Service (NIS) was developed independently of DNS and has a slightly different focus DNS focuses on making communication easier by using host names instead of numerical IP addresses NIS focuses on making network administration more manageable by providing centralized control over a variety of network information NIS stores information about host names, addresses, users, groups, and network services This collection of network information is referred to as the NIS namespace NIS namespace information is stored in files called NIS maps NIS maps were designed to supplement many of the UNIX /etc files These maps store much more than names and addresses As a result, the NIS namespace has a large set of maps NIS maps are database files created from source files in the /etc directory (or in a directory that you specify) By default, these maps are stored in the /var/yp/domainname directory on NIS servers For example, the set of maps that contain hosts information include: q hosts.byaddr q hosts.byname Using Name Services Copyright 2002 Sun Microsystems, Inc All Rights Reserved Enterprise Services, Revision A 14-5 Introducing the Name Service Concept Note – You can obtain a list of the full set of maps from an NIS-configured system by running the ypwhich -m command NIS uses domains to define who can access the host names, user information, and other administrative data in its namespace However, NIS does not use a domain hierarchy to store its data; therefore, the NIS namespace is flat You cannot directly connect an NIS domain to the Internet by using just NIS However, organizations that want to use NIS and also want to be connected to the Internet can combine NIS with DNS You can use NIS to manage all local information and use DNS for Internet host lookup NIS provides a forwarding service that forwards host lookups to DNS if the information cannot be found in an NIS map The Solaris OE also allows you to set up the nsswitch.conf file so that lookup requests for hosts: q Go only to DNS q Go to DNS and then to NIS, if the requests are not found by DNS q Go to NIS and then to DNS, if the requests are not found by NIS NIS uses a client-server arrangement similar to DNS Replicated NIS servers provide services to NIS clients The principal server is called a master server, and, for reliability, it has a backup, or a slave server Both master and slave servers use the NIS information retrieval software and both store NIS maps Each server implements NIS by running the ypserv daemon All NIS clients and servers must run the ypbind daemon to exchange NIS information The /etc/rc2.d/S71rpc script starts the NIS processes during the boot process NIS processes are only started if the appropriate configuration conditions are met 14-6 Advanced System Administration for the Solaris™ Operating Environment Copyright 2002 Sun Microsystems, Inc All Rights Reserved Enterprise Services, Revision A Introducing the Name Service Concept Network Information Service Plus (NIS+) Network Information Service Plus (NIS+) is similar to NIS but provides many more features NIS+ is not an extension of NIS NIS+ is a different software program You can configure the NIS+ name service to match the requirements of the organization using it NIS+ enables you to store information about machine addresses, security information, mail information, Ethernet interfaces, and network services in central locations where all machines on a network can have access to the information This configuration of network information is referred to as the NIS+ namespace The NIS+ namespace is hierarchical and is similar in structure to the UNIX directory tree The hierarchical structure allows an NIS+ namespace to be configured to conform to the logical hierarchy of an organization The namespace’s layout of information is unrelated to its physical arrangement Therefore, an NIS+ namespace can be divided into multiple domains that can be administered independently Clients might have access to information in other domains in addition to their own if they have the appropriate permissions NIS+ uses a client-server model to store and gain access to the information contained in an NIS+ namespace Each domain is supported by a set of servers The principal server is called the root server, and the backup servers are called replica servers The network information is stored in standard NIS+ tables in an internal NIS+ database Both root and replica servers run NIS+ server software as well as maintain copies of NIS+ tables Unlike NIS, the NIS+ namespace is dynamic because updates can occur and be put into effect at any time by any authorized user Changes made to the NIS+ data on the root server are automatically and incrementally propagated to the replica servers NIS+ includes a sophisticated security system to protect the structure of the namespace and its information NIS+ uses authentication and authorization to verify whether a client’s request for information should be fulfilled Authentication determines whether the information requester is a valid user on the network Authorization determines whether a particular user is allowed to have or to modify the information requested Each server implements NIS+ by running the rpc.nisd daemon NIS+ clients and servers run the nis_cachemgr daemon to enhance data access performance The /etc/rc2.d/S71rpc script starts the NIS+ name service during the boot process NIS+ processes are only started if the appropriate configuration conditions are met Using Name Services Copyright 2002 Sun Microsystems, Inc All Rights Reserved Enterprise Services, Revision A 14-7 Introducing the Name Service Concept Lightweight Directory Access Protocol (LDAP) The Solaris™ Operating Environment (Solaris OE) supports Lightweight Directory Access Protocol (LDAP) with the iPlanet™ Directory Server 5.1, as well as other LDAP directory servers Services supported by LDAP include application servers, calendar servers, and messaging servers LDAP is the emerging industry standard protocol for accessing directory servers LDAP is a lightweight protocol that uses a simplified set of system-independent encoding methods and runs directly on top of Transmission Control Protocol/Internet Protocol (TCP/IP) LDAP directories provide a way to name, manage, and access collections of directory entries A directory entry is composed of attributes that have a type and one or more values The syntax for each attribute defines the allowed values, or the allowed data type of the attribute values, such as American Standard Code for Information Interchange (ASCII) characters or a numerical data LDAP also defines how those values are interpreted during a directory operation; for example, determining if a search or compare is case sensitive Directory entries are organized into a tree structure, which can be based on boundaries defined by geography (country), organization (company), or domain components (dc) Entries are named according to their position in this tree structure by a distinguished name (DN) Each component of the DN is called a relative distinguished name (RDN) An RDN is composed of one or more attributes from the entry The hierarchy of the directory tree structure is similar to that of the UNIX file system An RDN is similar to the relative path name of a file, and the DN is similar to the absolute path name As in the UNIX file system, sibling directory entries must have unique RDNs However, in the directory tree, each entry can contain content or attributes Like the DNS namespace, LDAP names start with the least significant component and proceed to the most significant; in other words, those just below root The DN is constructed by concatenating the sequence of RDNs up to the root of the tree 14-8 Advanced System Administration for the Solaris™ Operating Environment Copyright 2002 Sun Microsystems, Inc All Rights Reserved Enterprise Services, Revision A Introducing the Name Service Concept Figure 14-4 shows an example of a Solaris LDAP Directory Information Tree Directory Root dc=suned, dc=com ou = People ou = Hosts cn = John Jones cn = mailserver ou = Services cn = telnet DN = "cn = John Jones, ou = People, dc = suned, dc = com" Figure 14-4 Solaris LDAP Directory Information Tree The iPlanet Directory Server 5.1 must be set up and then configured to support Solaris LDAP clients On a configured LDAP server, the /etc/rc2.d/S72directory script starts the iPlanet Directory Server during the boot process Using Name Services Copyright 2002 Sun Microsystems, Inc All Rights Reserved Enterprise Services, Revision A 14-9 Introducing the Name Service Concept Name Service Features Summary Table 14-1 lists and compares the name services available in the Solaris OE Table 14-1 Name Service Features Feature DNS NIS NIS+ LDAP Namespace Hierarchical Flat Hierarchical Hierarchical Data storage Files/resource records Two column maps Multicolumn tables Directories (varied) Server types Master/ slave/ caching only/ forwarding Master/ slave Root master/ non-root master/ replica Master/ consumer Transport TCP/IP TCP/IP TCP/IP TCP/IP Scale Wide area network (WAN) Local area network (LAN) LAN WAN 14-10 Advanced System Administration for the Solaris™ Operating Environment Copyright 2002 Sun Microsystems, Inc All Rights Reserved Enterprise Services, Revision A Introducing the Name Service Switch File Introducing the Name Service Switch File The name service switch file determines which name services a system uses to search for information, and in which order the name services are searched All Solaris OE systems use the /etc/nsswitch.conf file as the name service switch file The nsswitch.conf file is loaded with the contents of a template file during the installation of the Solaris OE, depending on the name service that is selected, as shown in Table 14-2 Table 14-2 Name Service Template Files Name Service Name Service Template Local files /etc/nsswitch.files DNS /etc/nsswitch.dns NIS /etc/nsswitch.nis NIS+ /etc/nsswitch.nisplus LDAP /etc/nsswitch.ldap Note – If you select the default name service during installation of the Solaris OE, the /etc/nsswitch.nisplus template configures the name service for NIS+ The following example is the /etc/nsswitch.conf file configured to support the NIS name service using the /etc/nsswitch.nis template # # # # # # # # /etc/nsswitch.nis: An example file that could be copied over to /etc/nsswitch.conf; it uses NIS (YP) in conjunction with files "hosts:" and "services:" in this file are used only if the /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports # the following two lines obviate the "+" entry in /etc/passwd and /etc/group passwd: files nis group: files nis # consult /etc "files" only if nis is down Using Name Services Copyright 2002 Sun Microsystems, Inc All Rights Reserved Enterprise Services, Revision A 14-11 Introducing the Name Service Switch File hosts: nis [NOTFOUND=return] files ipnodes: files # Uncomment the following line and comment out the above to resolve # both IPv4 and IPv6 addresses from the ipnodes databases Note that # IPv4 addresses are searched in all of the ipnodes databases before # searching the hosts databases Before turning this option on, consult # the Network Administration Guide for more details on using IPv6 #ipnodes: nis [NOTFOUND=return] files networks: protocols: rpc: ethers: netmasks: bootparams: publickey: nis nis nis nis nis nis nis [NOTFOUND=return] [NOTFOUND=return] [NOTFOUND=return] [NOTFOUND=return] [NOTFOUND=return] [NOTFOUND=return] [NOTFOUND=return] netgroup: nis automount: aliases: files files files files files files files files nis files nis # for efficient getservbyname() avoid nis services: files nis sendmailvars: files printers: user files nis auth_attr: prof_attr: project: files nis files nis files nis The /etc/nsswitch.conf file includes a list of databases that are sources of information about IP addresses, users, and groups Data for these can come from a variety of sources For example, host names and host addresses, are located in the /etc/hosts file, NIS, NIS+, LDAP, or DNS Each database has zero or more sources; the sources and their lookup order are specified in the /etc/nsswitch.conf file 14-12 Advanced System Administration for the Solaris™ Operating Environment Copyright 2002 Sun Microsystems, Inc All Rights Reserved Enterprise Services, Revision A Introducing the Name Service Switch File Database Sources There is an entry in the /etc/nsswitch.conf file for each database Some typical examples of these entries are: q ipnodes: files q passwd: files nis q hosts: nis [NOTFOUND=return] files The information sources are listed in the order that they are searched, and these sources are defined in Table 14-3 Table 14-3 Information Sources Information Sources Description files Specifies that entries be obtained from a file stored in the client’s /etc directory For example, /etc/hosts nisplus Specifies that entries be obtained from an NIS+ table For example, the hosts table nis Specifies that entries be obtained from an NIS map For example, the hosts map dns Specifies that host information be obtained from DNS ldap Specifies that entries be obtained from the LDAP directory user Specifies that printer information be obtained from the ${HOME}/.printers file There might be a single information source listed, in which case the search terminates if the information is not found If two or more sources are listed, the first listed source is searched before moving on to the next listed source The relationships between these name service keywords, when found in the nsswitch.conf file, is further explained in Table 14-4 on page 14-14 and Table 14-5 on page 14-15 Using Name Services Copyright 2002 Sun Microsystems, Inc All Rights Reserved Enterprise Services, Revision A 14-13 Introducing the Name Service Switch File Status Codes When multiple information sources are specified, it is sometimes necessary to define precisely the circumstances under which each source is searched When a name service is referenced, the attempt to search this source can return one of the following status codes, as shown in Table 14-4 Table 14-4 Status Message Codes Status Message SUCCESS The requested entry was found in the specified source UNAVAIL The source is not configured on this system and cannot be used In other words, the NIS or NIS+ processes could not be found or contacted NOTFOUND The source responded with No such entry In other words, the table, map, or file was accessed, but it did not contain the needed information TRYAGAIN 14-14 Meaning of Message The source is busy It might respond if tried again In other words, the name service is running and was contacted but could not service the request at that moment Advanced System Administration for the Solaris™ Operating Environment Copyright 2002 Sun Microsystems, Inc All Rights Reserved Enterprise Services, Revision A ... of the /etc/hosts/ file Example A /etc/hosts: 1 92 .9. 20 0.1 host1 loghost 1 92 .9. 20 0 .2 host2 Example B /etc/hosts: 1 92 .9. 20 0.1 host1 1 92 .9. 20 0 .2 host2 loghost When the syslogd daemon starts at system... ncard.service.payflex.PayFlexServiceFactory PayFlex.ATR = 3B 690 0005 7 92 020 101000100A9 3B 691 10000005 7 92 02 0101000100 3B 690 00 02 494 010301000100A9 OpenCard.terminals = com.sun.opencard.terminal.scm.SCMStc.SCMStcCa... 1 92 .9. 20 0.1 on Port 45800 Table 13-3 lists each field in this figure and its corresponding result  ! " # $ Jun 14 13:15: 39 host1 inetd [23 59] :[ID 3 170 13 daemon.notice] telnet [23 61] from 1 92 .9. 20 0.1